多版本支持json
- 設置不一樣版本的目的,就是要考慮到接口升級之後帶來的兼容問題。
- 在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種容錯機制,分別以下服務器
- failsafe 失敗安全,能夠認爲是把錯誤吞掉(記錄日誌)
- failover(默認) 重試其餘服務器; retries(2)
- failfast 快速失敗, 失敗之後立馬報錯
- failback 失敗後自動恢復。
- forking forks. 設置並行數
- broadcast 廣播,任意一臺報錯,則執行的方法報錯
配置方式以下,經過cluster方式,配置指定的容錯方案:網絡
服務降級架構
降級的目的是爲了保證核心服務可用。app
- 降級能夠有幾個層面的分類: 自動降級和人工降級;
- 按照功能能夠分爲:讀服務降級和寫服務降級;
- 對一些非核心服務進行人工降級,在大促以前經過降級開關關閉哪些推薦內容、評價等對主流程沒有影響的功能
- 故障降級,好比調用的遠程服務掛了,網絡故障、或者RPC服務返回異常。
- 那麼能夠直接降級,降級的方案好比設置默認值、採用兜底數據(系統推薦的行爲廣告掛了,能夠提早準備靜態頁面作返回)等等
- 限流降級,在秒殺這種流量比較集中而且流量特別大的狀況下,由於突發訪問量特別大可能會致使系統支撐不了。
- 這個時候能夠採用限流來限制訪問量。當達到閥值時,後續的請求被降級,好比進入排隊頁面,好比跳轉到錯誤頁(活動太火爆,稍後重試等)
dubbo的降級方式: Mock分佈式
實現步驟ide
- 在client端建立一個TestMock類,實現對應IGpHello的接口(須要對哪一個接口進行mock,就實現哪一個),名稱必須以Mock結尾
- 在client端的xml配置文件中,添加以下配置,增長一個mock屬性指向建立的TestMock模擬錯誤(設置timeout),
- 模擬超時異常,運行測試代碼便可訪問到TestMock這個類。當服務端故障解除之後,調用過程將恢復正常
配置的優先級別
- 以timeout爲例,顯示了配置的查找順序,其它retries, loadbalance等相似。
- 方法級優先,接口級次之,全局配置再次之。
- 若是級別同樣,則消費方優先,提供方次之。
其中,服務提供方配置,經過URL經由註冊中心傳遞給消費方。測試
- 建議由服務提供方設置超時,由於一個方法須要執行多長時間,服務提供方更清楚,
- 若是一個消費方同時引用多個服務,就不須要關心每一個服務的超時設置。