Dubbo之旅--問題彙總
在工作和學習的過程中,具體運用Dubbo的時候遇到了很多的問題,這些問題一方面讓自己進一步瞭解所謂的dubbo,另一方面通過對它們的總結和分析能夠在工作中加倍的提高效率,接下來將會對遇到的和別人總結的一些常見的問題進行彙總.
1.增加提供服務版本號和消費服務版本號.
這個具體來說不算是一個問題,而是一種問題的解決方案,在我們的實際工作中會面臨各種環境資源短缺的問題,也是很實際的問題,剛開始我們還可以提供一個服務進行相關的開發和測試,但是當有多個環境多個版本,多個任務的時候就不滿足我們的需求,這時候我們可以通過給提供方增加版本的方式來區分.這樣能夠剩下很多的物理資源,同時為今後更換介面定義釋出線上時，可不停機發布，使用版本號
引用只會找相應版本的服務,例如
<dubbo:serviceinterface=“com.xxx.XxxService”ref=“xxxService” version=“1.0” />
<dubbo:referenceid=“xxxService”interface=“com.xxx.XxxService” version=“1.0”/>
dubbo服務的版本號在專案中非常實用,如果後續系列允許的話,我會專門對dubbo的版本進行一個詳細的文章說明.
2.dubbo reference註解問題
@Reference只能在springbean例項對應的當前類中使用，暫時無法在父類使用；如果確實要在父類宣告一個引用，可通過配置檔案配置dubbo:reference，然後在需要引用的地方跟引用springbean一樣就可以了
3.服務超時問題.
此問題也是在專案中非常常見的一個問題,但是這個問題背後可能是各種原因導致.
目前如果存在超時，情況基本都在如下：
(1) 一種情況是服務請求超時.
客戶端耗時大，也就是超時異常時的client elapsedxxx，這個是從建立Future物件開始到使用channel發出請求的這段時間，中間沒有複雜操作，只要CPU沒問題基本不會出現大耗時，頂多1ms屬於正常IOThread繁忙，預設情況下，dubbo協議一個客戶端與一個服務提供者會建立一個共享長連線，如果某個客戶端處於特別繁忙而且一直往一個服務提供者塞請求，可能造成IOThread阻塞，一般非常特殊的情況才會出現服務端工作執行緒池中執行緒全部繁忙，接收訊息後塞入佇列等待，如果等待時間比預想長會引起超時網路抖動，如果上述情況都排除了，還出現在請求發出後，服務接收請求前超過預想時間，只能歸類到網路抖動了，需要SA一起檢視問題服務自身耗時大，這個需要應用自身做好耗時統計，當出現這種情況的時候需要用資料來說明問題及規劃優化方案，建議採用快取埋點的方式統計服務中各個執行階段的耗時情況，最終如果超過預想時間則把快取統計的耗時情況打日誌，減少日誌量，且能夠得到更明確的資訊現在我們應用使用過程中發現兩種型別的耗時，一種我們目前只能歸類到網路抖動，後續需要找運維一起關注這個問題，另外一種是由於一些歷史原因，資料庫查詢容易發生抖動，總有一個時間點會突然多出很多超時。
(2) 二大類的情況是呼叫的版本不對.
在上面我們已經說了具體的版本問題,如果你呼叫的對方版本不對的話,就相當於你的消費者沒有提供者.所以會出現超時,此時只需要把版本對應好即可.
(3)提供者的服務被禁止.
這是一種人為的控制,通過監控中心我們可以對具體的服務,以及它的權重進行控制,當我將一個具體的服務禁止之後消費者就調不到相關的服務,此時就會出現超時的問題.解決方案,取消禁止即可.注意這裡有一定時間的快取,實際操作的時候應該注意.
4.服務保護
服務保護的原則上是避免發生類似雪崩效應，儘量將異常控制在服務周圍，不要擴散開。說到雪崩效應，還得提下dubbo自身的重試機制，預設3次，當失敗時會進行重試，這樣在某個時間點出現效能問題，然後呼叫方再連續重複呼叫，很容易引起雪崩，建議的話還是很據業務情況規劃好如何進行異常處理，何時進行重試。服務保護的話 考慮服務的dubbo執行緒池型別（fix執行緒池的話考慮執行緒池大小）、資料庫連線池、dubbo連線數限制是否都合適.
5.註冊中心的分組group和服務的不同實現group
這兩個東西完全不同的概念，使用的時候不要弄混了。registry上可以配置group，用於區分不同分組的註冊中心，比如在同一個註冊中心下，有一部分註冊資訊是要給開發環境用的，有一部分註冊資訊時要給測試環境用的，可以分別用不同的group區分開，目前對這個理解還不透徹，大致就是用於區分不同環境。service和reference上也可以配置group，這個用於區分同一個介面的不同實現，只有在reference上指定與service相同的group才會被發現。
以上為5類我們所遇到的問題,總結下來為了以後的路走的更順暢.