原因如下：
provider 上盡量多配置 consumer 端的屬性，讓 provider 實現者一開始就思考 provider 服務特點、服務質量的問題。
示例：inte***ce="com.alibaba.hello.api.helloservice"
version="1.0.0"
ref="helloservice"
timeout="300"
retry="2"
loadbalance="random"
actives="0"/>
inte***ce="com.alibaba.hello.api.worldservice"
version="1.0.0"
ref="helloservice"
timeout="300"
retry="2"
loadbalance="random"
actives="0" >
name="findallperson"
timeout="10000"
retries="9"
loadbalance="leastactive"
actives="5" />
在 provider 上可以配置的 consumer 端屬性有：
timeout方法呼叫超時
retries失敗重試次數，預設是 2 [2]
loadbalance負載均衡演算法 [3]，預設是隨機random。還可以有輪詢roundrobin、最不活躍優先 [4]leastactive
actives消費者端，最大併發呼叫限制，即當 consumer 對乙個服務的併發呼叫到上限後，新呼叫會 wait 直到超時 在方法上配置dubbo:method則併發限制針對方法，在介面上配置dubbo:service，則併發限制針對服務
說明一點：關於配置優先順序：
1. 方法級優先，介面級次之，全域性配置再次之。
2. 如果級別一樣，則消費方優先，提供方次之。
threads="200" />
inte***ce=
"com.alibaba.hello.api.helloservice"
version="1.0.0"
ref="helloservice"
executes="200" >
name="findallperson"
executes="50" />
dubbo:service>
provider 上可以配置的 provider 端屬性有：
threads服務執行緒池大小
executes乙個服務提供者並行執行請求上限，即當 provider 對乙個服務的併發呼叫到上限後，新呼叫會 wait，這個時候 consumer可能會超時。在方法上配置dubbo:method則併發限制針對方法，在介面上配置dubbo:service，則併發限制針對服務
目前有負責人資訊和組織資訊用於區分站點。有問題時便於的找到服務的負責人，至少寫兩個人以便備份。負責人和組織的資訊可以在註冊中心的上看到。
應用配置負責人、組織：
應用配置負責人、組織：
service 配置負責人：
檔案的路徑，應用可以根據需要調整，保證這個檔案不會在發布過程中被清除。
如果有多個應用程序注意不要使用同乙個檔案，避免內容被覆蓋。
這個檔案會快取註冊中心的列表和服務提供者列表。有了這項配置後，當應用重啟過程中，dubbo 註冊中心不可用時則應用會從這個快取檔案讀取服務提供者列表的資訊，進一步保證應用可靠性。
使用固定埠暴露服務，而不要使用隨機埠
這樣在註冊中心推送有延遲的情況下，消費者通過快取列表也能呼叫到原位址，保證呼叫成功。
使用 dragoon 的 http 監控項監控註冊中心上服務提供方
dragoon 監控服務在註冊中心上的狀態： 確保註冊中心上有該服務的存在。
服務提供方，使用 dragoon 的 telnet 或 shell 監控項
監控服務提供者埠狀態：echo status | nc -i 1 20880 | grep ok | wc -l，其中的 20880 為服務埠
服務消費方，通過將服務強制轉型為 echoservice，並呼叫$echo()測試該服務的提供者是可用
如asserteqauls(「ok」, ((echoservice)memberservice).$echo(「ok」));
dubbo 中所有的配置項都可以配置在 spring 配置檔案中，並且可以針對單個服務配置。
如完全不配置則使用 dubbo 預設值，參見 dubbo配置參考手冊 中的說明。
註冊中心位址dubbo.registry.address
呼叫超時dubbo.service.*.timeout
可以在多個配置項設定超時timeout，由上至下覆蓋（即上面的優先）[5]，其它的引數（retries、loadbalance、actives等）的覆蓋策略也一樣示例如下：
提供者端特定方法的配置
服務提供者協議dubbo.service.protocol、服務的監聽埠dubbo.service.server.port
服務執行緒池大小dubbo.service.max.thread.threads.size
消費者啟動時，沒有提供者是否拋異常 fast-failalibaba.intl.commons.dubbo.service.allow.no.provider
配置的覆蓋規則：1) 方法級別配置優於介面級別，即小 scope 優先 2) consumer 端配置優於 provider 配置，優於全域性配置，最後是dubbo 硬編碼的配置值（dubbo 配置參考手冊） ↩︎
表示加上第一次呼叫，會呼叫 3 次 ↩︎
有多個 provider 時，如何挑選 provider 呼叫 ↩︎
指從 consume r端併發呼叫最好的 provider，可以減少的反應慢的 provider 的呼叫，因為反應更容易累積併發的呼叫 ↩︎
Dubbo 如何使用Dubbo
如上圖所示，dubbo的設計結構如上所示。包含服務消費者 consumer 服務提供者 provider 註冊中心 registry 監控中心 monitor 紫色箭頭代表初始化時的動作 藍色虛線箭頭代表非同步動作 藍色實線箭頭代表同步動作 1 配置乙個zookeeper為註冊中心，也可以使用red...
Dubbo系列之 Dubbo入門介紹
分布式soa服務治理框架dubbo 背景 隨著網際網路的發展，應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需乙個治理系統確保架構有條不紊的演進。比較常用的分布式服務治理框架也有很多，比如著名的spring cloud dubbo等 spring clo...
dubbo總結 dubbo的使用
dubbo是乙個微服務框架，dubbo也是有乙個服務註冊中心 zookeeper 服務提供者以及服務消費者。服務提供者需要乙個暴露介面的工程，用來服務消費的呼叫。服務提供者的介面實現類繼承暴露介面工程的介面。dubbo呼叫流程 1.服務容器負責啟動，載入，執行服務提供者 2.服務提供者在啟動時，向註...