2018-08-16 08:58:20 ServiceComb

2018年6月27日，ApacheServiceComb在北京舉辦主題Workshop，當中，來自華為消費者雲的架構師李林鋒分享了《ServiceComb在華為消費者雲的億級用戶微服務實踐》，以下為演講實錄。

講師介紹

李林鋒，華為消費者雲應用市場微服務架構師，多年平臺中間件、雲平臺、微服務框架設計和開發經驗。工作之餘愛好技術寫作，《Netty權威指南》和《分佈式服務框架原理與實踐》作者

今天分享主要有三個主題，第一個就是服務化的總體的策略，第二個是服務化實踐，最後就是業務微服務化以後得到的收益。先自我介紹下，我最早是做業務的，後來從業務轉到平臺中間件團隊做各種平臺，包括：短信網關平臺、SOA中間件、PaaS平臺等。現在在華為終端消費者雲業務做雲化和微服務化相關架構設計。從業務到平臺再回歸做業務，感覺還是蠻有意思的。

關於華為消費者雲服務

簡單介紹一下華為消費者雲服務，它包括我們經常用到的華為手機應用市場（類似於蘋果的APP store），還有我們的智能助手、雲空間、天際通等。當然還有一些生活服務相關的，例如視頻、音樂、閱讀等，這些都屬於華為消費者雲服務的範疇。我所在的華為應用市場目前是世界第三大應用市場，在全球一百多個國家（支持70多種語言）上線運行。

頂層統一設計

今天分享的服務化策略不僅僅單指華為應用市場，還包括了整個華為消費者雲服務業務的服務化策略。首先我們看一下整個策略，華為消費者雲服務的規模是非常大的，有很多個業務和產品。我們在做服務化設計的時候，最大的一個挑戰就是如果能夠從頂層統一設計。當一個小團隊做服務化的時候，可以採用自底向上的策略。有些技術很強的骨幹做技術選型，然後大家就用起來，反正團隊人少，業務量也不是很大，最終效果可能還不錯。但對華為消費者雲服務來說有非常多的團隊和業務產品線，如果沒有頂層的統一設計，就會造成技術架構選型不一致，這對一個大公司來說成本是非常非常高的。假如要構建一條微服務CI/CD流水線，就要支持所有業務線的所有的異構服務框架，成本很高。因此對於一個體量非常大的業務，一定要有一個頂層的統一設計。我們的技術選型是由架構部跟各個業務產品線設計部一起來完成。

這裡面比較重要的一點就是頂層統一設計的理念要能夠標準化、規範化和工具化，前幾年我們也在電信領域做運營商各個系統服務化時，發現在一個大的業務團隊去做服務化時，有些架構僅僅存在於架構師的腦海裡，下面的整個團隊其實並不瞭解整個服務化的設計理念和思路。這會導致大家認為你是在強推一些東西，或者因為不理解導致實現時走彎路。當大家帶著疑問被動去做服務化時，會造成整個團隊的割裂，服務化的效果也不會很好。所以在我們設計之處，整體由架設體系來牽頭，完成微服務規範的制定、協議選擇、流水線建設，以及微服務治理、上線和驗收標準。

還有一點比較重要的就是組織賦能，因為業務團隊是非常大的，業務線又很多，所以要把我們整個服務化的選型以及架構的設計理念，包括我們整個的開發、測試流程以及一整套的CI/CD流水線都是要向設計、開發、測試還有我們的運維人員去講解。讓大家能夠充分理解頂層設計和架構思路，防止實現時與架構設計不一致。

最後一點就是微服務上線以後，有個服務化地圖，就是從組織架構層次來審視和管理微服務，它會包含微服務的SLA指標、微服務流水線地址、微服務重要的治理參數設置、以及微服務業務模型等，方便從更宏觀的視角來管控上線的微服務。

沒有十全十美的微服務架構，適合的才是最好的

選型其實非常非常重要，很多人向我諮詢微服務框架選型問題，我也看到很多團隊在糾結這個，想選SpringCloud，又感覺gRPC不錯，非常糾結。其實對整個服務化選型而言，最重要一點大家一定要明白，就是沒有十全十美的微服務架構。現在所有開源出來的，不管是哪個廠商或者組織，都會有優缺點和適應場景，所以說大家不要去陷入一種脫離業務的爭論，這種爭論其實也會走偏。對我們而言，選型其實也是非常謹慎的，就個人經驗，在來華為消費者雲服務之前，已經在電信領域做過3到4年的服務化，所以很清楚業務需要什麼樣的服務框架。只有真正的理解業務的需求，才能夠做出好的技術選型。

內外API一致，支持多種服務開發方式

選ServiceComb的一個重要原因就是API的統一和標準化：我們希望微服務內部的API以及對外的（例如對手機端和華為手錶，以及對各種各樣的設備），API保持一致，方便管理。遵循Open API 2.0/3.0規範也就是支持Swagger API規範的Restful API是非常容易管理的，所以我們這次就果斷地選用了Rest API而沒用RPC私有協議承載API。微服務的開發方式問題：我們在做微服務化之前，不同團隊技術堆棧不同，有用Spring MVC的，也有用Spring Cloud的，還會有一些其他的微服務框架（比如透明RPC方式），我們希望微服務框架能支持多種開發方式，降低業務適配和學習成本。

輕量易集成

對於集成，我們傾向於微服務框架支持輕量級的集成。我們現在做微服務化，以重構為主，有一些微服務跑在tomcat容器裡，有一些業務做的不太好，綁定了Web的一些技術，因為改造量工作量比較大，所以這個時候希望微服務框架能集成在tomcat裡面跑。還有一些是純後臺的業務，不想部署在J2EE容器中，可以更加輕量的部署在Docker容器裡面，可能2C4G的資源就能跑起來。 ServiceComb支持vertX的standalone方式（純後臺），還支持跟tomcat這種Web容器集成，正好可以滿足我們的業務場景。

ServiceComb的輕量級主要體現在兩點，第一個就是開發態可以按需引用。假如沒用流控，就不需要引流控handler，業務可以做到ServiceComb的最小化依賴，減小二方庫/三方庫衝突的風險。第二點就是支持standalone模式，不依賴任何Web容器，對於純消費端應用，甚至不需要啟動監聽端口，它的啟停速度非常快，特別適合雲化之後的容器化部署以及彈性伸縮。

API First—“大家只認接口”

我們服務化的一個很重要實踐就是API First的落地。不僅僅使用Swagger在線管理API，還有就是服務端和消費端各自基於API定義生成接口和模型，消費端不導入服務端的接口定義類庫，實現代碼解耦。測試基於API定義生成自動化測試用例（API Test），防止開發人員繞過在線API定義私自修改接口（一旦有不一致修改，接口測試就失敗）。設計、開發和測試都只遵循在線的API接口定義，就防止了接口文檔與代碼、測試用例與代碼之間的不一致。

開發模式的選擇

還有一個就是開發模式，其實開發模式沒有好壞之分，像以前我們在做電信服務化的時候，喜歡用透明RPC，消費端會導入服務端的接口定義類庫。但是現在在消費雲這邊我們用的更多是Spring MVC註解，因為業務團隊用Spring MVC的比較多，ServiceComb對Spring MVC開發模式是天生支持的，因此改造成本非常低。

我們有些團隊以前用的是我們電信軟件做的支持電信級的高性能私有的服務框架DSF，更喜歡透明RPC開發模式。當然JAX-RS風格的接口也有。開發模式沒有優劣，但是有一點需要強調的就是一定要考慮到開發成本，因為對一個重構項目而言，業務需求要做，還要同時做服務化重構，需要考慮各種成本，包括學習成本、代碼重用成本等。

“凡是說性能不重要的都是性能沒做好”

很多時候大家說雲時代或者硬件白菜價的時代，軟件的性能就不重要了。但事實上沒有哪一家的產品不把性能作為微服務框架競爭力的，所以大家不要相信所謂性能不重要之類的言亂。業務當前不需要這麼高的性能並不代表未來也不需要，尤其對於快速發展的互聯網業務，如果選型了一個性能不行的架構，後續橫向擴展成本會非常高。按照經驗，凡是說性能不重要的都是它自身的性能沒做好。衡量性能有三個要素：

1）吞吐量（QPS）

2）時延

3）架構平滑擴展能力。

異步非常重要

關於線程模型，最重要的一點就要支持異步。像gRPC對異步的支持就非常好，它是基於http /2.0 Stream設計的，http/2.0 Stream支持多路複用，加上異步I/O，很容易構建異步RPC。當前大部分的服務框架不支持異步或者對異步支持不夠好，比如有些會返回一個jdk的原生Feature, 很難做比較強大的異步處理。架構原生支持異步是非常重要的。

今年是微服務異步化的元年

以前大家都傾向於先用同步的方式做服務調用，但是上線後發現CPU等資源使用率不高但是性能也上不來，原因是什麼？都是同步阻塞式調用惹的禍。異步改造之後，會把大量的資源節省下來，能把機器的cpu和帶寬壓上去，提升資源的使用率，降低業務的硬件成本。

這裡澄清一個概念，微服務框架的異步跟I/O的異步是沒有任何關係的，舉個例子，Tomcat從5.0以後就支持NIO， Servlet規範從3.0才開始支持異步。在此之前，Tomcat的通信I/O是異步了，但是整個http調用是同步的，原因就是Servlet2.X系列接口本身就是同步的。同步服務調用主要有三大缺點：

1）資源利用率低

2）超時時間比較難設，設置大了容易掛住，設置短了容易超時，比較糾結。

3）雪崩效應，如果你的整個調用鏈上都是同步的，下游節點慢了就阻塞上遊，會導致整個調用線程都被阻塞，形成雪崩。

我們業務的異步並沒有一刀切，因為切異步是有成本的，適合異步的業務才需要切異步。比如說應用分發下載，每天全球有數十億次的下載或者更新，併發量非常大，而且下載經常集中在某個時間段，流量高，針對這種這種場景就可以做異步優化。

適合異步的場景

異步的主要場景有四個：

1）降低長流程/複雜業務流程時延：消費端需要調用多個微服務，進行業務邏輯編排，多個微服務之間沒有執行先後順序和參數依賴，可以並行執行。

2）性能提升，使用更少的線程處理更多的消息，減少線程的等待時間。設別適用於一些時延敏感型業務

3）服務上對服務調用時延不敏感（例如1-3S），如果採用同步調用 + 大超時時間，在業務高峰期，如果時延達到超時閾值，系統很容易被壓掛。（單個線程3S完成一次服務調用）。採用異步，則可以按照業務實際要求設置超時時間，不用擔心線程資源被掛住

4）需要調用多個微服務，希望提升可靠性，不會因為某個微服務處理慢而導致其它微服務調用、以及後續其它業務消息被阻塞，則可以考慮使用異步服務調用

異步的收益與挑戰

業務採用Reactive異步以後帶來的收益還是比較大的，帶著業務實測性能提升40%多，時延降了30%左右，CPU使用率下降56%，綜合性能收益約為2-3倍。業務要做全棧異步實際是非常困難的，會遇到各種挑戰。純Reactive就意味著在整個調用鏈上不能有同步阻塞操作：

1）同步訪問數據庫、redis緩存或者對象存儲服務。

2）同步的磁盤I/O操作

3）調用第三方SDK，SDK提供的是同步訪問接口（例如HttpClient），

4）業務代碼的意外阻塞，例如sleep、wait或者長時間的鎖等待。

第二個難點是異步過程中的上下文的傳遞，因為大家以前同步寫代碼的時候，總是喜歡通過類似ThreadLocal線程變量來傳遞上下文。採用異步之後，只要有線程切換，就要考慮到線程上下文可能會丟失的問題，例如調用鏈的Trace ID。第三個問題就是異常的傳遞，同步調用發生異常可以直接在當前調用線程try catch捕獲並處理異常。但是當異步切到另一個線程發生異常時，異常是很難傳遞到調用方線程的，調用方如何更好的處理異步代碼塊裡面拋出的異常，是個難點。最後一個難點就是異步超時控制機制，線程切換之後，超時控制就非常困難了，很多情況下你無法通過調用方超時去中斷異步線程的執行。

做全棧異步的挑戰還是蠻大的，這個不僅僅是微服務框架本身要支持，而且中間件、第三方調用等都需要支持異步，才能達到較好的預期效果。由於Vert.X提供了一個異步生態系統，包含了各種常用開源中間件的SDK，因此基於ServiceComb的異步微服務框架 + Vert.X的各種異步SDK構建全棧異步系統，相對比較容易一些。

關於回調地獄

由於接口模型的原因，一些異步框架容易出現回調地獄， ServiceComb當前實現的是JDK 8 Complete Feature，它支持異步操作結果可編排、可組合。這個類庫裡面提供60個左右常用的方法，每3個一組，實際20個常用的異步接口，可以指定線程池，活著使用jdk的Fork Join Pool，也可以直接在當前線程執行。它具備類似BPM的一些對異步結果做編排的能力，例如對多個異步操作做Join、或、與等，也支持條件判斷。異步接口的參數大部分是jdk8的function接口，業務可以直接寫Lambda表達式，避免所謂的回調地獄。

接口級隔離艙支持

還有一個故障隔離，以前我們做的，比如說Tomcat、Spring MVC架構。如果用同步SpringMVC它的後臺用的是Tomcat的Work線程，就是應用在server.xml裡面配置的Connector。如果某一個接口或者某個服務慢了以後，它可能會導致整個線程池都被阻塞，這對業務來說是不可接受的。通過ServiceComb的隔離倉技術，可以把快慢不同接口、核心和非核心類接口、管理和租戶面接口區分開進行線程池隔離。通過不同維度的隔離艙來實現當某個接口慢或者出了問題以後，把故障嚴格封閉在某個隔離艙內，防止故障擴散。ServiceComb的隔離倉支持微服務級、接口級和方法級，支持業務自定義隔離線程池，使用起來非常靈活。

微服務治理

基於ServiceComb提供的服務治理功能，業務重點構建如下兩大能力：

1）線上自動化運維：服務狀態檢測、容量管理、基於大數據分析的自適應調優、故障診斷、彈性伸縮、故障自動重啟、在線遷移等

2）微服務的自治理：服務無狀態設計，故障自動切換，Failover失敗自動重試 , 故障隔離、大數據分析自動展示系統關鍵路徑、調用依賴畫圖等

微服務化帶來的收益

以ServiceComb為核心構建的業務微服務體系，本質還是為了提升業務的研發效率。具體提升點如下：

1）上線效率提升：以前業務都是一個大版本（超級war包，也就是所謂的巨無霸的業務），現在拆分成微服務之後各個微服務之間只有API契約依賴，各個微服務獨立發版本，迭代週期更快。例如推薦系統服務化之後，各種推薦算法和策略就可以更快的上線驗證和優化。

2) 全自動化的微服務流水線：基於ServiceComb業務建立了一套涵蓋個人、團隊到項目組級別的微服務流水線。每個開發測試都有一套自己的微服務的流水線，這個是個人級的；我們還有微服務團隊一級的；業務最終要上線，還是要大家的微服務集成在一起，所以還有個整個項目集成級的流水線。利用微服務流水線，從架構師開始設計API接口、到開發態的靜態檢查、編譯再到打包部署、灰度發佈，自動化測試，直到最終微服務上線，全部都是自動化的。

3）精細化運維能力提升：利用微服務調用鏈可以快速的識別業務的關鍵路徑、熱點、故障點以及接口依賴，針對特定的故障場景，可以通過服務治理、彈性伸縮、代碼架構優化等來保障微服務的高質量線上運行，提升運維能力。

以微服務架構為牽引，我們構建了一套適合終端消費者雲業務的微服務化體系和團隊，通過更好的架構來支撐消費者雲業務的全球化發展，為華為終端用戶提供更好的服務和體驗。