微服務架構拆分的 7 大黃金法則

你是否還在為微服務架構的拆分而苦惱？本文揭秘 7 大拆分原則，助你輕松駕馭微服務架構！

隨著云計算的普及，微服務架構成為企業數字化轉型的重要選擇。

然而，如何合理拆分微服務卻成為許多開發者的難題。本文將揭秘 7 大拆分原則，助你輕松駕馭微服務架構，提升系統性能和可維護性。

無論你是架構師還是開發者，這些原則都將為你帶來實實在在的幫助。

今天，碼哥帶大家從不同角度來剖析微服務架構設計的 7 大原則，做到合理且正確地拆分出微服務，避免打造一個被人詬病的偽微服務架構大單體，徒增運維和開發成本。

1.一個反例

這是碼哥親身經歷的一個事情，當時我作為架構師角色將公司原 saas 團隊的供應鏈金融系統重新打造成一個標準化應用，基于插件機制，業務開發只需要專注于功能，實現快速得到一個客戶想要的軟件。

該系統的團隊負責人帶著 IT 人的傲嬌對我說這是一個微服務架構系統……

打開項目代碼發現這是一個披著微服務外衣的大單體巨石服務。

我真是太難了，該團隊的開發人員把這個系統拆分成了八九個‘微’服務，可實際上業務功能系統壓力全集中在 web-service 服務上。

至于拆出來其他的“微”服務，只干了一件事：Myabtis 作為 ORM 框架操作數據庫，我問他們為何這樣拆？

對方的老開發一臉驕傲的說：“這樣可以做到單一職責，解耦……”

單一職責不是這樣理解的，大兄弟。真的是「黛玉騎鬼火，該強的強，該弱的弱」。

鐵觀因：“碼哥，微服務架構設計哪些原則可以指導我們正確的設計？避免設計出「依托答辯」的架構。”

好問題，一共有 7 大原則可以幫助我們設計一個好的微服務架構。

2.單一職責

簡單的就是最好的！

每個微服務都只負責一個單一的業務，并確保做好這個業務，保證微服務職責單一性、功能完整性拆分， 這樣，就便于維護、測試和部署。

另外，每個微服務都有自己的數據庫來存儲數據，避免一個微服務與其他微服務共享數據庫，在數據層解耦，以確保可擴展性和可靠性。

3.基于可靠性拆分

Dora：這個我懂，不能讓一顆老鼠屎搞壞一鍋湯。

你這么理解沒毛病。

在單體應用中，一個組件的故障可能導致整個系統的崩潰。

通過微服務架構，我們可以將系統拆分為多個獨立的服務，從而將故障隔離在單個服務內，避免故障擴散到整個系統。

將可靠性要求高的核心服務和可靠性要求低的非核心服務拆分開來，然后重點保證核心服務的高可用。

當重要策劃高難度較低的服務發生故障時，不會影響核心模塊的服務。

比如將賬號信息、登錄信息、服務中心等重要度最高的要害模塊單獨拆分在一個服務顆粒上（因為這類模塊不可用之后，整個系統基本完全癱瘓），再做成服務集群，來保障它的高可用。

4.DDD 領域驅動原則

微服務架構設計其實非常采用 DDD。因為每個微服務本就可以設計成特定領域的實現。

基于領域模型拆分，圍繞業務領域按職責單一性、功能完整性拆分。

• 戰略設計主要從業務視角出發，建立業務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。
• 戰術設計則從技術視角出發，側重于領域模型的技術實現，完成軟件開發和落地，包括：聚合根、實體、值對象、領域服務、應用服務和資源庫等代碼邏輯的設計和實現。

使用 DDD（領域驅動建模） 進行業務建模，從業務中獲取抽象的模型（例如訂單、用戶），根據模型的關系進行劃分限界上下文。

從 DDD 的限界上下文往微服務轉化，并得到系統架構、API 列表、集成方式等產出。

限界上下文可以視為邏輯上的微服務，或者單體應用中的一個組件。

Dora：“碼哥，如何找到系統的邊界呢？愛情起碼還能根據生理上的喜歡來輔助判斷。”

DDD 邊界上下文可以通過事件風暴來找到，把系統狀態做出改變的事件作為關鍵點，從系統事件的角度觸發，提取能反應系統運作的業務模型。

再進一步識別模型之間的關系，劃分出限界上下文，可以看做邏輯上的微服務。

例如系統管理員可以創建商品、上架商品，對應的系統狀態的改變是商品已創建、商品已經上架；

相應的顧客創建訂單、支付，對應的系統狀態改變是訂單已創建、訂單已支付。

商家發貨：選擇快遞公司、顧客填寫收貨地址……

5.按照業務穩定性原則

這個很容易理解，需要區分系統中變與不變的部分，不變的部分一般是成熟的、通用的服務功能。

變的部分一般是改動比較多的需求、滿足業務迭代擴展性需要的功能，我們可以將不變的部分拆分出來，作為共用的服務，將變的部分獨立出來滿足個性化擴展需要。

根據二八原則，系統中經常變動的部分大約 20%，80% 是很少變動的，這種拆分方式還能避免 80% 那部分服務的頻繁發布。

比如一個電商系統，用戶信息、商品信息等管理模塊一般是比較穩定的；而運營類的活動和頁面是經常變化的。

6.基于吞吐量原則

這是一個拓展原則，是針對特定場景的微服務拆分，簡單的說就是訪問量特別大，訪問頻率特別高的業務，又要保證高效的響應能力，這些業務對性能的要求特別高。

比如積分競拍、低價秒殺、限量搶購。

盡可能把這部分業務拆分出來，既能保證高性能的要求，又能保證業務的獨立性。

如果這種訪問量巨大的業務如果與其他通用業務放一塊，很容易因為某個鏈路阻塞，導致雪崩效應影響其他業務。

7.演進式原則

微服務拆分并不是一步到位的，應當根據實際情況逐步展開。

如果一開始不知道應該劃分多細，完全可以先粗粒度劃分，然后隨著需要，適當將粒度劃分更細拆分。

Chaya：如果拆分粒度太細會增加運維復雜度，粒度過大又起不到效果，那么改造過程中如何平衡拆分粒度呢？

從兩個方面做權衡，一是業務發展的復雜度，二是團隊人員規模。

比如一個電商一開始索性可以拆分為商品服務和交易服務，一個負責展示商品，一個負責購買支付。

隨后隨著交易服務越來越復雜，就可以逐步的拆分成訂單服務和支付服務、庫存服務、價格服務、物流服務等等。

雖然業務復雜度已經滿足了，如果公司此時沒有足夠的人力（招聘不及時或員工異動比較多），服務最好也不要拆分，拆分會因為人力的不足導致更多的問題，如研發效率大幅下降（一個開發負責與其不匹配數量的服務）。

Chaya：戀愛是兩個人的事，3+ 以上就大亂了，所以一個微服務究竟需要幾個開發維護是比較合理呢？

三個！

系統規模

從系統規模來講，3 個人負責開發一個系統，系統的復雜度剛好達到每個人都能全面理解整個系統，又能夠進行分工的粒度。

如果是 2 個人開發一個系統，系統的復雜度不夠，開發人員可能覺得無法體現自己的技術實力。

團隊管理

從團隊管理來說，3 個人可以形成一個穩定的備份，即使 1 個人休假或者調配到其他系統，剩余 2 個人還可以支撐。

如果是 2 個人，抽調 1 個后剩余的 1 個人壓力很大。

一個人更不用說了，如果他去大保健被抓了，系統出問題就沒人維護了。

技術提升

從技術提升的角度來講，3 個人的技術小組既能夠形成有效的討論，又能夠快速達成一致意見。

如果是 2 個人，可能會出現互相堅持自己的意見，或者 2 個人經驗都不足導致設計缺陷。

一個人的話，沒人進行技術討論，容易陷入思維盲區。

8.避免環形、雙向依賴

微服務拆分還有一個重要原則，就是避免環形、雙向依賴。

服務之間的環形/雙向依賴會使得服務間耦合加重，在服務升級的時候會比較頭疼，不知道應該先升級哪個，后升級哪個，難以維護。

產生這種情況大多數是因為服務之間的調用可沒有約束導致，為了方便獲取或者更新某個表的數據，服務之間任意調用。

也說明我們的功能劃分不夠清楚或者通用功能沒有下沉下來。

消除環形依賴的方法

要解決循環依賴，必須要在微服務之間建立一些原則來約束微服務之間的通信，定期通過這些原則來審視我們的系統，找到問題并進行重構，這些原則應該包括：

• 定義服務上下游關系，上游服務可以直接依賴下游服務，反之則不可。
• 上游服務的變更對下游服務產生影響需要通過領域事件（異步）的方式來實現。
• 服務之間要通過數據 Id（或類 Id，能夠唯一代表數據且不變的屬性）來進行關聯，盡量不做過多的數據冗余。
• 一旦需要上游服務調用下游服務才能完成業務時，要考慮是否上游服務缺少業務概念
• 為滿足前端邏輯而導致的服務間交互邏輯要放到 BFF（Backend for frontend）中來編排，而不是增加服務間的調用。