服務接口建議以業務場景為單位劃分,並對相近的業務做抽象,防止接口數量爆增(爆炸)。
例:某一個接口有多個實現,做成一個接口,再在dubbo分組中多實現
不建議使用過於抽象的通用接口,如Map query(Map),這樣的接口沒有明確語義,會給後期維護帶來不便
每個接口應定義版本號,為後續不兼容升級提供可能
如:
<service>接口兼容性:服務接口增加方法,或服務模型增加字段,可向後兼容;刪除方法或刪除字段,將不兼容,枚舉類型新增字段也不兼容,需要通過變更版本號升級。異常處理:建議使用異常彙報錯誤,而不是返回錯誤碼,異常信息能攜帶更多的信息,以及語義更友好。如果擔心性能問題,在必要時,可以通過override掉異常類的finlllnStackTrace()方法為空方法,使其不拷貝棧信息。查詢方法不建議拋出checked異常,否則調用 方在查詢 時將過多的try...catch,並且不能進行有效處理。服務提供方不應將DAO或者SQL等異常拋給消費方,應在服務實現中對消費方不關心的異常進行包裝,否則可能出現消費方無法反序列化相應異常必要的接口輸入參數校驗在Provider上儘量多配置Consumer端屬性:原因如下:作為服務的提供者,比服務使用方更清楚服務性能參數,如調用的超時時間,合理的重試次數,併發控制數量,負載均衡 ,等等在Provider配置後,Consumer不配置則會使用Provider的配置值 ,即Provider配置可以作為Comsumer的缺省值,否則,Consumer會使用Consumer端的全局設置,這對於Provider不可控的,並且往往是不合理的-Provider上儘量多配置Consumer端的屬性,讓Provider實現者一開始就思考Provider服務特點、服務質量的問題
架構師進階
想要學習Dubbo框架、zookeper基本原理、redis分佈式緩存、JVM性能優化,Nginx+apache+Tomcat集群部署、大數據hadoop,Hbase實時計算spark、storm、數據分析分詞和權重等核心技術;需要的可以關注之後私信哈,記得要點贊轉發噢!!!