微服務架構 | 如果是你，你會怎么拆？

hi，這里是桑小榆呀，

前面我們一起探討了一個微服務的概念了解，微服務，也稱為微服務架構，是一種架構風格，它將應用程式構建為服務的集合，集合里的每個服務具有高度可維護和可測試、松耦合效果、圍繞業務能力組織，由一個小團隊擁有，

我們知道，微服務架構是一種架構風格，所謂的架構風格就是一種抽象的結構，它由軟件的各個組成部分和這些部分之間的依賴構成，或許看著概念有些抽象，但只要記住任何涉及抽象的設計，它的目的都是為了很好地適應大型業務應用，構建一個穩健的系統，

作為開發者就深有體會，一個應用初次開發完成了并不是真正的完成，它會伴隨著時間或者用戶的需求而不斷的更迭，隨著時間更迭就會存在人員因素和歷史系統設計的局限性，日常維護糟糕且不穩定的系統一定會讓人崩潰吧，這是每一位開發者都需考慮和面臨的問題，

那么，假如你所負責的應用變得龐大，需要進行重構，我們采用微服務架構，對你現在的需求進行拆分設計，你會怎么拆分呢？

▲圖/ 微服務架構策略圖，橙色為當前內容

微服務拆分策略

首先，我們需要考慮的是共享類別庫的角色，也就是我們在開發程序中，習慣把一些通用的功能（幫助類）打包成一個公共類別庫或者包中，其他服務需要使用直接參考呼叫即可，增加代碼的復用性，但是很可能存在隱患，這個公共類別庫不斷地疊加導致出錯或者版本問題會影響到其他服務，

更好的做法就是努力使得這個共享庫都是一些不太可能改變的功能，同時由專門的人去維護而不是人人都去更迭它，或者是把這些可能會變更的通用功能作為一個服務來實現，而不是共享庫，

其次，在拆分服務時，我們需要精心設計的服務將適合由一個小團隊開發的服務，并且交付時間最短，與其他團隊的協作最少，同時，將一些小的、松耦合的服務組織到一起，以便提升開發階段效率，特別是可維護性、可測驗性和可部署性，這樣能夠讓組織的軟體開發速度更快，

接下來，我們需要對一個應用程式來定義微服務架構，進行拆分了，

第一步通常在開始之前，我們需要收集這個應用有關的資訊，比如說需求檔案，領域專家的資訊（具有這個領域的豐富知識和技能）等，之后，我們便需要從這些資訊中提煉出各種關鍵資訊，使用抽象的系統操作來描述服務之間協作方式的架構場景，這是一種抽象化的，而不是具體的，它既可以是更新資料的命令，也可以是檢索資料的查詢，每個命令的行為都是根據抽象的領域模型定義的，抽象領域模型也是從需求派生出來的，

第二步，就是如何分解服務，這里有兩種廣為熟知的策略，一種是源于業務架構學派的策略是定義與業務能力相對應的服務，另一種策略是圍繞領域驅動設計的子域來分解和設計服務，這兩種方式最終都是圍繞業務概念而非技術概念分解和設計的服務，所以最后的設計結果往往會有些相像，

第三步，即是確定每個服務的API，這一步設計程序中需要采用哪種行程間通訊機制來實作每個服務API的通訊，同時，需要考慮幾個困難，第一個就是網絡延遲，如果服務之間往返太多，導致網路延遲，那么你需要重新審視你拆分的服務是否合理，第二個就是服務之間同步通信降低了可用性，第三個就是需要維護跨服務的資料一致性，例如使用Saga，共享資料庫，領域事件來解決，當然這些將會在后續探討，第四個，就是上帝類帶來的阻礙，上帝類即是整個應用中的全域類，可以通過驅動領域的概念來消除這個上帝類，

細心的伙伴會發現，在采用微服務架構時，很多難啃的骨頭都可以通過DDD(驅動領域)來化解，這也是廣為使用的原因之一，能夠很好的配合微服務架構，

這里我們展開講解第二步，如何分解服務，第三步將會涉及更多內容，將在后續逐一探討，

業務能力拆分服務

使用業務能力進行服務拆分，是微服務架構的策略之一，或許不用講也知道，業務能力是指一些能夠為公司（或組織）產生價值的商業活動，每個企業也有自己的特定的業務型別，例如，在線商店所包含的業務能力包括：訂單管理、庫存管理和發貨，保險公司業務能力包含承保、理賠管理、賬務和合規等，

公司的業務能力通常是指這個組織的業務是做什么，它們通常是穩定的，與之相反公司采用何種方式來實作它的業務能力，是隨著時間不斷變化的，例如以往的支付方式，除了線下支付，還支持財付通支付，現如今還支持支付寶，微信支付，但是始終屬于支付業務，穩定不變的，僅僅只是實作方式發生了變壞，

▲圖/ 某大型餐飲系統架構

業務能力的拆解，我們可以舉一個例子：例如一個餐廳管理系統，其業務能力包含：

1. 供應商管理，送餐員相關資訊，餐館選單和其他資訊管理，例如營業時間和地址，

    

2. 消費者管理：消費者相關資訊的管理，

    

3. 訂單獲取和履行（直接運送、第三方派送，自己運送等），具備消費者創建和管理訂單，餐館管理訂單生產程序，送餐，跟蹤外賣員的實時狀態，訂單送到用戶手中，

    

4. 會計記賬，管理跟消費者相關的會計記賬，管理跟餐館相關的會計記賬，管理外賣員相關的會計記賬，

    

5. 其他，

    

通過上面的業務梳理，我們可以對應到API服務，

子域拆分服務

Eric Evans 于 2003 提出的領域驅動設計構建復雜軟體的方法論，這些軟體通常都以面向對象和領域模型為核心，領域模型以解決具體問題的方式包含了一個領域內的知識，它定義了當前領域相關團隊的詞匯表，DDD也稱之為通用語言，領域模型會被緊密地映射到應用的設計和實作環節，在微服務架構的設計層面，DDD有兩個特別重要的概念，子域和限定背景關系，

領域驅動為每一個子域定義單獨的領域模型，這跟傳統的企業架構建模為整個企業建立一個單獨的模型不同，子域是領域的一部分，領域是DDD中用來描述應用問題域的一個術語，識別子域的方式跟識別業務能力一樣：分析業務并識別業務的不同專業領域，分析產出的子域定義結果也會跟業務能力非常接近，例如上例某餐館服務的子域包括：訂單獲取、訂單管理、餐館管理、送餐和會計，能夠看出和上面業務能力拆分服務非常相近，

DDD把領域模型的邊界稱為限界上下文，限界背景關系包括實作這個模型的代碼集合，當使用微服務架構時，每一個限定背景關系對應一個或者一組服務，換一種說法，我們可以通過DDD的方式來定義子域，并把子域對應為每一個服務，這樣就完成了微服務的設計作業，

或許這些內容需要多讀多理解，下面我們使用一個小案例來助解，

假如我們要為一個小賣部設計一套進銷存系統，她為我們提供的業務描述是這樣的：每天凌晨從布吉農批市場買蘋果、梨、葡萄、橘子、香蕉、荔枝、核桃等等，反正哪些好賣她就買回來賣，葡萄、荔枝不能長久保留，一般要當天賣出去…，

針對上面這段業務描述，我們怎么進行領域模型設計？將給出以下幾個步驟來完成領域模型設計，

總結業務描述中的名詞，首先建一個名詞表，把涉及到的名詞列出來：

這個名詞列表包括了業務的行為主體：角色，以及業務過程中的操作實體：模型，對我們接下來的用例描述、領域模型分析、需求分析很有幫助，當然這個名詞列表需要經過進一步分析提煉，成為領域模型

確定業務物體，用序號名詞描述；

經過分析，我們得出的實體是蘋果、梨、葡萄、橘子、香蕉、荔枝、核桃，這些是不是模型呢？應該說還不是，還要經過進一步分析：在我們分析的業務領域內，它們有沒有共性？蘋果、梨、葡萄、橘子、香蕉、荔枝屬于水果，核桃屬于干果，它們都是果品的一個具體實體，而在水果中葡萄和荔枝屬于不宜保存水果，通過這樣進一步的分析得出如下的領域模型：

果品進銷存領域模型

這個領域模型不但能反映當前的經營物體，同時給我們需求分析人員和系統功能提供了一定的擴展視野：將來會不會經營食品，短期保持水果采取什么利潤空間來促銷，長期保存的水果會不會因為保存成本而導致利潤下降，

那么，我們根據領域模型對業務能力拆分的某餐館系統進行設計如下：

可以看到，DDD和微服務架構簡直是天生的一對，DDD的子域和限定上下文的概念，可以很好的跟微服務架構中的服務進行匹配，

以上兩種是微服務拆分的主要策略，但是也有一些有用的拆分原則是源于面向對象的設計，分別是單一職責和閉包原則，熟悉面向對象的伙伴也不陌生，這里不展開講解，

好了，本篇我們一起探討完了微服務拆分設計，如果有所收獲的話，點個??也是鼓勵呀，

下面我們繼續探討拆分服務之后，服務間的通訊，

標籤：架構設計

上一篇：初識設計模式 - 命令模式

下一篇：說說 Redis pipeline