大規模微服務實戰經驗

作者 | 李林鋒

《Netty 進階之路》、《分布式服務框架原理與實踐》作者李林鋒分享大規模業務團隊實施微服務的經驗和教訓。

引言——背景

對于一些復雜的業務系統(例如CRM)進行服務化改造，涉及到多個業務團隊的配合和協調，加上業務本身的復雜度，對已有的系統進行微服務化重構是個極具挑戰的任務...

實施前的準備工作——目標要清晰，處理好“舍與得”

教訓
1、微服務化目標不清晰：

各業務模塊處在不同技術階段，有單體應用、RPC架構、SOA服務等，業務痛點不同。沒有明確各業務的微服務化目標：是提升開發效率、縮短新業務上線周期，還是單純的追求技術先進性。

2、沒有處理好“舍與得”：

微服務不是銀彈，看著美好，但是要在大規模團隊和電信復雜業務系統中實施，一定要處理好舍與得。例如分布式帶來的時延增加、可靠性降低。

經驗總結
明確目標，敢于舍棄

實施前的準備工作——微服務不僅僅是架構師的愿景

教訓
1、愿景美好，但落地變形：

頂層架構設計僅僅存在于架構師的腦海和架構設計文檔中，設計理念和關鍵架構屬性，底層的開發人員并不完全理解，架構落地時存在較大偏差。

2、大兵團作戰，各自為戰：

大規模業務團隊拆分成很多小的微服務團隊之后，需要互相協作和配合，在架構設計原則的理解和遵循上存在較大偏差，各自為戰。

經驗總結
統一認識，組織賦能

實施前的準備工作——技術選型要全面

教訓
1、過于關注運行態服務框架，而忽略其它質量屬性：

在選型時，過于關注微服務框架的性能指標、功能豐富性，以及對業務的侵入程度，而忽略了服務運維和治理。

2、忽略微服務語言中立原則：

業務模塊多，場景復雜。大部分業務采用Java開發，但是對于計費、批價等性能要求苛刻的業務仍然需要繼續使用C（C++）、GO等語言，服務框架不支持異構語言，跨語言調用存在問題。

經驗總結
分析全面，語言中立

跨團隊協作——接口依賴和進度協同問題多

教訓
1、無法及時提供接口API，影響其它團隊開發進度：

a) 初期經驗不足：服務提供者過分專注于微服務的內部實現，而不是優先設計微服務的API提供契約化的接口給消費者。

b) 后期項目規則制約：限制迭代微服務接口變更次數。 提供者擔心接口會經常性的變更和重構，遲遲不提供接口契約。

2、無有效的變更通知機制：

微服務接口契約文檔離線管理，變更之后無有效通知機制。

經驗總結
推行API First設計理念

01 消費者參與：

推行API First的設計理念，讓微服務提供者從消費者的角度，與消費者一起設計API，同時把API通過在線的方式發布和管控起來。

02 全在線：

基于swagger，可以通過YAML或者JSON的方式設計API、在線發布API。

跨團隊協作——接口兼容性問題

教訓
1、微服務版本管控意識不強，隨意變更：

隨意刪除、修改接口字段，導致其它團隊CI構建失敗，測試用例通過率低。

2、完全基于管理手段：

通過管理條例等約束接口變更，但是缺乏統一的技術保障手段。例如新增字段、刪除字段，不同語言、不同團隊怎么保證實施的一致性。

經驗總結
技術保障、管理協同

01

制定并嚴格執行《微服務接口兼容性規范》，避免發生不兼容修改或者私自修改不通知周邊的情況。

02

接口兼容性技術保障：例如Thrift的IDL，支持新增、修改和刪除字段，字段定義位置無關性，碼流支持亂序等。通過URL中攜帶V1/V2等主版本號，實現灰度路由。

03

持續交付流水線的每日構建和契約化驅動測試，能夠快速識別和發現不兼容。

微服務實施——不是所有業務都一刀切

教訓
1、研發階段：

為了技術架構的統一，不考慮業務之間的差異性，不同業務的痛點差異，全部一刀切的進行微服務化改造。

2、上線階段：

一次性全量上線，所有微服務化改造的業務同時進行升級，沒有觀察期和緩沖期。

經驗總結
循序漸進、穩扎穩打

01 先外圍，后中心：

先找一些相對成熟，非核心模塊的業務做微服務改造，在這個過程中不斷積累經驗，為后續核心模塊的微服務化做準備。

02 麻雀雖小五臟俱全：

在微服務化早期實踐中，除了開發工具和運行框架，需要把微服務持續交付流水線、微服務治理框架、調用鏈分析等配套設施全部構建起來。

03 逐步上線和上量：

上線時，可以采用灰度路由等方式，逐步把流量切換到新的微服務系統中來。

不可忽視的技術細節——微服務編排

教訓
1、編排框架混亂：

硬編碼/BPMN流程引擎、腳本（Groovy、JS）編排引擎等，缺乏統一的輕量級微服務編排引擎（PVM）。

2、微服務編排層：

頂層缺乏統一的設計和策略，導致各業務模塊實現五花八門。有的在后臺能力中心層、有的在中臺、有的在API Gateway、有的在客戶端。

經驗總結
輕量級微服務編排層

01

按需選擇輕量級的微服務編排引擎（PVM）， 傳統的BPMN在微服務時代模型較重、依賴較多。

02

微服務的編排適合單獨獨立出來（中臺），保障后臺微服務的原子性、穩定性，同時又能夠滿足前臺、移動端各種個性化需求。

不可忽視的技術細節——分布式事務

教訓
1、分布式事務選型：

業務補償、事務強一致性（TCC框架）或者基于消息的最終一致性方案，平臺和業務之間、不同業務團隊之間沒有達成一致性方案，影響事務一致性。

2、習慣思維，強一致性事務占比過高：

單體應用都是本地事務，強一致性容易保障。服務化之后，沒有基于業務場景深入分析，習慣性的采用強一致性方案，業務成本很高。

經驗總結
以用戶體驗為本，兼顧時效性與成本

01

最終一致性，采用基于消息中間件的事務方案。

02

強一致性，TCC方案。

不可忽視的技術細節——API開放和集成

教訓
1、內部的實現細節開放給前端/第三方：

包括但不限于特定語言的實現細節，例如異常類、繼承和重載、抽象接口等。

2、為了后端數據結構重用，開放冗余的字段：

有時候為了重用內部的數據結構，把整個對象都開放出去，事實上消費者只需要使用其中的幾個字段，導致接口易用性變差。

3、缺乏統一的 API Gateway：

沒有統一的API入口和精準的流量管控手段。

經驗總結
基于API Gateway，提升開放API的易用性

不可忽視的技術細節——熔斷和降級

教訓
1、閉門造車，技術五花八門：

沒有構建統一的微服務可靠性框架、故障注入框架等，不同的業務團隊各自為戰。經驗豐富的團隊，可靠性做的較好，技能較差的團隊，缺乏有效的可靠性保障。

2、重復研發，資源浪費：

業務場景不同，可靠性訴求大同小異。異步數據庫訪問、異步I/O操作、微服務故障隔離等能力，被不同團隊重復構建。

經驗總結
集成業界成熟技術，統一構建可靠性和故障注入框架

對第三方依賴進行分類、分組管理，根據依賴的特點設置熔斷策略、優雅降級策略、超時策略等，以實現差異化的處理。

體系化的故障場景梳理——微服務故障隔離全景圖

教訓
1、沒有體系化的梳理微服務故障場景。

2、沒有自動化的微服務故障注入和模擬工具，微服務可靠性測試場景覆蓋不足，問題遺留到線上。

經驗總結
體系化的故障場景分析、自動化故障注入和故障隔離措施，提升微服務的可靠性

不可忽視的技術細節——微服務是否必須獨立部署

教訓
1、機械照搬微服務原則，所有微服務都獨立部署：

上千個微服務，上百個節點集群組網，微服務進程數膨脹到數十萬，周邊配套設施無法承受（例如網管OSS）。

2、為了簡化部署和管理，微服務全部合設在同一個進程：

喪失升級靈活性、無法按需伸縮、故障隔離差、異構語言無法合設在一起等缺點。

經驗總結
按照微服務的拆分粒度、微服務規模、以及運維團隊能夠接受的維護成本來決定微服務的部署策略

01

可以進程內合設的微服務

a) 性能、時延要求苛刻，需要本地短路的微服務可以合設。

b) 業務強相關的一組微服務，為了便于統一管理。

c) 暫時不支持分布式事務，需要本地事務保障強一致性的相關微服務（非長久之計）。

02

拆分粒度較粗的微服務、功能獨立和內聚，建議獨立部署。

不可忽視的技術細節——告警泛濫，坐臥不安

教訓
1、告警漫天飛，心驚肉跳：

微服務化之后，本地的方法調用變成了遠程的微服務調用，一個業務流程的多個微服務會有多個開發者負責。告警也由本地集中式演變成了分散的分布式告警，如果仍然沿用之前的告警方式，就會發現告警滿天飛，而且大部分告警都是重復無效的告警。

經驗總結
動態構造告警樹，自動抑制重復告警

01 原理

結合分布式調用鏈跟蹤功能，在運行態將微服務調用關系動態刻畫出來，然后構造告警樹，每次葉子節點發生異常需要告警時，需要沿著樹干層層下鉆，對告警進行關聯，尋找告警的Root節點，如果能夠匹配上，則說明已經由根節點做了告警，葉子節點放棄告警，防止重復告警。

平臺和業務關系——并非甲方和乙方

教訓
1、以甲乙方來處理微服務平臺和業務的關系：

大規模業務團隊，服務化需求五花八門，平臺方需要識別高優先級、通用的需求，大部分個性化的需求需要開放給業務團隊實現，或者規劃到后續版本。如果業務方只從本團隊利益出發，不顧全大局，很容易壓垮平臺，最終交付質量無法保障。

經驗總結
敢于和善于拒絕不合理需求

01 平臺方：

a) 合理溝通，據理力爭。

b) 深刻理解業務場景，抓主要矛盾和矛盾的主要方面。

c) 敢于承擔責任，敢于對不合理需求說“不”。

02 業務方：

a) 不斷提升微服務實踐經驗，能夠分辨哪些是平臺需求，哪些是業務需求。

b) 與平臺建立互信、合作共贏的新型關系。

關注微服務技術，關注云原生，就在“微服務蜂巢”公眾號