作者 | 李林鋒

成都創(chuàng)新互聯(lián)專注于企業(yè)營銷型網(wǎng)站、網(wǎng)站重做改版、康保網(wǎng)站定制設(shè)計、自適應品牌網(wǎng)站建設(shè)、H5響應式網(wǎng)站、商城開發(fā)、集團公司官網(wǎng)建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應式網(wǎng)頁設(shè)計等建站業(yè)務，價格優(yōu)惠性價比高，為康保等各大城市提供網(wǎng)站開發(fā)制作服務。

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

引言——背景

對于一些復雜的業(yè)務系統(tǒng)(例如CRM)進行服務化改造，涉及到多個業(yè)務團隊的配合和協(xié)調(diào)，加上業(yè)務本身的復雜度，對已有的系統(tǒng)進行微服務化重構(gòu)是個極具挑戰(zhàn)的任務...

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

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

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

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

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

經(jīng)驗總結(jié)
明確目標，敢于舍棄

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

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

頂層架構(gòu)設(shè)計僅僅存在于架構(gòu)師的腦海和架構(gòu)設(shè)計文檔中，設(shè)計理念和關(guān)鍵架構(gòu)屬性，底層的開發(fā)人員并不完全理解，架構(gòu)落地時存在較大偏差。

2、大兵團作戰(zhàn)，各自為戰(zhàn)：

大規(guī)模業(yè)務團隊拆分成很多小的微服務團隊之后，需要互相協(xié)作和配合，在架構(gòu)設(shè)計原則的理解和遵循上存在較大偏差，各自為戰(zhàn)。

經(jīng)驗總結(jié)
統(tǒng)一認識，組織賦能

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

教訓
1、過于關(guān)注運行態(tài)服務框架，而忽略其它質(zhì)量屬性：

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

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

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

經(jīng)驗總結(jié)
分析全面，語言中立

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

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

a) 初期經(jīng)驗不足：服務提供者過分專注于微服務的內(nèi)部實現(xiàn)，而不是優(yōu)先設(shè)計微服務的API提供契約化的接口給消費者。

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

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

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

經(jīng)驗總結(jié)
推行API First設(shè)計理念

01 消費者參與：

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

02 全在線：

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

跨團隊協(xié)作——接口兼容性問題

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

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

2、完全基于管理手段：

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

經(jīng)驗總結(jié)
技術(shù)保障、管理協(xié)同

01

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

02

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

03

持續(xù)交付流水線的每日構(gòu)建和契約化驅(qū)動測試，能夠快速識別和發(fā)現(xiàn)不兼容。

微服務實施——不是所有業(yè)務都一刀切

教訓
1、研發(fā)階段：

為了技術(shù)架構(gòu)的統(tǒng)一，不考慮業(yè)務之間的差異性，不同業(yè)務的痛點差異，全部一刀切的進行微服務化改造。

2、上線階段：

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

經(jīng)驗總結(jié)
循序漸進、穩(wěn)扎穩(wěn)打

01 先外圍，后中心：

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

02 麻雀雖小五臟俱全：

在微服務化早期實踐中，除了開發(fā)工具和運行框架，需要把微服務持續(xù)交付流水線、微服務治理框架、調(diào)用鏈分析等配套設(shè)施全部構(gòu)建起來。

03 逐步上線和上量：

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

不可忽視的技術(shù)細節(jié)——微服務編排

教訓
1、編排框架混亂：

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

2、微服務編排層：

頂層缺乏統(tǒng)一的設(shè)計和策略，導致各業(yè)務模塊實現(xiàn)五花八門。有的在后臺能力中心層、有的在中臺、有的在API Gateway、有的在客戶端。

經(jīng)驗總結(jié)
輕量級微服務編排層

01

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

02

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

不可忽視的技術(shù)細節(jié)——分布式事務

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

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

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

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

經(jīng)驗總結(jié)
以用戶體驗為本，兼顧時效性與成本

01

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

02

強一致性，TCC方案。

不可忽視的技術(shù)細節(jié)——API開放和集成

教訓
1、內(nèi)部的實現(xiàn)細節(jié)開放給前端/第三方：

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

2、為了后端數(shù)據(jù)結(jié)構(gòu)重用，開放冗余的字段：

有時候為了重用內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，把整個對象都開放出去，事實上消費者只需要使用其中的幾個字段，導致接口易用性變差。

3、缺乏統(tǒng)一的 API Gateway：

沒有統(tǒng)一的API入口和精準的流量管控手段。

經(jīng)驗總結(jié)
基于API Gateway，提升開放API的易用性

不可忽視的技術(shù)細節(jié)——熔斷和降級

教訓
1、閉門造車，技術(shù)五花八門：

沒有構(gòu)建統(tǒng)一的微服務可靠性框架、故障注入框架等，不同的業(yè)務團隊各自為戰(zhàn)。經(jīng)驗豐富的團隊，可靠性做的較好，技能較差的團隊，缺乏有效的可靠性保障。

2、重復研發(fā)，資源浪費：

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

經(jīng)驗總結(jié)
集成業(yè)界成熟技術(shù)，統(tǒng)一構(gòu)建可靠性和故障注入框架

對第三方依賴進行分類、分組管理，根據(jù)依賴的特點設(shè)置熔斷策略、優(yōu)雅降級策略、超時策略等，以實現(xiàn)差異化的處理。

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

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

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

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

不可忽視的技術(shù)細節(jié)——微服務是否必須獨立部署

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

上千個微服務，上百個節(jié)點集群組網(wǎng)，微服務進程數(shù)膨脹到數(shù)十萬，周邊配套設(shè)施無法承受（例如網(wǎng)管OSS）。

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

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

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

01

可以進程內(nèi)合設(shè)的微服務

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

b) 業(yè)務強相關(guān)的一組微服務，為了便于統(tǒng)一管理。

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

02

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

不可忽視的技術(shù)細節(jié)——告警泛濫，坐臥不安

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

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

經(jīng)驗總結(jié)
動態(tài)構(gòu)造告警樹，自動抑制重復告警

01 原理

結(jié)合分布式調(diào)用鏈跟蹤功能，在運行態(tài)將微服務調(diào)用關(guān)系動態(tài)刻畫出來，然后構(gòu)造告警樹，每次葉子節(jié)點發(fā)生異常需要告警時，需要沿著樹干層層下鉆，對告警進行關(guān)聯(lián)，尋找告警的Root節(jié)點，如果能夠匹配上，則說明已經(jīng)由根節(jié)點做了告警，葉子節(jié)點放棄告警，防止重復告警。

平臺和業(yè)務關(guān)系——并非甲方和乙方

教訓
1、以甲乙方來處理微服務平臺和業(yè)務的關(guān)系：

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

經(jīng)驗總結(jié)
敢于和善于拒絕不合理需求

01 平臺方：

a) 合理溝通，據(jù)理力爭。

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

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

02 業(yè)務方：

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

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

關(guān)注微服務技術(shù)，關(guān)注云原生，就在“微服務蜂巢”公眾號

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

本文題目：大規(guī)模微服務實戰(zhàn)經(jīng)驗-創(chuàng)新互聯(lián)
網(wǎng)頁URL：http://www.rwnh.cn/article36/ccsgsg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、電子商務、App開發(fā)、營銷型網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、服務器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)