dubbo 在服務治理方面的一些策略

本文策略說明所有來自官方文檔.

 

1. 集羣容錯策略:

Failover Cluster

• 失敗自動切換，當出現失敗，重試其它服務器。(缺省)
• 一般用於讀操做，但重試會帶來更長延遲。
• 可經過retries="2"來設置重試次數(不含第一次)。

Failfast Cluster

• 快速失敗，只發起一次調用，失敗當即報錯。
• 一般用於非冪等性的寫操做，好比新增記錄。

Failsafe Cluster

• 失敗安全，出現異常時，直接忽略。
• 一般用於寫入審計日誌等操做。

Failback Cluster

• 失敗自動恢復，後臺記錄失敗請求，定時重發。
• 一般用於消息通知操做。

Forking Cluster

• 並行調用多個服務器，只要一個成功即返回。
• 一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。
• 可經過forks="2"來設置最大並行數。

Broadcast Cluster

• 廣播調用全部提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)
• 一般用於通知全部提供者更新緩存或日誌等本地資源信息。

 

 

2. 負載均衡策略

Random LoadBalance

• 隨機，按權重設置隨機機率。
• 在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobin LoadBalance

• 輪循，按公約後的權重設置輪循比率。
• 存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

LeastActive LoadBalance

• 最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。
• 使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

ConsistentHash LoadBalance

• 一致性Hash，相同參數的請求老是發到同一提供者。
• 當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。
• 算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
• 缺省只對第一個參數Hash，若是要修改，請配置<dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用160份虛擬節點，若是要修改，請配置<dubbo:parameter key="hash.nodes" value="320" />

 

 

3. 靜態服務

有時候但願人工管理服務提供者的上線和下線，此時需將註冊中心標識爲非動態管理模式。

服務提供者初次註冊時爲禁用狀態，需人工啓用，斷線時，將不會被自動刪除，需人工禁用。

 

4. 服務分組

當一個接口有多種實現時, 能夠用group區分

 

5. 多版本

當一個接口實現，出現不兼容升級時，能夠用版本號過渡，版本號不一樣的服務相互間不引用。

• 在低壓力時間段，先升級一半提供者爲新版本
• 再將全部消費者升級爲新版本
• 而後將剩下的一半提供者升級爲新版本

 

6. 分組聚合

按組合並返回結果，好比菜單服務，接口同樣，但有多種實現，用group區分，如今消費方需從每種group中調用一次返回結果，合併結果返回，這樣就能夠實現聚合菜單項.

 

7. 泛化引用:

泛接口調用方式主要用於客戶端沒有API接口及模型類元的狀況，參數及返回值中的全部POJO均用Map表示，一般用於框架集成，好比：實現一個通用的服務測試框架，可經過GenericService調用全部服務實現。

 

8. 泛化實現:

泛接口實現方式主要用於服務器端沒有API接口及模型類元的狀況，參數及返回值中的全部POJO均用Map表示，一般用於框架集成，好比：實現一個通用的遠程服務Mock框架，可經過實現GenericService接口處理全部服務請求。

 

9. 回聲測試:

回聲測試用於檢測服務是否可用，回聲測試按照正常請求流程執行，可以測試整個調用是否通暢，可用於監控。

全部服務自動實現EchoService接口，只需將任意服務引用強制轉型爲EchoService，便可使用。

 

10. 異步調用:

基於NIO的非阻塞實現並行調用，客戶端不須要啓動多線程便可完成並行調用多個遠程服務，相對多線程開銷較小。

 

11. 參數回調:

參數回調方式與調用本地callback或listener相同，只須要在Spring的配置文件中聲明哪一個參數是callback類型便可，Dubbo將基於長鏈接生成反向代理，這樣就能夠從服務器端調用客戶端邏輯。

 

12. 事件通知:

在調用以前，調用以後，出現異常時，會觸發oninvoke, onreturn, onthrow三個事件，能夠配置當事件發生時，通知哪一個類的哪一個方法。

 

13. 本地存根:

遠程服務後，客戶端一般只剩下接口，而實現全在服務器端，但提供方有些時候想在客戶端也執行部分邏輯，好比：作ThreadLocal緩存，提早驗證參 數，調用失敗後僞造容錯數據等等，此時就須要在API中帶上Stub，客戶端生成Proxy實，會把Proxy經過構造函數傳給Stub，而後把Stub 暴露組給用戶，Stub能夠決定要不要去調Proxy。

 

14. 本地假裝:

Mock一般用於服務降級，好比某驗權服務，當服務提供方所有掛掉後，客戶端不拋出異常，而是經過Mock數據返回受權失敗。

Mock是Stub的一 個子集，便於服務提供方在客戶端執行容錯邏輯，因常常須要在出現RpcException(好比網絡失敗，超時等)時進行容錯，而在出現業務異常(好比登 錄用戶名密碼錯誤)時不須要容錯，若是用Stub，可能就須要捕獲並依賴RpcException類，而用Mock就能夠不依賴 RpcException，由於它的約定就是隻有出現RpcException時才執行。

 

15. 併發控制:

可控制客戶端, 服務端併發執行的個數

 

16. 鏈接控制:

可控制服務端接受的鏈接數, 限制客戶端使用的鏈接數

 

17. 延遲鏈接:

只對dubbo長鏈接有效, 只有當調用發起時, 再建立長鏈接

 

18. 粘滯鏈接:

粘滯鏈接用於有狀態服務，儘量讓客戶端老是向同一提供者發起調用，除非該提供者掛了，再連另外一臺。

 

19. 令牌驗證:

    防止消費者繞過註冊中心訪問提供者

    在註冊中心控制權限，以決定要不要下發令牌給消費者

    註冊中心可靈活改變受權方式，而不需修改或升級提供者

20. 路由規則:

    條件路由規則, 幾個有用的示例:

 

1) 排除預發佈機：

=> host != 172.22.3.91

2) 白名單：(注意：一個服務只能有一條白名單規則，不然兩條規則交叉，就都被篩選掉了)

host != 10.20.153.10,10.20.153.11 =>

3) 黑名單：

host = 10.20.153.10,10.20.153.11 =>

4) 服務寄宿在應用上，只暴露一部分的機器，防止整個集羣掛掉：

=> host = 172.22.3.1*,172.22.3.2*

5) 爲重要應用提供額外的機器：

application != kylin => host != 172.22.3.95,172.22.3.96

6) 讀寫分離：

method = find*,list*,get*,is* => host = 172.22.3.94,172.22.3.95,172.22.3.96

method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98

7) 先後臺分離：

application = bops => host = 172.22.3.91,172.22.3.92,172.22.3.93

application != bops => host = 172.22.3.94,172.22.3.95,172.22.3.96

8) 隔離不一樣機房網段：

host != 172.22.3.* => host != 172.22.3.*

9) 提供者與消費者部署在同集羣內，本機只訪問本機的服務：

=> host = $host

 

21. 配置規則:

可動態的向註冊中心寫入動態配置覆蓋規則.

 

22. 服務降級:

 

• 消費方對該服務的方法調用都直接返回null值，不發起遠程調用。

屏蔽不重要服務不可用時對調用方的影響。

• 或者消費方對該服務的方法調用在失敗後，再返回null值，不拋異常。

容忍不重要服務不穩定時對調用方的影響。

 

23. 優雅停機:

原理：

• 服務提供方
  • 中止時，先標記爲不接收新請求，新請求過來時直接報錯，讓客戶端重試其它機器。
  • 而後，檢測線程池中的線程是否正在運行，若是有，等待全部線程執行完成，除非超時，則強制關閉。
• 服務消費方
  • 中止時，再也不發起新的調用請求，全部新的調用在客戶端即報錯。
  • 而後，檢測有沒有請求的響應尚未返回，等待響應返回，除非超時，則強制關閉。

設置優雅停機超時時間，缺省超時時間是10秒：(超時則強制關閉)

 

24. 服務容器:

服務容器是一個standalone的啓動程序，由於後臺服務不須要Tomcat或JBoss等Web容器的功能，若是硬要用Web容器去加載服務提供方，增長複雜性，也浪費資源。