【51CTO.com快譯】如果您的組織正打算采用和實施微服務(wù)，那么您一定聽說過諸如：領(lǐng)域驅(qū)動設(shè)計(Domain-Driven Design)、事件驅(qū)動架構(gòu)(Event-Driven Architecture)、核心域(Core Domain)、子域(Subdomain)、限界上下文(Bounded Context)，防腐層(Anti-corruption Layer)等概念。同時，您的團(tuán)隊是否有能力以正確的方式，分解業(yè)務(wù)域邏輯(或稱業(yè)務(wù)空間)，并將其與微服務(wù)架構(gòu)(或稱代碼空間)相映射，以便受益于微服務(wù)架構(gòu)帶來的優(yōu)勢呢?

微服務(wù)分解架構(gòu)邏輯圖

在本文中，我將為您總結(jié)分解微服務(wù)的十項原則與相關(guān)策略。

1.使用限界上下文和通用語言(Ubiquitous Language)來查看業(yè)務(wù)域

在進(jìn)行分解之前，我們首先要做的是縮小產(chǎn)品所有者與開發(fā)人員之間的距離。產(chǎn)品所有者可能并不了解技術(shù)術(shù)語，而技術(shù)團(tuán)隊也可能不了解術(shù)語在解釋業(yè)務(wù)中的重要性。因此，為了彌合這種“雞同鴨講”的差距，我們需要采取以下步驟：

• 將產(chǎn)品所有者聚攏到看板前，詢問他們：“業(yè)務(wù)目標(biāo)是什么?”、“在特定功能中有什么角色?”、“他們在定義功能時使用了哪些術(shù)語?”這些問題將有助于技術(shù)人員弄清可能引起誤解的業(yè)務(wù)術(shù)語。例如“訂單上下文客戶”與“架構(gòu)支持上下文客戶”之間的區(qū)別。
• 一旦理解了容易產(chǎn)生歧義的術(shù)語，請結(jié)合相關(guān)功能繪制出上下文，以保證在每個上下文中，每個域?qū)嶓w的名稱都足夠清晰。
• 為每個上下文定義一種通用語言，以便業(yè)務(wù)團(tuán)隊和技術(shù)團(tuán)隊在交流時，可以使用相同的通用語言進(jìn)行同步。
• 先從一個粗粒度(coarse-grained)的限界上下文開始。除非以后出現(xiàn)了令人信服的業(yè)務(wù)理由，否則不再細(xì)分限界上下文。

2.確定核心域并運用創(chuàng)新思想

核心域是那些能夠為您的業(yè)務(wù)帶來收益的部分。對于B2C的在線購物應(yīng)用而言，其購物車模塊便屬于核心域。我們需要通過思考如何改進(jìn)那些競爭對手所不具備的模塊，以充分了解自己的核心模塊。任何自動化、或創(chuàng)新都會增加您的營收與優(yōu)勢，因此你需要針對核心域進(jìn)行重點研發(fā)和投入，以保持自身競爭優(yōu)勢。

3.對通用域進(jìn)行成本優(yōu)化

通用域是每個企業(yè)所共有的部分。通常，不同的第三方會針對商業(yè)化市場，提供通用的解決方案。例如，各個業(yè)務(wù)配套的通知模塊，或是廣告推送模塊。為了避免重復(fù)“造輪子”，我們需要以成本優(yōu)化的方式創(chuàng)建通用域，或是以相對便宜的價格，采用第三方解決方案。

4.適當(dāng)考慮支持域

通常，核心域需要支持域的協(xié)助，來豐富自身。當(dāng)然在某些情況下，支持域不但可以帶來收益，也可能在將來轉(zhuǎn)換為核心域。例如，在前面的例子中，相比購物車域，庫存管理屬于支持域。那么，通過對支持領(lǐng)域進(jìn)行投入，也能夠產(chǎn)生營收。例如，為了降低運輸?shù)某杀?，我們既可以選擇增加庫存的站點，又可以運用算法，識別客戶訂單最近的庫存位置。

5.引入防腐層

防腐層是微服務(wù)設(shè)計中不可或缺的部分，它可以保護(hù)微服務(wù)免受外界變化的影響。例如，在實際情況下，一些舊的項目會受到大型主機環(huán)境、或依賴某種語言的構(gòu)建限制。由于它們是微服務(wù)輸入數(shù)據(jù)的重要來源，因此它們不但需要與微服務(wù)架構(gòu)并存，甚至阻礙對系統(tǒng)進(jìn)行分解。因此，在舊版架構(gòu)和微服務(wù)通信之間創(chuàng)建外包層(facade)，比起直接使用舊版中的數(shù)據(jù)，并在微服務(wù)和舊版架構(gòu)上創(chuàng)建耦合，要好得多。

同時，由于通用域會調(diào)用第三方庫，我們與其根據(jù)合約直接使用(consume)/發(fā)布數(shù)據(jù)，不如引入一個防腐層，將微服務(wù)與外部合約的API，端口與hub模式隔離開來。也就是說，我們可以通過創(chuàng)建合約和防腐層，來充當(dāng)微服務(wù)與第三方聯(lián)系間的“翻譯器”，以協(xié)助調(diào)用第三方庫。

6.識別數(shù)據(jù)通信模式

一旦您基于功能分解了微服務(wù)，并在核心服務(wù)中封裝了自己的數(shù)據(jù)庫與持久層(即，基于每個服務(wù)的數(shù)據(jù)庫)，接下來需要理解的重要事項便是，UI的視圖/組件將如何與每個組件進(jìn)行通信(包括流程)。例如：用戶在以異步的方式獲取某項功能時，您可以在執(zhí)行部分​​功能后創(chuàng)建中間狀態(tài)，以便另一個系統(tǒng)對該中間狀態(tài)執(zhí)行處理，并以回調(diào)的方式通知用戶繼續(xù)后續(xù)的操作。

7.引入事件驅(qū)動架構(gòu)(EDA)

在實時應(yīng)用中，您的業(yè)務(wù)用例可能具有復(fù)雜的工作流，并且需要根據(jù)數(shù)據(jù)的狀態(tài)變化，在工作流上產(chǎn)生許多分支。由于工作流程可以采取不同的策略，因此如果您需要通過Rest API公開所有的內(nèi)容，則會發(fā)現(xiàn)每個微服務(wù)都需要與其他微服務(wù)耦合。這勢必會造成“意大利面”式的代碼和分布式的“泥球”。

可見，我們需要的是一個干凈的架構(gòu)。其中每個微服務(wù)都可以獨立運行，而不會產(chǎn)生耦合。這正是事件驅(qū)動架構(gòu)能夠起作用的地方--每個事件都能夠包含某個狀態(tài)的變化。微服務(wù)通過遵循pub/sub模型，產(chǎn)生狀態(tài)更改，并以事件的形式包含必要的數(shù)據(jù)。其他微服務(wù)則會偵聽該事件，并能夠基于事件中的數(shù)據(jù)，采取相應(yīng)的策略。由于事件是不可變的，因此它也會保存實體或聚合器的歷史記錄。據(jù)此，如果您要采用事件存儲和事件風(fēng)暴，則會生成相應(yīng)的統(tǒng)計信息和事件報告。

8.讓API合約簡潔明了

在微服務(wù)中，您往往需要以API的形式，來發(fā)布合約。那么，在發(fā)布API時，請確保您的API不會發(fā)布內(nèi)部狀態(tài)信息。考慮到網(wǎng)絡(luò)調(diào)用與封裝，發(fā)布API其實就是一種使其他服務(wù)可以獲取足夠的信息，以便繼續(xù)其流程的方式。不過，它們不應(yīng)該為了獲取派生信息，而有多次返回。因此，在規(guī)劃事件時，您應(yīng)該考慮哪些事件可以被發(fā)布，而哪些事件需要被保留在內(nèi)部。您甚至可以只發(fā)布一個粗粒度的事件，而非多個小型內(nèi)部事件。例如：如果您內(nèi)部產(chǎn)生了地址更改事件和個人信息更改事件，那么就應(yīng)該發(fā)布一個名為CustomerUpdateEvent的粗粒度事件，而不是在API合約中同時發(fā)布這兩者。

9.將相關(guān)的微服務(wù)合并為更大的服務(wù)

在分解之后，您可能會遇到在需要添加或更新功能時，某些微服務(wù)總會一起發(fā)生變化的情況。此時，您才會意識到自己以錯誤的方式分解了它。由于屬于同一邏輯單元的不同部分，因此它們一定不能夠被隔離到更小的服務(wù)中。對此，您可以將它們合并為一個大服務(wù)，以減少不必要的耦合和網(wǎng)絡(luò)調(diào)用。

10.引入支持無縫開發(fā)的工具

通過采用微服務(wù)，我們既可以提高可擴(kuò)展性和高可用性，又能夠縮短產(chǎn)品上市的時間。不過由于該架構(gòu)是基于分布式網(wǎng)絡(luò)工作的，因此在出現(xiàn)不可避免的故障之前，我們需要事先購置各種支持軟件。例如，您可以在CI/CD管道上采用云基礎(chǔ)架構(gòu)，使用配套的跟蹤工具，采用日志聚合器來搜索日志，以及使用各種混沌工具(chaos tools)來檢測各種失敗。

原文標(biāo)題：10 Commandments of Microservice Decomposition，作者：Shamik Mitradecomposition

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】