涵蓋整個(gè)生命周期，微服務(wù)設(shè)計(jì)與治理的16條常用原則

作者：阿丸筆記 2022-10-11 09:07:02

開發(fā) 新聞

本文總結(jié)了16條常用原則，希望能提供一些思路和啟發(fā)。

今天將從存儲(chǔ)的上一層「服務(wù)維度」學(xué)習(xí)架構(gòu)師的第二項(xiàng)常用能力——微服務(wù)設(shè)計(jì)與治理。

如何設(shè)計(jì)合理的微服務(wù)架構(gòu)？
如何保持微服務(wù)健康運(yùn)行？

這是我們對(duì)微服務(wù)進(jìn)行架構(gòu)設(shè)計(jì)過程中非常關(guān)注的兩個(gè)問題。

本文對(duì)微服務(wù)的生命周期定義了七個(gè)階段，如下圖所示。

圍繞這七個(gè)階段總結(jié)了16條常用原則。

一、微服務(wù)規(guī)劃

原則1：按照業(yè)務(wù)能力（business capabilities）來規(guī)劃或拆微服務(wù)。

康威定律：Conway’s law: Organizations which design systems[…] are constrained to produce designs which are copies of the communication structures of these organizations.

（設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)和架構(gòu)等價(jià)于組織間的溝通結(jié)構(gòu)。)

組織的溝通和系統(tǒng)的設(shè)計(jì)之間緊密相連，特別是復(fù)雜系統(tǒng)，解決好人與人的溝通才能有一個(gè)更好的系統(tǒng)設(shè)計(jì)。

《人月神話》中總結(jié)出了隨著人員的增加溝通成本呈指數(shù)增長(zhǎng)的規(guī)律：溝通成本 = n(n-1)/2。舉例說明：

5人項(xiàng)目組，需要溝通的渠道是 5*(5–1)/2 = 10
15人項(xiàng)目組，需要溝通的渠道是15*(15–1)/2 = 105
50人項(xiàng)目組，需要溝通的渠道是50*(50–1)/2 = 1225

系統(tǒng)越復(fù)雜，人手越多，溝通成本也呈指數(shù)增長(zhǎng)。因此，分而治之便是大多數(shù)公司選擇的解決方案。分不同的層級(jí)，分不同的小團(tuán)隊(duì)，讓團(tuán)隊(duì)內(nèi)部完成自治理。

原則2: 按照領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design，DDD）來規(guī)劃或拆解微服務(wù)。

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)是微服務(wù)領(lǐng)域的熱門話題，本文不展開說明，僅說明幾點(diǎn)重要事項(xiàng)：

基本過程：抽象業(yè)務(wù)、分析流程、識(shí)別邊界、建立模型、映射到服務(wù)和代碼
避免過度耦合、存在貧血領(lǐng)域?qū)ο蟮惹闆r。
劃分界限上下文，厘清上下文之間的映射關(guān)系，比如合作關(guān)系、共享內(nèi)核、客戶方-供應(yīng)方開發(fā)、防腐層、開放主機(jī)服務(wù)等等。
細(xì)化上下文對(duì)象，區(qū)分實(shí)體、值對(duì)象、聚合根、領(lǐng)域服務(wù)、領(lǐng)域事件。

原則2與原則1的區(qū)別在于，原則1關(guān)注組織架構(gòu)領(lǐng)域，原則2更偏向軟件工程設(shè)計(jì)領(lǐng)域。

二、微服務(wù)設(shè)計(jì)

原則3：微服務(wù)的設(shè)計(jì)應(yīng)該遵循「單一職責(zé)」原則。

所謂單一職責(zé)原則，就是對(duì)一個(gè)服務(wù)而言，它的功能要單一，只做與它相關(guān)的事情。在微服務(wù)的設(shè)計(jì)過程中要按職責(zé)進(jìn)行設(shè)計(jì)，彼此保持正交，互不干涉。

什么樣的單一領(lǐng)域?qū)ο蟮膯我宦氊?zé)微服務(wù)才是有價(jià)值的？就是不斷有業(yè)務(wù)變化，能夠維持業(yè)務(wù)持久性，有業(yè)務(wù)生命力的領(lǐng)域?qū)ο蟆Ｅe例來說：

與別的功能點(diǎn)相比，調(diào)用頻率非常高
或者其數(shù)據(jù)量存量大，數(shù)據(jù)增速快，TB級(jí)甚至是PB級(jí)的

那么就很有價(jià)值獨(dú)立為一個(gè)微服務(wù)，實(shí)現(xiàn)獨(dú)立演進(jìn)、個(gè)性化的彈性伸縮。

所以，我們?cè)谶M(jìn)行微服務(wù)設(shè)計(jì)時(shí)，要能夠分析、預(yù)測(cè)出需求變化的點(diǎn)在哪里？高并發(fā)的點(diǎn)在哪些？數(shù)據(jù)增長(zhǎng)的位置在哪里？與DDD分析相結(jié)合，找出最有價(jià)值的那個(gè)單一職責(zé)，進(jìn)行合理、適度的領(lǐng)域、子領(lǐng)域、有界上下文分解，才能更好的應(yīng)對(duì)復(fù)雜的業(yè)務(wù)、不斷變化的業(yè)務(wù)。

原則4: 微服務(wù)的設(shè)計(jì)應(yīng)該遵循「高內(nèi)聚」原則。

過度追求「單一職責(zé)」，或者拆分微服務(wù)過細(xì)，往往會(huì)帶來不良后果。微服務(wù)的設(shè)計(jì)并不是越細(xì)越好，過度拆分會(huì)導(dǎo)致調(diào)用性能變差、數(shù)據(jù)一致性難以保障、系統(tǒng)可用性降低等問題。

因此，「高內(nèi)聚」原則要求：

完全獨(dú)立：微服務(wù)粒度的下界是它至少應(yīng)滿足獨(dú)立，能夠獨(dú)立發(fā)布、獨(dú)立部署、獨(dú)立運(yùn)行與獨(dú)立測(cè)試。
足夠內(nèi)聚：強(qiáng)相關(guān)的功能與數(shù)據(jù)在同一個(gè)服務(wù)中處理。
足夠完備：一個(gè)服務(wù)包含至少一項(xiàng)業(yè)務(wù)實(shí)體與對(duì)應(yīng)的完整操作。

原則5：微服務(wù)的設(shè)計(jì)應(yīng)該遵循「低耦合」原則。

避免數(shù)據(jù)過度暴露
避免數(shù)據(jù)庫(kù)共享
最小化同步調(diào)用，如有必要，引入事件驅(qū)動(dòng)進(jìn)行異步調(diào)用

三、微服務(wù)實(shí)現(xiàn)

原則6：服務(wù)無狀態(tài)。

什么是「狀態(tài)」？如果一個(gè)數(shù)據(jù)需要被多個(gè)服務(wù)共享，才能完成一筆交易，那么這個(gè)數(shù)據(jù)被稱為狀態(tài)。

依賴這個(gè)「狀態(tài)」數(shù)據(jù)的服務(wù)被稱為有狀態(tài)服務(wù)，反之稱為無狀態(tài)服務(wù)。

「無狀態(tài)」原則并不是說在微服務(wù)架構(gòu)里就不允許存在狀態(tài)，而是要把有狀態(tài)的業(yè)務(wù)服務(wù)改變?yōu)闊o狀態(tài)的計(jì)算類服務(wù)，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對(duì)應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。

場(chǎng)景說明：例如我們以前在本地內(nèi)存中建立的數(shù)據(jù)緩存、Session緩存，到現(xiàn)在的微服務(wù)架構(gòu)中就應(yīng)該把這些數(shù)據(jù)遷移到分布式緩存中存儲(chǔ)，讓業(yè)務(wù)服務(wù)變成一個(gè)無狀態(tài)的計(jì)算節(jié)點(diǎn)。遷移后，就可以做到按需動(dòng)態(tài)伸縮，微服務(wù)應(yīng)用在運(yùn)行時(shí)動(dòng)態(tài)增刪節(jié)點(diǎn)，就不再需要考慮緩存數(shù)據(jù)如何同步的問題。

只有服務(wù)無狀態(tài)，才能實(shí)現(xiàn)快速?gòu)椥詳U(kuò)縮容，應(yīng)對(duì)流量峰谷。

原則7：服務(wù)高可用。

接入高可用中間件（如sentinal)，實(shí)現(xiàn)限流、熔斷、降級(jí)，增強(qiáng)可用性。

原則8：服務(wù)可觀測(cè)。

除了默認(rèn)系統(tǒng)監(jiān)控外，微服務(wù)需要梳理并定義必要的「業(yè)務(wù)監(jiān)控指標(biāo)」。

原則9：服務(wù)配置可管理。

微服務(wù)相關(guān)配置需要統(tǒng)一接入配置中心進(jìn)行管理、控制。

四、微服務(wù)調(diào)用

原則10：避免「分布式大單體」。

只做單向調(diào)用，避免循環(huán)調(diào)用。

多個(gè)服務(wù)循環(huán)依賴調(diào)用形成集中式“分布式大單體”，違背微服務(wù)的原則。

原則11：異步解耦。

按需接入消息隊(duì)列，實(shí)現(xiàn)「依賴解耦」、「流量削峰」

串行同步調(diào)用異步化，提高響應(yīng)能力和響應(yīng)速度
應(yīng)對(duì)突發(fā)流量，實(shí)現(xiàn)流量削峰與流量控制
解耦核心業(yè)務(wù)邏輯不必要的依賴
業(yè)務(wù)設(shè)計(jì)中的最終一致性

原則12：引入BFF層，降低客戶端與后端微服務(wù)之間的耦合。

盡量設(shè)計(jì)BFF層，把前端的特殊需求交給BFF層，使后端服務(wù)邏輯具有高內(nèi)聚、高復(fù)用性的精簡(jiǎn)核心邏輯。

五、微服務(wù)發(fā)布

原則13：服務(wù)發(fā)布遵循安全發(fā)布三板斧。

保證「可灰度」、「可監(jiān)控」、「可回滾」。

六、微服務(wù)治理

原則14：正視「架構(gòu)腐化」，遵循「持續(xù)演進(jìn)」原則。

「架構(gòu)腐化」的常見場(chǎng)景：

多人維護(hù)一個(gè)微服務(wù)，出現(xiàn)「頻繁代碼沖突」，影響快速迭代，那么這個(gè)微服務(wù)就需要拆分了。
當(dāng)你修改了一個(gè)邊角的小功能，但是你不敢馬上上線，因?yàn)槟阋蕾嚨钠渌K才開發(fā)了一半，出現(xiàn)大量「功能耦合」，那么這個(gè)微服務(wù)就需要拆分了。
當(dāng)你發(fā)現(xiàn)微服務(wù)A內(nèi)聚合a的功能變成了海量高頻業(yè)務(wù)。這時(shí)聚合a就會(huì)拖累整個(gè)微服務(wù)A，并且因?yàn)榫酆蟖面臨性能瓶頸，在微服務(wù)A進(jìn)行彈性擴(kuò)縮時(shí)，也會(huì)造成資源浪費(fèi)。這時(shí)，我們就可以將聚合a從微服務(wù)A中整體拆分，獨(dú)立為一個(gè)新微服務(wù)B。在資源配置方面也可以更加有針對(duì)性的投入到微服務(wù)B，可以隨時(shí)滿足高頻訪問的性能要求了。
當(dāng)你發(fā)現(xiàn)在領(lǐng)域建模時(shí)錯(cuò)誤地將聚合d放到了微服務(wù)C里，或者隨著業(yè)務(wù)發(fā)展聚合d更適合放在微服務(wù)D里。由于領(lǐng)域模型的不合適，可能會(huì)導(dǎo)致微服務(wù)之間出現(xiàn)頻繁調(diào)用，進(jìn)而導(dǎo)致微服務(wù)之間出現(xiàn)「緊耦合關(guān)系」。這時(shí)，我們就可以對(duì)領(lǐng)域模型做出調(diào)整，將聚合d從微服務(wù)C整體遷移到微服務(wù)D里。

原則15：參考「AKF擴(kuò)展立方」模型，服務(wù)除了「水平擴(kuò)容」外，還可以考慮「功能拆分」或者「數(shù)據(jù)分區(qū)」。

1）X軸：服務(wù)和數(shù)據(jù)的水平擴(kuò)容

「水平擴(kuò)容」比較容易理解，直白點(diǎn)說就是加機(jī)器。根據(jù)AKF模型，除了加機(jī)器外，我們還可以考慮「功能拆分」或者「數(shù)據(jù)分區(qū)」。

2）Y軸：功能/業(yè)務(wù)拆分

「功能拆分」相對(duì)復(fù)雜，一般包括幾種模式：

微服務(wù)拆分。根據(jù)具體業(yè)務(wù)模型、領(lǐng)域模型拆分更細(xì)粒度的微服務(wù)。
業(yè)務(wù)隔離拆分。利用消息隊(duì)列，將在線業(yè)務(wù)（OLTP）和耗費(fèi)大量資源的計(jì)算任務(wù)拆分隔離。
核心與非核心隔離。對(duì)于一個(gè)微服務(wù)，可以將SKA客戶與普通客戶進(jìn)行隔離，SKA客戶使用獨(dú)立的集群資源，提高穩(wěn)定性。

3）Z軸：沿客戶邊界的服務(wù)和數(shù)據(jù)分區(qū)

「數(shù)據(jù)分區(qū)」往往指的是數(shù)據(jù)庫(kù)層面。需要引入數(shù)據(jù)庫(kù)中間件，像 sharding-jdbc、mycat 等，在數(shù)據(jù)層面需要配置相應(yīng)的分片邏輯。正確的拆分對(duì)提高系統(tǒng)的容量有很大的幫助，失敗的拆分可能會(huì)造成熱點(diǎn)集中，得不償失。常用的分區(qū)邏輯包括按照時(shí)間分區(qū)、按照用戶id取模分區(qū)等。