dubbo服務劃分和介面設計原則(五)
1.服務劃分
服務化的目標：
將系統中獨立的業務模組抽取出來，按業務的獨立性進行垂直劃分，抽象出基礎服務層。
服務化的目標：
服務化的目標：基礎服務為上游業務的功能實現提供支撐，基礎服務應用本身無狀態，可隨著系統的負荷靈活伸縮來提供服務能力。
服務子系統的數量把控
過多：可能劃分過細，破壞業務子系統的獨立性（如：支付訂單、退款訂單，使用者、賬戶）部署維護工作量大，獨立程序佔用記憶體多
過少：沒能很好的解耦開發維護不好分工升級維護影響面大
（以簡易版支付系統服務的劃分為例）服務子系統劃分注意事項：
不要出現A服務中的SQL需要連結查詢到B服務中的表等情況，這樣在A服務與B服務進行垂直拆庫時就會出錯。（一旦分庫分表就 會出錯）
服務子系統間避免出現環狀的依賴呼叫服務子系統間的依賴關係鏈不要過長儘量避免分散式事務
服務子系統的劃分是一個不斷優化的過程
2.Dubbo服務介面設計
action、facade、biz、dao
好的Dubbo服務介面設計，並非只是純粹的介面服務化
2.1介面型別
簡單資料查詢介面：action、facade、dao
帶業務邏輯的資料查詢介面：action、facade、biz、dao
簡單的資料寫入介面：action、facade、dao
帶業務邏輯的資料寫入介面：action、facade、biz、dao
同步介面非同步介面
2.2設計原則介面粒度
服務介面儘可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將面臨分散式事務問題，Dubbo
服務介面建議以業務場景為單位劃分，並對相近業務做抽象，防止介面數量爆炸。
不建議使用過於抽象的通用介面，如：Mapquery(Map)，這樣的介面沒有明確語義，會給後期維護帶來不便。
2.3設計原則介面版本
每個介面都應定義版本號，為後續不相容升級提供可能，如：
<dubbo:serviceinterface="com.XxService" version="1.0" />
2.4設計原則介面相容性
服務介面增加方法，或服務模型增加欄位，可向後相容；刪除方法或刪除欄位，將不相容，列舉型別新增欄位也不相容，需通過變更版本號升級。
2.5設計原則異常處理
建議使用異常彙報錯誤，而不是返回錯誤碼，異常資訊能攜帶更多資訊，以及語義更友好。
如果擔心效能問題，在必要時，可以通過override掉異常類的 fillInStackTrace()方法為空方法，使其不拷貝棧資訊。
查詢方法不建議丟擲checked異常，否則呼叫方在查詢時將過多的try...catch，並且不能進行有效處理。
服務提供方不應將DAO或SQL等異常拋給消費方，應在服務實現中對消費方不關心的異常進行包裝，否則可能出現消費方無法反序列化相應異常。