?今天將從存儲的上一層「服務維度」學習架構師的第二項常用能力——微服務設計與治理。

• 如何設計合理的微服務架構？
• 如何保持微服務健康運行？

這是我們對微服務進行架構設計過程中非常關注的兩個問題。

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

圍繞這七個階段總結了16條常用原則。

1.微服務規劃

原則1：按照業務能力（business capabilities）來規劃或拆微服務。

康威定律：Conway’s law: Organizations which design systems[…] are constrained to produce designs which are copies of the communication structures of these organizations.（設計系統的組織，其產生的設計和架構等價于組織間的溝通結構。)

組織的溝通和系統的設計之間緊密相連，特別是復雜系統，解決好人與人的溝通才能有一個更好的系統設計。

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

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

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

原則2: 按照領域驅動設計（Domain-Driven Design，DDD）來規劃或拆解微服務。

領域驅動設計是微服務領域的熱門話題，本文不展開說明，僅說明幾點重要事項：

• 基本過程：抽象業務、分析流程、識別邊界、建立模型、映射到服務和代碼
• 避免過度耦合、存在貧血領域對象等情況
• 劃分界限上下文，厘清上下文之間的映射關系，比如合作關系、共享內核、客戶方-供應方開發、防腐層、開放主機服務等等。
• 細化上下文對象，區分實體、值對象、聚合根、領域服務、領域事件

原則2與原則1的區別在于，原則1關注組織架構領域，原則2更偏向軟件工程設計領域。

2.微服務設計

原則3：微服務的設計應該遵循「單一職責」原則

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

什么樣的單一領域對象的單一職責微服務才是有價值的？就是不斷有業務變化，能夠維持業務持久性，有業務生命力的領域對象。舉例來說：

• 與別的功能點相比，調用頻率非常高
• 或者其數據量存量大，數據增速快，TB級甚至是PB級的。

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

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

原則4: 微服務的設計應該遵循「高內聚」原則

過度追求「單一職責」，或者拆分微服務過細，往往會帶來不良后果。微服務的設計并不是越細越好，過度拆分會導致調用性能變差、數據一致性難以保障、系統可用性降低等問題。

因此，「高內聚」原則要求：

• 完全獨立。微服務粒度的下界是它至少應滿足獨立，能夠獨立發布、獨立部署、獨立運行與獨立測試
• 足夠內聚。強相關的功能與數據在同一個服務中處理
• 足夠完備。一個服務包含至少一項業務實體與對應的完整操作

原則5：微服務的設計應該遵循「低耦合」原則

• 避免數據過度暴露
• 避免數據庫共享
• 最小化同步調用，如有必要，引入事件驅動進行異步調用

3.微服務實現

原則6：服務無狀態。

什么是「狀態」？如果一個數據需要被多個服務共享，才能完成一筆交易，那么這個數據被稱為狀態。

依賴這個「狀態」數據的服務被稱為有狀態服務，反之稱為無狀態服務。

「無狀態」原則并不是說在微服務架構里就不允許存在狀態，而是要把有狀態的業務服務改變為無狀態的計算類服務，那么狀態數據也就相應的遷移到對應的“有狀態數據服務”中。

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

只有服務無狀態，才能實現快速彈性擴縮容，應對流量峰谷。

原則7：服務高可用。

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

原則8：服務可觀測。

除了默認系統監控外，微服務需要梳理并定義必要的「業務監控指標」。

原則9：服務配置可管理。

微服務相關配置需要統一接入配置中心進行管理、控制。

4.微服務調用

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

只做單向調用，避免循環調用。

多個服務循環依賴調用形成集中式“分布式大單體”，違背微服務的原則。

原則11：異步解耦。

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

• 串行同步調用異步化，提高響應能力和響應速度
• 應對突發流量，實現流量削峰與流量控制
• 解耦核心業務邏輯不必要的依賴
• 業務設計中的最終一致性

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

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

5.微服務發布

原則13：服務發布遵循安全發布三板斧

保證「可灰度」、「可監控」、「可回滾」。

6.微服務治理

原則14：正視「架構腐化」，遵循「持續演進」原則

「架構腐化」的常見場景：

多人維護一個微服務，出現「頻繁代碼沖突」，影響快速迭代，那么這個微服務就需要拆分了。

當你修改了一個邊角的小功能，但是你不敢馬上上線，因為你依賴的其他模塊才開發了一半，出現大量「功能耦合」，那么這個微服務就需要拆分了。

當你發現微服務A內聚合a的功能變成了海量高頻業務。這時聚合a就會拖累整個微服務A，并且因為聚合a面臨性能瓶頸，在微服務A進行彈性擴縮時，也會造成資源浪費。這時，我們就可以將聚合a從微服務A中整體拆分，獨立為一個新微服務B。在資源配置方面也可以更加有針對性的投入到微服務B，可以隨時滿足高頻訪問的性能要求了。

當你發現在領域建模時錯誤地將聚合d放到了微服務C里，或者隨著業務發展聚合d更適合放在微服務D里。由于領域模型的不合適，可能會導致微服務之間出現頻繁調用，進而導致微服務之間出現「緊耦合關系」。這時，我們就可以對領域模型做出調整，將聚合d從微服務C整體遷移到微服務D里。

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

• X軸：服務和數據的水平擴容。
• Y軸：功能/業務拆分
• Z軸：沿客戶邊界的服務和數據分區

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

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

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

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

7.微服務下線

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

清理無效代碼、環境，減少維護成本。同時釋放資源，節約成本。

8.總結

架構師在進行微服務設計和微服務治理時，可以圍繞微服務生命周期的七個階段展開。

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