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

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

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

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

圍繞這七個階段總結(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è)計系統(tǒng)的組織，其產(chǎn)生的設(shè)計和架構(gòu)等價于組織間的溝通結(jié)構(gòu)。)

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

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

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

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

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

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

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

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

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

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

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

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

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

那么就很有價值獨立為一個微服務(wù)，實現(xiàn)獨立演進、個性化的彈性伸縮。

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

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

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

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

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

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

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

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

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

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

依賴這個「狀態(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)的計算類服務(wù)，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。

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

只有服務(wù)無狀態(tài)，才能實現(xiàn)快速彈性擴縮容，應(yīng)對流量峰谷。

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

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

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

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

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

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

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

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

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

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

原則11：異步解耦。

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

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

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

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

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

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

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

六、微服務(wù)治理

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

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

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

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

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

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

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

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

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

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

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

七、微服務(wù)下線

原則16：對于「廢棄服務(wù)」，需要做好「下線」工作，包括服務(wù)下線、存儲釋放等。

清理無效代碼、環(huán)境，減少維護成本。同時釋放資源，節(jié)約成本。

八、總結(jié)

架構(gòu)師在進行微服務(wù)設(shè)計和微服務(wù)治理時，可以圍繞微服務(wù)生命周期的七個階段展開。

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