須彌零一

微服務拆分10條戒律

當下微服務是真的火啊！真是感覺現(xiàn)在在IT圈混的說自己不懂微服務都OUT了。放眼當前的大環(huán)境，大到各種大大小小的廠商產(chǎn)品介紹，小到漫天亂飛的招聘信息，微服務這個詞總能在你的眼前飄來飄去。

說真的，微服務這個詞真是讓人又愛又恨。愛的是凡是打上了微服務架構的標簽，不管內部構架如何，產(chǎn)品立馬讓人覺得高大上了，逼格更高了（潛臺詞：能賣個好價錢）。然而讓人恨的是，讓我們架構師自己捫心自問，我們的產(chǎn)品當前做微服務架構是最優(yōu)的產(chǎn)品架構嗎？這其中的答案可能每位架構師都有自己的答案，或者也各自有各自的無奈。

好了，這個問題就此打住。既然我們的產(chǎn)品導向是要做微服務架構。那么，基于我們的產(chǎn)品應該如何來拆分呢？下面就和大家討論交流一下。

什么是微服務

微服務（英語：Microservices）是一種軟件架構風格，它是以專注于單一責任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎，利用模塊化的方式組合出復雜的大型應用程序，各功能區(qū)塊使用與語言無關 (Language-Independent/Language agnostic）的API集相互通信。微服務是一種以業(yè)務功能為主的服務設計概念，每一個服務都具有自主運行的業(yè)務功能，對外開放不受語言限制的 API (最常用的是 HTTP)，應用程序則是由一個或多個微服務組成。

微服務是對比于單體應用來講的。單體應用表示一個應用程序內包含了所有需要的業(yè)務功能，并且使用比如C/S架構（Client/Server）或是多層次架構（N-tier）實現(xiàn)。雖然它也是能以分布式應用程序來實現(xiàn)，但是在單體式應用內，每一個業(yè)務功能是不可分割的。若要對單體式應用進行擴展則必須將整個應用程序都放到新的運算資源（如：虛擬機）內，但事實上應用程序中最耗費資源、最需要運算資源的僅有某個業(yè)務部分（例如跑分析報表或是數(shù)學算法分析），但因為單體式應用無法分割該部分，因此無形中會有大量的資源浪費的現(xiàn)象。

微服務運用了以業(yè)務功能為關注點的設計理念，應用程序在設計時就能先以業(yè)務功能或流程設計先行分割，將各個業(yè)務功能都獨立實現(xiàn)成一個能自主運行的個體服務，然后再利用相同的協(xié)議將所有應用程序需要的服務都組合起來，形成一個應用程序。若需要針對特定業(yè)務功能進行擴展時，只要對該業(yè)務功能的服務進行擴展就好，不需要整個應用程序都擴展。同時，由于微服務是以業(yè)務功能導向的實現(xiàn)，因此一個微服務不會受到其他應用程序的干擾，微服務的管理員可以視運算資源的需要來配置微服務到不同的運算資源內，或是部署新的運算資源并將它配置進去。

總結一下，簡單的來說微服務就是以業(yè)務為導向，將原有的單體應用拆分成多個服務單元。每個單元之間互不影響其內部狀態(tài)，并通過共同認可的協(xié)議進行通信的架構設計。下面我們來討論一下如何將一個單體服務拆分成多個業(yè)務單元。

微服務拆分的10條戒律

1.用有限的上下文和普適語言來審視您的業(yè)務領域：

在進行分解之前，首先要做的是縮小產(chǎn)品所有者與開發(fā)人員之間的理解差異。一般產(chǎn)品所有者可能不了解技術術語，技術團隊可能不了解術語在業(yè)務和業(yè)務解釋方面的重要性。他們就像一個葡萄牙人用葡萄牙語和一位說英語的美國人交談：兩人之間沒有人能理解對話的內容。因此，為了消除這些認知上的差距，我們需要采取以下步驟：

1.與產(chǎn)品所有者進行討論：“業(yè)務目標是什么？”、“特定功能中的參與者是誰？”、“他們在定義功能時使用了哪些術語？”。在這些每個步驟上，都要提出更多問題，直到您弄清楚沖突的術語是什么為止，例如“訂單上下文客戶”與“基礎結構支持上下文客戶”是不同的。2.一旦理解了沖突的術語并結合了相關功能，請制定一個上下文，以便在每個上下文中的每個域名的實體名稱都是清晰的。3.為每種情況定義一種通用語言，以便業(yè)務團隊和技術團隊在交流時可以使用一種通用語言進行溝通交流。4.從一個粗粒度的有界上下文開始。如果以后有令人信服的理由進行劃分，則劃分有界上下文。如果有商業(yè)原因，我建議不要這樣做。

2.確定核心領域并應用創(chuàng)新的點子：

核心域是為您的業(yè)務帶來收益的領域。就在線購物而言，購物車模塊是核心領域，它為從企業(yè)到消費者的買賣（B2C）平臺提供了核心功能。了解您的核心模塊，并思考如何改進這些競爭對手沒有的模塊。任何自動化或創(chuàng)新都會增加優(yōu)勢并增加您的收入，因此請注意：應該在核心領域進行研發(fā)和投資，以保持競爭優(yōu)勢。

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

通用域就是該領域中每個企業(yè)所共有的領域。對于這些領域，市場上不同的第三方廠商已經(jīng)提供了不同的、相對成熟的商業(yè)化解決方案。比如您產(chǎn)品中的通知模塊或廣告活動模塊。所以最好的策略是不要花任何錢在內部項目上創(chuàng)建該模塊來重新發(fā)明輪子，除非您有一些令人信服的理由。一般情況下以便宜的價格采用第三方解決方案是比較好的選擇。

4.考慮支持領域：

核心域需要支持域的幫助來豐富自身，并且在某些情況下，支持域也是可以帶來收益的，并且將來有可能孵化（轉變）成為核心域。因此，重要的是要思考并做出合適的決定：在支持領域進行投資，以便它可以產(chǎn)生收入。比如，在購物車域中，庫存管理是支持領域，但投資研發(fā)-識別客戶訂單最近庫存位置的算法，對降低運輸成本也很重要。

5.引入反腐層（Anti-Corruption Layer）：

反腐層（Anti-corruption layer，簡稱 ACL）介于新應用和舊應用之間，用于確保新應用的設計不受老應用的限制。是一種在不同應用間轉換的機制。

創(chuàng)建一個反腐層，以根據(jù)客戶端自己的域模型為客戶端提供功能。該層幾乎不需要對其進行任何修改就可以通過其現(xiàn)有的接口與另一個系統(tǒng)進行通信。因此，反腐層隔離不僅是為了保護你的系統(tǒng)免受異常代碼的侵害，還在于解耦不同的域并確保它們在將來保持解耦的狀態(tài)。

反腐層是將一個域映射到另一個域，這樣使用第二個域的服務就不必被第一個域的概念“破壞”。

實際上，我們經(jīng)常遇到基于大型機或任何其他語言構建的舊系統(tǒng)。我們無法拆分該系統(tǒng)，但是還需要使用舊應用的數(shù)據(jù)。因此，在舊應用和微服務通信之間創(chuàng)建反腐層會是一個好主意。

另外，我們還需要考慮到通用領域。因為他們是不受開發(fā)團隊控制的任何外部系統(tǒng)(第三方系統(tǒng)) ，因此也需要引入一個反腐層，該層將微服務與外部AP隔離開來，充當微服務和第三方之間的翻譯者。并且還有一個用途是，它還可以幫助你在將來接入其他的任何第三方庫（服務）。

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

一旦已經(jīng)基于功能拆分了微服務，并且核心服務也封裝了它們自己的數(shù)據(jù)庫/持久層。那么接下來我們要考慮的問題是，您的UI視圖/組件之間是如何進行通信的。是異步？還是同步？例如，對于一些系統(tǒng)，用戶可以執(zhí)行部分功能并創(chuàng)建中間狀態(tài)，另一個系統(tǒng)對中間狀態(tài)采取措施并回調或通知用戶。

7.引入事件驅動架構（EDA）：

在實時應用程序中，您的業(yè)務案例可能具有復雜的工作流，并且根據(jù)數(shù)據(jù)的狀態(tài)（基于狀態(tài)變化）在工作流上具有許多分支。每個工作流程分支都可能采取不同的策略。因此，如果您考慮通過Rest API公開所有內容，那么你將會看到這些API創(chuàng)建出了一個非常復雜的通信網(wǎng)絡。

因此，我們需要一個干凈整潔的架構，其中每個微服務都可以獨立運行而不會產(chǎn)生耦合。這里事件驅動的架構將會起著至關重要的作用，每個事件都包裹著狀態(tài)的變化，并且微服務的設計遵循發(fā)布訂閱(pub/sub)模型。因此一個微服務會發(fā)布以事件的形式包裝的數(shù)據(jù)，其他微服務會偵聽該事件。由于事件是不可變的，因此它也保存了實體或聚合器的歷史記錄。

8.使API簡潔明了

在微服務中發(fā)布API時，請確保你的API不會將內部狀態(tài)發(fā)布出去。發(fā)布API是一種使其他服務可以獲取足夠的信息以繼續(xù)其流程的方式，因此要慮封裝和網(wǎng)絡調用，不應多次返回以獲取派生信息。還要考慮事件，應該發(fā)布哪些事件以及哪些事件必須保留在內部。也許你可以發(fā)布一個粗粒度事件，而不是發(fā)布一個個內部的小事件。

例如，你有地址更改事件和個人信息更改事件。最好是發(fā)布一個名為CustomerUpdateEvent的粗粒度事件，而不是提供兩個獨立的事件。

9.將相關的微服務合并為更大的服務：

拆分之后，當需要添加或更新功能時，你會遇到一些微服務總是一起變化的情況。這時候，你應該知道你已經(jīng)以錯誤的方式拆分了它。它們一定不能被隔離到一個小型服務中，它們是同一邏輯單元的一部分。因此，將它們合并為一個服務是明智的，這將減少不必要的網(wǎng)絡通信開銷，和降低模塊間的復雜度。

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

微服務不是免費的午餐。如果你采用微服務，那么首先要做好準備，因為微服務是分布式的，因此要投資一些軟件工具，以此來擴展彈性和提高可用性，并縮短產(chǎn)品投產(chǎn)時間，幫助盡早發(fā)現(xiàn)故障等。

因此，請在CI/CD流水線上投入一定的資金資源。采用云基礎架構，使用跟蹤工具，使用日志聚合器來搜索日志，使用混沌工程測試你的系統(tǒng)，等等。

最后

以上就是10點我們要做微服務拆分時的一點想法和建議，至于對錯，本人也沒有一個肯定的答案。但是，盲目跟進微服務架構，個人覺得其實不是一個很好的現(xiàn)象。

一個產(chǎn)品誕生的起因本身就是為了解決一系列實際的業(yè)務問題，結合業(yè)務實際來構建一個合理的技術架構才是一個最好的選擇。當然，有些朋友可能會覺得微服務架構有那么多單體架構沒有的有點，我可以提前布局以應對業(yè)務量上去之后的系統(tǒng)瓶頸。但是，每個產(chǎn)品都有自己的生命周期，每個產(chǎn)品也都有自己的業(yè)務特點。另外更要命的是，誰也無法預測未來，需求也是在不斷的快速變化，有時候提前布局到的東西可能永遠也用不上，這就白白浪費了前期的投入，反而得不償失。您覺得呢？當然，如果有其他外力因素不能左右那就另說了。

歡迎留言討論。

---- END ----

譯文連接：

https://dzone.com/articles/10-commandments-on-microservice-decomposition

歡迎關注我的公眾號“須彌零一”，原創(chuàng)技術文章第一時間推送。