高併發整體可用性：一文詳解降級、限流和熔斷

• 併發線程數：當單台機器上所有入口流量的併發線程數達到閾值即觸發系統保護。

合作方只有那麼大的能力，我只能索取這麼多！

對下游依賴系統的服務能力，需要有一個精準的判斷，對於服務能力弱的下游系統，要適當減少調用，得有點眼力見，對不對。

因為，絕大部分的業務系統都不是單獨存在的，會依賴很多其他的系統，這些依賴方的服務能力，就像是木桶短板，限制了當前系統的處理能力。這個時候就需要把下游當做一個整體來考慮。

因此，需要把集群限流和單機限流配合起來使用，特別是下游服務的實例數、服務能力等和當前系統有較大差距的時候，集群限流還是必要的。

一種方案：是通過收集服務節點的請求日誌，統計請求量，並通過限流配置，控制節點限流邏輯：

我將其稱為後置限流，即收集各個節點的請求量和既定閾值對比，超過則反饋到各個節點，依賴單機限流進行比例限流。

另一種方案：是限流總控服務，根據配置生產token，然後各個節點消費token，正常獲取token後才能繼續業務：

摘自:Sentinel

我將其稱為前置限流，預先確定分配好可用的token，省去了彙總和反饋的處理機制，相比而言，這種控制方式要相對精準和優雅。

合作方雖然能力有限，但態度很好，加班加點的處理；而我們的客戶也很友好，同意多等等

一個非常經典的例子，就是第三方支付平臺的還款業務，用過的同學應該都有體會，一般都是支付完成之後等一會才會收到銷賬的通知。

這個時延的底層邏輯是什麼呢？

一般的，金融機構的服務介面，因為其數據一致性和系統穩定性的要求，性能方面可能不如互聯網公司的系統。

那麼，當到了月初月末的還款高峰，如果把支持成功用戶的銷賬請求一股腦的都壓給機構，後果可想而知。

但是，對於用戶來說，整個流程是可以被拆分的，用戶側只要完成支付操作就可以了。至於最終結果，可以允許延後被通知。

因此，基本上，金融網關在處理機構銷賬都是非同步的，即先將各業務的銷賬請求落地，然後非同步的限速輪詢待處理的單據，再和機構交互。

其實，不僅僅是在金融領域，只要我們的業務處理速度存在差異，且流程可以被拆分，即可考慮這種架構思路，來緩解系統壓力，保障業務可用性。

事發突然，能力有限，我只能緊著幾個重要客戶服務！

那麼，什麼情況需要降級，什麼鏈路可以被降級呢？

當整個業務處於高峰期，或活動脈衝期，當服務的負載很高，逼近了服務承載閾值，即可以考慮服務降級來保障主功能可用。

可以降級的一定是非核心的鏈路，比如網購場景下的積分抵扣，如果降級積分抵扣鏈路，其實不影響大部分的支付功能。

那麼，在系統中我們一般採用的降級方案有哪些呢？

即從用戶操作頁面進行操作，直接限制和截斷某功能的入口：

從頁面入口對積分鏈路降級

如上圖所示，該業務場景下，是否使用積分，是在頁面渲染階段決定並返回給前段進行頁面拼接的。

當我們需要對其進行降級時，會通過控制平臺進行降級開關切換，系統讀到降級開啟後，會返回前段積分降級的標識，前端將不再顯示積分抵扣入口。即從入口處截斷積分鏈路的執行，達到降級的目的。

使用緩存方式來降級頻繁操作的存儲

https://blog.csdn.net/di_ko/article/details/118058080

對於秒殺業務這種寫多讀少的場景，對DB的壓力是非常大的，一般的，我們會採用上圖所示的緩存架構，用緩存操作代替DB操作，用非同步MQ代替同步介面，也屬於一種存儲的降級行為。

對於非核心信息的讀請求禁用

微信的搶紅包場景，紅包列表的展示屬於搶紅包的非核心鏈路，因此，對於列表展示，在業務壓力較大的情況下，對頭像等信息的讀，可以直接禁用。

直接禁止相關寫操作的服務請求

總結，一句話概括降級的核心--丟車保帥。以損失部分體驗的代價，來換取整個業務鏈路的穩定性和持續可用。