服務化最佳實踐
分包
建議將服務接口、服務模型、服務異常等均放在 API 包中，因爲服務模型和異常也是 API 的一部分，這樣做也符合分包原則：重用發佈等價原則(REP)，共同重用原則(CRP)。
如果需要，也可以考慮在 API 包中放置一份 Spring 的引用配置，這樣使用方只需在 Spring 加載過程中引用此配置即可。配置建議放在模塊的包目錄下，以免衝突，如：com/alibaba/china/xxx/dubbo-reference.xml。
Maven 聚合項目改造
公用的接口、工具類、實體類等抽取出API項目獨立維護更新
每次更新後需要install
粒度
服務接口儘可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將面臨分佈式事務問題，Dubbo 暫未提供分佈式事務支持。
服務接口建議以業務場景爲單位劃分，並對相近業務做抽象，防止接口數量爆炸。
不建議使用過於抽象的通用接口，如：Map query(Map)，這樣的接口沒有明確語義，會給後期維護帶來不便。
版本
每個接口都應定義版本號，爲後續不兼容升級提供可能，如： <dubbo:service interface=“com.xxx.XxxService” version=“1.0” />。
建議使用兩位版本號，因爲第三位版本號通常表示兼容升級，只有不兼容時才需要變更服務版本。
當不兼容時，先升級一半提供者爲新版本，再將消費者全部升爲新版本，然後將剩下的一半提供者升爲新版本。
兼容性
服務接口增加方法，或服務模型增加字段，可向後兼容，刪除方法或刪除字段，將不兼容，枚舉類型新增字段也不兼容，需通過變更版本號升級。
枚舉值
如果是完備集，可以用 Enum，比如：ENABLE, DISABLE。
如果是業務種類，以後明顯會有類型增加，不建議用 Enum，可以用 String 代替。
如果是在返回值中用了 Enum，並新增了 Enum 值，建議先升級服務消費方，這樣服務提供方不會返回新值。
如果是在傳入參數中用了 Enum，並新增了 Enum 值，建議先升級服務提供方，這樣服務消費方不會傳入新值。
序列化
服務參數及返回值建議使用 POJO 對象，即通過 setter, getter 方法表示屬性的對象。
服務參數及返回值不建議使用接口，因爲數據模型抽象的意義不大，並且序列化需要接口實現類的元信息，並不能起到隱藏實現的意圖。
服務參數及返回值都必須是傳值調用，而不能是傳引用調用，消費方和提供方的參數或返回值引用並不是同一個，只是值相同，Dubbo 不支持引用遠程對象。
異常
建議使用異常彙報錯誤，而不是返回錯誤碼，異常信息能攜帶更多信息，並且語義更友好。
如果擔心性能問題，在必要時，可以通過 override 掉異常類的 fillInStackTrace() 方法爲空方法，使其不拷貝棧信息。
查詢方法不建議拋出 checked 異常，否則調用方在查詢時將過多的 try…catch，並且不能進行有效處理。
服務提供方不應將 DAO 或 SQL 等異常拋給消費方，應在服務實現中對消費方不關心的異常進行包裝，否則可能出現消費方無法反序列化相應異常。
調用
不要只是因爲是 Dubbo 調用，而把調用 try…catch 起來。try…catch 應該加上合適的回滾邊界上。
Provider 端需要對輸入參數進行校驗。如有性能上的考慮，服務實現者可以考慮在 API 包上加上服務 Stub 類來完成檢驗。
在 Provider 端儘量多配置 Consumer 端屬性
原因如下：
作服務的提供方，比服務消費方更清楚服務的性能參數，如調用的超時時間、合理的重試次數等
在 Provider 端配置後，Consumer 端不配置則會使用 Provider 端的配置，即 Provider 端的配置可以作爲 Consumer 的缺省值 [1]。
否則，Consumer 會使用 Consumer 端的全局設置，這對於 Provider 是不可控的，並且往往是不合理的
Provider 端儘量多配置 Consumer 端的屬性，讓 Provider 的實現者一開始就思考 Provider 端的服務特點和服務質量等問題。
建議在 Provider 端配置的 Consumer 端屬性
- timeout：方法調用的超時時間
- retries：失敗重試次數，缺省是 2
- loadbalance：負載均衡算法，缺省是隨機 random + 權重。還可以配置輪詢 roundrobin、最不活躍優先 leastactive 和一致性哈希 consistenthash 等
- actives：消費者端的最大併發調用限制，即當 Consumer 對一個服務的併發調用到上限後，新調用會阻塞直到超時，
- 在方法上配置 dubbo:method 則針對該方法進行併發限制，
- 在接口上配置 dubbo:service，則針對該服務進行併發限制
- executes服務提供方可以使用的最大線程數
- 在 Provider 端配置合理的 Provider 端屬性
建議在 Provider 端配置的 Provider 端屬性有：
- threads：服務線程池大小
- executes：一個服務提供者並行執行請求上限，即當 Provider 對一個服務的併發調用達到上限後，新調用會阻塞，此時 Consumer 可能會超時。
- 在方法上配置 dubbo:method 則針對該方法進行併發限制，
- 在接口上配置 dubbo:service，則針對該服務進行併發限制
項目中多個模塊間公共依賴的版本號、scope的控制
配置 Dubbo 緩存文件
提供者列表緩存文件：
<dubbo:registry file=”${user.home}/output/dubbo.cache” />
dubbo.registry.file=c:/output/dubbo.cache
注意：
- 可以根據需要調整緩存文件的路徑，保證這個文件不會在發佈過程中被清除；
- 如果有多個應用進程，請注意不要使用同一個文件，避免內容被覆蓋；
該文件會緩存註冊中心列表和服務提供者列表。配置緩存文件後，應用重啓過程中，若註冊中心不可用，應用會從該緩存文件讀取服務提供者列表，進一步保證應用可靠性。