摘要

在前面一篇介紹瞭如何通過DDD的思想，來調整單體服務內的工程結構，為微服務的拆分做準備。同時介紹了我們在進行微服務拆分的時候踩過的一些坑。
這篇介紹下我們最終的方案，不一定對，歡迎留言討論。

微服務劃分

問題分析

上篇介紹過我們一開始的服務劃分標準

1. 一個領域一個服務的規則去拆分，
2. 同時為了保證領域的純潔性，我們區分了領域服務，和前臺服務。領域服務就是領域邏輯，不直接對前端暴露。前臺服務組裝各個領域服務，暴露給前端。
3. 同時為了保持擴充套件，我們預留了一個微服務作為服務孵化器。對於領域不清晰的（比如大部分的新的業務），放在這個服務裡面孵化，然後等領域足夠大的時候再拆分出去。

實踐後有些典型的問題也比較突出

• 服務熱點問題
  我們是一個新的業務，在業務迭代的過程中，大部分新需求都是領域不清晰，不知道能不能迭代下去的。所以按照之前的標準，都往growth服務裡面去寫程式碼，這樣導致幾乎團隊裡面的所有的人都在開發這一個專案，失去了拆分微服務的意義。

• 服務依賴太嚴重
  無論寫什麼需求，都需要寫多個應用，領域服務1個，前臺如果有pc,需要在pc服務上開發，移動端要展示，要在mobile服務開發。服務之間的呼叫需要寫rpc client介面，需要發版本，因為同時開發的人多，經常發生版本混亂，依賴問題。服務上線也很頭疼，改一個小需求，需要部署多個服務。微服務一個很重要的點是去耦合，可獨立部署。多了一層UI層作為微服務顯然不是很合適。

• 領域劃分問題
  一個領域一個服務，粒度太小，有些東西不知道放在哪個服務裡面，比如使用者收藏部落格，是放在使用者服務裡面，還是放在部落格領域呢。

三個比較突出的問題，反應出的共性問題就是

• 服務邊界不清晰

  微服務的邊界不清晰，起因肯定是標準定義的不夠準確

• 服務之間依賴多了

  微服務的一個重要特徵就是自治性，如果依賴的服務多了，那麼我們就享受不到微服務帶來的好處，而只能感受到微服務的壞處。

解決手法

為了解決以上問題，我們反思了下我們的劃分標準，組內進行了深入的討論。一致覺得是因為我們為了推行DDD，在沒有深入思考的情況下，過早的進行了大面積的微服務拆分。導致了諸多的問題。雖然這麼做在當時的情況下，是最優的解決方案，但是帶來的問題也很突出。那什麼時候才是進行微服務拆分的最好時機呢?

因為理論學習、認知始終都沒有盡頭，只有實踐才能出真知。我們沒有糾結在過去的錯誤之中，而是重新讀取了DDD的理論。這一次有了不一樣的思考。

DDD中有戰略設計，劃分領域，找出限界上下文，識別出核心域。然後有戰術設計，對領域進行建模，
聚合根、實體、值物件、領域服務、領域事件等。戰略設計通常就是指導思想，戰術設計是具體打法。我們一開始認定要
先有指導思想，然後再有具體打法。現在發現我們錯了，指導思想不是一蹴而就的，也不是不成不變的。在一開始沒有標準時，它必須要來源於實際打法中。
同時需要在實踐過程中不斷總結，修正、完善指導思想。

於是我們又重新梳理了一遍我們的整體業務

前臺功能

把我們所有端的前臺功能都梳理一遍，畫成圖

業務架構全景

根據前臺功能，進一步整理，抽象出業務架構全景

劃分出上下文

根據業務架構全景，在核心域中建立出限界上下文，拆分微服務

非常抱歉了，涉及敏感資訊，這裡不能貼圖,如果覺得太抽象不好理解，請參考DDD落地：業務分析師和架構師的完美結對

新的微服務劃分標準

我們提出了一種新的微服務劃分標準

• 確定以限界上下文為微服務劃分的標準

  限界上下文的劃分很難，但是必須要做。限界上下文不是憑空造出來的，而是從一個實體關聯關係、與業務人員溝通出來的。

• 服務的演進是以限界上下文作為單元進行演進的

  之前我們拿一個微服務作為領域孵化器，其實就是放棄了對業務的整體認知，和對新需求的業務思考。
  我們的新業務不是一個新產品，全部推倒重來的。大多時候它還是解決某類業務上的問題。只是採取的手段不一樣罷了。
  所以我們需要挖掘其本質，將它放到現有的上下文中。每個上下文一個微服務，對應一個開發owner,他負責這個領域內的事情。
  這樣每個服務都有新的領域孵化。

舉例

以電商舉例，如果只是一個創業公司，不可能都跟阿里巴巴一樣的架構，上百個服務。但是解決的問題電商領域可以抽象出來。

限界上下文

分為人、貨、場、交易幾個上下文。然後不斷的孵化，哪一部分是你業務的核心域，然後不斷的服務拆分，比如你也是一家做垂直電商的公司，這些基本的東西肯定不應該是你的核心域，只能是支撐域，要不然你的業務肯定發展不起來。

微服務的劃分

從限界上下文中抽出微服務，一個微服務中包含了多個領域。

另外我們遺棄了之前的UI服務，所有微服務可以直接和前臺互動，這樣可以有效的減少服務的依賴。
只有當需要多個領域進行組合時，我們才寫在一個新的【組合ui】服務裡面

另外限界上下文不是一層不變的，比如商品營銷，是一個領域，業務簡單時和商品的關聯性比較大，放在商品域。當你需要同時對店鋪做營銷，對使用者做營銷，顯然他不應該在商品上下文了，那麼可以剝離出來，作為一個獨立的限界上下文：營銷上下文。

相關閱讀

可落地的DDD(1)-目標討論

可落地的DDD的(2)-為什麼說MVC工程架構已經過時

可落地的DDD(3)-如何利用DDD進行微服務的劃分

關注【方丈的寺院】，第一時間收到文章的更新，與方丈一起開始技術修行之路

相關推薦