1、介面粒度
1.1 服務介面盡可能大粒度，每個服務方法應代表乙個功能，而不是某功能的乙個步驟，否則將面臨分布式事務問題，dubbo暫未提供分布式事務支援。同時可以減少系統間的網路互動。
1.2 服務介面建議以業務場景為單位劃分，並對相近業務做抽象，防止介面數量**。
1.3 不建議使用過於抽象的通用介面，介面名稱的定義應遵循望文生義原則，如：map query(map)，這樣的介面沒有明確語義，會給後期維護帶來不便。
2、介面版本
2.1 每個介面都應定義版本號，為後續不相容公升級提供可能，如：
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實現者一開始就思
考provider服務特點、服務質量的問題
7、服務介面設計與服務子系統劃分過程相互優化
Dubbo之 服務介面的設計原則
action facade biz dao 好的dubbo服務介面設計，並非只是純粹的介面服務化 簡單的資料查詢介面 action.facade dao 例根據id查詢記錄 帶業務邏輯的資料查詢介面 action facade biz dao 複雜的查詢，帶業務邏輯 簡單的資料寫入介面 action...
dubbo介面的呼叫
dubbo是乙個分布式服務框架，致力於提供高效能和透明化的rpc遠端服務呼叫方案，以及soa服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分布式的需求，其實是不需要用的，只有在分布式的時候，才有dubbo這樣的分布式服務框架的需求，並且本質上是個服務呼叫的東東，說白了就是個遠端服務呼叫的...
Dubbo介面的invek資料
使用telnet命令進入控制台 命令 telnet ip 埠 這個埠和ip，可以去dubbo管理控制台中搜尋服務名，然後找到提供者的機器ip 使用invoke命令注入 如果注入的是json 那就直接傳入json串就ok了，如果是基礎資料型別，也可以分別對應引數直接傳 invoke service.m...