根據接口類型劃分
- 簡單的數據查詢接口:action facade dao
- 帶業務邏輯的數據查詢接口:action facade biz dao
- 簡單的數據寫入接口:action facade dao
- 帶業務邏輯的數據寫入接口:action facade biz dao
- 同步接口
- 異步接口
設計原則
接口粒度
服務接口儘可能大粒度,每個服務方法應代表一個功能,而不是某功能的一個步驟,否則將地面臨分佈式事務問題,Dubbo暫未提供分佈式事務支持,同時可以減少系統間的網絡交互
服務接口建議以業務場景爲單位劃分,並對相近的業務做抽象,防止接口數量爆增(爆炸)。
例:某一個接口有多個實現,做成一個接口,再在dubbo分組中多實現
不建議使用過於抽象的通用接口,如Map query(Map),這樣的接口沒有明確語義,會給後期維護帶來不便
接口版本:
每個接口應定義版本號,爲後續不兼容升級提供可能
如:
<dubbo:service interface="com.xxService" version="1.0"/>
接口兼容性:
服務接口增加方法,或服務模型增加字段,可向後兼容;
刪除方法或刪除字段,將不兼容,枚舉類型新增字段也不兼容,需要通過變更版本號升級。
異常處理:
建議使用異常彙報錯誤,而不是返回錯誤碼,異常信息能攜帶更多的信息,以及語義更友好。
如果擔心性能問題,在必要時,可以通過override掉異常類的finlllnStackTrace()方法爲空方法,使其不拷貝棧信息。
查詢方法不建議拋出checked異常,否則調用 方在查詢 時將過多的try…catch,並且不能進行有效處理。
服務提供方不應將DAO或者SQL等異常拋給消費方,應在服務實現中對消費方不關心的異常進行包裝,否則可能出現消費方無法反序列化相應異常
必要的接口輸入參數校驗
在Provider上儘量多配置Consumer端屬性: