在工作和學習的過程中
,具體運用
dubbo
的時候遇到了很多的問題
,這些問題一方面讓自己進一步了解所謂的
dubbo,
另一方面通過對它們的總結和分析能夠在工作中加倍的提高效率
,接下來將會對遇到的和別人總結的一些常見的問題進行彙總.
1.增加提供服務版本號和消費服務版本號.
這個具體來說不算是乙個問題
,而是一種問題的解決方案
,在我們的實際工作中會面臨各種環境資源短缺的問題
,也是很實際的問題
,剛開始我們還可以提供乙個服務進行相關的開發和測試
,但是當有多個環境多個版本
,多個任務的時候就不滿足我們的需求
,這時候我們可以通過給提供方增加版本的方式來區分
.這樣能夠剩下很多的物理資源,.
引用只會找相應版本的服務,例如
dubbo
服務的版本號在專案中非常實用
,如果後續系列允許的話
,我會專門對
dubbo
的版本進行乙個詳細的文章說明.
2.dubbo reference註解問題
@reference只能在springbean例項對應的當前類中使用，暫時無法在父類使用；如果確實要在父類宣告乙個引用，可通過配置檔案配置dubbo:reference，然後在需要引用的地方跟引用springbean一樣就可以了.
3.服務超時問題.
此問題也是在專案中非常常見的乙個問題
,但是這個問題背後可能是各種原因導致.
目前如果存在超時，情況基本都在如下：
(1)
一種情況是服務請求超時.
(2)
二大類的情況是呼叫的版本不對.
在上面我們已經說了具體的版本問題
,如果你呼叫的對方版本不對的話
,就相當於你的消費者沒有提供者
.所以會出現超時
,此時只需要把版本對應好即可.
(3)提供者的服務被禁止.
這是一種人為的控制
,通過監控中心我們可以對具體的服務
,以及它的權重進行控制
,當我將乙個具體的服務禁止之後消費者就調不到相關的服務
,此時就會出現超時的問題
.解決方案
,取消禁止即可
.注意這裡有一定時間的快取
,實際操作的時候應該注意.
4.服務保護
服務保護的原則上是避免發生類似雪崩效應，盡量將異常控制在服務周圍，不要擴散開。說到雪崩效應，還得提下dubbo自身的重試機制，預設3次，當失敗時會進行重試，這樣在某個時間點出現效能問題，然後呼叫方再連續重複呼叫，很容易引起雪崩，建議的話還是很據業務情況規劃好如何進行異常處理，何時進行重試。服務保護的話 考慮服務的dubbo執行緒池型別（fix執行緒池的話考慮執行緒池大小）、資料庫連線池、dubbo連線數限制是否都合適.
5.註冊中心的分組group和服務的不同實現group
這兩個東西完全不同的概念，使用的時候不要弄混了。registry上可以配置group，用於區分不同分組的註冊中心，比如在同乙個註冊中心下，有一部分註冊資訊是要給開發環境用的，有一部分註冊資訊時要給測試環境用的，可以分別用不同的group區分開，目前對這個理解還不透徹，大致就是用於區分不同環境。service和reference上也可以配置group，這個用於區分同乙個介面的不同實現，只有在reference上指定與service相同的group才會被發現。
以上為5類我們所遇到的問題
,總結下來為了以後的路走的更順暢.
在工作和學習的過程中
,具體運用
dubbo
的時候遇到了很多的問題
,這些問題一方面讓自己進一步了解所謂的
dubbo,
另一方面通過對它們的總結和分析能夠在工作中加倍的提高效率
,接下來將會對遇到的和別人總結的一些常見的問題進行彙總.
1.增加提供服務版本號和消費服務版本號.
這個具體來說不算是乙個問題
,而是一種問題的解決方案
,在我們的實際工作中會面臨各種環境資源短缺的問題
,也是很實際的問題
,剛開始我們還可以提供乙個服務進行相關的開發和測試
,但是當有多個環境多個版本
,多個任務的時候就不滿足我們的需求
,這時候我們可以通過給提供方增加版本的方式來區分
.這樣能夠剩下很多的物理資源,.
引用只會找相應版本的服務,例如
dubbo
服務的版本號在專案中非常實用
,如果後續系列允許的話
,我會專門對
dubbo
的版本進行乙個詳細的文章說明.
2.dubbo reference註解問題
@reference只能在springbean例項對應的當前類中使用，暫時無法在父類使用；如果確實要在父類宣告乙個引用，可通過配置檔案配置dubbo:reference，然後在需要引用的地方跟引用springbean一樣就可以了.
3.服務超時問題.
此問題也是在專案中非常常見的乙個問題
,但是這個問題背後可能是各種原因導致.
目前如果存在超時，情況基本都在如下：
(1)
一種情況是服務請求超時.
(2)
二大類的情況是呼叫的版本不對.
在上面我們已經說了具體的版本問題
,如果你呼叫的對方版本不對的話
,就相當於你的消費者沒有提供者
.所以會出現超時
,此時只需要把版本對應好即可.
(3)提供者的服務被禁止.
這是一種人為的控制
,通過監控中心我們可以對具體的服務
,以及它的權重進行控制
,當我將乙個具體的服務禁止之後消費者就調不到相關的服務
,此時就會出現超時的問題
.解決方案
,取消禁止即可
.注意這裡有一定時間的快取
,實際操作的時候應該注意.
4.服務保護
服務保護的原則上是避免發生類似雪崩效應，盡量將異常控制在服務周圍，不要擴散開。說到雪崩效應，還得提下dubbo自身的重試機制，預設3次，當失敗時會進行重試，這樣在某個時間點出現效能問題，然後呼叫方再連續重複呼叫，很容易引起雪崩，建議的話還是很據業務情況規劃好如何進行異常處理，何時進行重試。服務保護的話 考慮服務的dubbo執行緒池型別（fix執行緒池的話考慮執行緒池大小）、資料庫連線池、dubbo連線數限制是否都合適.
5.註冊中心的分組group和服務的不同實現group
這兩個東西完全不同的概念，使用的時候不要弄混了。registry上可以配置group，用於區分不同分組的註冊中心，比如在同乙個註冊中心下，有一部分註冊資訊是要給開發環境用的，有一部分註冊資訊時要給測試環境用的，可以分別用不同的group區分開，目前對這個理解還不透徹，大致就是用於區分不同環境。service和reference上也可以配置group，這個用於區分同乙個介面的不同實現，只有在reference上指定與service相同的group才會被發現。
以上為5
類我們所遇到的問題
,總結下來為了以後的路走的更順暢.
Dubbo之旅 擴充套件協議
在實際工作中運用 dubbo 的時候,以上系列的文章基本上能夠滿足專案的基本需求,當然 對於一些特殊的需求 dubbo 可以對其進行擴充套件 dubbo 擁有者豐富的擴充套件內容 這次主要將會帶領大家去感受一下 dubbo 的協議擴充套件和註冊中心擴充套件 首先要說的是協議擴充套件.為什麼要擴充套件...
Dubbo之旅 內部邏輯
在沒有開始用 來解釋之前 用圖最能夠表達一些關係,關於 dubbo 的內部邏輯呼叫關係 借用官方的圖示來說明一下 如下圖 通過上圖中的乙個個方框我們稱之為節點 總共有 5個節點 這五個節點可以看成五個角色 每個角色都有一定的功能 每個角色的意思如下 provider 暴露服務的服務提供方。在實際專案...
Dubbo之旅 擴充套件註冊中心
在上篇文章中我們介紹了關於協議的擴充套件 並了解擴充套件它所需要的需求 本篇主要是對註冊中心的擴充套件進行著重的探索.同樣的問題 為什麼我們需要去擴充套件註冊中心的 主要有以下三個需求.1 多註冊中心註冊 需求 xx 銀行有些服務來不及在上海部署，只在北京部署，而上海的其它應用需要引用此服務，就可以...