在工作和學習的進程中,具體應用Dubbo的時候遇到了很多的問題,這些問題1方面讓自己進1步了解所謂的dubbo,另外一方面通過對它們的總結和分析能夠在工作中加倍的提高效力,接下來將會對遇到的和他人總結的1些常見的問題進行匯總.
1.增加提供服務版本號和消費服務版本號.
這個具體來講不算是1個問題,而是1種問題的解決方案,在我們的實際工作中會面臨各種環境資源短缺的問題,也是很實際的問題,剛開始我們還可以提供1個服務進行相干的開發和測試,但是當有多個環境多個版本,多個任務的時候就不滿足我們的需求,這時候候我們可以通過給提供方增加版本的方式來辨別.這樣能夠剩下很多的物理資源,同時為今后更換接口定義發布在線時,可不停機發布,使用版本號.
援用只會找相應版本的服務,例如
<dubbo:serviceinterface=“com.xxx.XxxService”ref=“xxxService” version=“1.0” />
<dubbo:referenceid=“xxxService”interface=“com.xxx.XxxService” version=“1.0”/>
dubbo服務的版本號在項目中非常實用,如果后續系列允許的話,我會專門對dubbo的版本進行1個詳細的文章說明.
2.dubbo reference注解問題
@Reference只能在springbean實例對應確當前類中使用,暫時沒法在父類使用;如果確切要在父類聲明1個援用,可通過配置文件配置dubbo:reference,然后在需要援用的地方跟援用springbean1樣就能夠了.
3.服務超時問題.
此問題也是在項目中非常常見的1個問題,但是這個問題背后多是各種緣由致使.
目前如果存在超時,情況基本都在以下:
(1) 1種情況是服務要求超時.
客戶端耗時大,也就是超時異常時的client elapsedxxx,這個是從創建Future對象開始到使用channel發出要求的這段時間,中間沒有復雜操作,只要CPU沒問題基本不會出現大耗時,頂多1ms屬于正常IOThread繁忙,默許情況下,dubbo協議1個客戶端與1個服務提供者會建立1個同享長連接,如果某個客戶端處于特別繁忙而且1直往1個服務提供者塞要求,可能造成IOThread阻塞,1般非常特殊的情況才會出現服務端工作線程池中線程全部繁忙,接收消息后塞入隊列等待,如果等待時間比料想長會引發超時網絡抖動,如果上述情況都排除,還出現在要求發出后,服務接收要求前超過料想時間,只能歸類到網絡抖動了,需要SA1起查看問題服務本身耗時大,這個需要利用本身做好耗時統計,當出現這類情況的時候需要用數據來講明問題及計劃優化方案,建議采取緩存埋點的方式統計服務中各個履行階段的耗時情況,終究如果超過料想時間則把緩存統計的耗時情況打日志,減少日志量,且能夠得到更明確的信息現在我們利用使用進程中發現兩種類型的耗時,1種我們目前只能歸類到網絡抖動,后續需要找運維1起關注這個問題,另外1種是由于1些歷史緣由,數據庫查詢容易產生抖動,總有1個時間點會突然多出很多超時。
(2) 2大類的情況是調用的版本不對.
在上面我們已說了具體的版本問題,如果你調用的對方版本不對的話,就相當于你的消費者沒有提供者.所以會出現超時,此時只需要把版本對應好便可.
(3)提供者的服務被制止.
這是1種人為的控制,通過監控中心我們可以對具體的服務,和它的權重進行控制,當我將1個具體的服務制止以后消費者就調不到相干的服務,此時就會出現超時的問題.解決方案,取消制止便可.注意這里有1定時間的緩存,實際操作的時候應當注意.
4.服務保護
服務保護的原則上是避免產生類似雪崩效應,盡可能將異常控制在服務周圍,不要分散開。說到雪崩效應,還得提下dubbo本身的重試機制,默許3次,當失敗時會進行重試,這樣在某個時間點出現性能問題,然后調用方再連續重復調用,很容易引發雪崩,建議的話還是很據業務情況計劃好如何進行異常處理,什么時候進行重試。服務保護的話 斟酌服務的dubbo線程池類型(fix線程池的話斟酌線程池大小)、數據庫連接池、dubbo連接數限制是不是都適合.
5.注冊中心的分組group和服務的不同實現group
這兩個東西完全不同的概念,使用的時候不要弄混了。registry上可以配置group,用于辨別不同分組的注冊中心,比如在同1個注冊中心下,有1部份注冊信息是要給開發環境用的,有1部份注冊信息時要給測試環境用的,可以分別用不同的group辨別開,目前對這個理解還不透徹,大致就是用于辨別不同環境。service和reference上也能夠配置group,這個用于辨別同1個接口的不同實現,只有在reference上指定與service相同的group才會被發現。
以上為5類我們所遇到的問題,總結下來為了以后的路走的更順暢.