技術文章 » 高可用三大利器 — 熔斷、限流和降級

高可用三大利器 — 熔斷、限流和降級

2023-07-27 21:01:03

近年來，各大廠Google、微軟、阿里、騰訊等都在提高可用的概念。高可用（High Availability，簡稱HA）是指系統或服務在遭受故障或異常情況時仍能持續提供穩定和可靠的執行能力。

在武俠世界裡，「利器」通常指的是武器中的上乘、出色之物；武器對於武者的重要性不言而喻，擁有一把優秀的武器可以讓武者在戰鬥中更加得心應手，威力更強。

在分散式系統追求高可用的背景下，熔斷、限流和降級這三個重要的策略可以稱得上三大利器。

熔斷（Circuit Breaker）：熔斷是一種防止故障擴散的策略。當一個服務出現故障或超時，熔斷器會開啟並快速失敗，拒絕後續的請求，避免請求堆積和資源耗盡。熔斷器會暫時遮蔽該服務，並在一段時間後嘗試恢復。熔斷器的狀態變化可用於監控系統健康和提供告警資訊。

限流（Rate Limiting）：限流是一種控制系統請求流量的策略。通過設定一個請求速率閾值，限流可以限制每個使用者端或使用者在特定時間內的請求次數。這樣可以防止過多的請求湧入系統，保護系統免受過載和壓力衝擊。限流可以平滑流量，避免系統突發流量的影響。

降級（Fallback）：降級是一種在面對特殊業務或異常情況時保持系統可用的策略。當服務不可用時，降級服務會代替提供一些基本功能或返回預設的預設值，以確保系統依然能夠提供有限的功能或服務；又或者某些特定活動場景（例如：雙十一）下優先保障計算資源投入到 業務傾向的服務，降級邊緣服務。

熔斷（Circuit Breaker）

在分散式架構中，一個服務通常會與多個外部服務進行互動，這些外部服務可能是RPC介面、資料庫、第三方API等。例如，在支付過程中，可能需要呼叫銀聯提供的API；而查詢某個商品的價格，則可能需要進行行銷活動查詢。然而，除了自身服務外，依賴的外部服務的穩定性是無法絕對保證。

當依賴的第三方服務出現不穩定的情況時，例如三方伺服器過載，會導致服務自身呼叫第三方服務的響應時間也變長，甚者形成級聯效應。這樣一來，服務自身的執行緒可能會積壓，最終可能耗盡業務自身的執行緒池，導致服務本身變得不可用。

熔斷（Circuit Breaker）就是應對這種三方服務不穩定的設計，它可以幫助系統在出現問題時保持高可用，防止故障進一步擴散，同時也能在一段時間後重新嘗試恢復正常操作。避免區域性不穩定因素導致整個分散式系統的雪崩。作為保護服務自身的手段，通常在使用者端（呼叫端）進行設定。

熔斷器模式（Circuit Breaker Pattern），是Michael Nygard在他的著作《Release It!》中開始推薦使用的。其可以防止應用程式反覆嘗試執行可能會失敗的操作，使其能夠繼續進行而無需等待故障被修復，也無需浪費CPU週期來確定故障是否持久。Circuit Breaker模式還使應用程式能夠檢測故障是否已解決。如果問題似乎已經解決，應用程式可以嘗試呼叫該操作。

注：這種設計也是典型的 快速失敗原則（Fail-Fast Principle） 的應用。強調在面對錯誤或異常情況時，系統應該儘早地檢測並快速失敗，而不是繼續執行可能導致更嚴重後果的操作。這個原則的目的是儘早發現問題並及時處理，避免故障進一步擴大，從而提高系統的穩定性和可靠性。

熔斷器模式中最關鍵的設計在於熔斷器的三種狀態：

  • Closed狀態：來自應用程式的請求被 Proxy 操作。Proxy 維護最近故障次數的計數，如果對操作的呼叫不成功，Proxy 會增加這個計數。如果在給定的時間段內最近故障的次數超過了指定的閾值，Proxy 將進入Open狀態。此時，Proxy 啟動一個超時計時器，當計時器到達閾值時，Proxy 將進入Half-Open狀態。（這裡 Proxy 代指 Resilience4j、Sentinel、Hystrix類似框架）

  • Open狀態：來自應用程式的請求立即失敗，並嚮應用程式返回異常。

  • Half-Open狀態：應用程式允許有限數量的請求通過並呼叫操作。如果這些請求成功，假定之前導致失敗的故障已經修復，將切換到Closed狀態（故障計數器被重置）。如果任何請求失敗，會認為故障仍然存在，因此它會回退到Open狀態，並重新啟動超時計時器，為系統提供進一步的時間來從故障中恢復。。

許多開源的框架都基於這三個狀態進行了熔斷實現的設計，比如：Resilience4j、Sentinel、Hystrix；就實際使用上推薦 Sentinel 和 Resilience4j ，因為 Hystrix 已經宣佈不維護了。附上，一張網上廣泛流傳的對比表格 [1]

開源框架僅僅只是熔斷機制的程式碼實現，更重要的在於結合具體業務常見來設計相關的熔斷策略。這裡列出一些通常具體業務設計熔斷時候的考量點：

熔斷異常應該如何處理：三方服務處於在熔斷 Open狀態下，應該如何進行服務的返回。比如：用一個預設值來替代三方服務的返回結果；返回異常頁面告知使用者稍後再重試；呼叫其他的服務來替代原來的功能等。異常往往多樣的，也可以考慮不同異常下設定不同的處理方式。

應該記錄詳細紀錄檔：注意異常紀錄檔的記錄，確保關鍵資訊都寫入紀錄檔，往往線上故障異常的多樣的；好的紀錄檔格式/紀錄檔設計能夠快速的定位問題、監控熔斷策略符合預期。熔斷狀態的轉換需要詳細寫入，方便覆盤熔斷策略。

是否需要診斷定時程式：當處於熔斷 Open狀態時，考慮是否需要來做個定時程式 測試三方服務是否恢復並轉換 到 Half-Open狀態，更靈活的恢復服務。

管理熔斷的工具：由於異常是多樣的，某些情況下意外觸發了熔斷；此時管理員可以通過熔斷工具來恢復相關狀態，應對熔斷策略出現問題的情況。

注意三方服務耗時：有時候三方服務能夠正常返回但耗時很長，這樣可能會導致自身服務的超時；針對這種情況應該進行相關超時熔斷處理，應該關注這種隱蔽的超時異常。

限流（Rate Limit）

無論伺服器的硬體多麼強大，總歸也是有限的資源只能處理有限的請求；簡單理解限流（Rate Limit）的話，在有限時間內請求數量超過服務的處理數量，自動丟棄新來的請求從而保障有限的請求高可用。

用日常例子來類比說明就很好理解，一個餐廳只有5張四人桌，理想坐滿的情況也也就是20個人；而如果湧進來50個人都點單，那麼每個人都無法正常的用餐。因此，要限制進來的人數是保障正常用餐。

同樣的對於系統而言，一次性接受超出硬體承載的資源，就會導致資源的劇烈競爭從而 導致請求服務的延遲、異常等等，無法提供到高可用的服務。為此，對服務進行限流保護是提供高可用的重要策略了。

以下是常見的限流演演算法：

固定視窗計數限流演演算法（Fixed Window Counter）：在固定的時間視窗內，限制請求的數量。例如，在1秒內最多允許處理10個請求，當視窗滿時，後續請求將被拒絕。

滑動視窗計數限流演演算法（Sliding Window Counter）：設定一個滑動時間視窗，計算在該時間視窗內的請求數量，並限制其在指定範圍內。與固定視窗計數演演算法相比，滑動視窗演演算法允許更加靈活的流量控制。

令牌桶演演算法（Token Bucket）：令牌桶演演算法通過將請求放入令牌桶中來控制流量。每個請求需要從令牌桶中獲取令牌，如果桶中沒有足夠的令牌，則請求被拒絕。令牌桶演演算法允許突發流量一定程度的處理，並平滑了請求的速率。

  1. 令牌桶是一個固定容量的桶，它以恆定的速率產生令牌（即令牌產生速率），並將其放入桶中。
  2. 桶中最大可以儲存的令牌數量為桶的容量，當桶滿時，多餘的令牌會被丟棄。
  3. 每當有請求到達時，如果令牌桶中有足夠的令牌，該請求會獲取一個令牌，並被處理。如果桶中沒有令牌可用，該請求將被延遲或丟棄。
  4. 令牌桶可以應用於固定視窗計數限流演演算法和滑動視窗計數限流演演算法。在固定視窗計數限流中，令牌桶以固定速率產生令牌，而在滑動視窗計數限流中，令牌桶按照滑動時間視窗的速率產生令牌。

令牌桶演演算法的優點在於，它可以平滑地處理突發流量，即使在短時間內有大量請求到達，令牌桶演演算法仍然能夠保持相對穩定的速率來處理這些請求。此外，令牌桶演演算法還可以允許一定程度的突發流量，因為桶中積累的令牌可以處理突發的請求。令牌桶演演算法的缺點是在某些情況下可能會導致請求的延遲。如果請求到達時桶中沒有足夠的令牌，該請求將被延遲等待令牌，可能會導致響應時間增加。

漏桶演演算法（Leaky Bucket）：漏桶演演算法將請求放入一個漏桶中，請求以恆定的速率從漏桶中流出。如果漏桶已滿，則多餘的請求將被拒絕。漏桶演演算法可以用於平滑流量，防止突發請求造成的資源浪費。

  1. 漏桶是一個固定容量的桶，它有一個漏口。桶底的漏口以固定的速率（即令牌產生速率）漏水。
  2. 每個請求都會向漏桶中新增一個令牌。如果漏桶已滿（即桶內令牌數量達到了最大容量），則新的令牌會被丟棄。
  3. 當請求到達時，如果漏桶中有可用的令牌，則請求被處理，且漏桶中的令牌數量減少一個。如果漏桶中沒有足夠的令牌，則請求被丟棄或延遲處理。

漏桶演演算法的優點在於，它能夠以固定的速率來處理請求，從而平滑流量，防止突發請求對系統造成過大的壓力。此外，漏桶演演算法還能夠控制流出速率，避免資源的浪費;然而，漏桶演演算法的缺點是對於突發流量的處理相對較差。如果漏桶中的令牌數量耗盡，那麼突發流量的請求會被丟棄，可能會導致某些請求的延遲。

降級（Fallback）

不知道大家是否有經歷，當在樓下沙縣小店吃麵時，如果小店人不多的情況下 店員會端上一碟小菜給到我們；而人很多的情況，如果想吃小菜可以自己去視窗附近用小蝶裝取。換個角度，這其實也可以稱得上服務降級。

服務降級往往指在面對系統過載、資源不足、有計劃的大型活動（雙十一），有意識地降低系統的部分功能或服務質量，以保證系統的核心功能和關鍵服務仍能繼續正常執行。

舉個例子，電商系統中支援 商家對商品的價格調整 是一種非常常見的功能，但當 雙十一零點的時刻 往往會和商家達成一致 不提供在零點後一段時間內商品價格的調整服務，以用來保障零點活動的高效執行。

所以降級是一種非常規應對措施，不應該成為長期的解決方案。一旦面對情況有所改變就應該恢復降級的服務，確保系統能夠正常提供全部功能和服務。

降級本身的實現是根據具體業務規則來進行編碼，常見的設計有：

開關寫死： 用一個引數標識是否進行降級，在服務中用 if 來判斷標識 從而進行相關服務降級的業務邏輯。如果時間很短情況下要實現降級，可能是最直接最常見的選擇。

AOP攔截：通過 AOP切面面程式設計攔截服務請求，並更加服務降級的業務要求條件，呼叫降級服務請求。因為使用到了 AOP切面技術，程式碼侵入性小，但程式碼可讀性差；如果沒有一些註釋說明，不熟悉相關業務的研發者忽略了降級攔截。

策略/工廠設計模式：在服務設計的時候採用工廠 或者 策略的設計模式，根據降級業務要求條件來進行策略/工廠的具體服務生成，從而實現服務降級邏輯。程式碼邏輯實現上會複雜些，可能帶來更多類，可讀性上對於設計模式不熟悉的研發者造成疑惑。

三者的關係

行文至此，也許有部分讀者困惑比如：降級和熔斷是不是一回事？熔斷後執行策略就相當於降級？

糾結於這些問題的本身，還是要回到文章開頭三大策略提出所面對解決的高可用問題。熔斷是針對防止故障擴散所進行的策略設計，而 降級面對的是特殊場景的 服務功能/質量的調整策略。

因此，可以看到 描述降級中提到的 雙十一零點前關閉商家價格調整的功能，顯然 並非為了防止故障擴散的措施而是保障其他業務關注功能效能（不是熔斷，主動改變）；同樣的，也可以舉個例子當呼叫某個服務失敗高時，切換呼叫到備用伺服器來作為熔斷處理策略，此時提供的服務功能或許都沒有變化，只是啟動了熔斷一種技術處理策略（不屬於服務降級）。

兩者並非一回事。但如果考慮到 熔斷髮生時，處理的方式是 調整某種產品功能服務，那其實既可以算熔斷也可以算降級，所以有些文章中也有提到 熔斷降級 的概念。限流 與 降級呢？ 熔斷 與 限流呢？ 在此就不一一贅述了，簡而言之的話，三者都非一回事，但在某些場景下相互支撐。

熔斷、限流、降級這些概念，更多是指導 在分散式系統 高可用設計上 應該考慮方面，其核心目的都是 達到系統的高可用。

轉載望能 保留，歡迎關注 Java研究者 公眾號

參考文獻