身邊很多朋友都在使用得到 app， 但是對於背後的技術團隊大家可能還瞭解不多， 能簡單介紹一下你們技術團隊嗎？作為得到的首席架構師， 您的日常主要職責是什麼？
方圓：得到的技術團隊主要包括前端（Web， iOS， Android）， 得到後端， 商城團隊， 基礎服務團隊， 大資料團隊和運維團隊。
我的工作主要是帶領得到後端團隊負責得到 app 後端研發。 其中包括業務系統功能日常研發， 還有內部使用的服務框架和工具的研發。
您在 2017 年 12 月的 GIAC 大會擔當了中介軟體專題的出品人， 能否給廣大讀者介紹一下什麼是中介軟體？對於一個架構師，
方圓：中介軟體是非業務的技術組件。 個人以為廣義上來說， 除作業系統之外， 其他都是中介軟體。 當然一般意義上來說， 中介軟體主要是消息中介軟體， 框架， 配置服務， 緩存等等。
中介軟體對於應用系統來說最重要的價值是， 減少應用系統控制邏輯的複雜性從而讓工程師儘量多的關注應用的業務邏輯， 舉例來說比如服務框架可以降低我們拆分服務的複雜度， 類似 DRDS 這樣的框架可以讓程式師儘量少的關心分庫分表， 通過消息中介軟體可以對一些應用系統解耦。
而對於工程師來說， 學習中介軟體可以迅速提高自己的抽象能力和代碼能力， 最好是能夠在熟悉之後， 嘗試自己實現一個小的 demo 從而加深理解。
大部分團隊在項目中採用開源的中介軟體， 也有一些團隊比較青睞自研， 對於引入和自研中介軟體有什麼建議？
方圓：在業務初期試錯階段， 建議採用成熟的開源的中介軟體， 這樣避免踩坑， 也能夠加快開發進度， 但在中介軟體的選型上要根據自己團隊的熟悉程度來確定， 不能盲目跟風， 降低團隊整體的學習成本。
而業務發展穩定階段， 可以根據自己的業務特性來自研， 同時也要考慮公司的資源投入情況， 以及相容主流的資料格式或者通訊協定。 自研的週期一般較長， 需要拆解成階段性目標， 這樣利於落地， 同時也要兼顧舊系統， 充分考慮將來上線資料移轉， 業務平滑過渡。
阿裡在 2017 年重新成立了 Dubbo 開發團隊，
方圓：參會人員對於 Dubbo 的關注點主要在以下兩點：第一， 阿裡對於 Dubbo 的支持到底如何？第二， 協力廠商團隊如何給 Dubbo 貢獻代碼？
阿裡這次重拾 Dubbo， 官方很有信心讓 Dubbo 成為 Apache 項目， 前段時間也看到 Dubbo 3.0 的消息， 新的 Dubbo 內核與 Dubbo 2.0 完全不同， 但它相容 2.0。 Dubbo 3.0 將以 Streaming 為內核， 而不再是 2.0 時代的 RPC， 但是 RPC 會在 3.0 中變成遠端 Streaming 對接的一種可選形態。 具體的變化還需要等 Dubbo 新版本 release。
Kafka 最近幾年在大資料領域得到了廣泛應用， 能介紹下 Kafka 領域發展的一些動態嗎？相比於前幾年， Kafka 的使用場景和關注點是否發生了一些變化？
方圓：近幾年 Kafka 關鍵版本升級：
0.8 支援副本模式， 增強容災能力
0.9 增加了 groupcoordinator， 徹底解決 partition 和 consume 的動態調
0.10 支援流處理功能， 同時將 consume 的 offset 移到默認 topic 裡
1.0.0 stream 能力增強
2017 年 8 月 5 日 Kafka 發佈 0.11 版本支援 exactly-once， 增強了交易處理能力
2017 年 8 月 LinkedIn 開源 Kafka Cruise Control， 提供自動化運維功能
2017 年 8 月 28 日 Confluent 宣佈開源 KSQL， 用於 Kafka 的流資料 SQL 引擎
2017 年 11 月 3 日 Kafka 宣佈 1.0.0 發佈
Kafka 使用場景最大的變化：最早大家主要用 Kafka 做些日誌處理系統， 後來主要應用在訊息佇列系統， 近兩年隨著 Kafka stream 方面處理能力增強， 逐漸轉變成羽量級的流處理平臺。
另外 LinkedIn 團隊最近也在 Kafka 自動化運維方面作出了很多工作， 本次大會來自 LinkedIn 團隊的秦江傑介紹了他們實現的自動化運維工具 Cruise Control， 之前也看到高可用架構有文章介紹該工具。
去哪兒的余昭輝老師在 GIAC 大會上分享了訊息佇列（MQ）的主題， 能給大家簡短介紹下他的分享主題？對於使用 MQ 的場景有哪些啟發？
方圓：去哪兒的 MQ 分享的內容對落地分散式事務來說很有説明。 講師的分享主要分兩個部分， 一個是分散式事務的簡單模型， 另一個是因為需要支援分散式事務， 去哪兒自研中介軟體都做了哪些優化， 並且還跟流行的消息中介軟體做了對比（比如 Kafka 和 rocketmq）。 對於我們公司來說， 正好也要落地分散式事務， 跟講師交流了不少細節， 避免我們踩坑。
讓我們把話題再轉回到你們團隊， 得到最近的跨年演講受到了廣泛關注， 為了應對這次跨年， 你們做了哪些準備？
方圓：我們從 2017 年 10 月份正式開始準備， 實際上最早的準備工作從 9 月就開始。 工作主要集中在以下幾個方面：
業務架構梳理我們梳理出了很多潛在的問題， 比如早期的系統裡有很多雙向調用，也有很多隨意使用資源，還有很多引起讀放大或者寫放大的代碼，還有很多不合理的調用關係棧，對業務系統有個比較清晰的架構。同時也在調用鏈路上發現一些問題。
服務/資源拆分早期主要業務系統是一個整體式架構，核心業務調用鏈上只使用了一個資料庫，緩存使用也是集中在幾個主要的緩存集群中，因此我們做了很多資源和服務拆分，分散壓力
重要服務代碼重構相應的主要業務模組拆分成單獨服務，做好對資源的抽象，為了應對較大的壓力，我們實現了一個簡單的多級緩存框架，所有代碼重構項目都使用了這個多級緩存框架，保證業務系統的處理能力
壓力測試壓力測試分兩部分，一部分是功能上線前由開發工程師進行相應的壓力測試，如果有問題通過 Go 語言相應工具進行分析，提高到一定標準後才能上線發佈。另一部分是由阿裡雲 PTS 團隊提供的全鏈路壓力測試，我們在 3 個月時間內進行了 18 輪全鏈路壓力測試，覆蓋到得到主要介面（接近 200 個介面，覆蓋率接近 50%）。通過單個服務的壓力測試，我們解決了單個服務的性能問題，通過全鏈路壓力測試，我們解決了調用鏈路引起的問題。經過 18 輪壓力測試後，系統負載能力提升 25 倍以上，為跨年作好準備。
API 閘道即使我們做了前面所述的業務拆分，服務拆分和重構，我們也不能保證系統 100% 不出問題，特別是那些沒重構的系統。畢竟系統的負載能力取決於最短板。我們解決這個問題的方法是引入 API 閘道。我們在 9 月份的時候，引入 API 閘道，跨年前對一些可能出問題的介面做了對應的限流策略。
提問：據瞭解得到在跨年前夕做了重要的重構，簡單介紹下這次重構的背景及成效嗎？
方圓：重構背景其實也比較簡單，去年 8 月 31 日，得到第二次產品發佈會在深圳衛視和多個視頻網站播出，帶來的流量是平時早晚高峰的 4 倍左右，導致一次大故障。因此從 9 月份開始，我們集中一部分開發力量重構了 10 多個重要的業務模組。在重構的過程中，主要考慮以下幾點來優化性能問題：
嚴格控制資源（資料庫，緩存）使用早期服務對資源使用很隨意，有很多引起讀/寫放大的代碼，因此新系統嚴格控制對資源的使用
保證非核心業務資料可以自動降級對非核心業務進行自動調用降級，但是因為我們使用 Go 語言的原因，尚未做熔斷機制，這也是我們 18 年確定的落地目標之一。
提問：得到在跨年活動期間，應對情況怎樣？有沒有一些意料之外的問題，當時怎麼應對的？
方圓：跨年活動期間，狀況基本在意料之中，核心系統最高峰時期的流量也只是我們準備的 1/8 上下，因此核心系統壓力不大。誇張一點講，核心系統可以應付 8 個羅胖一起跨年而沒有太大壓力。但是一些遺留系統依然有很大壓力。比如我們有一個遺留系統，在流量高峰時期資料庫壓力很大，當時我們通過監控系統發現該系統有很大壓力，迅速通過閘道對該系統的 API 進行限流，保證該系統不會宕機。
提問：通過這次跨年活動，團隊想必有很多收穫，能介紹一下這次應對的一些經驗？
方圓：個人總結下來，以下三點是比較重要的：
全鏈路壓力測試得到後端的服務化剛開始做，還沒有 tracing 系統。雖然我們可以保證單個系統的處理能力，但是當多個系統組合起來的時候，系統的整體表現就難以把握了。阿裡 PTS 幫助我們發現了很多調用鏈路上的問題，每次壓測都能發現一些新問題，壓測後迅速解決，因此可以看到我們每次壓測的系統負載能力都有很大提高。
API 閘道如上所述，使用 API 閘道對 API 進行限流，保證即使有問題的情況下，保護後端系統，以讓部分使用者可以正常訪問。
核心業務鏈路重構對於有坑的老系統來說，一定不能手軟。進行代碼重構可以一方面提升系統處理能力，另一方面也保證後續功能開發可以輕裝上陣。
作為一個首席架構師，請問您每天還寫代碼嗎？如果有的話，您的代碼主要是在哪個領域，對團隊有哪些貢獻？您覺得首席架構師對團隊的價值主要提現在哪些方面？
方圓：我不是每天都會寫代碼，但是還是堅持定期有代碼產出。我的代碼主要集中在一些公有庫/框架/工具上，因為這些代碼對於整個團隊的開發效率和代碼品質很關鍵。
舉個例子來說，我們有個服務上線前進行了壓測，發現單台機器最主要的介面 QPS 只有 300 多，通過火焰圖發現問題之後，對公有庫進行了少量代碼改造，一天之後再次進行壓測單台機器 QPS 就可以到 12000 左右，並且由於是在公有代碼庫方面的改動，其他使用該庫的業務模組也都獲得了數倍性能提升。
我個人認為首席架構師應該有以下幾方面的工作：
公司架構團隊的管理工作；
技術方向的確定，架構分析，設計和部分實現；
公司技術平臺和業務線之間的相互促進；
業務架構和實現的把控。
很多團隊的架構師並不帶人，因此不能直接要求工程師按照自己的想法去執行，這種情況下，架構師如何更好提現自己價值？而避免僅僅成為 CTO 或者技術總監下面一個執行者？
方圓：我個人認為如果架構師不能帶人的情況下，是很難影響工程師的執行方案的。工程師在執行的時候，可能會有各種因素影響他選擇執行方案，架構師只是其中之一。另外大家在不同的位置，不同的時候，不同的背景，對一個技術問題的看法，對一個技術方案的選型，都可能有不同的看法，本身也是很正常的事情，架構師具體要靠什麼方式來落地也很難有固定的模式。
舉例來說，我剛到公司的時候就在強調讀寫放大的問題，但是沒有人當回事，各種原因都有，大部分人都覺得功能開發太緊了，顧不上，直到我負責得到後端的具體工作，才能強制大家落地解決。最終大家發現其實不會增加多少工作，就可以讓系統處理能力提升一個數量級，在後續的工作中，不需要再進行強調，大家也會這麼做。
我個人認為架構師和 CTO 及技術總監的角色還是不同的，CTO 以及技術總監管理的身份更重一些，而架構師更多是一個技術身份。對於 CTO 以及技術總監，他們需要放手讓架構師去做設計和實現，對於架構師，除了做好架構工作之外，也需要輔助 CTO 技術總監，做一些管理工作。
小編：感謝方圓的訪談，大家對於得到架構以及中介軟體技術方面任何問題，歡迎通過留言與方圓進一步討論。在 1月 20 日 24 點之前，本文留言點贊最高的 5 個用戶，贈送得到體驗卡一張。
比如早期的系統裡有很多雙向調用，也有很多隨意使用資源，還有很多引起讀放大或者寫放大的代碼，還有很多不合理的調用關係棧，對業務系統有個比較清晰的架構。同時也在調用鏈路上發現一些問題。服務/資源拆分早期主要業務系統是一個整體式架構，核心業務調用鏈上只使用了一個資料庫，緩存使用也是集中在幾個主要的緩存集群中，因此我們做了很多資源和服務拆分，分散壓力
重要服務代碼重構相應的主要業務模組拆分成單獨服務，做好對資源的抽象，為了應對較大的壓力，我們實現了一個簡單的多級緩存框架，所有代碼重構項目都使用了這個多級緩存框架，保證業務系統的處理能力
壓力測試壓力測試分兩部分，一部分是功能上線前由開發工程師進行相應的壓力測試，如果有問題通過 Go 語言相應工具進行分析，提高到一定標準後才能上線發佈。另一部分是由阿裡雲 PTS 團隊提供的全鏈路壓力測試，我們在 3 個月時間內進行了 18 輪全鏈路壓力測試，覆蓋到得到主要介面（接近 200 個介面，覆蓋率接近 50%）。通過單個服務的壓力測試，我們解決了單個服務的性能問題，通過全鏈路壓力測試，我們解決了調用鏈路引起的問題。經過 18 輪壓力測試後，系統負載能力提升 25 倍以上，為跨年作好準備。
API 閘道即使我們做了前面所述的業務拆分，服務拆分和重構，我們也不能保證系統 100% 不出問題，特別是那些沒重構的系統。畢竟系統的負載能力取決於最短板。我們解決這個問題的方法是引入 API 閘道。我們在 9 月份的時候，引入 API 閘道，跨年前對一些可能出問題的介面做了對應的限流策略。
提問：據瞭解得到在跨年前夕做了重要的重構，簡單介紹下這次重構的背景及成效嗎？
方圓：重構背景其實也比較簡單，去年 8 月 31 日，得到第二次產品發佈會在深圳衛視和多個視頻網站播出，帶來的流量是平時早晚高峰的 4 倍左右，導致一次大故障。因此從 9 月份開始，我們集中一部分開發力量重構了 10 多個重要的業務模組。在重構的過程中，主要考慮以下幾點來優化性能問題：
嚴格控制資源（資料庫，緩存）使用早期服務對資源使用很隨意，有很多引起讀/寫放大的代碼，因此新系統嚴格控制對資源的使用
保證非核心業務資料可以自動降級對非核心業務進行自動調用降級，但是因為我們使用 Go 語言的原因，尚未做熔斷機制，這也是我們 18 年確定的落地目標之一。
提問：得到在跨年活動期間，應對情況怎樣？有沒有一些意料之外的問題，當時怎麼應對的？
方圓：跨年活動期間，狀況基本在意料之中，核心系統最高峰時期的流量也只是我們準備的 1/8 上下，因此核心系統壓力不大。誇張一點講，核心系統可以應付 8 個羅胖一起跨年而沒有太大壓力。但是一些遺留系統依然有很大壓力。比如我們有一個遺留系統，在流量高峰時期資料庫壓力很大，當時我們通過監控系統發現該系統有很大壓力，迅速通過閘道對該系統的 API 進行限流，保證該系統不會宕機。
提問：通過這次跨年活動，團隊想必有很多收穫，能介紹一下這次應對的一些經驗？
方圓：個人總結下來，以下三點是比較重要的：
全鏈路壓力測試得到後端的服務化剛開始做，還沒有 tracing 系統。雖然我們可以保證單個系統的處理能力，但是當多個系統組合起來的時候，系統的整體表現就難以把握了。阿裡 PTS 幫助我們發現了很多調用鏈路上的問題，每次壓測都能發現一些新問題，壓測後迅速解決，因此可以看到我們每次壓測的系統負載能力都有很大提高。
API 閘道如上所述，使用 API 閘道對 API 進行限流，保證即使有問題的情況下，保護後端系統，以讓部分使用者可以正常訪問。
核心業務鏈路重構對於有坑的老系統來說，一定不能手軟。進行代碼重構可以一方面提升系統處理能力，另一方面也保證後續功能開發可以輕裝上陣。
作為一個首席架構師，請問您每天還寫代碼嗎？如果有的話，您的代碼主要是在哪個領域，對團隊有哪些貢獻？您覺得首席架構師對團隊的價值主要提現在哪些方面？
方圓：我不是每天都會寫代碼，但是還是堅持定期有代碼產出。我的代碼主要集中在一些公有庫/框架/工具上，因為這些代碼對於整個團隊的開發效率和代碼品質很關鍵。
舉個例子來說，我們有個服務上線前進行了壓測，發現單台機器最主要的介面 QPS 只有 300 多，通過火焰圖發現問題之後，對公有庫進行了少量代碼改造，一天之後再次進行壓測單台機器 QPS 就可以到 12000 左右，並且由於是在公有代碼庫方面的改動，其他使用該庫的業務模組也都獲得了數倍性能提升。
我個人認為首席架構師應該有以下幾方面的工作：
公司架構團隊的管理工作；
技術方向的確定，架構分析，設計和部分實現；
公司技術平臺和業務線之間的相互促進；
業務架構和實現的把控。
很多團隊的架構師並不帶人，因此不能直接要求工程師按照自己的想法去執行，這種情況下，架構師如何更好提現自己價值？而避免僅僅成為 CTO 或者技術總監下面一個執行者？
方圓：我個人認為如果架構師不能帶人的情況下，是很難影響工程師的執行方案的。工程師在執行的時候，可能會有各種因素影響他選擇執行方案，架構師只是其中之一。另外大家在不同的位置，不同的時候，不同的背景，對一個技術問題的看法，對一個技術方案的選型，都可能有不同的看法，本身也是很正常的事情，架構師具體要靠什麼方式來落地也很難有固定的模式。
舉例來說，我剛到公司的時候就在強調讀寫放大的問題，但是沒有人當回事，各種原因都有，大部分人都覺得功能開發太緊了，顧不上，直到我負責得到後端的具體工作，才能強制大家落地解決。最終大家發現其實不會增加多少工作，就可以讓系統處理能力提升一個數量級，在後續的工作中，不需要再進行強調，大家也會這麼做。
我個人認為架構師和 CTO 及技術總監的角色還是不同的，CTO 以及技術總監管理的身份更重一些，而架構師更多是一個技術身份。對於 CTO 以及技術總監，他們需要放手讓架構師去做設計和實現，對於架構師，除了做好架構工作之外，也需要輔助 CTO 技術總監，做一些管理工作。
小編：感謝方圓的訪談，大家對於得到架構以及中介軟體技術方面任何問題，歡迎通過留言與方圓進一步討論。在 1月 20 日 24 點之前，本文留言點贊最高的 5 個用戶，贈送得到體驗卡一張。