作者 | 李林鋒

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

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

引言——背景

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

實(shí)施前的準(zhǔn)備工作——目標(biāo)要清晰，處理好“舍與得”

教訓(xùn)
1、微服務(wù)化目標(biāo)不清晰：

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

2、沒(méi)有處理好“舍與得”：

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

經(jīng)驗(yàn)總結(jié)
明確目標(biāo)，敢于舍棄

實(shí)施前的準(zhǔn)備工作——微服務(wù)不僅僅是架構(gòu)師的愿景

教訓(xùn)
1、愿景美好，但落地變形：

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

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

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

經(jīng)驗(yàn)總結(jié)
統(tǒng)一認(rèn)識(shí)，組織賦能

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

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

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

2、忽略微服務(wù)語(yǔ)言中立原則：

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

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

跨團(tuán)隊(duì)協(xié)作——接口依賴和進(jìn)度協(xié)同問(wèn)題多

教訓(xùn)
1、無(wú)法及時(shí)提供接口API，影響其它團(tuán)隊(duì)開(kāi)發(fā)進(jìn)度：

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

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

2、無(wú)有效的變更通知機(jī)制：

微服務(wù)接口契約文檔離線管理，變更之后無(wú)有效通知機(jī)制。

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

01 消費(fèi)者參與：

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

02 全在線：

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

跨團(tuán)隊(duì)協(xié)作——接口兼容性問(wèn)題

教訓(xùn)
1、微服務(wù)版本管控意識(shí)不強(qiáng)，隨意變更：

隨意刪除、修改接口字段，導(dǎo)致其它團(tuán)隊(duì)CI構(gòu)建失敗，測(cè)試用例通過(guò)率低。

2、完全基于管理手段：

通過(guò)管理?xiàng)l例等約束接口變更，但是缺乏統(tǒng)一的技術(shù)保障手段。例如新增字段、刪除字段，不同語(yǔ)言、不同團(tuán)隊(duì)怎么保證實(shí)施的一致性。

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

01

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

02

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

03

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

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

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

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

2、上線階段：

一次性全量上線，所有微服務(wù)化改造的業(yè)務(wù)同時(shí)進(jìn)行升級(jí)，沒(méi)有觀察期和緩沖期。

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

01 先外圍，后中心：

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

02 麻雀雖小五臟俱全：

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

03 逐步上線和上量：

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

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

教訓(xùn)
1、編排框架混亂：

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

2、微服務(wù)編排層：

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

經(jīng)驗(yàn)總結(jié)
輕量級(jí)微服務(wù)編排層

01

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

02

微服務(wù)的編排適合單獨(dú)獨(dú)立出來(lái)（中臺(tái)），保障后臺(tái)微服務(wù)的原子性、穩(wěn)定性，同時(shí)又能夠滿足前臺(tái)、移動(dòng)端各種個(gè)性化需求。

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

教訓(xùn)
1、分布式事務(wù)選型：

業(yè)務(wù)補(bǔ)償、事務(wù)強(qiáng)一致性（TCC框架）或者基于消息的最終一致性方案，平臺(tái)和業(yè)務(wù)之間、不同業(yè)務(wù)團(tuán)隊(duì)之間沒(méi)有達(dá)成一致性方案，影響事務(wù)一致性。

2、習(xí)慣思維，強(qiáng)一致性事務(wù)占比過(guò)高：

單體應(yīng)用都是本地事務(wù)，強(qiáng)一致性容易保障。服務(wù)化之后，沒(méi)有基于業(yè)務(wù)場(chǎng)景深入分析，習(xí)慣性的采用強(qiáng)一致性方案，業(yè)務(wù)成本很高。

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

01

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

02

強(qiáng)一致性，TCC方案。

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

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

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

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

有時(shí)候?yàn)榱酥赜脙?nèi)部的數(shù)據(jù)結(jié)構(gòu)，把整個(gè)對(duì)象都開(kāi)放出去，事實(shí)上消費(fèi)者只需要使用其中的幾個(gè)字段，導(dǎo)致接口易用性變差。

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

沒(méi)有統(tǒng)一的API入口和精準(zhǔn)的流量管控手段。

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

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

教訓(xùn)
1、閉門(mén)造車(chē)，技術(shù)五花八門(mén)：

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

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

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

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

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

體系化的故障場(chǎng)景梳理——微服務(wù)故障隔離全景圖

教訓(xùn)
1、沒(méi)有體系化的梳理微服務(wù)故障場(chǎng)景。

2、沒(méi)有自動(dòng)化的微服務(wù)故障注入和模擬工具，微服務(wù)可靠性測(cè)試場(chǎng)景覆蓋不足，問(wèn)題遺留到線上。

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

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

教訓(xùn)
1、機(jī)械照搬微服務(wù)原則，所有微服務(wù)都獨(dú)立部署：

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

2、為了簡(jiǎn)化部署和管理，微服務(wù)全部合設(shè)在同一個(gè)進(jìn)程：

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

經(jīng)驗(yàn)總結(jié)
按照微服務(wù)的拆分粒度、微服務(wù)規(guī)模、以及運(yùn)維團(tuán)隊(duì)能夠接受的維護(hù)成本來(lái)決定微服務(wù)的部署策略

01

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

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

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

c) 暫時(shí)不支持分布式事務(wù)，需要本地事務(wù)保障強(qiáng)一致性的相關(guān)微服務(wù)（非長(zhǎng)久之計(jì)）。

02

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

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

教訓(xùn)
1、告警漫天飛，心驚肉跳：

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

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

01 原理

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

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

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

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

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

01 平臺(tái)方：

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

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

c) 敢于承擔(dān)責(zé)任，敢于對(duì)不合理需求說(shuō)“不”。

02 業(yè)務(wù)方：

a) 不斷提升微服務(wù)實(shí)踐經(jīng)驗(yàn)，能夠分辨哪些是平臺(tái)需求，哪些是業(yè)務(wù)需求。

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

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

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

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

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

廣告

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