Dubbo的服務延遲暴露

如果我們的服務啟動過程中需要預熱事件（再啟動一段時間后性能才能到達最佳狀態）比如初始化緩存，等待相關資源就位等，可以使用deplay進行延遲暴露

如上所示：我們只需要在服務的提供方的<dubbo:service />標簽中添加delay屬性，單位毫秒

若值為正數，則表示延遲暴露多少毫秒，在指定時間后再發布服務，

若值為-1,則表示在spring初始化完成后暴露服務

Dubbo的多注冊中心

很多時候一個項目會有多個注冊中心

同一個服務注冊到多個注冊中心_[一對多]

同一個服務可以注冊到多個不同地域的注冊中心，為多個不同地域的服務提供服務

修改服務提供者的配置文件，多個注冊中心之間使用逗號分割，如下：

　　

當然第二個集群是假的，知道牛啃南瓜怎么下嘴就行？當然你也可以使用ZK單機模式演示

不同的服務注冊到不同的注冊中心_[一對一]

一個項目中，不同的服務可以注冊不同的注冊中心：如下

　　

同一個服務引用自不同的注冊中心_[多對一]

同一個消費者需要調用兩個注冊中心的服務，而被調用的服務的接口名，版本號，分組等是相同的，不同中心的這個相同名稱的服務CURD的是不同的數據庫，即服務名相同，但是實現是不同的，修改服務消費者如下：

　　

Dubbo的多協議支持

服務暴露協議

在我們前面的Demo中，服務提供者和服務的消費者是通過zookeepeer連接協議連接上Zookeeper注冊中心的

　　

為什么服務的提供者和消費者連接上Zookeeper，消費者就可以消費服務了呢？

• zookeeper協議：是提供者/消費者連接注冊中心的連接協議，并不是提供者和消費者之間的連接協議

• 當消費者連接上注冊中心后，在消費服務之前，首先需要連接上這個服務的提供者，雖然服務的消費者可以通過注冊中心獲取到服務提供者，但提供者對于消費者來說確實透明的，消費者并不知道真正的服務提供者是誰，不過無論服務的提供者是誰，消費者都需要連接上服務的提供者才可以獲取到真正的服務，而這個連接也是需要專門的鏈接協議的，這個協議被稱為服務的暴露協議

• 在我們之前的Demo中并沒有看到服務暴露協議的相關配置，項目也是可以運行，因為Dubbo采用了默認的暴露協議，Dubbo服務暴露協議

• Dubbo服務暴露協議，適用于小數據量大并發的服務調用，以及服務消費者主機數遠遠大于服務提供者主機的情況，服務提供少，需求多，單個主機應對高并發。

• 了解內容：除了Dubbo服務暴露協議，Dubbo框架還支持另外七種服務暴露協議，Hessian協議，Http協議，RMI協議，WebService協議，THrift協議，Memcached協議，Redis協議，在實際中使用最多的就是Dubbo服務暴露協議

服務暴露協議用法

下面我們以Dubbo服務暴露協議作為列子來說明服務暴露協議的用法

在服務的提供者的Spring配置文件中注冊服務暴露協議，

然后在暴露服務時具體指定所使用的已經被注冊的暴露協議

　　　　

二、同一服務支持多種協議（修改服務提供者的配置文件）

　　

三、不同服務使用不同的協議（修改服務提供者的配置文件）

　　

牛啃南瓜知道怎么啃就行，這里我就沒做過多的演示

Dubbo的高級設置以及使用建議

在Provider上盡量多的配置Consumer端的屬性

使得Provider實現著一開始就考慮到Provider的服務特點、服務質量等問題，因為作為服務的提供者比服務的消費者更加清楚服務的性能參數，如調用的超時時間，合理的重試次數等，在Provider配置后，Consumer不配置則會默認使用Provider端的配置值，如果Consumer沒有配置，Provider也沒有配置，就會使用Consumer端的全局設置，這對于Provider而言是不可控的，也是不合理的

　　

粒度到可以針對某一個服務也可以針對服務的同時針對某一個方法（hello方法）

• timeout：遠程服務調用超時的時限

• retries：失敗重試次數，默認為2

• loadbalance：負載均衡算法，默認是隨機random，還可以選擇輪詢(roundrobin)、最不活躍優先(leastactive)等

• actives：消費者最大并發調用限制，達到上限后，新的調用會被阻塞直到超時，0表示不限制

Provider端配置合理的Provider端屬性

　　

threads：用于指定服務的線程池大小

executes：一個服務并行執行的請求上限，超過上限，新請求肯定被阻塞，可能阻塞到超時，該屬性在<dubbo：method/>則是針對指定的方法，配置在<dubbo：service />上則是針對整個服務

常用性能調優參數（來自網絡）

參數名	作用范圍	默認值	說明	備注
threads	provider	200	業務處理線程池大小	?
iothreads	provider	CPU+1	io線程池大小	?
queues	provider	0	線程池隊列大小，當線程池滿時，排隊等待執行的隊列大小， 建議不要設置，當線程程池時應立即失敗， 重試其它服務提供機器，而不是排隊，除非有特殊需求	?
connections	consumer	0	對每個提供者的最大連接數， rmi、http、hessian等短連接協議表示限制連接數， Dubbo等長連接協表示建立的長連接個數	Dubbo協議默認共享一個長連接
actives	consumer	0	每服務消費者每服務每方法最大并發調用數	0表示不限制
acceptes	provider	0	服務提供方最大可接受連接數	0表示不限制
executes	provider	0	服務提供者每服務每方法最大可并行執行請求數	0表示不限制

轉載于:https://www.cnblogs.com/msi-chen/p/11094581.html

總結

以上是生活随笔為你收集整理的Dubbo的核心玩法三的全部內容，希望文章能夠幫你解決所遇到的問題。

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