API 的呼叫穩定性被視為資料服務的最重要的指標。該指標的影響因素是多種多樣的，「 」不僅多次對於呼叫效能和穩定性進行壓測和調優，而且還提供了多種配置項最佳化手段供客戶進行自行調優。但是當遇到不可預期的大流量或其他突然情況時還是會遇到 API 呼叫失敗的情況。

當隨著流量的不斷增長，達到或超過服務本身的可承載範圍，系統服務的自我保護機制的建立就顯得很重要了。「 」將 API 呼叫和微服務流量控制概念相結合，推出了 ，最大/程度保證 API 呼叫的穩定性和系統可用性。

本文希望可以用最通俗的解釋和貼切的例項帶大家瞭解什麼是 。

熔斷降級概述

一般提到微服務系統流量保護，都會提起限流、熔斷、降級三種手段，其實他們都是系統容錯的重要設計模式。

限流、熔斷、降級

● 限流

是一種對系統被請求頻率以及內部部分功能的執行頻率進行限制的措施，防止因突發的流量激增，導致整個系統不可用。限流主要是防禦保護手段，從流量源頭開始控制流量、規避問題。

● 熔斷

機制是一種自動化的應對措施，當流量過大或下游服務出現問題時，可以自動斷開與下游服務的互動，以防止故障的進一步擴散。同時，熔斷機制還可以自我診斷下游系統的錯誤是否已經修正，或者上游流量是否減少至正常水平，以實現自我恢復。

熔斷更像是 ，可能發生在服務無法支撐大量請求或服務發生其他故障時，對請求進行限制處理，同時還可嘗試性的進行恢復。

● 服務降級

主要是針對非核心業務功能，而核心業務如果流程超過預估的峰值，就需要進行限流。 一般考慮的是分散式系統的整體性，從源頭上切斷流量的來源。降級更像是一種預估手段，在預計流量峰值前提下，提前透過配置功能降低服務體驗，或暫停次要功能，保證系統主要流程功能平穩響應。

熔斷降級

限流和熔斷也可以看作是一種服務降級的手段。微服務架構下，服務和服務之間的呼叫通常關注的是流量，開發者需要從流量路由、 、流量整形、熔斷降級、 、熱點流量防護等多個維度來保障微服務的穩定性。其中熔斷降級更趨向於在微服務呼叫鏈路中保障重點鏈路或者重點服務的穩定性。

如下圖，當 serviceD 發生異常不可用時會影響到 serviceA、B、G、F，如不加以管控，最終可能會導致整個微服務全部癱瘓。熔斷要做的事情就是達到某個錯誤閾值後停止再呼叫 serviceD 服務；降級則會返回開發者自定義的降級內容，至少保證鏈路的整體可用。

熔斷規則介紹

「 」目前提供三種熔斷策略，每個 API 可以且僅可關聯一個熔斷策略，策略型別分別為：

● 慢呼叫比例（SLOW_REQUEST_RATIO）

選擇以 作為閾值，需要設定允許的慢呼叫 RT（即最大的響應時間），請求的響應時間大於該值則統計為慢呼叫。當單位統計時長（statIntervalMs）內請求數目大於設定的最小請求數目，並且慢呼叫的比例大於閾值，則接下來的熔斷時長內請求會自動被熔斷。

經過熔斷時長後熔斷器會進入 （HALF-OPEN 狀態），若接下來的一個請求響應時間小於設定的慢呼叫 RT 則結束熔斷，若大於設定的慢呼叫 RT 則會再次被熔斷。

● 異常比例（ERROR_RATIO）

當單位統計時長（statIntervalMs）內請求數目大於設定的最小請求數目，並且異常的比例大於閾值，則接下來的熔斷時長內請求會自動被熔斷。

經過熔斷時長後熔斷器會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。異常比率的閾值範圍是 [0.0, 1.0]，代表 0% - 100%。

● 異常數（ERROR_COUNT）

當單位統計時長內的異常數目超過閾值之後會自動進行熔斷。經過熔斷時長後 會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。

DataAPI 對於熔斷降級的應用

接下來透過例項為大家介紹熔斷降級在「 」內的應用。

熔斷

資料服務的熔斷降級是基於 實現的。Sentinel 對於資源的定義更偏向於服務級別，不過也提供了對於指定程式碼或內容進行資源定義。所以 是透過定義 APIID 作為唯/一資源來進行 的判斷和具體熔斷動作的實施。同時，透過控制資源名稱的生成規則，測試 API 和正式 API 實現了環境隔離。

在開發實現的過程中，最大的難點在於 Sentinel 原生支援限流策略的叢集控制，但是不支援熔斷策略的叢集控制。DataAPI 採用的方法是採用 的方式去實現叢集的控制，主要有以下兩點內容。

● 熔斷規則如何只載入到主節點上

首先， 基於記憶體是透過 DegradeRuleManager 載入的，既然是基於記憶體那麼必然要做持久化動作，否則程式重啟規則就會清空。這裡採用了 MySQL 建立 的方式進行規則詳情的修改操作。

其次啟動時透過 nacos 獲取 gateway 例項列表並選取主節點，呼叫 nacos 的 namingService.getAllInstance 方法可以獲取到所有的 gateway 例項。選取第一個健康的 gateway 例項為主節點，將主節點 ip 資訊以 key value 的形式儲存到 redis 中，主節點重新選舉時會更新此 redis key，gateway 叢集所有例項每次啟動先判斷當前節點是否為主節點，只有主節點才會進行熔斷策略的初始化載入動作。

這裡針對主節點的選舉 DataAPI 是做了 的，即使當前主節點當機，也可以透過每分鐘一次的定時器獲取到存活的節點例項並重新選取主節點，保證高可用。當主節點發生變更後也會傳送 redis 通知給到所有節點，新的主節點收到通知後會從 MySQL 獲取當前最新的熔斷策略載入進記憶體，不過此動作會清空之前的流量統計，時間視窗會重置。

最後，策略的修改如何同步到主節點。資料服務採用的是 通知的方式，每臺 gateway 都監聽 channel 訊息，只有判斷當前節點為主節點的 gateway 才進行記憶體規則的 load 操作。

● 叢集閾值判定

透過主節點進行規則載入和閾值判斷，叢集所有示例都正常執行 API 請求，只有 會發起 http 請求到主節點進行判斷，並返回是否透過結果，整體工作流程圖如下：

閾值判定一共分為兩種模式：

· 錯誤模式，也可細分為錯誤數或者錯誤率

· 慢呼叫模式，指慢呼叫請求佔比

由於判斷主節點為例項B，但是錯誤發生在例項A/C，所以在例項B是需要手動去產生異常或者慢呼叫的。當節點請求發生異常後主節點收到異常標誌位，則手動丟擲異常，這時候 Sentinel 是可以感知的並且異常數會加一。慢呼叫則是透過修改請求的 complateTime 讓計數器能夠判斷到慢呼叫來實現。

降級

用於可在 API 編輯頁面進行降級內容的配置，配置條件為需先配置熔斷策略，當熔斷器處於開啟狀態時 gateway 會返回完全由使用者自定義的降級內容，該內容必須為 json 格式。

降級最主要解決的是資源不足和訪問量增加的矛盾，在有限的資源情況下，可以應對 。尤其當 API 配置被訪問的資料來源無法承載大流量時，在有限的資源情況下，想要達到以上效果就需要對一些服務功能進行一些限制但是又不是完全的不可用狀態，系統將返回預設的值，保證整個系統能夠平穩執行。

降級的程式碼實現相對簡單，判斷條件生效後，透過重寫 ServerWebExchange 物件的 Response 即可。

《資料治理行業實踐白皮書》下載地址：

《數棧V6.0產品白皮書》下載地址：

想了解更多有關大資料產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網： https://www.dtstack.com/?src=szitpub