服務限流熔斷
SOA團隊 2020-03-16
對于服務流量控制往往是ESB平臺實現SLA和Qos管理的一個重要內容，對于業界主流的商用ESB總線產品基本包括了服務流量控制的內容，下面簡單談下服務流量控制的一些重點。
首先看下對于服務流量應該包括兩個層面的內容，一個是服務單位時間調用的并發量，一個是服務單位時間調用的消息報文的數據量。對于有些服務雖然調用的頻率不高，但是如果調用傳遞的數據量很大仍然會影響到ESB總線整體性能，因此也需要進行專門的流量控制。其次對于流量控制本身而言，可以對ESB服務總線所有的服務調用總量進行控制，也可
其次對于流量控制本身而言，可以對ESB服務總線所有的服務調用總量進行控制，也可以按具體的服務域控制，最細粒度應該還可以單獨控制到每一個服務。當控制到單個服務的時候，我們可以在流量控制策略的時候更好的和服務的SLA等級定義進行綁定。
最后，對于服務的流量控制往往包括了入口流量控制和出口流量控制兩個層面的內容，對于入口流量控制往往比較容易理解，即當觸發流量控制策略后直接在服務調用訪問的時候就Reject掉而不再進行處理。而對于出口流量控制最重要的目的是對于服務提供方系統往往存在單位并發下處理能力的瓶頸，而這個時候剛好可以利用ESB中的消息中間件和MQ機制，控制向目標的數據流入速度。
對于整個流量控制的技術實現方式往往通用的做法仍然是在ESB服務總線的服務調用中增加inBound和outBound處理插件和攔截器，在插件中實時的獲取到服務調用次數和服務調用數據量信息，然后再內存中進行計算，當滿足了流量控制策略后即實時出發流量控制。
對于ESB服務總線集群化部署的時候可以看到，要對ESB總線調用服務進行流量控制就需要考慮內存實時計算的次數和數據量的結果不能存儲在單臺計算節點上，而需要考慮集中化內存存儲?；谶@個思路，一個關鍵的實現策略即是可以結合分布式緩存來實現內存計算結果的存儲。
在分布式緩存實現過程中，由于存在對緩存數據的多點并發寫入和更新問題，很容易引起臟讀或臟寫，為了解決這個問題可以引入分布式并發鎖機制來解決一致性問題，但是當增加了鎖機制后帶來的就是影響到整個服務的調用性能。因此是否真正引入鎖機制還需要進一步權衡。
另外一種實現方法即是對于分布式緩存數據的讀寫進行分離操作，即各分布式ESB計算節點仍然從分布式緩存讀取數據，但是各個計算節點在通過業務攔截器獲取到服務調用次數和數據量信息后首先寫入到集中的一個消息中間件中，然后由消息中間件處理后再統一更新緩存信息以避免發生并發更新情況。
首先本文談到的服務限流和熔斷，和常規我們說的限流和熔斷有區別，具體說明為：
1. 服務限流：取消某個消費方對某個服務的訪問授權，只單個消費方受影響
2. 服務熔斷：直接對該服務進行下線處理，或將該服務狀態設置為不可用，所有消費方受影響
其次，對于服務流控我們需要設置具體要監控哪些指標，注意這個指標監控是在單位時間里面的監控指標，即計算在單位時間的累計數據，當觸發后即進行流控。具體包括：
1. 運行次數：單位時間里面的運行次數累計，比如一個消費方大并發調用，可以限流
2. 業務系統異常次數：即源服務出現異常的次數，也可以考慮異常占比率
3. 系統異常：即出現系統級異常次數，本身包括Token失效，也包括ESB總線本身故障
4. 報文量：即單位時間內傳輸的報文量達到某個值，考慮是輸入+輸出報文量和的累計
對于運行時長更多是預警，而實際上直接限流和熔斷不現實。因此主要的流控指標就是上面這些，基于以上指標本身又有兩種操作，一種是限流，一種是整個服務熔斷?？梢钥吹剑?/p>
1. 限流：運行次數，Token失效，報文量
2. 熔斷：業務系統異常，系統ESB本身故障異常
最后，還需要考慮的就是在實施了限流和熔斷后如何解除的問題，在實際實現的時候，對于限流可以在規定時間后自動解除，而對于熔斷最好還是人工恢復解除。即，比如對CRM系統訪問MDM的查詢供應商服務進行限流后，在啟動限流后的某個時間間隔后，比如2小時后，可以自動進行解除。這個時間間隔可以靈活配置。
以上限流和熔斷實現基本可以滿足我們大部分的業務需求場景，同時本身又對ESB總線和業務系統實現保護作用，防止出現大并發大數據量的調用出現的影響。當然對于限流也可以人工進行恢復，人工恢復好處是可以跟蹤到消費方端是否已經修改了消費方法，當確認修改后再進行重新授權恢復調用。
遠行科技
遠行云商
