Dubbo之旅--問題匯總

    在工作和學(xué)習(xí)的進程中,具體應(yīng)用Dubbo的時候遇到了很多的問題,這些問題1方面讓自己進1步了解所謂的dubbo,另外一方面通過對它們的總結(jié)和分析能夠在工作中加倍的提高效力,接下來將會對遇到的和他人總結(jié)的1些常見的問題進行匯總.

1.增加提供服務(wù)版本號和消費服務(wù)版本號.

        這個具體來講不算是1個問題,而是1種問題的解決方案,在我們的實際工作中會面臨各種環(huán)境資源短缺的問題,也是很實際的問題,剛開始我們還可以提供1個服務(wù)進行相干的開發(fā)和測試,但是當(dāng)有多個環(huán)境多個版本,多個任務(wù)的時候就不滿足我們的需求,這時候候我們可以通過給提供方增加版本的方式來辨別.這樣能夠剩下很多的物理資源,同時為今后更換接口定義發(fā)布在線時，可不停機發(fā)布，使用版本號.

        援用只會找相應(yīng)版本的服務(wù),例如

<dubbo:serviceinterface=“com.xxx.XxxService”ref=“xxxService” version=“1.0” />

<dubbo:referenceid=“xxxService”interface=“com.xxx.XxxService” version=“1.0”/>

dubbo服務(wù)的版本號在項目中非常實用,如果后續(xù)系列允許的話,我會專門對dubbo的版本進行1個詳細的文章說明.

2.dubbo reference注解問題

       @Reference只能在springbean實例對應(yīng)確當(dāng)前類中使用，暫時沒法在父類使用；如果確切要在父類聲明1個援用，可通過配置文件配置dubbo:reference，然后在需要援用的地方跟援用springbean1樣就能夠了.

3.服務(wù)超時問題.

此問題也是在項目中非常常見的1個問題,但是這個問題背后多是各種緣由致使.

         目前如果存在超時，情況基本都在以下：

(1) 1種情況是服務(wù)要求超時.

       客戶端耗時大，也就是超時異常時的client elapsedxxx，這個是從創(chuàng)建Future對象開始到使用channel發(fā)出要求的這段時間，中間沒有復(fù)雜操作，只要CPU沒問題基本不會出現(xiàn)大耗時，頂多1ms屬于正常IOThread繁忙，默許情況下，dubbo協(xié)議1個客戶端與1個服務(wù)提供者會建立1個同享長連接，如果某個客戶端處于特別繁忙而且1直往1個服務(wù)提供者塞要求，可能造成IOThread阻塞，1般非常特殊的情況才會出現(xiàn)服務(wù)端工作線程池中線程全部繁忙，接收消息后塞入隊列等待，如果等待時間比料想長會引發(fā)超時網(wǎng)絡(luò)抖動，如果上述情況都排除，還出現(xiàn)在要求發(fā)出后，服務(wù)接收要求前超過料想時間，只能歸類到網(wǎng)絡(luò)抖動了，需要SA1起查看問題服務(wù)本身耗時大，這個需要利用本身做好耗時統(tǒng)計，當(dāng)出現(xiàn)這類情況的時候需要用數(shù)據(jù)來講明問題及計劃優(yōu)化方案，建議采取緩存埋點的方式統(tǒng)計服務(wù)中各個履行階段的耗時情況，終究如果超過料想時間則把緩存統(tǒng)計的耗時情況打日志，減少日志量，且能夠得到更明確的信息現(xiàn)在我們利用使用進程中發(fā)現(xiàn)兩種類型的耗時，1種我們目前只能歸類到網(wǎng)絡(luò)抖動，后續(xù)需要找運維1起關(guān)注這個問題，另外1種是由于1些歷史緣由，數(shù)據(jù)庫查詢?nèi)菀桩a(chǎn)生抖動，總有1個時間點會突然多出很多超時。

        (2) 2大類的情況是調(diào)用的版本不對.

在上面我們已說了具體的版本問題,如果你調(diào)用的對方版本不對的話,就相當(dāng)于你的消費者沒有提供者.所以會出現(xiàn)超時,此時只需要把版本對應(yīng)好便可.

(3)提供者的服務(wù)被制止.

這是1種人為的控制,通過監(jiān)控中心我們可以對具體的服務(wù),和它的權(quán)重進行控制,當(dāng)我將1個具體的服務(wù)制止以后消費者就調(diào)不到相干的服務(wù),此時就會出現(xiàn)超時的問題.解決方案,取消制止便可.注意這里有1定時間的緩存,實際操作的時候應(yīng)當(dāng)注意.

4.服務(wù)保護

         服務(wù)保護的原則上是避免產(chǎn)生類似雪崩效應(yīng)，盡可能將異常控制在服務(wù)周圍，不要分散開。說到雪崩效應(yīng)，還得提下dubbo本身的重試機制，默許3次，當(dāng)失敗時會進行重試，這樣在某個時間點出現(xiàn)性能問題，然后調(diào)用方再連續(xù)重復(fù)調(diào)用，很容易引發(fā)雪崩，建議的話還是很據(jù)業(yè)務(wù)情況計劃好如何進行異常處理，什么時候進行重試。服務(wù)保護的話 斟酌服務(wù)的dubbo線程池類型（fix線程池的話斟酌線程池大小）、數(shù)據(jù)庫連接池、dubbo連接數(shù)限制是不是都適合.

5.注冊中心的分組group和服務(wù)的不同實現(xiàn)group

           這兩個東西完全不同的概念，使用的時候不要弄混了。registry上可以配置group，用于辨別不同分組的注冊中心，比如在同1個注冊中心下，有1部份注冊信息是要給開發(fā)環(huán)境用的，有1部份注冊信息時要給測試環(huán)境用的，可以分別用不同的group辨別開，目前對這個理解還不透徹，大致就是用于辨別不同環(huán)境。service和reference上也能夠配置group，這個用于辨別同1個接口的不同實現(xiàn)，只有在reference上指定與service相同的group才會被發(fā)現(xiàn)。

        以上為5類我們所遇到的問題,總結(jié)下來為了以后的路走的更順暢.

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機掃描二維碼進行捐贈