#頭條創作挑戰賽#
引言
在前面的兩篇文章中，筆者給大家介紹了 DDD 核心思想、重要概念以及如何進行 DDD 進行微服務實踐的大緻過程，後續的文章中将逐漸深入 DDD 的實踐細節，包括領域模型與代碼模型的映射以及具體的微服務設計執行個體等。當下微服務盛行，微服務架構解決了單點系統的可用性問題、突破單節點服務的性能瓶頸同時提升了整個系統的穩定性。是以各大公司紛紛轉向微服務架構，但是在實際的微服務拆分過程中也會遇到不少的問題。而 DDD 中的領域模型建構以及邊界上下文的劃分天然的和微服務劃分有着異曲同工之妙，是以結合 DD 領域驅動設計來進行微服務拆分是一種比較好的微服務拆分方案。那麼今天就和大家聊聊怎麼進行微服務拆分。
為什麼要進行微服務拆分？
在進行微服務拆分之前，我們首先應該搞清楚為什麼要進行微服務拆分？微服務拆分後會帶來怎樣的業務價值？在後期維護上面會不會比以前的維護成本更低？我想這些問題都是架構師在實作微服務拆分之前需要回答的問題。那麼我們就來先看看單體應用在業務不斷發展的過程中會遇到怎樣的問題。
維護難
随着業務的不斷發展，單體應用的功能越來越多，需求不斷變化，修改不斷進行，單個應用多團隊維護就會出現各種團隊協作問題，不知不覺中降低了産品的研發效能。而且由于各個業務子產品雜糅在一起，一個需求過來後，到底改哪個團隊來做，經常在開會的時候吵得臉紅脖子粗，增加了時間以及溝通成本。
更新難
進行需求疊代的時候，也許隻修改了某個子產品的功能，但是每次釋出都是一整個大的包進行釋出，其中建構、發包的時間成本會随着應用的疊代逐漸增加，導緻整個需求上線過程變更顯得十分笨重，不利于進行團隊規模的靈活開發。
穩定難
由于單體應用故障隔離範圍隻是線程級别的，單體應用可能會由于某個子產品的功能有問題而導緻整個服務平台的不可用，是以平台穩定性方面顯然不能滿足經常變化的業務發展的需要。
鑒于上述問題，我們需要對大泥球似的單體大應用進行合理拆分，以便于适用業務的快速發展。微服務架構拆分之後，團隊成員不用都圍繞一個大泥球應用轉了，根據拆分的不同的業務域，各自負責自己的業務域，維護起來相對來說更加友善。同時如果有需求疊代，沒有功能修改的業務域可以不用發生變更，不需要進行重新部署，大大降低了修改變更導緻的平台穩定性性問題。另外由于是微服務分布式架構，不再是單點應用，不再存在單點問題，性能方面也會有所提升。
微服務到底該怎麼拆？
當我們想清楚為什麼進行微服務拆分之後，團隊 Boss 也同意進行微服務拆分了。于是我們準備撸起袖子加油幹的時候，另外一個問題又擋在我們前面，微服務到底應該怎麼拆呢？或者換句話說，我們應該按照怎樣的标準來進行拆分呢？如果拆分得不好，邏輯混亂的微服務還不如邏輯清晰的單體應用。這時候天空飄來了三個大字---DDD。
DDD 的理論中提供了我們進行領域驅動設計的指導方針，對于我們進行微服務的拆分具備天然的指導意義。比如 DDD 指導我們首先要對目前系統平台的業務進行全面的分析，可以通過用例分析法、事件風暴法以及四色模組化法來進行業務分析，使用統一的業務語言進行業務領域劃分以及邊界上下文的劃定，當然在這個過程中還包含了領域模型的建構，在業務分析中找到對應的實體、值對象以及聚合根，進而形成聚合，将聚合劃分到邊界上下文中。後面我們就可以根據邊界上下文來進行具體的微服務的劃分了。
筆者在實踐微服務拆分的過程中主要按照業務能力、通用能力兩個次元來進行具體的拆分。接下來給大家詳細說明下。
業務能力
所謂業務能力就是平台的具體實作的業務功能是什麼，這就好比在電商業務中物流域我們按照業務可以劃分為倉儲、運輸、配送、計費等業務領域。大的領域劃分出來之後，我們可以用真實的業務流程來串聯這些業務領域。當業務流程經過這些業務領域的時候，必定會觸發一些領域事件，經曆一些業務流程，那麼在這個過程中我們就可以梳理出對應的實體、值對象以及聚合根，我們将具有緊密業務邏輯關系的實體以及值對象收斂在聚合根的周圍，進而形成聚合。例如在倉儲領域中就會涉及到入庫、庫内操作以及出庫這三大流程，其中入庫主要包括質檢、收貨以及上架。這其中涉及到的實體主要用入庫單、貨品、操作員等，其中入庫單就是聚合根，通過它可以将貨品、操作員等實體以及值對象聚合起來，形成入庫聚合。
通用能力
這裡的通用能力其實包含兩個意思，對于微服務本身來說，通用能力就是将各個微服務都涉及到的通用能力進行抽象形成單獨的微服務。但是對于整個業務平台來說，通用能力實際就是業務中台。
1、通用服務
所謂通用服務就是在各個微服務之間都會碰到的問題，比如說接口的鑒權、日志的監控和管理、服務狀态的監控和管理以及服務幂等等分布式系統問題。是以，我們需要将這些微服務的通用服務進行統一的抽象，形成通用的基礎服務，這樣微服務本身隻需要關注自身的業務，這些微服務通用的能力由單獨的基礎服務來進行實作就 OK 了。
2、業務中台
我們還是拿大家最熟悉的電商業務來舉個栗子吧，電商的業務形态有很多種，就阿裡巴巴來說，有淘寶、天貓、主打生鮮的盒馬、天貓超市等等。不管上層的業務形态有怎樣的變化，實際上他們都是有比較核心的業務域是通用的，比如使用者、支付、倉儲、物流等等。那麼實際上這些通用的業務對于整個電商平台來說實際就是通用能力，是以我們需要将這些通用的公共的能力進行下沉，形成業務中台，實作企業級的通用業務能力複用。
微服務拆分原則
在進行微服務拆分的過程中，有幾條筆者總結的原則大家可以參考下，在實操的時候如果沒有原則來遵循，實際我們自己也沒辦法去評判微服務拆分的效果到底有沒有達到我們的預期。
微服務拆分要把握度
如果在微服務拆分過程中發生過度拆分，就會導緻微服務爆炸的情況。不可避免地增加軟體系統的維護成本，同時由于拆分也會導緻業務流程變長，原本一兩個服務就完成的業務，拆分後需要在五六個甚至更多的微服務才能完成，增加了平台出現 Bug 的機率，不知不覺中降低了平台的穩定性。另外更多的微服務意味着需要更多的伺服器資源，進而在無形中增加了業務成本。是以我們可以借助于 DDD 劃分的邊界上下文，防止微服務過度拆分情況的發生。
拆分過程逐漸疊代
軟體平台架構的演進過程必定會經曆現有平台以及新架構平台先共存，後替代的過程。是以我們可以先從平台的非核心功能開始再到核心功能這樣逐漸拆分的方式進行疊代拆分，避免一上來就要大刀闊斧的進行微服務拆分以及架構調整，否則就會陷入舊平台不穩定而新平台又不完善的尴尬處境。
確定微服務高内聚低耦合
在進行微服務拆分之前，應該對平台進行完整的領域劃分，建立合适的領域模型，确定好邊界上下文，并以此作為微服務拆分的指導。将領域模型的穩定與不斷變化的外部需求進行隔離，保證核心領域模型的穩定，避免領域模型之間的強依賴。進而達到實作微服務高内聚低耦合的目的。
總結
本文主要圍繞微服務拆分在實踐落地層面存在的問題進行了分析，并結合自身的實踐經驗，可以分别從業務能力次元以及通用能力次元兩方面進行拆分，同時提出了微服務拆分的相關原則和建議。希望大家在自己的實際項目中進行微服務拆分落地的時候可以有所參考。