今天準(zhǔn)備談下微服務(wù)架構(gòu)和API網(wǎng)關(guān)中的限流熔斷，當(dāng)前可以看到對(duì)于Spring Cloud框架本身也提供了Hystrix，主流的開源API網(wǎng)關(guān)產(chǎn)品類似Kong網(wǎng)關(guān)本身也包括了限流熔斷能力。

當(dāng)然也有完全較為獨(dú)立的限流熔斷開源實(shí)現(xiàn)，比如阿里的Sentinel即是我們經(jīng)常會(huì)用到的限流熔斷開源產(chǎn)品，而且可以和Dubbo，SpringCloud等各種微服務(wù)框架無(wú)縫集成。

由于網(wǎng)上大家能夠搜索到的關(guān)于各開源產(chǎn)品實(shí)現(xiàn)的限流熔斷功能和使用的文章都很多，因此這篇文章不打算再去介紹這些開源產(chǎn)品，而是從業(yè)務(wù)場(chǎng)景出發(fā)來(lái)思考下一個(gè)限流熔斷功能實(shí)現(xiàn)中的一些思路。當(dāng)然，對(duì)于我們常說(shuō)的資源定義，線程池隔離，滑動(dòng)時(shí)間窗口計(jì)算等內(nèi)容仍然是相通的。

問(wèn)題和背景說(shuō)明

首先我們來(lái)看下限流熔斷的出現(xiàn)背景。比如上圖的一個(gè)微服務(wù)間調(diào)用關(guān)系，我們用這個(gè)圖作為參考來(lái)進(jìn)行一些常見的場(chǎng)景和問(wèn)題。

某一個(gè)API接口服務(wù)調(diào)用導(dǎo)致整體資源被耗盡

這是一個(gè)比較典型的場(chǎng)景，即某一個(gè)API接口服務(wù)的大并發(fā)，大數(shù)據(jù)量調(diào)用導(dǎo)致服務(wù)器線程和內(nèi)存資源的全部耗盡。

對(duì)于API接口服務(wù)調(diào)用，往往并不怕大并發(fā)調(diào)用，而是怕長(zhǎng)耗時(shí)和大數(shù)據(jù)量的調(diào)用，這種接口調(diào)用導(dǎo)致連接一直被占用，而是大數(shù)據(jù)量情況下內(nèi)存資源也一直被占用而服務(wù)是否。在這種場(chǎng)景下往往導(dǎo)致線程池滿，或者場(chǎng)景的JVM內(nèi)存溢出問(wèn)題，將直接導(dǎo)致整個(gè)JVM內(nèi)存溢出宕機(jī)。

即我們常說(shuō)的單個(gè)API服務(wù)問(wèn)題導(dǎo)致所有資源被搶占，而影響到所有API接口調(diào)用。

常說(shuō)的服務(wù)調(diào)用引發(fā)雪崩

在微服務(wù)架構(gòu)下，微服務(wù)API接口間相互依賴，形成服務(wù)鏈調(diào)用關(guān)系，如上圖。在這種情況下依賴的API接口服務(wù)如果出現(xiàn)問(wèn)題，那么就會(huì)導(dǎo)致上層的各個(gè)消費(fèi)方都出現(xiàn)調(diào)用異常，而導(dǎo)致整體服務(wù)鏈調(diào)用雪崩。

比如上圖里面如果C1出現(xiàn)性能問(wèn)題，那么將直接導(dǎo)致B1和B2都出現(xiàn)性能問(wèn)題，而由于B層出現(xiàn)的性能問(wèn)題又會(huì)快速的傳遞到A層，導(dǎo)致A層相關(guān)的API接口服務(wù)全部出現(xiàn)問(wèn)題。

通過(guò)上面初步分析也可以看到，服務(wù)限流熔斷簡(jiǎn)單來(lái)說(shuō)就是不要因?yàn)閱蝹€(gè)API接口服務(wù)出現(xiàn)的異?；蛐阅軉?wèn)題而影響都整體API網(wǎng)關(guān)或微服務(wù)架構(gòu)的運(yùn)行，犧牲或拒絕一個(gè)服務(wù)的訪問(wèn)往往是確保了更多的服務(wù)能夠正常被消費(fèi)和調(diào)用。

在梳理清楚以上概念后，我們?cè)倩貋?lái)看下服務(wù)限流熔斷本身的概念。

限流熔斷的基本概念

對(duì)于限流熔斷，我原來(lái)給過(guò)一個(gè)概念，簡(jiǎn)單來(lái)說(shuō)限流就是服務(wù)請(qǐng)求調(diào)用要排隊(duì)，只給你一個(gè)線程池總數(shù)，超過(guò)就等待，即使你瞬間的請(qǐng)求并發(fā)再大也需要慢慢進(jìn)入。而對(duì)于熔斷則我們常說(shuō)的整個(gè)服務(wù)都處于不可用狀態(tài)。

今天我們對(duì)這個(gè)概念重新進(jìn)行下說(shuō)明。如下圖：

一個(gè)API接口有多個(gè)Consumer消費(fèi)方，對(duì)于限流更多的是針對(duì)消費(fèi)方+API這個(gè)粒度來(lái)說(shuō)的，而對(duì)于熔斷則是針對(duì)整個(gè)API Provider服務(wù)來(lái)說(shuō)的。

一個(gè)限流策略既可以是讓消費(fèi)方的服務(wù)請(qǐng)求進(jìn)行排隊(duì)，也可以是對(duì)觸發(fā)某個(gè)規(guī)則后直接對(duì)某個(gè)特定的消費(fèi)方調(diào)用進(jìn)行拒絕，比如上圖僅拒絕Consumer2的調(diào)用，而對(duì)于其它消費(fèi)方調(diào)用仍然放行。而對(duì)于熔斷策略則一定是整個(gè)服務(wù)全部進(jìn)行拒絕訪問(wèn)，注意這種熔斷不一定必須是服務(wù)下線或狀態(tài)變更，也可以是直接在限流熔斷攔截器上對(duì)所有入口請(qǐng)求進(jìn)行拒絕。

整體實(shí)現(xiàn)思路說(shuō)明

在講具體的實(shí)現(xiàn)方案的時(shí)候先講下整體的實(shí)現(xiàn)思路。

從前面的分析我們也看到，實(shí)際上對(duì)于限流和熔斷更多的是控制的資源單位和粒度不一樣，因?yàn)槲覀兿Ｍ氖菢?gòu)建一套算法來(lái)滿足對(duì)所有的問(wèn)題場(chǎng)景下的需求。由于服務(wù)限流熔斷更多的是需要對(duì)服務(wù)進(jìn)行攔截處理，我們也看到限流熔斷器一般都會(huì)配合API網(wǎng)關(guān)，微服務(wù)網(wǎng)關(guān)等使用，而不是獨(dú)立的存在。

01-對(duì)于資源粒度的考慮

在阿里的Sentinel的實(shí)現(xiàn)里面有幾個(gè)重要的概念，一個(gè)是資源，一個(gè)是Slot，一個(gè)是實(shí)現(xiàn)機(jī)制中的滑動(dòng)時(shí)間窗口，但是初步看好像無(wú)法配置到單個(gè)消費(fèi)方+服務(wù)這個(gè)層面。

對(duì)資源粒度，初步分析應(yīng)該包括了多個(gè)層次，從最粗的資源到最細(xì)化的資源，在傳統(tǒng)的資源粒度考慮里面我們往往并不會(huì)考慮到某個(gè)微服務(wù)或業(yè)務(wù)系統(tǒng)這個(gè)粒度，但是如果從API網(wǎng)關(guān)的限流熔斷，對(duì)API網(wǎng)關(guān)本身的性能保護(hù)來(lái)說(shuō)，這個(gè)還是有必要。

比如用戶中心這個(gè)微服務(wù)，實(shí)際上提供29個(gè)API服務(wù)接口。

當(dāng)用戶中心微服務(wù)模塊本身出現(xiàn)問(wèn)題的時(shí)候，這29個(gè)微服務(wù)可能都會(huì)出現(xiàn)性能訪問(wèn)緩慢，那么需要的是對(duì)整個(gè)用戶中心接入的API服務(wù)全部限流和熔斷。

即我們對(duì)資源本身的顆粒度進(jìn)一步細(xì)化，從最細(xì)粒度到最粗粒度可以分為：

• 最細(xì)粒度：API消費(fèi)方+API服務(wù)+API提供方
• 熔斷層：API服務(wù)+API提供方
• 熔斷范圍：API提供方(對(duì)API服務(wù)提供方所有服務(wù)進(jìn)行熔斷)

以上三種粒度才是我們實(shí)際進(jìn)行資源控制的時(shí)候需要考慮的內(nèi)容。

為啥考慮這個(gè)問(wèn)題，搞清楚了資源管控的顆粒度，我們一個(gè)方面是要在規(guī)則配置的時(shí)候支持多種層次的配置，一個(gè)方面就是我們實(shí)際實(shí)時(shí)數(shù)據(jù)計(jì)算的時(shí)候需要進(jìn)行顆粒度的考慮。

02-對(duì)規(guī)則的關(guān)鍵說(shuō)明

要實(shí)現(xiàn)限流熔斷，簡(jiǎn)單來(lái)就是三個(gè)方面的內(nèi)容，一個(gè)就是資源，一個(gè)是就是規(guī)則，一個(gè)就是通過(guò)計(jì)算匯總處理過(guò)程。計(jì)算過(guò)程最終就是來(lái)判斷在某一個(gè)時(shí)間點(diǎn)當(dāng)前的實(shí)際數(shù)據(jù)是否已經(jīng)滿足了規(guī)則觸發(fā)的要求，如果滿足要求就觸發(fā)規(guī)則進(jìn)行限流熔斷。

對(duì)于規(guī)則，首先要考慮維度定義，而維度本身就是API接口服務(wù)運(yùn)行實(shí)例的匯總統(tǒng)計(jì)數(shù)據(jù)，那么這些場(chǎng)景的維度包括了：

• API服務(wù)運(yùn)行時(shí)長(zhǎng)
• API服務(wù)單位時(shí)間的運(yùn)行次數(shù)
• API服務(wù)運(yùn)行數(shù)據(jù)量

而這三個(gè)基礎(chǔ)維度本身又會(huì)進(jìn)一步產(chǎn)生其它擴(kuò)展維度，比如我們常說(shuō)的最大數(shù)據(jù)量，評(píng)價(jià)數(shù)據(jù)量，運(yùn)行失敗次數(shù)，運(yùn)行成功率，運(yùn)行最大耗時(shí)等。

而對(duì)于具體的規(guī)則，我們希望最簡(jiǎn)單處理，即：

某一個(gè)指標(biāo) 大于 或小于 我們預(yù)定的某一個(gè)閾值，就算規(guī)則滿足。

其次就是可以定義復(fù)合規(guī)則。復(fù)合規(guī)則也簡(jiǎn)單處理為規(guī)則的與或處理，即：

規(guī)則1和規(guī)則2同時(shí)滿足，就算整體規(guī)則滿足

而對(duì)于規(guī)則本身的作用范圍，我在前面已經(jīng)講到，即資源本身的不同粒度。規(guī)則可以最細(xì)化的作用到某一個(gè)特定的消費(fèi)方調(diào)用的某一個(gè)特定服務(wù)，也可以是作用到某個(gè)服務(wù)所有消費(fèi)方。

簡(jiǎn)單來(lái)說(shuō)就是：規(guī)則+資源最終通過(guò)計(jì)算后觸發(fā)限流熔斷行為。

03-對(duì)計(jì)算邏輯的關(guān)鍵說(shuō)明

在前面我們把規(guī)則和資源講清楚后，再來(lái)看下具體的計(jì)算邏輯思路。

對(duì)于計(jì)算邏輯，我們可以將計(jì)算過(guò)程分解為多個(gè)獨(dú)立的計(jì)算單元，然后多個(gè)計(jì)算單元的組合最終形成了完整的計(jì)算和處理邏輯。

大家可以看下，對(duì)于Sentinel限流熔斷產(chǎn)品中的Slot概念正是可以理解為我們前面談到的計(jì)算單元。Sentinel將各個(gè)Slot的能力最終組合在一起完成了一次完整的限流熔斷邏輯處理。

對(duì)于計(jì)算邏輯，我們還是要回歸到具體的規(guī)則配置。

比如，我們配置完成的規(guī)則呈現(xiàn)方式可能如下：

• 對(duì)于用戶查詢API接口，在5分鐘內(nèi)調(diào)用次數(shù)大于1萬(wàn)次即整體熔斷
• 對(duì)于CRM系統(tǒng)消費(fèi)產(chǎn)品查詢接口，在10分鐘內(nèi)如果平均時(shí)長(zhǎng)大于30秒則拒絕CRM訪問(wèn)
• 對(duì)于訂單更新API接口，如果失敗率超過(guò)1%則全部熔斷

從上面的描述我們看了單位時(shí)間的概念，即當(dāng)我們?nèi)ビ|發(fā)限流熔斷行為的時(shí)候，我們不希望是一次偶然的調(diào)用并發(fā)或異常就馬上觸發(fā)，而是希望是我們觀察的一個(gè)單位時(shí)間段，如果持續(xù)發(fā)生某種異常行為才觸發(fā)。

這個(gè)單位時(shí)間可以是5分鐘，也是是10分鐘，乃至1個(gè)小時(shí)。

也就是說(shuō)我們最終統(tǒng)計(jì)的是單位時(shí)間的最終匯總統(tǒng)計(jì)數(shù)據(jù)。也就是說(shuō)對(duì)于服務(wù)運(yùn)行實(shí)例數(shù)據(jù)我們需要進(jìn)行實(shí)時(shí)采集，采集完成后在基于資源粒度進(jìn)行分類匯總，形成匯總數(shù)據(jù)。

那么如何匯總?

如果希望是統(tǒng)計(jì)1個(gè)小時(shí)，難道我們要在內(nèi)存里面一直存儲(chǔ)一個(gè)小時(shí)的實(shí)例數(shù)據(jù)，達(dá)到了1個(gè)小時(shí)的單位時(shí)間后再進(jìn)行匯總處理?這個(gè)顯然是不合適的。

Hystrix滑動(dòng)窗口計(jì)算邏輯

正是這個(gè)原因，我們?cè)俳o出一個(gè)最小統(tǒng)計(jì)時(shí)間間隔概念，比如我們可以設(shè)置為10秒，我們先將10秒這個(gè)最小時(shí)間間隔的實(shí)例數(shù)據(jù)進(jìn)行一次匯總，然后將第一次匯總后的數(shù)據(jù)放入到我們的滑動(dòng)窗口數(shù)組里面。然后再基于規(guī)則配置，提取滑動(dòng)窗口中的數(shù)據(jù)來(lái)進(jìn)行二次匯總處理，最終判斷配置的規(guī)則是否觸發(fā)限流熔斷操作。

限流熔斷整體實(shí)現(xiàn)邏輯

在前面的內(nèi)容講解完成后，我們?cè)賮?lái)看下限流熔斷的整體實(shí)現(xiàn)邏輯，你可以將這篇文章邏輯看做是當(dāng)前主流的限流熔斷產(chǎn)品的一個(gè)邏輯簡(jiǎn)化實(shí)現(xiàn)。

當(dāng)然一方面是簡(jiǎn)化，一方面在資源控制顆粒度上反而是本文的方法會(huì)更加細(xì)化。對(duì)于整個(gè)限流熔斷的處理邏輯流程，我們可以簡(jiǎn)化為下圖：

對(duì)于該圖，實(shí)際可以看到，如果按 Slot計(jì)算邏輯單元?jiǎng)澐值乃悸房梢苑譃椋?/p>

• 基于配置的規(guī)則將服務(wù)運(yùn)行實(shí)例按資源顆粒度匹配要求存到實(shí)例數(shù)據(jù)暫存區(qū)
• 進(jìn)行第一次匯總計(jì)算
• 將匯總數(shù)據(jù)推入到滑動(dòng)時(shí)間窗口數(shù)組
• 基于規(guī)則配置進(jìn)行二次匯總計(jì)算
• 對(duì)限流熔斷是否觸發(fā)進(jìn)行判斷和處理
• 我們?cè)賹⑸厦娴乃悸纷鲆粋€(gè)簡(jiǎn)單的描述。

比如我們當(dāng)前在限流熔斷規(guī)則配置中配置了三條獨(dú)立的規(guī)則，不同的資源顆粒度。

• 規(guī)則1：對(duì)于CRM消費(fèi)getCustomer接口進(jìn)行限流，10分鐘調(diào)用>1萬(wàn)即拒絕
• 規(guī)則2：對(duì)于getProductinfo接口流控，5分鐘錯(cuò)誤>1%則整體熔斷
• 規(guī)則3：對(duì)于ERP系統(tǒng)提供所有服務(wù)，1分鐘平均時(shí)長(zhǎng)>30秒則整體熔斷

如果是以上三條獨(dú)立的限流熔斷規(guī)則，則我們需要配置三個(gè)不同的臨時(shí)數(shù)據(jù)存儲(chǔ)區(qū)和三個(gè)獨(dú)立的滑動(dòng)時(shí)間窗口區(qū)。

在朝10秒臨時(shí)數(shù)據(jù)暫存區(qū)推送臨時(shí)數(shù)據(jù)的時(shí)候可能會(huì)造成冗余，但是在限流規(guī)則本身不帶來(lái)配置的情況下該方案反而是最優(yōu)方案。畢竟在實(shí)際應(yīng)用場(chǎng)景中，我們往往是在發(fā)現(xiàn)了明細(xì)的性能異?；騿?wèn)題的時(shí)候才會(huì)配置限流熔斷規(guī)則。

比如，CRM系統(tǒng)調(diào)用getCustomer API接口。

當(dāng)獲取到這次實(shí)例數(shù)據(jù)的時(shí)候，我們將其推送到第一個(gè)緩存集合，如果該接口本身也是ERP系統(tǒng)提供的接口，那么我們會(huì)同時(shí)將該數(shù)據(jù)推送一份到ERP系統(tǒng)緩存集合。

對(duì)于緩存數(shù)據(jù)集，我們每10秒就做一次匯總處理。并將匯總完成的結(jié)果數(shù)據(jù)形成一條記錄推送到對(duì)應(yīng)的滑動(dòng)時(shí)間窗口區(qū)。在推送完成后將該數(shù)據(jù)集數(shù)據(jù)全部清空或進(jìn)行資源釋放。

基于滑動(dòng)窗口數(shù)據(jù)的二次數(shù)據(jù)處理

對(duì)于滑動(dòng)窗口中的二次數(shù)據(jù)處理，我們可以在每次數(shù)據(jù)推送完成后就計(jì)算一次滑動(dòng)窗口數(shù)據(jù)，比如5分鐘規(guī)則，我們就獲取窗口中最近5分鐘的數(shù)據(jù)進(jìn)行二次匯總，并判斷二次匯總后的數(shù)據(jù)是否滿足了相應(yīng)的觸發(fā)條件。

如果滿足條件，就進(jìn)行限流熔斷處理。

限流熔斷實(shí)現(xiàn)邏輯和API網(wǎng)關(guān)能力的解耦

最后談下限流熔斷實(shí)現(xiàn)和整個(gè)API網(wǎng)關(guān)能力的解耦。

簡(jiǎn)單來(lái)說(shuō)，限流熔斷本身也是一個(gè)獨(dú)立的攔截器，對(duì)服務(wù)請(qǐng)求進(jìn)行攔截，并判斷當(dāng)前限流熔斷規(guī)則是否處于生效狀態(tài)，如果處于生效狀態(tài)就觸發(fā)限流熔斷操作，比如對(duì)訪問(wèn)請(qǐng)求進(jìn)行拒絕。如果不生效狀態(tài)，那么就放行服務(wù)請(qǐng)求。

那么整個(gè)限流熔斷和API網(wǎng)關(guān)的集成關(guān)系，我們需要重新梳理如下：

當(dāng)然在服務(wù)本身被熔斷后，我們還可以設(shè)置一個(gè)解除時(shí)間間隔，比如5分鐘或10分鐘，我們還需要設(shè)置一個(gè)定時(shí)任務(wù)來(lái)進(jìn)行計(jì)算，當(dāng)解除條件滿足后，將全局狀態(tài)緩存中的服務(wù)狀態(tài)進(jìn)行刷新，以對(duì)服務(wù)限流進(jìn)行解除。

以上即是服務(wù)限流熔斷邏輯實(shí)現(xiàn)的以下關(guān)鍵思考，供參考。

本文轉(zhuǎn)載自微信公眾號(hào)「人月聊IT」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系人月聊IT公眾號(hào)。