1 、設計方式

action->facade->biz->dao

好的Dubbo服務介面設計，並非只是純粹的介面服務化

2.介面型別

簡單的資料查詢介面:action.facade、dao(例根據Id查詢記錄)

帶業務邏輯的資料查詢介面:action、facade、biz、dao(複雜的查詢，帶業務邏輯)

簡單的資料寫入介面：action、facade、dao(簡單資料插入)

帶業務邏輯的資料寫入介面:action、facade、biz、dao(有業務邏輯的資料處理)

同步介面

非同步介面

3.設計原則

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

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

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

例:某一個介面有多個實現，做成一個介面，再在dubbo分組中多實現

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

介面版本:

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

如:

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

介面相容性:

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

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

異常處理:

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

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

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

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

必要的介面輸入引數校驗

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

原因如下:

作為服務的提供者，比服務使用方更清楚服務效能引數，如呼叫的超時時間，合理的重試次數，併發控制數量，負載均衡 ，等等

在Provider配置後，Consumer不配置則會使用Provider的配置值 ，

即Provider配置可以作為Comsumer的預設值，否則，Consumer會使用Consumer端的全域性設定，這對於Provider不可控的，並且往往是不合理的

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

樣例: