水滿則溢，月盈則虧，任何事物都不可能無限制的發(fā)展，我們的系統(tǒng)服務(wù)能力也一樣。

當(dāng)隨著流量的不斷增長，達(dá)到或超過服務(wù)本身的可承載范圍，系統(tǒng)服務(wù)的自我保護(hù)機(jī)制的建立就顯得很重要了。

本文希望可以用最通俗的解釋和貼切的實(shí)例來帶大家了解什么是限流、降級和熔斷。

Part1限流 - 自知之明和眼力見

一個(gè)是本身的承載能力，一個(gè)是依賴方的服務(wù)能力，其實(shí)都是從當(dāng)前系統(tǒng)的角度來說，

1.1自知之明之被動(dòng)限流

我只有這么大的能力，只能服務(wù)這么多客戶！

系統(tǒng)對自身的承載能力需要有一個(gè)清晰的認(rèn)識(shí)，對于超過承載能力的額外調(diào)用，要適當(dāng)拒絕。

而怎樣衡量系統(tǒng)承載能力是一個(gè)問題。

一般的我們有兩種常見方案：一是定義閾值和規(guī)則，二是自適應(yīng)限流策略。

閾值和規(guī)則是owner通過對業(yè)務(wù)的把控和自身的存儲(chǔ)、連接的現(xiàn)狀，根據(jù)人工經(jīng)驗(yàn)制定的。這樣的策略一般不會(huì)出什么大問題，但是不夠靈活，對請求反饋的靈敏度和資源的利用率不夠。

相對的，自適應(yīng)策略則是一種動(dòng)態(tài)限流策略，是通過對系統(tǒng)當(dāng)前的運(yùn)行狀況，動(dòng)態(tài)的調(diào)整限流閾值，在機(jī)器資源和流量處理之間尋找一個(gè)平衡。

如阿里開源的Sentinel限流器，在動(dòng)態(tài)限流策略上支持^[1]：

• Load 自適應(yīng)：系統(tǒng)的 load1 作為啟發(fā)指標(biāo)，進(jìn)行自適應(yīng)系統(tǒng)保護(hù)。當(dāng)系統(tǒng) load1 超過設(shè)定的啟發(fā)值，且系統(tǒng)當(dāng)前的并發(fā)線程數(shù)超過估算的系統(tǒng)容量時(shí)才會(huì)觸發(fā)系統(tǒng)保護(hù)。
• CPU usage：當(dāng)系統(tǒng) CPU 使用率超過閾值即觸發(fā)系統(tǒng)保護(hù)（取值范圍 0.0-1.0），比較靈敏。
• 平均 RT：當(dāng)單臺(tái)機(jī)器上所有入口流量的平均 RT 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)，單位是毫秒。
• 并發(fā)線程數(shù)：當(dāng)單臺(tái)機(jī)器上所有入口流量的并發(fā)線程數(shù)達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。
• 入口 QPS：當(dāng)單臺(tái)機(jī)器上所有入口流量的 QPS 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。

1.2眼力見之主動(dòng)限流

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

對下游依賴系統(tǒng)的服務(wù)能力，需要有一個(gè)精準(zhǔn)的判斷，對于服務(wù)能力弱的下游系統(tǒng)，要適當(dāng)減少調(diào)用，得有點(diǎn)眼力見，對不對。

因?yàn)椋^大部分的業(yè)務(wù)系統(tǒng)都不是單獨(dú)存在的，會(huì)依賴很多其他的系統(tǒng)，這些依賴方的服務(wù)能力，就像是木桶短板，限制了當(dāng)前系統(tǒng)的處理能力。這個(gè)時(shí)候就需要把下游當(dāng)做一個(gè)整體來考慮。

因此，需要把集群限流和單機(jī)限流配合起來使用，特別是下游服務(wù)的實(shí)例數(shù)、服務(wù)能力等和當(dāng)前系統(tǒng)有較大差距的時(shí)候，集群限流還是必要的。

一種方案：是通過收集服務(wù)節(jié)點(diǎn)的請求日志，統(tǒng)計(jì)請求量，并通過限流配置，控制節(jié)點(diǎn)限流邏輯：

我將其稱為后置限流，即收集各個(gè)節(jié)點(diǎn)的請求量和既定閾值對比，超過則反饋到各個(gè)節(jié)點(diǎn)，依賴單機(jī)限流進(jìn)行比例限流。

另一種方案：是限流總控服務(wù)，根據(jù)配置生產(chǎn)token，然后各個(gè)節(jié)點(diǎn)消費(fèi)token，正常獲取token后才能繼續(xù)業(yè)務(wù)：

我將其稱為前置限流，預(yù)先確定分配好可用的token，省去了匯總和反饋的處理機(jī)制，相比而言，這種控制方式要相對精準(zhǔn)和優(yōu)雅。

1.3同步轉(zhuǎn)異步

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

一個(gè)非常經(jīng)典的例子，就是第三方支付平臺(tái)的還款業(yè)務(wù)，用過的同學(xué)應(yīng)該都有體會(huì)，一般都是支付完成之后等一會(huì)才會(huì)收到銷賬的通知。

這個(gè)時(shí)延的底層邏輯是什么呢？

一般的，金融機(jī)構(gòu)的服務(wù)接口，因?yàn)槠鋽?shù)據(jù)一致性和系統(tǒng)穩(wěn)定性的要求，性能方面可能不如互聯(lián)網(wǎng)公司的系統(tǒng)。

那么，當(dāng)?shù)搅嗽鲁踉履┑倪€款高峰，如果把支持成功用戶的銷賬請求一股腦的都壓給機(jī)構(gòu)，后果可想而知。

但是，對于用戶來說，整個(gè)流程是可以被拆分的，用戶側(cè)只要完成支付操作就可以了。至于最終結(jié)果，可以允許延后被通知。

因此，基本上，金融網(wǎng)關(guān)在處理機(jī)構(gòu)銷賬都是異步的，即先將各業(yè)務(wù)的銷賬請求落地，然后異步的限速輪詢待處理的單據(jù)，再和機(jī)構(gòu)交互。

其實(shí)，不僅僅是在金融領(lǐng)域，只要我們的業(yè)務(wù)處理速度存在差異，且流程可以被拆分，即可考慮這種架構(gòu)思路，來緩解系統(tǒng)壓力，保障業(yè)務(wù)可用性。

Part2降級 - 丟車保帥

事發(fā)突然，能力有限，我只能緊著幾個(gè)重要客戶服務(wù)！

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

當(dāng)整個(gè)業(yè)務(wù)處于高峰期，或活動(dòng)脈沖期，當(dāng)服務(wù)的負(fù)載很高，逼近了服務(wù)承載閾值，即可以考慮服務(wù)降級來保障主功能可用。

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

那么，在系統(tǒng)中我們一般采用的降級方案有哪些呢？

1、頁面降級：即從用戶操作頁面進(jìn)行操作，直接限制和截?cái)嗄彻δ艿娜肟冢?/p>

如上圖所示，該業(yè)務(wù)場景下，是否使用積分，是在頁面渲染階段決定并返回給前段進(jìn)行頁面拼接的。

當(dāng)我們需要對其進(jìn)行降級時(shí)，會(huì)通過控制平臺(tái)進(jìn)行降級開關(guān)切換，系統(tǒng)讀到降級開啟后，會(huì)返回前段積分降級的標(biāo)識(shí)，前端將不再顯示積分抵扣入口。即從入口處截?cái)喾e分鏈路的執(zhí)行，達(dá)到降級的目的。

2、存儲(chǔ)降級：使用緩存方式來降級頻繁操作的存儲(chǔ)

對于秒殺業(yè)務(wù)這種寫多讀少的場景，對DB的壓力是非常大的，一般的，我們會(huì)采用上圖所示的緩存架構(gòu)，用緩存操作代替DB操作，用異步MQ代替同步接口，也屬于一種存儲(chǔ)的降級行為。

3、讀降級：對于非核心信息的讀請求禁用

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

4、寫降級：直接禁止相關(guān)寫操作的服務(wù)請求

總結(jié)，一句話概括降級的核心--丟車保帥。以損失部分體驗(yàn)的代價(jià)，來換取整個(gè)業(yè)務(wù)鏈路的穩(wěn)定性和持續(xù)可用。

Part3熔斷- 大局觀

合作方遇到困難了，不能為了自己把人家逼上絕路，別把自己也拖垮！出于人道主義，還得時(shí)不時(shí)問詢下，Are you ok ？

熔斷機(jī)制之所以被我賦予大局觀的美稱，是因?yàn)槠渌鉀Q的問題是級聯(lián)故障和服務(wù)雪崩！

在分布式的環(huán)境下，異常是常態(tài)。如上圖所示，當(dāng)服務(wù)C出現(xiàn)調(diào)用異常時(shí)，會(huì)在服務(wù)B中出現(xiàn)大量的請求超時(shí)和調(diào)用延遲。

這些調(diào)用也是需要占用系統(tǒng)資源的，當(dāng)大量請求積壓，服務(wù)B的線程池等資源也會(huì)隨之耗盡，最終導(dǎo)致整個(gè)服務(wù)鏈路的雪崩都是有可能的。

因此，當(dāng)服務(wù)C出現(xiàn)異常時(shí)，對服務(wù)C的調(diào)用適當(dāng)暫停，同時(shí)不斷監(jiān)測其接口是否恢復(fù)，對于整個(gè)鏈路的健康非常有必要的，上述針對C的處理過程就是熔斷。

從上圖可以看到，熔斷操作的三個(gè)關(guān)鍵點(diǎn)：

• 熔斷算法，即什么情況即會(huì)被判定為需要熔斷
• 熔斷后處理，即當(dāng)前系統(tǒng)不進(jìn)行遠(yuǎn)程調(diào)用，但調(diào)用結(jié)果需要有替代邏輯
• 熔斷恢復(fù)，適當(dāng)?shù)臋z測機(jī)制，用于結(jié)束熔斷，恢復(fù)正常服務(wù)調(diào)用。

之前在《在所依賴存儲(chǔ)不授信的場景下實(shí)現(xiàn)柔性事務(wù)降級》一文中提到過，我們的分布式事務(wù)，會(huì)依賴底層存儲(chǔ)做元數(shù)據(jù)存儲(chǔ)和一致性校驗(yàn)。

但是底層存儲(chǔ)的穩(wěn)定性稍有不足，這里就涉及到了服務(wù)熔斷的處理：

• 當(dāng)我們通過關(guān)鍵字監(jiān)控，檢測到底層存儲(chǔ)的操作異常操作某閾值時(shí)，就會(huì)通過腳本觸發(fā)一個(gè)開關(guān)切換的操作。此開關(guān)打開的作用是，棄用底層存儲(chǔ)，直接走兜底消息隊(duì)列，以保障絕大部分請求得以正常進(jìn)行。在開發(fā)開啟的時(shí)間段內(nèi)，用試探線程去試探底層存儲(chǔ)是否恢復(fù)，當(dāng)探測到存儲(chǔ)恢復(fù)正常時(shí)，切換開關(guān)恢復(fù)到正常鏈路。（這一步目前還未實(shí)現(xiàn)，用人工代替了）
  
  

參考資料

[1]Sentinel: "https://github.com/alibaba/Sentinel/wiki/系統(tǒng)自適應(yīng)限流"

[2]Hystrix: "https://github.com/Netflix/Hystrix/wiki"