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

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

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

Part1限流 - 自知之明和眼力見(jiàn)

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

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

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

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

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

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

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

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

如阿里開(kāi)源的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 超過(guò)設(shè)定的啟發(fā)值，且系統(tǒng)當(dāng)前的并發(fā)線(xiàn)程數(shù)超過(guò)估算的系統(tǒng)容量時(shí)才會(huì)觸發(fā)系統(tǒng)保護(hù)。
• CPU usage：當(dāng)系統(tǒng) CPU 使用率超過(guò)閾值即觸發(fā)系統(tǒng)保護(hù)（取值范圍 0.0-1.0），比較靈敏。
• 平均 RT：當(dāng)單臺(tái)機(jī)器上所有入口流量的平均 RT 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)，單位是毫秒。
• 并發(fā)線(xiàn)程數(shù)：當(dāng)單臺(tái)機(jī)器上所有入口流量的并發(fā)線(xiàn)程數(shù)達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。
• 入口 QPS：當(dāng)單臺(tái)機(jī)器上所有入口流量的 QPS 達(dá)到閾值即觸發(fā)系統(tǒng)保護(hù)。

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

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

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

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

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

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

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

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

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

1.3同步轉(zhuǎn)異步

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

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

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

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

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

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

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

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

Part2降級(jí) - 丟車(chē)保帥

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

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

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

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

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

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

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

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

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

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

3、讀降級(jí)：對(duì)于非核心信息的讀請(qǐng)求禁用

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

4、寫(xiě)降級(jí)：直接禁止相關(guān)寫(xiě)操作的服務(wù)請(qǐng)求

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

Part3熔斷- 大局觀(guān)

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

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

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

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

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

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

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

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

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

• 當(dāng)我們通過(guò)關(guān)鍵字監(jiān)控，檢測(cè)到底層存儲(chǔ)的操作異常操作某閾值時(shí)，就會(huì)通過(guò)腳本觸發(fā)一個(gè)開(kāi)關(guān)切換的操作。此開(kāi)關(guān)打開(kāi)的作用是，棄用底層存儲(chǔ)，直接走兜底消息隊(duì)列，以保障絕大部分請(qǐng)求得以正常進(jìn)行。在開(kāi)發(fā)開(kāi)啟的時(shí)間段內(nèi)，用試探線(xiàn)程去試探底層存儲(chǔ)是否恢復(fù)，當(dāng)探測(cè)到存儲(chǔ)恢復(fù)正常時(shí)，切換開(kāi)關(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"