首先： 服務化是什麽，為什麽要服務化
服務化是一種將業務、功能或流程抽象為服務的設計方法，透過服務之間的協作和呼叫來實作系統的整合和復用。它可以提高系統的可維護性和擴充套件性，主要用來構建分布式系統。
然後：
怎樣服務化
SOA 和 微服務 都是實作了服務化的、比較典型的架構風格。
SOA的出現是為了解決功能復用的問題，將一些通用的模組提取出來做成服務。但是SOA對於通用模組的設計沒有設計核心原則，因此在對應需求變化等變更時，會產生可維護性變差，通用模組需求影響能力不足等問題。
微服務架構與DDD配合使用從理論上解決了SOA這方面的問題。基於微服務的 服務設計 一般要要滿足下面的 原則 ：
1>單一職責，一個服務要從屬於一個領域或者子領域，也就是說一個服務做的事情理論上應該是一句話能說清楚的。
2>服務自治，一個服務要具備獨立的業務能力和執行環境，依賴包括儲存也是獨立的，有一套完整的流程，可以當成一個計畫來對待。
3>服務組合，多個小型服務可組成一個更大的服務。
4>服務契約，API應該明確和清晰地定義其介面、協定、通訊方式、版本管理和SLA。
在微服務架構中，技術上的 關鍵是 服務治理。服務網格本質是服務治理的一個範疇。微服務架構給出了服務拆分的基本原則，DDD給出了拆分的一個參考方向：面向領域拆分，也給出了一些基本的拆分模型，比如DDD四層架構、洋蔥型架構。實際使用過程中也可以 面向流程拆分或者面向功能拆分。典型的面向功能拆分的架構是微內核架構。這兩個拆分方向與DDD並不沖突。
計畫實施時，還需要解決拆分粒度的問題。這個問題DDD中沒有給出明確的解決方案。
拆分粒度可以從成本維度和品質維度兩個大方向來考慮。
成本維度
考慮資源占用情況，虛機來做成本高，如果公司容器化做得好，粒度可以細一些，透過基礎設施來提高整體資源利用率。
考慮人力情況，多人維護一個服務，溝通成本高；一人維護多個服務，開發成本高。理論上，一個中級工程師獨立維護一到兩個服務是比較理想的。
考慮變更情況，如果兩個服務經常一起變更，分開成兩個服務成本相對較高。
品質維度
考慮服務治理等基礎設施支持，如果基礎設施支持足夠完善，提供標準的RPC呼叫、完善的鏈路追蹤、監控、數據視覺化支持，粒度可以細一些，反之，基礎設施不完善，粒度粗一些，整體服務品質更可控。
考慮效能消耗情況，拆分服務會增加通訊成本，這個成本是否可以接受、與收益是否成正比或者是否可以透過其他的技術手段降低影響。
考慮部署速度，如果粒度太粗，一個服務伺服器數量可能會增加，釋出時間可能會很長；如果粒度太細，也可能因為要部署多個套用釋出時間增長。要做好權衡。
考慮套用規模和業務量，計畫初期，建議粗分，然後演進。上量之後，一個原本簡單的業務，量級上的質變也可能需要拆得很細來解決穩定性、拆解場景的復雜性。
考慮 高可用要求上，高可用等級不同也可能拆分成不同服務，比如核心套用三地六機房部署，非核心套用雙機房部署。
