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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

服務(wù)限流

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

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

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

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

即在這個場景下，實際上服務(wù)限流本身是兩個層級的限流。

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

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

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

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

對于事前方式即我們在微服務(wù)上線前就要準備和模擬真正的業(yè)務(wù)場景，進行API接口的性能測試，看下API本身的性能和QPS數(shù)據(jù)。

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

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

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

對于限流的思考

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

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

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

舉個高速入口收費站的例子說明。

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

服務(wù)熔斷

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

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

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

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

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

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

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

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

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

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

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

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

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

因為熔斷本身不是基于并發(fā)量，而是基于服務(wù)響應(yīng)時間，報文量等進行熔斷控制。但是在混合架構(gòu)下如何形成統(tǒng)一的規(guī)則計算？這個時候就需要兩個限流熔斷控制點都訪問統(tǒng)一個日志中心和規(guī)則計算中心。具體參考下圖：

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

服務(wù)降級

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

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

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

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

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

拿上面的場景來舉例。

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

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

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

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

SLA：Service-Level Agreement的縮寫，意思是服務(wù)等級協(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)生對應(yīng)的客戶結(jié)果報告。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對于該圖，實際可以看到，如果按 Slot計算邏輯單元劃分的思路可以分為：

• 基于配置的規(guī)則將服務(wù)運行實例按資源顆粒度匹配要求存到實例數(shù)據(jù)暫存區(qū)
• 進行第一次匯總計算
• 將匯總數(shù)據(jù)推入到滑動時間窗口數(shù)組
• 基于規(guī)則配置進行二次匯總計算
• 對限流熔斷是否觸發(fā)進行判斷和處理

我們再將上面的思路做一個簡單的描述。

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

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

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

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

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

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

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

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

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

如果滿足條件，就進行限流熔斷處理。

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