今天準(zhǔn)備談下基于API網(wǎng)關(guān)來實(shí)現(xiàn)微服務(wù)治理管控中的服務(wù)限流，熔斷和降級(jí)方面的內(nèi)容。在前面談微服務(wù)架構(gòu)的時(shí)候也談到過類似通過Hystrix，Sentinel來是服務(wù)限流熔斷。包括也不斷地在談去中心化架構(gòu)和服務(wù)網(wǎng)格化。

但是通過API網(wǎng)關(guān)來實(shí)現(xiàn)微服務(wù)治理，短期仍然是一個(gè)必要選擇。

其原因主要體現(xiàn)在以下幾個(gè)方面：

其一是場(chǎng)景需求，即面對(duì)一個(gè)大集成項(xiàng)目，或多個(gè)開發(fā)商進(jìn)行協(xié)同集成的場(chǎng)景，采用API網(wǎng)關(guān)是必須的。一個(gè)開發(fā)商內(nèi)部可以去中心化，但是多個(gè)開發(fā)商間想要去中心化不容易。

其二是在微服務(wù)架構(gòu)開發(fā)里面，單個(gè)微服務(wù)應(yīng)該盡量簡單，就是實(shí)現(xiàn)業(yè)務(wù)規(guī)則邏輯和暴露API接口服務(wù)能力。但是當(dāng)前的微服務(wù)開發(fā)框架，在實(shí)現(xiàn)類似限流熔斷等的時(shí)候，基本都需要對(duì)已經(jīng)開發(fā)完成的微服務(wù)進(jìn)行相關(guān)的配置修改或增加注解等。

其三對(duì)于ServiceMesh服務(wù)網(wǎng)格當(dāng)前還沒有大足夠成熟和大面積應(yīng)用的階段，但是API網(wǎng)關(guān)本身已經(jīng)足夠成熟并得到大量項(xiàng)目實(shí)踐驗(yàn)證。

基于API網(wǎng)關(guān)進(jìn)行服務(wù)接入和管控

對(duì)于API網(wǎng)關(guān)我前面已經(jīng)寫過很多文章說明，在這里不再重復(fù)描述。對(duì)于今天要說明的微服務(wù)治理管控我們假設(shè)如上圖的場(chǎng)景，即：

有訂單，用戶和產(chǎn)品三個(gè)微服務(wù)暴露6個(gè)接口，其中3個(gè)屬于內(nèi)部使用走注冊(cè)中心接入。另外三個(gè)接口注入接入到API網(wǎng)關(guān)，網(wǎng)關(guān)代理封裝后暴露Http Rest接口提供外部小程序，App和CRM三個(gè)獨(dú)立的應(yīng)用訪問。

在這個(gè)場(chǎng)景下三個(gè)微服務(wù)僅僅提供API接口注冊(cè)，對(duì)于具體的API限流熔斷都在API網(wǎng)關(guān)上面進(jìn)行靈活的配置和管理，而這些配置和管控對(duì)微服務(wù)本身無任何侵入。

對(duì)于API網(wǎng)關(guān)本身也集群部署確保可靠性和性能，因此后續(xù)的限流熔斷實(shí)際是基于整個(gè)集群入口總流量進(jìn)行。其次，API網(wǎng)關(guān)的限流熔斷，不僅僅是訪問雪崩，包含后端的微服務(wù)模塊，另外一個(gè)重要作用是保護(hù)API網(wǎng)關(guān)本身的性能和可靠性。

為了方便敘述，假設(shè)API網(wǎng)關(guān)接入并暴露了查詢訂單，查詢用戶，查詢產(chǎn)品三個(gè)API接口服務(wù)。

對(duì)于限流熔斷的基本實(shí)現(xiàn)思路可以先參考我前面文章：

微服務(wù)和API網(wǎng)關(guān)限流熔斷實(shí)現(xiàn)關(guān)鍵邏輯思路

限流，熔斷和降級(jí)區(qū)別

先回顧下限流，熔斷和降級(jí)具體的內(nèi)容和區(qū)別。

對(duì)于限流簡單來說就是入口流量控制，比如QPS超過了我們定義的某個(gè)基準(zhǔn)值就禁止進(jìn)入，當(dāng)負(fù)荷下來后，又可以放入更多的請(qǐng)求。簡單來說就是服務(wù)調(diào)用請(qǐng)求，超過了請(qǐng)求負(fù)荷就需要等待或被拒絕掉，但是等負(fù)荷下來你又可以調(diào)用通。

而熔斷則是對(duì)整個(gè)API服務(wù)的處理，即整個(gè)API接口不再提供服務(wù)能力，直接拒絕訪問。具體恢復(fù)可以手工恢復(fù)，也可以在我們?cè)O(shè)置的時(shí)間間隔后自動(dòng)恢復(fù)。對(duì)于熔斷一般則是根據(jù)并發(fā)量，錯(cuò)誤數(shù)，響應(yīng)時(shí)長等達(dá)到某個(gè)閾值，就直接觸發(fā)熔斷。

服務(wù)降級(jí)則是針對(duì)所有服務(wù)而不是單個(gè)服務(wù)的，即當(dāng)出現(xiàn)巨大的訪問量或并發(fā)量的時(shí)候，如何通過將非核心服務(wù)降級(jí)（限流或熔斷）以釋放資源，來保證核心服務(wù)SLA水平。

通過上面的解釋總結(jié)如下：

限流時(shí)候本身不是服務(wù)完全不可用，而是對(duì)流量進(jìn)行控制；而熔斷則是完全服務(wù)不可用。服務(wù)降級(jí)不是針對(duì)單個(gè)服務(wù)，而是整個(gè)服務(wù)群，服務(wù)降級(jí)措施可以是限流，也可以是熔斷。

服務(wù)限流

在前面已經(jīng)談到，在去中心化的微服務(wù)架構(gòu)下，限流功能的實(shí)現(xiàn)僅僅是為了包含微服務(wù)本身不超負(fù)荷運(yùn)轉(zhuǎn)。我們還是以開在商場(chǎng)里面的餐館的例子來進(jìn)行說明。

即一個(gè)餐館最多只能容納100桌就餐，當(dāng)全部滿員后新來的人就需要等待，只有等已經(jīng)在就餐的客人就餐完畢空出資源后才能夠進(jìn)入。但是這個(gè)時(shí)候餐廳本身的客流本身來源于兩個(gè)點(diǎn)，一個(gè)是逛商城的人隨機(jī)過來的，一個(gè)是餐廳的少量會(huì)員VIP客戶。但是餐廳本身沒有包間，也就是說當(dāng)普通客戶過多的時(shí)候直接導(dǎo)致餐廳排隊(duì)，VIP客戶并不能得到應(yīng)有的服務(wù)。

這個(gè)時(shí)候我們希望的做法是對(duì)普通客戶流量進(jìn)行控制，而不是由于大量普通服務(wù)需求的滿足導(dǎo)致了VIP客戶排隊(duì)或服務(wù)無法得到滿足。即餐館不僅需要考慮自身負(fù)荷，還需要考慮對(duì)不同類型客戶的服務(wù)質(zhì)量。

對(duì)應(yīng)到微服務(wù)里面同樣，即訂單查詢服務(wù)時(shí)間上有APP，小程序和CRM三個(gè)服務(wù)消費(fèi)方。不能由于某一個(gè)消費(fèi)方的大量調(diào)用而導(dǎo)致其它消費(fèi)方服務(wù)請(qǐng)求也受影響。

即在這個(gè)場(chǎng)景下，實(shí)際上服務(wù)限流本身是兩個(gè)層級(jí)的限流。

其一是對(duì)服務(wù)入口總流量進(jìn)行限流，確保微服務(wù)本身在負(fù)荷之內(nèi)；其二是對(duì)單個(gè)服務(wù)進(jìn)行限流，以確保微服務(wù)本身有空余能力滿足其它服務(wù)。

在實(shí)際當(dāng)前開源的微服務(wù)限流熔斷實(shí)現(xiàn)上，基本很難控制到單個(gè)應(yīng)用請(qǐng)求方，而對(duì)應(yīng)API網(wǎng)關(guān)在進(jìn)行限流熔斷實(shí)現(xiàn)的時(shí)候，我們則可以完全做到這點(diǎn)。

具體的并發(fā)量設(shè)置多少？

對(duì)應(yīng)服務(wù)限流設(shè)置，我們以一秒內(nèi)的QPS請(qǐng)求數(shù)閾值進(jìn)行配置。那么針對(duì)一個(gè)微服務(wù)API接口，究竟應(yīng)該配置多大的QPS值？對(duì)于這個(gè)問題仍然是事前和事后兩種處理方式。

對(duì)于事前方式即我們?cè)谖⒎?wù)上線前就要準(zhǔn)備和模擬真正的業(yè)務(wù)場(chǎng)景，進(jìn)行API接口的性能測(cè)試，看下API本身的性能和QPS數(shù)據(jù)。

我們可以不斷地加大并發(fā)觀察兩個(gè)關(guān)鍵指標(biāo)，一個(gè)是系統(tǒng)本身的資源負(fù)荷情況，一個(gè)是服務(wù)本身的響應(yīng)時(shí)長情況。比如加大到500并發(fā)的時(shí)候，資源負(fù)荷已經(jīng)超過80%，那么這個(gè)時(shí)候500并發(fā)就是極限值。但是你可能加大到300個(gè)并發(fā)的時(shí)候服務(wù)響應(yīng)時(shí)長已經(jīng)指數(shù)級(jí)增長而無法滿足業(yè)務(wù)需求，那么這個(gè)時(shí)候你就只能取300并發(fā)下實(shí)際的QPS數(shù)據(jù)。

在配置的時(shí)候我們對(duì)QPS數(shù)據(jù)再預(yù)留點(diǎn)冗余即是我們可以配置的限流值。

當(dāng)然也可以是后期處理方式，比如前期我們對(duì)限流沒有任何配置，但是上線后會(huì)發(fā)現(xiàn)業(yè)務(wù)并發(fā)達(dá)到某個(gè)值的時(shí)候服務(wù)響應(yīng)緩慢或者資源負(fù)荷很大導(dǎo)致內(nèi)存泄漏等。那么這個(gè)時(shí)候，我們就需要基于實(shí)際服務(wù)運(yùn)行采集到的值進(jìn)行配置。

對(duì)于限流的思考

對(duì)于限流前面已經(jīng)描述過，實(shí)際有兩種情況，一個(gè)就是請(qǐng)求直接排隊(duì)等待，連接保持；一種是請(qǐng)求訪問直接被拒絕掉，但是過一會(huì)訪問又可以訪問了。

如果真要啟用限流，建議采用第一種情況。任何一個(gè)接口服務(wù)對(duì)于消費(fèi)方來說，如果出現(xiàn)一會(huì)可用，一會(huì)不可用，需要消費(fèi)方自己不斷地去重試都是不可接受的。雖然保證了微服務(wù)提供端的可靠性，但是對(duì)于服務(wù)提供本身的友好性則大打折扣。

即使是排隊(duì)等待，我們也需要考慮連接超時(shí)配置，你要確保在連接超時(shí)前，排隊(duì)等待的請(qǐng)求都能夠被正常地處理掉。

舉個(gè)高速入口收費(fèi)站的例子說明。

當(dāng)車輛進(jìn)入收費(fèi)站的時(shí)候，可以進(jìn)行排隊(duì)，但是約定的最大等待時(shí)間是10分鐘。即我們進(jìn)入排隊(duì)后就需要在10分鐘內(nèi)能夠通過，如果你無法滿足這個(gè)約定，你可以在我排隊(duì)前就告訴我收費(fèi)站滿負(fù)荷了，請(qǐng)走其它入口。

服務(wù)熔斷

對(duì)于限流前面已經(jīng)談到，一般是根據(jù)并發(fā)和QPS數(shù)來設(shè)置限流，但是我們并不明確超過了設(shè)置的QPS值是否就一定把微服務(wù)壓垮。

在前面也給出了一般需要根據(jù)訪問時(shí)長和資源利用率來測(cè)算具體設(shè)置多少Q(mào)PS合理。

而服務(wù)熔斷除了前面談到是將這個(gè)服務(wù)設(shè)置為不可用外，更加重要的就是服務(wù)熔斷的規(guī)則設(shè)置除了并發(fā)數(shù)外，還可以設(shè)置類似服務(wù)響應(yīng)時(shí)長，服務(wù)報(bào)文數(shù)據(jù)量等。

而服務(wù)響應(yīng)時(shí)長慢，或者報(bào)文量增大往往才是導(dǎo)致整體微服務(wù)或API網(wǎng)關(guān)出現(xiàn)不可用并造成雪崩效應(yīng)的關(guān)鍵。單個(gè)服務(wù)的熔斷不僅僅是防止雪崩效應(yīng)，更加重要的是防止單個(gè)服務(wù)大量的占用JVM內(nèi)存資源，占用線程資源而導(dǎo)致了整體API網(wǎng)關(guān)出現(xiàn)內(nèi)存溢出。

對(duì)于服務(wù)熔斷，同樣也存在上面的問題。

比如對(duì)于訂單信息查詢接口，你會(huì)發(fā)現(xiàn)僅僅是CRM系統(tǒng)出現(xiàn)了大并發(fā)量和大數(shù)據(jù)量的訪問，由于CRM的大量訪問導(dǎo)致了接口運(yùn)行緩慢。這個(gè)時(shí)候不應(yīng)該對(duì)整個(gè)接口進(jìn)行熔斷，而是應(yīng)該僅僅對(duì)CRM系統(tǒng)的訪問進(jìn)行熔斷。

即需要做到從服務(wù)粒度 =》（服務(wù)消費(fèi)方 + 服務(wù)）粒度。

API網(wǎng)關(guān)和注冊(cè)中心混合架構(gòu)

在一個(gè)微服務(wù)架構(gòu)環(huán)境下，由于內(nèi)部的各個(gè)微服務(wù)之間可能走的是服務(wù)注冊(cè)中心這種去中心化的模式，而僅僅需要對(duì)外暴露的接口服務(wù)注冊(cè)到了API網(wǎng)關(guān)上面進(jìn)行對(duì)外開放。

那么這個(gè)時(shí)候就可能同時(shí)存在內(nèi)部微服務(wù)體系中的熔斷和API網(wǎng)關(guān)上的熔斷兩處配置。但是這兩處配置都是必須進(jìn)行的。

對(duì)于內(nèi)部的類似Hystrix熔斷配置主要是針對(duì)內(nèi)部的API接口訪問和調(diào)用，重點(diǎn)是包含微服務(wù)模塊本身可靠性；而對(duì)于API網(wǎng)關(guān)本身限流主要是針對(duì)外部訪問，一方面是對(duì)大并發(fā)訪問進(jìn)行第一次攔截，一方面是保證API網(wǎng)關(guān)本身的穩(wěn)定性不超負(fù)荷。

但是實(shí)際你會(huì)看到，在這種混合架構(gòu)下如下一個(gè)新問題，即沒有一個(gè)地方對(duì)所有的流量進(jìn)行匯集而實(shí)現(xiàn)總的限流控制。

那么在這種情況下，采用熔斷則是最好的方式。

因?yàn)槿蹟啾旧聿皇腔诓l(fā)量，而是基于服務(wù)響應(yīng)時(shí)間，報(bào)文量等進(jìn)行熔斷控制。但是在混合架構(gòu)下如何形成統(tǒng)一的規(guī)則計(jì)算？這個(gè)時(shí)候就需要兩個(gè)限流熔斷控制點(diǎn)都訪問統(tǒng)一個(gè)日志中心和規(guī)則計(jì)算中心。具體參考下圖：

在這種模式下基本就可以實(shí)現(xiàn)一個(gè)整體的熔斷管理。

服務(wù)降級(jí)

在這里先談下微服務(wù)架構(gòu)里面談到的服務(wù)降級(jí)，在微服務(wù)架構(gòu)下的降級(jí)一般會(huì)談兩種形式的降級(jí)，一種是屏蔽降級(jí)，一種是熔斷降級(jí)。

對(duì)于屏蔽降級(jí)，簡單來說就是在微服務(wù)多節(jié)點(diǎn)集群部署的情況下，當(dāng)發(fā)往某一個(gè)集群節(jié)點(diǎn)，比如C節(jié)點(diǎn)的服務(wù)訪問調(diào)用出現(xiàn)大量異常錯(cuò)誤的時(shí)候，我們需要對(duì)C節(jié)點(diǎn)進(jìn)行屏蔽。

對(duì)于熔斷降級(jí)，則實(shí)際和熔斷類似了，即當(dāng)對(duì)于微服務(wù)的大并發(fā)訪問導(dǎo)致服務(wù)性能下降的時(shí)候，我們需要對(duì)服務(wù)進(jìn)行熔斷。這和前面談到的熔斷基本一致。但是這里的熔斷往往更加靈活，比如可以將熔斷器全部打開，半打開或全部關(guān)閉等。

即在熔斷后設(shè)置一個(gè)時(shí)間窗口恢復(fù)，在恢復(fù)的時(shí)候僅僅放入少量服務(wù)調(diào)用進(jìn)行驗(yàn)證，如果服務(wù)已經(jīng)恢復(fù)正常則將熔斷器關(guān)閉，如果仍然訪問失敗則繼續(xù)打開熔斷器并順延一個(gè)時(shí)間窗口。

而對(duì)于API網(wǎng)關(guān)來談服務(wù)降級(jí)，即在API網(wǎng)關(guān)本身能力有限的情況下，如何確保高SLA的服務(wù)都能夠得到需求滿足，在出現(xiàn)大并發(fā)訪問等場(chǎng)景的時(shí)候優(yōu)先犧牲低SLA服務(wù)。

拿上面的場(chǎng)景來舉例。

即不存在對(duì)于查詢訂單API接口并發(fā)量上來響應(yīng)時(shí)間無法滿足需求情況下對(duì)該接口降級(jí)的說法，這種情況只能叫對(duì)該接口限流。而實(shí)際場(chǎng)景說法應(yīng)該是當(dāng)查詢訂單API接口響應(yīng)無法滿足需求的時(shí)候，由于該接口是高SLA接口，因此需要對(duì)查詢用戶接口進(jìn)行限流或熔斷。以確保更多的資源能夠分配給查詢訂單接口使用。

拿去銀行辦理業(yè)務(wù)的窗口來舉例：

最初是4個(gè)普通窗口，一個(gè)VIP貴賓窗口。但是當(dāng)天VIP用戶來辦理業(yè)務(wù)的人相對(duì)多，這個(gè)時(shí)候不能降低VIP用戶的服務(wù)水平，因此需要將普通窗口減少到3個(gè)，而VIP窗口增加為2個(gè)。

我們可以再回顧下SLA服務(wù)等級(jí)協(xié)議，即：

SLA：Service-Level Agreement的縮寫，意思是服務(wù)等級(jí)協(xié)議du。zhiSLA是關(guān)于網(wǎng)絡(luò)服務(wù)供dao應(yīng)商和客戶間的一專份合同，其書中定義了服務(wù)類型、服務(wù)質(zhì)量和客戶付款等術(shù)語。按照 SLA 要求，服務(wù)供應(yīng)商采用多種技術(shù)和解決方案去監(jiān)控和管理網(wǎng)絡(luò)性能及流量，以滿足 SLP 中的相關(guān)需求，并產(chǎn)生對(duì)應(yīng)的客戶結(jié)果報(bào)告。

那么對(duì)于微服務(wù)下的API接口服務(wù)，同樣存在SLA等級(jí)要求。我們?cè)谶M(jìn)行微服務(wù)接口定義和設(shè)計(jì)的時(shí)候需要對(duì)里面的關(guān)鍵要求進(jìn)行定義。比如：

• 服務(wù)響應(yīng)時(shí)間要求：<2S
• 服務(wù)高可用性要求：99.99%

這些就是關(guān)鍵的KPI指標(biāo)，可以基于這些指標(biāo)來進(jìn)行服務(wù)SLA等級(jí)的劃分。

基于監(jiān)控預(yù)警來進(jìn)行手工降級(jí)

在整個(gè)服務(wù)運(yùn)行中，一般還有服務(wù)運(yùn)行監(jiān)控預(yù)警功能，即設(shè)置相關(guān)的服務(wù)KPI指標(biāo)或組合指標(biāo)，當(dāng)這些指標(biāo)閾值滿足的時(shí)候就發(fā)出監(jiān)控預(yù)警信息。

比如服務(wù)響應(yīng)環(huán)境，JVM內(nèi)存使用率居高不下等都可以進(jìn)行預(yù)警，在出現(xiàn)預(yù)警后運(yùn)維人員可以基于當(dāng)前服務(wù)運(yùn)行的真實(shí)情況來判斷具體是哪個(gè)服務(wù)或哪個(gè)消費(fèi)方導(dǎo)致的服務(wù)運(yùn)行性能問題，并對(duì)相應(yīng)的服務(wù)進(jìn)行熔斷操作。

如果是高SLA服務(wù)本身性能出現(xiàn)問題而整個(gè)集群資源負(fù)荷大的情況下，那么就需要對(duì)非核心業(yè)務(wù)涉及到的微服務(wù)或微服務(wù)API進(jìn)行手工關(guān)閉或限流熔斷。

智能化的服務(wù)限流和熔斷處理

在這里從API網(wǎng)關(guān)進(jìn)行接口服務(wù)集成和暴露的角度出發(fā)，是否需要對(duì)網(wǎng)關(guān)接入的每一個(gè)服務(wù)都進(jìn)行相應(yīng)的服務(wù)限流和熔斷配置？

由于每個(gè)服務(wù)本身的并發(fā)量不一樣，出現(xiàn)峰值的時(shí)候也不一樣，同時(shí)API網(wǎng)關(guān)本身承載了多個(gè)服務(wù)實(shí)際更多需要的是控制整個(gè)API網(wǎng)關(guān)本身的性能負(fù)荷，確保網(wǎng)關(guān)運(yùn)行的穩(wěn)定性。

微服務(wù)架構(gòu)體系下，對(duì)于微服務(wù)框架內(nèi)本身也有熔斷降級(jí)處理措施和機(jī)制，那么在這種場(chǎng)景下API網(wǎng)關(guān)的限流熔斷首先要考慮為了自身的高可靠性運(yùn)行需求。

如果我們對(duì)每個(gè)服務(wù)都進(jìn)行配置，往往并不能很理想地達(dá)到限流熔斷的目的。基于項(xiàng)目實(shí)際的實(shí)踐情況來看，要么是這個(gè)值配置的太小，導(dǎo)致對(duì)本身可以通過的服務(wù)請(qǐng)求進(jìn)行了熔斷和拒絕；要么是這個(gè)值配置的太大，API網(wǎng)關(guān)本身已經(jīng)內(nèi)存溢出也沒有觸發(fā)熔斷規(guī)則。

那么究竟是什么會(huì)影響到API網(wǎng)關(guān)的穩(wěn)定性？

這個(gè)一方面是大量的服務(wù)訪問請(qǐng)求連接長時(shí)間保持不釋放，導(dǎo)致線程池被消耗完；一方面是出現(xiàn)大報(bào)文的消息調(diào)用，導(dǎo)致JVM持續(xù)增長而無法回收。這兩種才是導(dǎo)致API網(wǎng)關(guān)出現(xiàn)宕機(jī)，重啟或不可用的關(guān)鍵因素。

簡單來說即首先設(shè)置一個(gè)統(tǒng)一的JVM閾值和線程池當(dāng)前線程數(shù)閾值即可。

然后規(guī)則中心對(duì)兩個(gè)值進(jìn)行持續(xù)的心跳監(jiān)控，當(dāng)發(fā)現(xiàn)閾值超過的時(shí)候，快速地找到對(duì)應(yīng)的接口服務(wù)和服務(wù)請(qǐng)求方，并執(zhí)行限流或熔斷操作，必要的時(shí)候還可以直接kill掉當(dāng)前線程。如果上述方法還不能恢復(fù)的話，還需要對(duì)集群中超過閾值的節(jié)點(diǎn)強(qiáng)制進(jìn)行節(jié)點(diǎn)重啟操作，以防止集群進(jìn)行故障漂移，導(dǎo)致正常節(jié)點(diǎn)也出現(xiàn)問題。

其次，整個(gè)服務(wù)性能下降也可能出現(xiàn)在月結(jié)或年結(jié)的時(shí)候，這個(gè)時(shí)候監(jiān)控中心并不會(huì)發(fā)現(xiàn)有明顯突發(fā)的大并發(fā)調(diào)用或大報(bào)文調(diào)用，而是所有接口服務(wù)訪問量都線性在增長。這個(gè)時(shí)候一方面可以自動(dòng)觸發(fā)資源彈性擴(kuò)容操作，另外一個(gè)方面就是可以實(shí)施服務(wù)降級(jí)策略，將SLA等級(jí)低的服務(wù)進(jìn)行限流或者直接熔斷以釋放資源。

API網(wǎng)關(guān)限流熔斷整體邏輯

對(duì)于整個(gè)限流熔斷的處理邏輯流程，我們可以簡化為下圖：

對(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è)簡單的描述。

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

• 規(guī)則1：對(duì)于CRM消費(fèi)getCustomer接口進(jìn)行限流，10分鐘調(diào)用>1萬即拒絕
• 規(guī)則2：對(duì)于getProductinfo接口流控，5分鐘錯(cuò)誤>1%則整體熔斷
• 規(guī)則3：對(duì)于ERP系統(tǒng)提供所有服務(wù)，1分鐘平均時(shí)長>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ī)則本身不帶來配置的情況下該方案反而是最優(yōu)方案。畢竟在實(shí)際應(yīng)用場(chǎng)景中，我們往往是在發(fā)現(xiàn)了明細(xì)的性能異常或問題的時(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)行限流熔斷處理。

對(duì)于這部分內(nèi)容的詳細(xì)說明，可以參考我前面發(fā)布的文章：