上一篇文章我們從「儲存選型」角度學習了架構師的基本能力。
今天將從儲存的上一層「服務維度」學習架構師的第二項常用能力——微服務設計與治理。
- 如何設計合理的微服務架構？
- 如何保持微服務健康執行？
這是我們對微服務進行架構設計過程中非常關注的兩個問題。
本文對微服務的生命週期定義了七個階段，如下圖所示。
圍繞這七個階段總結了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條常用原則，希望能提供一些思路和啟發。
如果你有其他補充和建議，歡迎留言討論。
都看到最後了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜尋「阿丸筆記 」第一時間閱讀，回覆【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回覆【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）