摘要：ROMA平台的核心系統ROMA Connect源自華為流程IT的內建平台，在華為内部有超過15年的企業業務內建經驗。
本文分享自華為雲社群《ROMA內建關鍵技術(1)-API流控技術詳解》，作者：中間件小哥 。
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流控實作，揭開高性能秒級流控的技術細節。
2 高并發高吞吐系統流控需求
2.1 流量控制的動因
在高并發高吞吐系統中，通常的技術關鍵詞是降級、緩存、流控等，流控更是其中的核心技術，當然，這些技術是相輔相成的。
- 流控的價值
- 提升系統穩定性/防止雪崩
- 保障高優先級服務
- 降低響應時延，提升使用者體驗
- 提升系統有效吞吐量
- 限制性業務使用等
- …
- 流控的目标參數
- 限制總并發數（比如資料庫連接配接池、線程池）
- 限制瞬時并發數（如nginx的limit_conn子產品）
- 限制時間視窗内的平均速率
- 限制遠端接口調用速率
- 限制MQ的消費速率
- 限制網絡流量
- 限制CPU與記憶體的使用率
2.2 業務挑戰
在大業務場景下，主要挑戰是高并發、低延遲時間、高精度、多元度靈活擴充等訴求。
圖2 業務挑戰
而對于流控的具體挑戰如下：
- 每天10次與每分鐘10萬次的流控同時存在
- 流控回報周期比流控周期還久
- 流控的次元特别多
- 流控同步處理時間影響使用者體驗
- 流控靜态設定，要麼過高要麼過低
- 流控失效造成業務失效
- 流控節點部署複雜資源消耗高
3 常見流控技術分析
3.1 常見流控邏輯架構
圖3 常見流控邏輯架構
各種方案的優缺點如下表所示：
3.2 常見流控算法
3.2.1 計數器算法
優點：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的負載和流控服務的負載。
點選關注，第一時間了解華為雲新鮮技術~