action->facade->biz->dao
好的dubbo服務介面設計，並非只是純粹的介面服務化
簡單的資料查詢介面:action.facade、dao(例根據id查詢記錄)
帶業務邏輯的資料查詢介面:action、facade、biz、dao(複雜的查詢，帶業務邏輯)
簡單的資料寫入介面：action、facade、dao(簡單資料插入)
帶業務邏輯的資料寫入介面:action、facade、biz、dao(有業務邏輯的資料處理)
同步介面
非同步介面
服務介面盡可能大粒度，每個服務方法應代表乙個功能，而不是某功能的乙個步驟，否則將地面臨分布式事務問題，
dubbo暫未提供分布式事務支援，同時可以減少系統間的網路互動
服務介面建議以業務場景為單位劃分，並對相近的業務做抽象,防止介面數量爆增(**)。
例:某乙個介面有多個實現，做成乙個介面，再在dubbo分組中多實現
不建議使用過於抽象的通用介面，如map query(map),這樣的介面沒有明確語義，會給後期維護帶來不便
介面版本:
每個介面應定義版本號，為後續不相容公升級提供可能 如:
服務介面增加方法，或服務模型增加字段，可向後相容；
刪除方法或刪除字段，將不相容，列舉型別新增欄位也不相容，需要通過變更版本號公升級。
異常處理:
建議使用異常匯報錯誤，而不是返回錯誤碼，異常資訊能攜帶更多的資訊，以及語義更友好。
如果擔心效能問題，在必要時，可以通過override掉異常類的finlllnstacktrace()方法為空方法，使其不拷貝棧資訊。
查詢方法不建議丟擲checked異常，否則呼叫 方在查詢 時將過多的try...catch,並且不能進行有效處理。
服務提供方不應將dao或者sql等異常拋給消費方，應在服務實現中對消費方不關心的異常進行包裝，否則可能出現消費方無法反序列化相應異常必要的介面輸入引數校驗
在provider上盡量多配置consumer端屬性:
原因如下:
作為服務的提供者，比服務使用方更清楚服務效能引數，如呼叫的超時時間，合理的重試次數，併發控制數量，負載均衡 ，等等
在provider配置後，consumer不配置則會使用provider的配置值 ，
即provider配置可以作為comsumer的預設值，否則，consumer會使用consumer端的全域性設定，這對於provider不可控的，並且往往是不合理的
provider上盡量多配置consumer端的屬性，讓provider實現者一開始就思考provider服務特點、服務質量的問題
樣例:
Dubbo服務介面的設計原則
1 介面粒度 1.1 服務介面盡可能大粒度，每個服務方法應代表乙個功能，而不是某功能的乙個步驟，否則將面臨分布式事務問題，dubbo暫未提供分布式事務支援。同時可以減少系統間的網路互動。1.2 服務介面建議以業務場景為單位劃分，並對相近業務做抽象，防止介面數量 1.3 不建議使用過於抽象的通用介面，...
dubbo介面的呼叫
dubbo是乙個分布式服務框架，致力於提供高效能和透明化的rpc遠端服務呼叫方案，以及soa服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分布式的需求，其實是不需要用的，只有在分布式的時候，才有dubbo這樣的分布式服務框架的需求，並且本質上是個服務呼叫的東東，說白了就是個遠端服務呼叫的...
設計原則之介面隔離原則
定義 客戶端不應該依賴它不需要的介面 類間的依賴關小應該建立在最小的介面上 什麼是介面？1.例項介面 person zhangsan newperson 類person就是zhangsan的例項介面。2.類介面，就是通常意義上，用inte ce關鍵字定義的介面。解釋 根據介面隔離原則的定義 事實上就...