知識星球導讀：最近幾年，知識付費型產品紛紛登上舞臺，大家可能瞭解過最近的羅輯思維的跨年活動，或者也用過得到 app 來進行新知識學習。對於得到這樣的產品，背後的技術挑戰及經驗外界瞭解不太多，恰逢羅輯思維首席架構師方圓作為中介軟體論壇的出品人參加 2017 年 12 月的 GIAC 大會，高可用架構對其進行了採訪。
方圓，羅輯思維首席架構師，曾先後在 Cisco，新浪微博從事基礎架構研發工作。十多年一直專註於後端技術的研發，在訊息通訊，分散式儲存等方向有著豐富的經驗。個人技術興趣廣泛，主要專註 Go/Java/Python 等程式語言的發展，尤其是在雲端計算等前沿領域的應用。
身邊很多朋友都在使用得到 app，但是對於背後的技術團隊大家可能還瞭解不多，能簡單介紹一下你們技術團隊嗎？作為得到的首席架構師，您的日常主要職責是什麼？
方圓：得到的技術團隊主要包括前端（Web，iOS，Android），得到後端，商城團隊，基礎服務團隊，大資料團隊和運維團隊。
我的工作主要是帶領得到後端團隊負責得到 app 後端研發。其中包括業務系統功能日常研發，還有內部使用的服務框架和工具的研發。
您在 2017 年 12 月的 GIAC 大會擔當了中介軟體專題的出品人，能否給廣大讀者介紹一下什麼是中介軟體？對於一個架構師，如何看待中介軟體的價值？
方圓：中介軟體是非業務的技術元件。個人以為廣義上來說，除作業系統之外，其他都是中介軟體。當然一般意義上來說，中介軟體主要是訊息中介軟體，框架，配置服務，快取等等。
中介軟體對於應用系統來說最重要的價值是，減少應用系統控制邏輯的複雜性從而讓工程師儘量多的關註應用的業務邏輯，舉例來說比如服務框架可以降低我們拆分服務的複雜度，類似 DRDS 這樣的框架可以讓程式員儘量少的關心分庫分表，透過訊息中介軟體可以對一些應用系統解耦。
而對於工程師來說，學習中介軟體可以迅速提高自己的抽象能力和程式碼能力，最好是能夠在熟悉之後，嘗試自己實現一個小的 demo 從而加深理解。
大部分團隊在專案中採用開源的中介軟體，也有一些團隊比較青睞自研，對於引入和自研中介軟體有什麼建議？
方圓：在業務初期試錯階段，建議採用成熟的開源的中介軟體，這樣避免踩坑，也能夠加快開發進度，但在中介軟體的選型上要根據自己團隊的熟悉程度來確定，不能盲目跟風，降低團隊整體的學習成本。
而業務發展穩定階段，可以根據自己的業務特性來自研，同時也要考慮公司的資源投入情況，以及相容主流的資料格式或者通訊協議。自研的週期一般較長，需要拆解成階段性標的，這樣利於落地，同時也要兼顧舊系統，充分考慮將來上線資料遷移，業務平滑過渡。
阿裡在 2017 年重新成立了 Dubbo 開發團隊，本次 GIAC 中介軟體專題也有相關的分享，從大會現場的瞭解的情況來看，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 年確定的落地標的之一。
-
保證核心鏈路穩定 對於跨年的核心鏈路來說，比如收聽，購買，拉新，兌換，我們保證核心鏈路不被非核心鏈路影響。
-
對寫入進行削峰處理和非同步化 對於購買流程來說，我們部分做了非同步化，對於非購買相關的業務流程，我們透過 MQ 進行了削峰和處理。效果還是很明顯，削峰和合併寫入之後，相關資料庫 IOPS 降低一個數量級。
提問：得到在跨年活動期間，應對情況怎樣？有沒有一些意料之外的問題，當時怎麼應對的？
方圓：跨年活動期間，狀況基本在意料之中，核心系統最高峰時期的流量也只是我們準備的 1/8 上下，因此核心系統壓力不大。誇張一點講，核心系統可以應付 8 個羅胖一起跨年而沒有太大壓力。但是一些遺留系統依然有很大壓力。比如我們有一個遺留系統，在流量高峰時期資料庫壓力很大，當時我們透過監控系統發現該系統有很大壓力，迅速透過閘道器對該系統的 API 進行限流，保證該系統不會宕機。
提問：透過這次跨年活動，團隊想必有很多收穫，能介紹一下這次應對的一些經驗？
方圓：個人總結下來，以下三點是比較重要的：
-
全鏈路壓力測試 得到後端的服務化剛開始做，還沒有 tracing 系統。雖然我們可以保證單個系統的處理能力，但是當多個系統組合起來的時候，系統的整體表現就難以把握了。阿裡 PTS 幫助我們發現了很多呼叫鏈路上的問題，每次壓測都能發現一些新問題，壓測後迅速解決，因此可以看到我們每次壓測的系統負載能力都有很大提高。
-
API 閘道器 如上所述，使用 API 閘道器對 API 進行限流，保證即使有問題的情況下，保護後端系統，以讓部分使用者可以正常訪問。
-
核心業務鏈路重構 對於有坑的老系統來說，一定不能手軟。進行程式碼重構可以一方面提升系統處理能力，另一方面也保證後續功能開發可以輕裝上陣。
作為一個首席架構師，請問您每天還寫程式碼嗎？如果有的話，您的程式碼主要是在哪個領域，對團隊有哪些貢獻？您覺得首席架構師對團隊的價值主要提現在哪些方面？
方圓：我不是每天都會寫程式碼，但是還是堅持定期有程式碼產出。我的程式碼主要集中在一些公有庫/框架/工具上，因為這些程式碼對於整個團隊的開發效率和程式碼質量很關鍵。
舉個例子來說，我們有個服務上線前進行了壓測，發現單臺機器最主要的介面 QPS 只有 300 多，透過火焰圖發現問題之後，對公有庫進行了少量程式碼改造，一天之後再次進行壓測單臺機器 QPS 就可以到 12000 左右，並且由於是在公有程式碼庫方面的改動，其他使用該庫的業務模組也都獲得了數倍效能提升。
我個人認為首席架構師應該有以下幾方面的工作：
-
公司架構團隊的管理工作；
-
技術方向的確定，架構分析，設計和部分實現；
-
公司技術平臺和業務線之間的相互促進；
-
業務架構和實現的把控。
很多團隊的架構師並不帶人，因此不能直接要求工程師按照自己的想法去執行，這種情況下，架構師如何更好提現自己價值？而避免僅僅成為 CTO 或者技術總監下麵一個執行者？
方圓：我個人認為如果架構師不能帶人的情況下，是很難影響工程師的執行方案的。工程師在執行的時候，可能會有各種因素影響他選擇執行方案，架構師只是其中之一。另外大家在不同的位置，不同的時候，不同的背景，對一個技術問題的看法，對一個技術方案的選型，都可能有不同的看法，本身也是很正常的事情，架構師具體要靠什麼方式來落地也很難有固定的樣式。
舉例來說，我剛到公司的時候就在強調讀寫放大的問題，但是沒有人當回事，各種原因都有，大部分人都覺得功能開發太緊了，顧不上，直到我負責得到後端的具體工作，才能強制大家落地解決。最終大家發現其實不會增加多少工作，就可以讓系統處理能力提升一個數量級，在後續的工作中，不需要再進行強調，大家也會這麼做。
我個人認為架構師和 CTO 及技術總監的角色還是不同的，CTO 以及技術總監管理的身份更重一些，而架構師更多是一個技術身份。對於 CTO 以及技術總監，他們需要放手讓架構師去做設計和實現，對於架構師，除了做好架構工作之外，也需要輔助 CTO 技術總監，做一些管理工作。
小編：感謝方圓的訪談，大家對於得到架構以及中介軟體技術方面任何問題，歡迎透過留言與方圓進一步討論。在 1月 20 日 24 點之前，本文留言點贊最高的 5 個使用者，贈送得到體驗卡一張。
推薦閱讀
高可用架構
改變網際網路的構建方式
長按二維碼 關註「高可用架構」公眾號
