Dubbo服務化，在當前互聯網后端開發中，大部分都使用了Dubbo。截止目前github dubbo上，star也將近3萬，使用dubbo的公司數量也很可觀，Dubbo確實也是一個比較不錯的服務化框架。下面整理比較不錯的Dubbo服務化最佳實踐，希望可以幫助我們少掉進一些坑，更好的使用Dubbo。

1

分包：公共API

建議將服務接口，服務模型，服務異常等均放在 API 包中，因為服務模型及異常也是 API 的一部分，同時，這樣做也符合分包原則：重用發布等價原則(REP)，共同重用原則(CRP)。如果需要，也可以考慮在 API 包中放置一份 spring 的引用配置，這樣使用方，只需在 spring 加載過程中引用此配置即可，配置建議放在模塊的包目錄下，以免沖突，如：com/alibaba/china/xxx/dubbo-reference.xml。

在互聯網公司開發的過程中，基本上也有一套開發規范，在這方面上也是有要求的，所以對于公共的服務接口、服務異常等，應該存放在公共的API包，這樣有利于復用、減少系統交互之間的成本等。

2

粒度：接口

服務接口盡可能大粒度，每個服務方法應代表一個功能，而不是某功能的一個步驟，否則將面臨分布式事務問題，Dubbo 暫未提供分布式事務支持。服務接口建議以業務場景為單位劃分，并對相近業務做抽象，防止接口數量爆炸。不建議使用過于抽象的通用接口，如：Map query(Map)，這樣的接口沒有明確語義，會給后期維護帶來不便。

接口在設計的時候，要參考面向對象的基本原則，設計時就應該考慮其粒度，方便業務上的理解和擴展。

3

版本：接口升級

每個接口都應定義版本號，為后續不兼容升級提供可能，如：?。建議使用兩位版本號，因為第三位版本號通常表示兼容升級，只有不兼容時才需要變更服務版本。當不兼容時，先升級一半提供者為新版本，再將消費者全部升為新版本，然后將剩下的一半提供者升為新版本。

接口升級在我們開發中也是非常常見的，新舊接口可能同時會存在，所以也存在兼容問題。使用版本號可以幫助我們過度接口的變更，以致達到平滑的上線。

4

兼容性：向后兼容

服務接口增加方法，或服務模型增加字段，可向后兼容，刪除方法或刪除字段，將不兼容，枚舉類型新增字段也不兼容，需通過變更版本號升級。各協議的兼容性不同，參見：服務協議。

跟上面的接口版本升級相關，主要是為接口的兼容考慮，往往都是向后兼容：盡量多加接口方法而不刪除或修改接口方法。

5

枚舉值：枚舉兼容

如果是完備集，可以用 Enum，比如：ENABLE, DISABLE。

如果是業務種類，以后明顯會有類型增加，不建議用 Enum，可以用 String 代替。

如果是在返回值中用了 Enum，并新增了 Enum 值，建議先升級服務消費方，這樣服務提供方不會返回新值。

如果是在傳入參數中用了 Enum，并新增了 Enum 值，建議先升級服務提供方，這樣服務消費方不會傳入新值。

枚舉非常常見，有時可能會增加類型或者刪除類型，甚至修改類型。這樣對我們服務的升級或者變更都會存在很大的問題，比如造成不兼容，可能丟失值或者拋出異常。一般在業務中盡量少用枚舉作為參數或者返回值，而是用String代替。

6

序列化：參數與返回值

服務參數及返回值建議使用 POJO 對象，即通過 setter, getter 方法表示屬性的對象。服務參數及返回值不建議使用接口，因為數據模型抽象的意義不大，并且序列化需要接口實現類的元信息，并不能起到隱藏實現的意圖。服務參數及返回值都必須是 byValue的，而不能是 byReference 的，消費方和提供方的參數或返回值引用并不是同一個，只是值相同，Dubbo 不支持引用遠程對象。

序列化對象序列號建議生成唯一，或者為1L。這樣可能在對象增加字段時造成序列化異常，從而造成服務調用異常，影響生產。(注意)

7

異常：異常處理

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

8

調用：異常捕獲

不要只是因為是 Dubbo 調用，而把調用 try...catch 起來。try...catch 應該加上合適的回滾邊界上。對于輸入參數的校驗邏輯在 Provider 端要有。如有性能上的考慮，服務實現者可以考慮在 API 包上加上服務 Stub 類(本地存根)來完成檢驗。

9

配置相關

9.1、在 Provider 上盡量多配置 Consumer 端屬性☉原因如下：

• 作為服務的提供者，比服務使用方更清楚服務性能參數，如調用的超時時間，合理的重試次數，等等
• 在 Provider 配置后，Consumer 不配置則會使用 Provider 的配置值，即 Provider 配置可以作為 Consumer 的缺省值?1。否則，Consumer 會使用 Consumer 端的全局設置，這對于 Provider 不可控的，并且往往是不合理的

Provider 上盡量多配置 Consumer 端的屬性，讓 Provider 實現者一開始就思考 Provider 服務特點、服務質量的問題。

示例：

interface="com.alibaba.hello.api.HelloService"?version="1.0.0"?ref="helloService"
????timeout="300"?retry="2"?loadbalance="random"?actives="0"
/>interface="com.alibaba.hello.api.WorldService"?version="1.0.0"?ref="helloService"
????timeout="300"?retry="2"?loadbalance="random"?actives="0"?>"findAllPerson"?timeout="10000"?retries="9"?loadbalance="leastactive"?actives="5"?/>

在 Provider 上可以配置的 Consumer 端屬性有：

1.timeout 方法調用超時2.retries 失敗重試次數，缺省是 23.loadbalance 負載均衡算法，缺省是隨機 random。還可以有輪詢 roundrobin、最不活躍優先 leastactive4.actives 消費者端，最大并發調用限制，即當 Consumer 對一個服務的并發調用到上限后，新調用會 Wait 直到超時 在方法上配置 dubbo:method 則并發限制針對方法，在接口上配置 dubbo:service，則并發限制針對服務9.2、Provider 上配置合理的 Provider 端屬性<dubbo:protocol?threads="200"?/>?
<dubbo:service?interface="com.alibaba.hello.api.HelloService"?version="1.0.0"?ref="helloService"executes="200"?>
????<dubbo:method?name="findAllPerson"?executes="50"?/>
dubbo:service>

Provider 上可以配置的 Provider 端屬性有：

1.threads 服務線程池大小;2.executes 一個服務提供者并行執行請求上限，即當 Provider 對一個服務的并發調用到上限后，新調用會 Wait，這個時候 Consumer可能會超時。在方法上配置 dubbo:method 則并發限制針對方法，在接口上配置 dubbo:service，則并發限制針對服務.9.3、配置管理信息目前有負責人信息和組織信息用于區分站點。有問題時便于的找到服務的負責人，至少寫兩個人以便備份。負責人和組織的信息可以在注冊中心的上看到。應用配置負責人、組織：<dubbo:application?owner=”ding.lid,william.liangf”?organization=”intl”?/>

service 配置負責人：

<dubbo:service?owner=”ding.lid,william.liangf”?/>

reference 配置負責人：

<dubbo:reference?owner=”ding.lid,william.liangf”?/>

dubbo:service、dubbo:reference 沒有配置負責人，則使用 dubbo:application 設置的負責人。

9.4、配置 Dubbo 緩存文件提供者列表緩存文件：<dubbo:registry?file=”${user.home}/output/dubbo.cache”?/>

☉注意：

1、文件的路徑，應用可以根據需要調整，保證這個文件不會在發布過程中被清除。

2、如果有多個應用進程注意不要使用同一個文件，避免內容被覆蓋。這個文件會緩存注冊中心的列表和服務提供者列表。有了這項配置后，當應用重啟過程中，Dubbo 注冊中心不可用時則應用會從這個緩存文件讀取服務提供者列表的信息，進一步保證應用可靠性。9.5、不要使用 dubbo.properties 文件配置，推薦使用對應 XML 配置Dubbo 中所有的配置項都可以配置在 Spring 配置文件中，并且可以針對單個服務配置。dubbo.properties 中屬性名與 XML 的對應關系1.應用名 dubbo.application.name<dubbo:application?name="myalibaba"?>

2.注冊中心地址 dubbo.registry.address

?<dubbo:registry?address="11.22.33.44:9090"?>

3.調用超時 dubbo.service.*.timeout

可以在多個配置項設置超時 timeout，由上至下覆蓋(即上面的優先)5，其它的參數(retries、loadbalance、actives等)的覆蓋策略也一樣示例如下：提供者端特定方法的配置<dubbo:service?interface="com.alibaba.xxx.XxxService"?>
?????<dubbo:method?name="findPerson"?timeout="1000"?/>
dubbo:service>

4.服務提供者協議 dubbo.service.protocol、服務的監聽端口 dubbo.service.server.port

<dubbo:protocol?name="dubbo"?port="20880"?/>

5.服務線程池大小 dubbo.service.max.thread.threads.size

<dubbo:protocol?threads="100"?/>

6.消費者啟動時，沒有提供者是否拋異常 Fast-Fail alibaba.intl.commons.dubbo.service.allow.no.provider

interface="com.alibaba.xxx.XxxService"?check="false"?/>

9.6、監控配置

1.使用固定端口暴露服務，而不要使用隨機端口這樣在注冊中心推送有延遲的情況下，消費者通過緩存列表也能調用到原地址，保證調用成功。2.使用 Dragoon 的 http 監控項監控注冊中心上服務提供方Dragoon 監控服務在注冊中心上的狀態：http://dubbo-reg1.hst.xyi.cn.alidc.net:8080/status/com.alibaba.morgan.member.MemberService:1.0.5 確保注冊中心上有該服務的存在。3.服務提供方，使用 Dragoon 的 telnet 或 shell 監控項監控服務提供者端口狀態：echo status | nc -i 1 20880 | grep OK | wc -l，其中的 20880 為服務端口4.服務消費方，通過將服務強制轉型為 EchoService，并調用 $echo() 測試該服務的提供者是可用如 assertEqauls(“OK”, ((EchoService)memberService).$echo(“OK”));在dubbo服務化后端的開發，最佳實踐可以更好的指導我們進行相關的業務開發。對于現實使用中，我們可能會存在沒有按照相關規范，或者可能是開發人員沒有注意到或者不關心接口的升級或者變更、枚舉類型的使用、序列化、異常的處理等，沒有做到前后兼容、異常合適處理等，從而等到上線之后才發現原來之前沒有在這方面考慮的比較周全，所以也造成了線上事故，或者發版延期等問題，這對我們開發人員也是非常不利。所以我們應該要在這方面能夠更加的重視，有了最佳實踐，也是因為有人踩了坑，或者在這方面非常熟練知道這些潛在的問題，可以更好的指導我們，幫助我們盡可能避免踩坑。如果你對Dubbo服務化最佳實踐這方面有所見識，或者曾經遇到了一些坑，歡迎你留言評論，大家一起探討，一起進步吧。

參考資料：

https://www.cnblogs.com/winner-0715/p/8446758.htmlhttp://dubbo.apache.org/zh-cn/docs/user/best-practice.html

---

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的dubbo 无法访问消费端_Dubbo最佳实践，我整理了以下9点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。