Dubbo的服務(wù)延遲暴露

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

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

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

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

Dubbo的多注冊中心

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

同一個服務(wù)注冊到多個注冊中心_[一對多]

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

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

　　

當(dāng)然第二個集群是假的，知道?？心瞎显趺聪伦炀托?#xff1f;當(dāng)然你也可以使用ZK單機模式演示

不同的服務(wù)注冊到不同的注冊中心_[一對一]

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

　　

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

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

　　

Dubbo的多協(xié)議支持

服務(wù)暴露協(xié)議

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

　　

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

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

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

• 在我們之前的Demo中并沒有看到服務(wù)暴露協(xié)議的相關(guān)配置，項目也是可以運行，因為Dubbo采用了默認(rèn)的暴露協(xié)議，Dubbo服務(wù)暴露協(xié)議

• Dubbo服務(wù)暴露協(xié)議，適用于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費者主機數(shù)遠(yuǎn)遠(yuǎn)大于服務(wù)提供者主機的情況，服務(wù)提供少，需求多，單個主機應(yīng)對高并發(fā)。

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

服務(wù)暴露協(xié)議用法

下面我們以Dubbo服務(wù)暴露協(xié)議作為列子來說明服務(wù)暴露協(xié)議的用法

在服務(wù)的提供者的Spring配置文件中注冊服務(wù)暴露協(xié)議，

然后在暴露服務(wù)時具體指定所使用的已經(jīng)被注冊的暴露協(xié)議

　　　　

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

　　

三、不同服務(wù)使用不同的協(xié)議（修改服務(wù)提供者的配置文件）

　　

?？心瞎现涝趺纯芯托?#xff0c;這里我就沒做過多的演示

Dubbo的高級設(shè)置以及使用建議

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

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

　　

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

• timeout：遠(yuǎn)程服務(wù)調(diào)用超時的時限

• retries：失敗重試次數(shù)，默認(rèn)為2

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

• actives：消費者最大并發(fā)調(diào)用限制，達(dá)到上限后，新的調(diào)用會被阻塞直到超時，0表示不限制

Provider端配置合理的Provider端屬性

　　

threads：用于指定服務(wù)的線程池大小

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

常用性能調(diào)優(yōu)參數(shù)（來自網(wǎng)絡(luò)）

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

轉(zhuǎn)載于:https://www.cnblogs.com/msi-chen/p/11094581.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。