詳解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業務挑戰

在大業務場景下，主要挑戰是高并發、低時延、高精度、多維度靈活擴展等訴求，

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

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

3、常見流控技術分析

3.1常見流控邏輯架構

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

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入門版

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：Linux策略路由詳解

下一篇：加油，也可以更智慧