多版本支援

• 設定不同版本的目的，就是要考慮到介面升級以後帶來的相容問題。
• 在Dubbo中配置不同版本的介面，會在Zookeeper地址中有多個協議url的體現，具體內容如下

dubbo://192.168.11.1:20880%2Fcom.gupaoedu.dubbo.IGpHello%3Fanyhost%3Dtrue%26application%3Dhello-world-
app%26dubbo%3D2.5.6%26generic%3Dfalse%26interface%3Dcom.gupaoedu.dubbo.IGpHello%26methods%3DsayHello
%26pid%3D60700%26revision%3D1.0.0%26side%3Dprovider%26timestamp%3D1529498478644%26version%3D1.0.0


dubbo://192.168.11.1%3A20880%2Fcom.gupaoedu.dubbo.IGpHello2%3Fanyhost%3Dtrue%26application%3Dhello-
world-
app%26dubbo%3D2.5.6%26generic%3Dfalse%26interface%3Dcom.gupaoedu.dubbo.IGpHello%26methods%3DsayHello
%26pid%3D60700%26revision%3D1.0.1%26side%3Dprovider%26timestamp%3D1529498488747%26version%3D1.0.1
 

叢集容錯

• 什麼是容錯機制？
  • 容錯機制指的是某種系統控制在一定範圍內的一種允許或包容犯錯情況的發生，
  • 舉個簡單例子，
    • 我們在電腦上執行一個程式，有時候會出現無響應的情況，然後系統會彈出一個提示框讓我們選擇，
    • 是立即結束還是繼續等待，然後根據我們的選擇執行對應的操作，這就是“容錯”。
• 在分散式架構下，網路、硬體、應用都可能發生故障，
  • 由於各個服務之間可能存在依賴關係，如果一條鏈路中的其中一個節點出現故障，將會導致雪崩效應。
  • 為了減少某一個節點故障的影響範圍，所以我們才需要去構建容錯服務，來優雅的處理這種中斷的響應結果

Dubbo提供了6種容錯機制，分別如下

1. failsafe 失敗安全，可以認為是把錯誤吞掉（記錄日誌）
2. failover(預設)   重試其他伺服器； retries（2）
3. failfast 快速失敗， 失敗以後立馬報錯
4. failback  失敗後自動恢復。
5. forking  forks. 設定並行數
6. broadcast  廣播，任意一臺報錯，則執行的方法報錯

配置方式如下，通過cluster方式，配置指定的容錯方案：

服務降級

降級的目的是為了保證核心服務可用。

• 降級可以有幾個層面的分類： 自動降級和人工降級；
• 按照功能可以分為：讀服務降級和寫服務降級；

1. 對一些非核心服務進行人工降級，在大促之前通過降級開關關閉哪些推薦內容、評價等對主流程沒有影響的功能
2. 故障降級，比如呼叫的遠端服務掛了，網路故障、或者RPC服務返回異常。
   • 那麼可以直接降級，降級的方案比如設定預設值、採用兜底資料（系統推薦的行為廣告掛了，可以提前準備靜態頁面做返回）等等
3. 限流降級，在秒殺這種流量比較集中並且流量特別大的情況下，因為突發訪問量特別大可能會導致系統支撐不了。
   • 這個時候可以採用限流來限制訪問量。當達到閥值時，後續的請求被降級，比如進入排隊頁面，比如跳轉到錯誤頁（活動太火爆，稍後重試等）

dubbo的降級方式： Mock

實現步驟

1. 在client端建立一個TestMock類，實現對應IGpHello的介面（需要對哪個介面進行mock，就實現哪個），名稱必須以Mock結尾
2. 在client端的xml配置檔案中，新增如下配置，增加一個mock屬性指向建立的TestMock模擬錯誤（設定timeout），
3. 模擬超時異常，執行測試程式碼即可訪問到TestMock這個類。當服務端故障解除以後，呼叫過程將恢復正常

配置的優先級別

• 以timeout為例，顯示了配置的查詢順序，其它retries, loadbalance等類似。

1. 方法級優先，介面級次之，全域性配置再次之。
2. 如果級別一樣，則消費方優先，提供方次之。

其中，服務提供方配置，通過URL經由註冊中心傳遞給消費方。

• 建議由服務提供方設定超時，因為一個方法需要執行多長時間，服務提供方更清楚，
• 如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設定。