微服務架構時遇到的第一個問題就是如何划分服務的邊界。
在實際項目中通常會采用兩種不同的方式划分服務邊界，即通過業務職能(Business Capability)或是 DDD 的限界上下文(Bounded Context)。
由於沒有一種算法和固有規則讓我們參考，導致我們只能像創造藝術品一樣去划分服務。
只要它好看、合理、高效即可。
而藝術品，就代表了不同的人、不同的業務、不同的管理方式會帶來不同的划分方式。
按什么划分
按接口（業務）分
比如把商品展示的接口都放到一個單體寫，那樣這個單體掛了，購買的人不受影響。
不同的服務解決不同業務問題。
問題就是公共模塊（鑒權、底層方法）我要寫多套。
適用於中型團隊，因為公共模塊也不是天天改。
最大程度將業務耦合性降低，A模塊掛了不影響B模塊，而且模塊可以分配給不同的人，單獨治理。
線下麻煩點，但是線上穩定點。
舉例：賬號模塊，此時可能是每個單體里面都有一套賬號數據生成代碼，然后用同一個git維護，一旦更新了就所有單體都要更新。
盡管也是模塊化邏輯，但是最終它還是會打包並部署為單體式應用。
問題
- 代碼冗余嚴重。
- 單機扛不住只能上負載均衡，查日志可能要查多台機器。更新也是，要批量上代碼。
- 數據庫難以隔離，尤其是用戶這種量最多的數據，可能一個bug導致全盤慢。
- 故障無法轉移，A機器掛了， B機器的代碼是一樣的，基本也會掛。
- 影響的是一個整體業務，無法降級，無法熔斷。掛就是一個業務掛。
按模塊（數據）分
不同的服務提供不同的數據。
我認為這才是真正的微服務，服務的切分，如果不切分庫，那將毫無意義。
適用於大型公司，業務量很大，每個模塊都是一個小團隊負責。
最大程度減少溝通成本。
因為當人員數量上來后，最大的消耗並不是編碼時間，而是溝通時間。
舉例：我將賬號集中到一個服務，所有人需要賬號信息都找我來拿，然后我這邊用負載均衡、集群保證我的高可用，如果有人要更新用戶數據，要我走我的接口，要么走我的消息隊列，我來維護賬號數據的一致性。
圍繞業務或者數據構建，服務關注單一業務。服務間采用輕量級的通信機制，可以全自動獨立部署，可以使用不同的編程語言和數據存儲技術。微服務架構通過業務拆分實現服務組件化，通過組件組合快速開發系統，業務單一的服務組件又可以獨立部署，使得整個系統變得清晰靈活。
分多細
細的好處：
- （1）服務都能夠獨立部署
- （2）擴容和縮容方便，有利於提高資源利用率
- （3）拆得越細，耦合相對會減小
- （4）拆得越細，容錯相對會更好，一個服務出問題不影響其他服務
- （5）擴展性更好
細的壞處：
- （1）拆得越細，系統越復雜
- （2）系統之間的依賴關系也更復雜
- （3）運維復雜度提升
- （4）監控更加復雜
- （5）出問題時定位問題更難
微的粒度還關乎着庫的分離。
怎么選擇
我的建議是：
一步步來
其實架構真的是分久必合、合久必分。
- 當你覺得兩個代碼沒有什么業務耦合的時候，就可以分離了。
- 當你覺得一個數據要調用多個服務的，就要合並了。
在最開始在對業務領域不是特別熟悉的時候，按照部門職能進行划分，例如賬號、財務等。
- 注意划分的時候要閉環，不要相同的功能散落到幾個部門當中
在系統穩定之后，積累了相關的業務經驗和微服務開發經驗之后，再考慮使用 DDD 限界上下文進行划分
- 如果可以閉環的解決一個用戶場景，那么它應該是一個微服務
- 還可以根據訪問頻率進行區分划分，將用戶高頻訪問的部分划分為一個服務
- 還可以根據讀寫進行划分
- CQRS: 將應用程序分為兩部分：命令端和查詢端。命令端處理程序創建，更新和刪除請求，並在數據更改時發出事件。查詢端通過針對一個或多個物化視圖執行查詢來處理查詢，這些物化視圖通過訂閱數據更改時發出的事件流而保持最新。
舉例：
- 賬號服務，開始是一個服務，只有昵稱、頭像、性別等。
- 后面加入了VIP、裝備系統、背包等等。
- 於是把這些都拆成了一個個服務，畢竟是沒有耦合關系的。
- 后來發現取一個用戶的數據，需要調用七八個子服務，好麻煩，代碼合並又很難受。
怎么辦？
架構就是一層加一層。
再加個中間層，用來組裝數據，需要賬號所有信息的就調用它就好了。
對外聚合，對內拆分。
總結
架構是慢慢演進出來的，要根據業務和實際環境來選擇架構和演進架構。
持續迭代，持續重構。