作爲一名java架構師使用dubbo應該注意什麼？

1. 設計方式
2. action->facade->biz->dao
3. 好的Dubbo服務接口設計，並非只是純粹的接口服務化
4. 接口類型
5. 簡單的數據查詢接口:action. facade、dao(例根據Id查詢記錄)
6. 帶業務邏輯的數據查詢接口:action、facade、biz、dao(複雜的查詢，帶業務邏輯)
7. 簡單的數據寫入接口：action、facade、dao(簡單數據插入)
8. 帶業務邏輯的數據寫入接口:action、facade、biz、dao(有業務邏輯的數據處理)
9. 同步接口
10. 異步接口
11. 設計原則
12. 服務接口儘可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將地面臨分佈式事務問題，
13. Dubbo暫未提供分佈式事務支持，同時可以減少系統間的網絡交互

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

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

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

1. 接口版本:

每個接口應定義版本號，為後續不兼容升級提供可能

如:

1. 接口兼容性:
2. 服務接口增加方法，或服務模型增加字段，可向後兼容；
3. 刪除方法或刪除字段，將不兼容，枚舉類型新增字段也不兼容，需要通過變更版本號升級。
4. 異常處理:

• 建議使用異常彙報錯誤，而不是返回錯誤碼，異常信息能攜帶更多的信息，以及語義更友好。
• 如果擔心性能問題，在必要時，可以通過override掉異常類的finlllnStackTrace()方法為空方法，使其不拷貝棧信息。
• 查詢方法不建議拋出checked異常，否則調用 方在查詢 時將過多的try...catch,並且不能進行有效處理。
• 服務提供方不應將DAO或者SQL等異常拋給消費方，應在服務實現中對消費方不關心的異常進行包裝，否則可能出現消費方無法反序列化相應異常
• 必要的接口輸入參數校驗

1. 在Provider上儘量多配置Consumer端屬性:
2. 原因如下:

• 作為服務的提供者，比服務使用方更清楚服務性能參數，如調用的超時時間，合理的重試次數，併發控制數量，負載均衡 ，等等
• 在Provider配置後，Consumer不配置則會使用Provider的配置值 ，
• 即Provider配置可以作為Comsumer的缺省值，否則，Consumer會使用Consumer端的全局設置，這對於Provider不可控的，並且往往是不合理的
• -Provider上儘量多配置Consumer端的屬性，讓Provider實現者一開始就思考Provider服務特點、服務質量的問題

架構師進階

想要學習Dubbo框架、zookeper基本原理、redis分佈式緩存、JVM性能優化，Nginx+apache+Tomcat集群部署、大數據hadoop,Hbase實時計算spark、storm、數據分析分詞和權重等核心技術；需要的可以關注之後私信哈，記得要點贊轉發噢！！！

閱讀更多 IT技術分享 的文章

關鍵字: Hadoop 接口 架構師