一、劃分子系統的策略
按照系統的業務模組的獨立性劃分
二、劃分時服務子系統的數量的控制
過多：可能劃分過細，破壞業務子系統的獨立性，部署維護工作量大，獨立程序占用記憶體多
過少：沒能很好的解耦，開發維護不好分工，公升級維護影響面大
三、服務子系統劃分要注意的地方
3.1 不要出現a服務中的sql需要鏈結查詢到b服務中的表等情況，
這樣在a服務與b服務進行垂直拆庫時就會出錯
eg:服務雖然拆分了，但是還是用的同乙個資料庫
3.2 服務子系統間避免出現環狀的依賴呼叫
eg:a服務呼叫b服務，b服務呼叫c服務，c服務呼叫a服務；出現這種情況說明服務劃分得還是不夠細，沒有完全的解耦，需要考慮出現環狀呼叫的幾個服務之間是否還有能合併得模組
3.3 服務子系統間的依賴關係鏈不要過長
eg:a服務——>b服務——>c服務——>d服務——>e服務;出現這種情況說明服務子系統劃分過細，需要考慮幾個服務之間是否能向上合併
3.4 盡量避免分布式事務，如果不能避免，需要考慮使用訊息中介軟體來保證事務的一致性
四、總結
dubbo分布式服務子系統的劃分是乙個不斷優化的過程，剛開始的時候可以只劃分幾個子系統，隨著業務量的變化不斷的增多
dubbo分布式服務子系統的劃分
1 將系統中獨立的業務模組抽取出來，按業務的獨立性進行 垂直劃分，抽象出基礎服務層。2 基礎服務為上游業務的功能實現提供支撐，基礎服務應用 本身無狀態，可隨著系統的負荷靈活伸縮來提供服務能力。過多 可能劃分過細，破壞業務子系統的獨立性 如 支付訂單 退款訂單，使用者 賬戶 部署維護工作量大，獨立程序...
Dubbo分布式服務系統
dubbo是alibaba開源的分布式服務框架，它最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合 或者最大限度地鬆耦合 從服務模型的角度來看，dubbo採用的是一種非常簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，所以基於這一點可以抽象出服務提供方 provider ...
Dubbo 分布式服務
隨著網際網路的發展，應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需乙個治理系統確保架構有條不紊的演進。垂直應用架構 分布式服務架構 流動計算架構 在大規模服務化之前，應用可能只是通過rmi或hessian等工具，簡單的暴露和引用遠端服務，通過配置服務的...