dubbo服務化最佳實踐，官方提供的解決方法：
分包
建議將服務接口，服務模型，服務異常等均放在API包中，因爲服務模型及異常也是API的一部分，
同時，這樣做也符合分包原則：重用發佈等價原則(REP)，共同重用原則(CRP)
如果需要，也可以考慮在API包中放置一份spring的引用配置，這樣使用方，只需在Spring加載過程中引用此配置即可，
配置建議放在模塊的包目錄下，以免衝突，如：com/alibaba/china/xxx/dubbo-reference.xml
粒度
服務接口儘可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將面臨分佈式事務問題，Dubbo暫未提供分佈式事務支持。
服務接口建議以業務場景爲單位劃分，並對相近業務做抽象，防止接口數量爆炸
不建議使用過於抽象的通用接口，如：Map
query(Map)，這樣的接口沒有明確語義，會給後期維護帶來不便。
版本
每個接口都應定義版本號，爲後續不兼容升級提供可能，如：<dubbo:serviceinterface="com.xxx.XxxService"version="1.0">
建議使用兩位版本號，因爲第三位版本號通常表示兼容升級，只有不兼容時才需要變更服務版本。
當不兼容時，先升級一半提供者爲新版本，再將消費者全部升爲新版本，然後將剩下的一半提供者升爲新版本。
兼容性
服務接口增加方法，或服務模型增加字段，可向後兼容，刪除方法或刪除字段，將不兼容，枚舉類型新增字段也不兼容，需通過變更版本號升級。
各協議的兼容性不同，參見：
服務協議
枚舉值
如果是完備集，可以用Enum，比如：ENABLE,
DISABLE。
如果是業務種類，以後明顯會有類型增加，不建議用Enum，可以用String代替。
如果是在返回值中用了Enum，並新增了Enum值，建議先升級服務消費方，這樣服務提供方不會返回新值。
如果是在傳入參數中用了Enum，並新增了Enum值，建議先升級服務提供方，這樣服務消費方不會傳入新值。
序列化
服務參數及返回值建議使用POJO對象，即通過set,get方法表示屬性的對象。
服務參數及返回值不建議使用接口，因爲數據模型抽象的意義不大，並且序列化需要接口實現類的元信息，並不能起到隱藏實現的意圖。
服務參數及返回值都必需是byValue的，而不能是byRef的，消費方和提供方的參數或返回值引用並不是同一個，只是值相同，Dubbo不支持引用遠程對象。
異常
建議使用異常彙報錯誤，而不是返回錯誤碼，異常信息能攜帶更多信息，以及語義更友好，
如果擔心性能問題，在必要時，可以通過override掉異常類的fillInStackTrace()方法爲空方法，使其不拷貝棧信息，
查詢方法不建議拋出checked異常，否則調用方在查詢時將過多的try...catch，並且不能進行有效處理，
服務提供方不應將DAO或SQL等異常拋給消費方，應在服務實現中對消費方不關心的異常進行包裝，否則可能出現消費方無法反序列化相應異常。
調用
不要只是因爲是Dubbo調用，而把調用Try-Catch起來。Try-Catch應該加上合適的回滾邊界上。
對於輸入參數的校驗邏輯在Provider端要有。如有性能上的考慮，服務實現者可以考慮在API包上加上服務Stub類來完成檢驗。
參看dubbo官方文檔
