2.3 業務服務化帶來的效益

1.提升代碼復用率

項目體系變大和架構變復雜后，系統難免會分模塊，甚至分組件。但是模塊之間、組件之間還是有大量的代碼重復。

2.消除依賴爆炸

各組件之間如果不經過抽取公共層來屏蔽直接依賴和調用，將會造成依賴爆炸，給運維、升級帶來巨大的工作量。

3.緩解持久層壓力

沒有服務化，持久層自然要面對更多上層的直接壓力，緩存只能起到緩沖的作用，沒有命中的緩存將會導致整個底層庫受影響，進而影響其他系統用戶。

4.降低維修難度

正是由于上述的幾個問題，在系統出問題時定位問題就比較困難，修改一個微小的地方，輕則需要重新發布、重啟系統，重則程序崩潰、服務下線，直接造成重大經濟損失。

5.開發團隊分工更明確

用一個上百人的團隊去維護同一份代碼，相信沒有人愿意干這樣的事情。

正是基于以上的這些亟待解決的痛點，單體架構的服務化改造變得非常有必要，同時，服務化也是從領域建模發展到微服務架構的過渡性產物。

限界上下文的劃分是為了更好地管理業務單元，讓業務具有高內聚、低耦合的特性，因為業務是經常變化的，要盡量封裝這種變化，不讓其影響周邊業務。服務化剛好能起到這種作用，內部封裝、對外提供接口、業務之間的調用可以通過企業服務總線ESB、消息隊列MQ、REST API以及其他RPC方式來完成。

服務化的過程涉及三個角色，如圖2-9所示，包括服務提供者、服務消費者、服務管理者。