詳解ROMA Connect API 流控實現技術

摘要：本文將詳細描述API Gateway流控實現，揭開高效能秒級流控的技術細節。

1、概述

ROMA平臺的核心繫統ROMA Connect源自華為流程IT的整合平臺，在華為內部有超過15年的企業業務整合經驗。依託ROMA Connect，可以將物聯網、巨量資料、視訊、統一通訊、GIS等基礎平臺及各個應用的服務、訊息、資料統一整合適配以及編排，遮蔽各個平臺對上層業務的介面差異性，對上提供服務、訊息、資料整合使能服務，以支撐新業務的快速開發部署，提升應用開發效率。適用於平安園區、智慧城市、企業數位化轉型等場景，圖1展示了ROMA Connect的功能檢視。

圖1 ROMA Connect功能檢視

其中APIC(APIC Connect)作為核心元件包含了API Gateway能力，承載了API的整合和開放能力，流控作為API Gateway的關鍵特性，為使用者的API整合、開放提供了快速、有效的安全防護，本文將詳細描述API Gateway流控實現，揭開高效能秒級流控的技術細節。

體驗ROMA Ccnnect入門版

2、高並行高吞吐系統流控需求

2.1流量控制的動因

在高並行高吞吐系統中，通常的技術關鍵詞是降級、快取、流控等，流控更是其中的核心技術，當然，這些技術是相輔相成的。

1、流控的價值

提升系統穩定性/防止雪崩
保障高優先順序服務
降低響應時延，提升使用者體驗
提升系統有效吞吐量
限制性業務使用等
…

2、流控的目標引數

限制總並行數（比如資料庫連線池、執行緒池）
限制瞬時並行數（如nginx的limit_conn模組）
限制時間視窗內的平均速率
限制遠端介面呼叫速率
限制MQ的消費速率
限制網路流量
限制CPU與記憶體的使用率
…

2.2業務挑戰

在大業務場景下，主要挑戰是高並行、低時延、高精度、多維度靈活擴充套件等訴求。

圖2 業務挑戰

而對於流控的具體挑戰如下：

每天10次與每分鐘10萬次的流控同時存在
流控反饋週期比流控週期還久
流控的維度特別多
流控同步處理時間影響使用者體驗
流控靜態設定，要麼過高要麼過低
流控失效造成業務失效
流控節點部署複雜資源消耗高
…

3、常見流控技術分析

3.1常見流控邏輯架構

圖3 常見流控邏輯架構

各種方案的優缺點如下表所示：

3.2常見流控演演算法

3.2.1計數器演演算法

優點：演演算法簡單易實現。

不足：（1）輸出不平滑。（2）有臨界問題，在流控週期邊界處易發生輸出激增，大幅超過流控閾值，沖壞後端服務。

3.2.2滑動視窗演演算法

優點：（1）可以解決計數器演演算法的臨界問題。（2）演演算法簡單易實現。

不足：（1）精度要求越高需要的視窗格子越多，記憶體開銷較大。（2）不保證輸出平滑。

3.2.3漏桶演演算法

優點：（1）輸出速度與輸入速度無關，是恆定的，流控效果平滑。（2）無臨界問題。（3）不依賴令牌。

不足：（1）由於漏桶輸出速度恆定，所以不支援一定程度的突發請求。（2）如果桶滿，輸入資料會被丟棄

3.2.4令牌桶演演算法

優點：（1）允許一定程度的突發流量。（2）通過客製化令牌新增方法，可客製化複雜的流控策略。（3）無臨界問題。

不足：（1）當桶內無可用令牌時，輸入請求會被直接丟棄。（2）不支援按優先順序處理輸入請求。

4、ROMA Connect流控技術實現

4.1總體策略

對高精度與高吞吐進行分層，區別不同場景的流控，採用不同策略與演演算法

對高精度低吞吐流控進行持久化；高吞吐高頻純記憶體計數策略
高吞吐高頻流控，不進行 HA 保障，故障後資料清零重新計算

多維度多優先順序，採用Policy 多維度控制，單一請求可觸發多Policy

解耦複雜控制，採用多條簡單策略分別對映；降低使用者使用複雜度
單一請求可觸發所有滿足條件的 Policy，進行綜合流控

通過分發策略、非同步、批申報等機制，降低請求時延與降低Controller 工作量

儘可能在 Filter/SDK 級別處理，避免流控請求影響業務時延
儘可能少上報到 Controller，降低 Controller 負載提升 Controller 效率

Filter 與演演算法門限降級放通，避免Ratelimit機制故障對業務造成影響
採用KEY/VALUE 模式和多維，提供通用機制，適應不同場景不同應用流控訴求

立足API Gateway第一個應用場景
Controller 不需理解具體業務，由基於SDK封裝的Filter適配具體業務與流控Controller

4.2邏輯檢視

RateLimit SDK存取根據一致性hash存取sharding後的RateLimit Controller，對於高吞吐高精度的流控集中在Controller記憶體進行限流計算。
RateLimit Controller對於高精度高吞吐只集中在本地記憶體計算，無需考慮crash後保留歷史限流資訊。
RateLimit Controller對於高精度低吞吐的限流採取非同步持久化策略，確保Controller crash後流控的精度。
當Ratelimit Controller服務終止的時候，Ratelimit SDK支援自動降級。
根據API Gateway採集的API Response latency等資訊反饋，支援動態調整流控策略。
支援SLA-Based 流控 Policies。

4.3架構設計

採用獨立的Controller 方案

獨立叢集 Controller 提供全域性精確高吞吐流控
Controller 內部採用 Sharding 機制

採用通用的Policy與Key/Value模型

採用可延伸的 Domain/Policy機制，適應不同業務場景
不同Policy關聯不同的演演算法

提供SDK與Tools，開發API G等外掛

提供可重用的SDK與偵錯工具等
預實現API Gateway等流控外掛

外接紀錄檔、流控資料分析模組

通過資料探勘、預測等反饋到設定/策略管理模組，動態修訂流控策略

4.4內建演演算法

4.4.1帶快取帶顏色的令牌桶演演算法

令牌桶演演算法的問題：

當無可用令牌時，請求會被立即拒絕。而使用者可能會繼續不斷傳送請求，直到有可用的令牌。這會增加API Gateway的負載和流控服務的負載。
所有的請求以同樣的概率獲得令牌，不支援優先順序。而在實際應用中，一些請求需要被優先處理，另一些請求可以被延遲處理或者直接拒絕。例如，應該優先處理電子商務網站的付款請求，而瀏覽商品的請求可以被延遲處理。

設計了一種支援快取和優先順序的令牌桶演演算法

快取：

當無可用令牌時，把請求暫時放在請求佇列裡，待有可用令牌時再處理。
採用FCFS演演算法處理請求。
如果快取也無可用空間，就直接拒絕請求。

令牌

令牌分為多種顏色，不同顏色代表不同優先順序，如綠色、黃色、紅色表示優先順序由高至低。
在API組態檔裡，可設定不同API的優先順序。根據預先設定的優先順序，對請求分配相應顏色的令牌。如果請求沒有優先順序，則使用預設優先順序。
根據API Gateway系統的能力設定令牌的數量。
當低優先順序的請求到達時，如果高優先順序的令牌量大於預留的數量，也可分配高優先順序的令牌給該低優先順序的請求。對令牌設定預留量，保證低優先順序請求不會耗盡高優先順序的令牌。
每種顏色的令牌有單獨的請求快取。

4.4.2高精度高吞吐量的流控演演算法

問題：高精度、高吞吐的矛盾

為了實現高精度流控，API Gateway需要為每個API請求傳送流控請求至流控服務，會很大程度降低處理請求的吞吐量。
為了提高吞吐量，API Gateway需降低傳送流控請求的頻度，這會降低流控的精度。傳送流控請求的頻度越低，流控的精度越低。

提出一種高精度高吞吐量的流控演演算法HAT（High Accuracy, High Throughput）

把流控分為自主流控階段和流控服務流控階段。
設流控閾值為L，自主流控閾值為S，API Gateway叢集節點數量為N，當前流控週期內已經處理的API數量為R。
流控服務計算：自主流控閾值S = L/N，並分發給每個API Gateway節點。
在自主流控閾值範圍內，每個API Gateway節點可做自主流控，無需向流控服務傳送流控請求。
當API Gateway叢集中有一個節點的API請求量超過自主流控閾值–α時，該節點傳送流控請求至流控服務，申請新的流控閾值。此時，流控服務聯絡API Gateway的其它節點獲得它們處理的API請求量。然後，流控服務重新計算自主流控閾值S = （L – R）/ N，並行送給各個API Gateway節點。
當流量餘額 < δ時，不再更新自主流控閾值。
當進入下一流控週期時，流控服務重置S，各API Gateway節點聯絡流控服務更新自主流控閾值。

演演算法分析

設u是單個流控週期內自主流控閾值更新的次數，Pi表示第i個API Gateway節點處理API的速度。
單個流控週期的流控請求的數量由L降至u*N。
最優情況是API Gateway叢集的每個節點的效能完全一樣，此時，u = 1。當流控閾值是10000，API Gateway節點數量是10時，單個流控週期的流控請求從10000降至10。
API Gateway叢集的每個節點的效能越接近，u越接近1。API Gateway叢集的每個節點的效能差距越大，u越大。

4.4.3動態流控演演算法

基於執行狀態、趨勢、API呼叫鏈進行動態流控。

請求取得令牌後，流控服務開始處理請求，生成流控響應（接受/拒絕，降級，或黑白名單）。
基於執行狀態的動態流控策略

根據使用網路狀態（可用連線數，網路延遲），請求處理延遲，API Gateway的cpu、memory等執行狀態，動態修改流控閾值。也可等等。
當cpu、記憶體等使用率遠小於閾值時，正常處理請求。
當cpu、記憶體等使用率接近閾值時，降低流控閾值（降級），減少API Gateway的負載。
當cpu、記憶體等使用率超過閾值很多時，提高降低流控閾值的速度。
當無可用cpu、記憶體時，直接拒絕請求。
當cpu、記憶體等使用率降低至正常水平時，恢復流控閾值。

基於執行狀態趨勢的動態流控策略

利用機器學習，分析歷史資料，生成預測模型，預測API Gateway的負載，提前修改流控閾值或降級服務，保證API Gateway負載平滑穩定。
利用機器學習發現應加入黑名單的請求。

基於API呼叫流的動態流控策略

Case: API呼叫流。
設計一種基於API呼叫流的動態流控策略。

利用機器學習發現API呼叫流。流控服務儲存API呼叫關係。
當系統負載較高時，當一個API請求達到閾值被限流後，對於相關聯的同一層次和低層次的所有API請求，不再存取Redis獲取實時資料和處理，而是直接延遲處理或拒絕。
當API Gateway系統負載正常時，不啟動該動態流控策略。
通過這種方式，可在基本不影響API處理速度的前提下，降低API Gateway的負載和流控服務的負載。

體驗ROMA Ccnnect入門版

點選關注，第一時間瞭解華為雲新鮮技術~