1、接口粒度

1.1 服務接口盡可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將面臨分布式事務問題，Dubbo暫未提供分布式事務支持。同時可以減少系統間的網絡交互。

1.2 服務接口建議以業務場景為單位劃分，並對相近業務做抽象，防止接口數量爆炸。

1.3 不建議使用過於抽象的通用接口，接口名稱的定義應遵循望文生義原則，如：Map query(Map)，這樣的接口沒有明確語義，會給後期維護帶來不便。

2、接口版本

2.1 每個接口都應定義版本號，為後續不兼容升級提供可能，如：<dubbo:service interface="com.XxService" version="1.0" />

3、接口兼容性

3.1 服務接口增加方法，或服務模型增加字段，可向後兼容；

3.2 刪除方法或刪除字段，將不兼容，枚舉類型新增字段也不兼容，需通過變更版本號升級。

4、異常處理

4.1 建議使用異常匯報錯誤，而不是返回錯誤碼，異常信息能攜帶更多信息，以及語義更友好。

4.2 如果擔心性能問題，在必要時，可以通過override掉異常類的fillInStackTrace()方法為空方法，使其不拷貝棧信息。

4.3 查詢方法不建議拋出checked異常，否則調用方在查詢時將過多的try...catch，並且不能進行有效處理。

4.4 服務提供方不應將DAO或SQL等異常拋給消費方，應在服務實現中對消費方不關心的異常進行包裝，否則可能出現消費方無

5. 設計接口時一定要保證輸入參數校驗通過，否則會給後續的生產者和消費方帶來問題，花費大量的時間去定位

6、在Provider上盡量多配置Consumer端屬性

6.1 作為服務的提供者，比服務使用方更清楚服務性能參數，如調用的超時時間，合理的重試次數，等等

6.2 在Provider配置後，Consumer不配置則會使用Provider的配置值，即Provider配置可以作為Consumer的缺省值。否則，Consumer會使用Consumer端的全局設置，這對於Provider不可控的，並且往往是不合理的。

6.3 Provider上盡量多配置Consumer端的屬性，讓Provider實現者一開始就思

7、服務接口設計與服務子系統劃分過程相互優化

Dubbo服務接口的設計原則