詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

華為雲開發者社群發表於2021-07-23
摘要:ROMA平臺的核心繫統ROMA Connect源自華為流程IT的整合平臺,在華為內部有超過15年的企業業務整合經驗。

本文分享自華為雲社群《ROMA整合關鍵技術(1)-API流控技術詳解》,作者:中介軟體小哥 。

1 概述

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

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

圖1 ROMA Connect功能檢視

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

2 高併發高吞吐系統流控需求

2.1 流量控制的動因

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

  • 流控的價值
  1. 提升系統穩定性/防止雪崩
  2. 保障高優先順序服務
  3. 降低響應時延,提升使用者體驗
  4. 提升系統有效吞吐量
  5. 限制性業務使用等
  • 流控的目標引數
  1. 限制總併發數(比如資料庫連線池、執行緒池)
  2. 限制瞬時併發數(如nginx的limit_conn模組)
  3. 限制時間視窗內的平均速率
  4. 限制遠端介面呼叫速率
  5. 限制MQ的消費速率
  6. 限制網路流量
  7. 限制CPU與記憶體的使用率

2.2 業務挑戰

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

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

圖2 業務挑戰

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

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

3 常見流控技術分析

3.1 常見流控邏輯架構

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

圖3 常見流控邏輯架構

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

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

3.2 常見流控演算法

3.2.1 計數器演算法

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

優點:1. 演算法簡單易實現。

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

3.2.2 滑動視窗演算法

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

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

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

3.2.3 漏桶演算法

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

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

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

3.2.4 令牌桶演算法

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

優點: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。

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

4.3 架構設計

  • 採用獨立的Controller 方案
    • 獨立叢集 Controller 提供全域性精確高吞吐流控
    • Controller 內部採用 Sharding 機制
  • 採用通用的Policy與Key/Value模型
    • 採用可擴充套件的 Domain/Policy機制,適應不同業務場景
    • 不同Policy關聯不同的演算法
  • 提供SDK與Tools,開發API G等外掛
    • 提供可重用的SDK與除錯工具等
    • 預實現API Gateway等流控外掛
  • 外接日誌、流控資料分析模組
    • 通過資料探勘、預測等反饋到配置/策略管理模組,動態修訂流控策略

詳解API Gateway流控實現,揭開ROMA平臺高效能秒級流控的技術細節

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的負載和流控服務的負載。

 

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

相關文章