服務降級的設計與實踐

服務降級的目的

爲什麼服務降級？

當對業務的請求超過業務系統預設的上限閾值時，爲了保證基本和重要的業務模塊正常運行，

  1. 拒絕部分請求

  2. 不重要的業務模塊暫停服務或延遲提供服務。

例如天貓在雙 11 的服務降級：

服務降級的實現手段

服務降級的手段有兩大類：

第一類是關閉部分非核心服務。例如雙 12 當天，京東暫時關閉退貨服務。

第二類是拒絕部分請求。這裏面又分成三個手段

（1）根據 RPC 隊列方式，把舊的請求丟棄。我們還是想想雙 12 買東西。在業務邏輯層 pendding 的舊的請求，或許客戶端已經取消了，因此要捨棄請求，一定先捨棄最久的。但這種方式有個問題，舊的請求可能是核心請求，新的可能是非核心請求的。

（2）根據請求報文 CMD 的優先級。在 CMD 列表的請求保留，不在列表中的 CMD 捨棄。

實際應用中，需要前兩種相結合，即（1）決定什麼時候開啓、關閉丟棄  （2）決定丟棄誰

（3）隨機拒絕方式：這種不靠譜，實際環境沒人用。

服務降級的設計

我們將服務降級設置在什麼位置？網關還是全鏈路？

  1. 在網關層做服務降級：

   這樣做不靠譜的地方是，因爲一個網關後面可能有多個業務邏輯層。

  1. 全鏈路降級。也就是使用上上個圖中兩種方法結合的方式。讓網關、業務邏輯層、數據訪問層都有降級的機制。每一層能處理多少請求自己說了算。

和方案 1 比，方案 2 更靠譜。

那麼，有一個小疑問，在方案 2 中，DB 層是否需要做降級？

在上圖的模型中，讀同步寫異步。讀的時候，DAO 層已經做了限流，就不用在 DB 層限流。在寫請求時，會先寫到 MQ，所以只要是 MQ 沒有超限，DB 就不會出現問題。

熔斷的實現

熔斷的實現有兩種方式：組件級、平臺級：

組件級解決方案

Neflix 的 Hystrix 熔斷組件是個 jar 包。Hystrix 的熔斷機制是 API 顆粒度的。如下圖所示：

前面說過，Hystrix 是組件級的熔斷，好處是使用的時候，直接引入 Jar 包就可以。壞處是，任何要做熔斷的微服務，它的上上游都需要引入 jar，而且 Hystrix 限制哪個 API，是需要硬編碼的。

平臺級解決方案

如果上下游調用是 RPC。我們能否把熔斷的功能寫入到 RPC Client。這樣上游引入 RPC Client 客戶端就可以，而不需要引入單獨的 jar 包。此外，哪些 API 需要熔斷，最好寫在配置中心。

如下圖所示，我們在 dashboard 寫入要限制 API 的名稱以及參數，然後通過服務管理平臺將配置規則推送給網關。網關上的 RPC Client（RPC Over TCP）可以解析這些配置，並其下游的業務邏輯層對應的 API 進行熔斷。

服務管理平臺的本質如下圖所示，即服務數據平臺是控制面板。

服務治理平臺實現熔斷的邏輯圖，圖示比較清楚，不再贅述：

在構建服務治理平臺時，可以參照現在市面上新型的熔斷器框架，例如 Resilience4j，會有服務器模式和嵌入模式。前者會有一個獨立的 Resilience4j server，後者還是引入 jar 包。前者性能會好不少。

具體可以參考 https://xie.infoq.cn/article/14786e571c1a4143ad1ef8f19

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/tIJtqlNJq4BZkT3QiZcFMw

猜你喜歡