介面粒度：

服務介面儘可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，負責將面臨分散式事務問題。

Dubbo暫未提供分散式事務支援。同時可減少系統間的網路互動。

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

不建議使用過於抽象的通用介面，如Map query(Map)，這樣的介面沒有明確語義，會給後期維護帶來不便。

介面版本：

每個介面都應定義版本號，為後續不相容升級提供可能，如

<dubbo:service interface="com.XxService" version="1.0" />

介面相容性：

服務介面增加方法，或服務模型增加欄位，可向後相容；

刪除方法或刪除欄位，將不相容，列舉型別新增欄位也不相容，需通過變更版本號升級。

異常處理：

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

如果擔心效能問題，在必要時，可以通過override掉異常類的filllnStackTrace()方法為空方法，使其不拷貝棧資訊。

查詢方法不建議丟擲checked異常，否則呼叫方法在查詢時將過多的try...catch，並且不能進行有效處理。

服務提供方不應該將Dao或SQL等異常拋給消費方，應在服務實現中對消費方不關心的異常進行包裝，否則可能出現消費方無法反序列化相應異常。

在Provider上儘量多配置Consumer端屬性：

作為服務的提供者，比服務使用方更清楚服務效能引數，如呼叫的超時時間，合理的重試次數等

在Provider配置後，Consumer不配置則會使用Provider的配置值，即Provider配置可以作為Consumer的預設值。

否則，Cousumer會使用Consumer端的全域性設定，這對於Provider來說不可控，且往往是不合理的

Provider上儘量多配置Consumer端的屬性，讓Provider實現者一開始就思考Provider服務特點，服務質量的問題。