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

 

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

Tags:

VirMach 便宜 VPS

QNews

QNews