閘道器流控利器：結合 AHAS 實現 Ingress/Nginx 流量控制

阿里巴巴雲原生發表於2022-01-25
Nginx

作者：塗鴉

微服務的穩定性一直是開發者非常關注的話題。隨著業務從單體架構向分散式架構演進以及部署方式的變化，服務之間的依賴關係變得越來越複雜，業務系統也面臨著巨大的高可用挑戰。應用高可用服務 AHAS (Application High Availability Service) 是經阿里巴巴內部多年高可用體系沉澱下來的雲產品，以流量與容錯為切入點，從流量控制、不穩定呼叫隔離、熔斷降級、熱點流量防護、系統自適應保護、叢集流控等多個維度來幫助保障服務和閘道器的穩定性，同時提供秒級的流量監控分析功能。AHAS 不僅在阿里內部淘寶、天貓等電商領域有著廣泛的應用，在網際網路金融、線上教育、遊戲、直播行業和其他大型政央企行業也有著大量的實踐。

流量漏斗防護原

在分散式系統架構中，每個請求都會經過很多層處理，比如從入口閘道器再到 Web Server 再到服務之間的呼叫，再到服務訪問快取或 DB 等儲存。在高可用流量防護體系中，我們通常遵循流量漏斗原則進行高可用流量防護。在流量鏈路的每一層，我們都需要進行鍼對性的流量防護與容錯手段，來保障服務的穩定性；同時，我們要儘可能地將流量防護進行前置，比如將一部分 HTTP 請求的流量控制前置到閘道器層，提前將一部分流量進行控制，這樣可以避免多餘的流量打到後端，對後端造成壓力同時也造成資源的浪費。

Ingress/Nginx 閘道器流量控制

Nginx 為目前比較流行的高效能開源伺服器，Ingress 則為實際的 Kubernetes 叢集流量入口。AHAS Sentinel 為 Ingress/Nginx 閘道器提供原生的入口流量控制能力，將流量防護進行前置，提前對多餘的流量進行攔截，保障後端服務的穩定性。近期釋出的新版 AHAS Nginx 流量防護外掛基於 Sentinel C++ 原生版本實現，與舊版本 sidecar 版本相比進行了大量的效能優化，在上萬 QPS 的場景也可以保證精確流量控制，同時不會對閘道器本身的效能帶來很大影響。

AHAS Nginx/Ingress 防護具有以下核心能力及優勢：

  • 低使用成本：僅需簡單配置即可快速將 Nginx/Ingress 閘道器接入 AHAS 流量防護，並在控制檯進行視覺化的監控、規則與返回行為配置
  • 控制檯動態配置流控規則，實時生效，無需 reload Nginx
  • 精準的入口總流量控制：AHAS Nginx/Ingress 防護支援上萬 QPS 量級精準的入口總流量控制，支援自定義流控粒度（如某一組 Host, URL 維度，甚至可以細化到引數、IP 維度）
  • 配套的可觀測能力，實時瞭解閘道器流量與防護規則生效情況

下面我們就來用一個示例來介紹一下，如何快速將 Kubernetes 叢集中的 Ingress 閘道器接入 AHAS 來玩轉流控能力，保障服務穩定性。

快速玩轉 AHAS Ingress 流量防護

首先，我們假設我們已有一個建立好的阿里雲容器服務的 ACK 叢集（如果叢集中沒有 Ingress，可以在 ACK 元件管理中手動安裝），我們只需要在 kube-system 名稱空間的 nginx-configuration 配置項 (ConfigMap) 中新增以下兩個欄位：

use-sentinel: true
sentinel-params: --app=ahas-ingress-demo

即可完成 Nginx/Ingress 流量防護的接入。此時我們開啟 AHAS 控制檯，就可以看到名為 ahas-ingress-demo 的 Ingress 閘道器了。

成功接入 AHAS 流量防護後，我們要做的就是先定義好一個請求分組。點開請求分組管理的 Tab 頁，我們新建一個名為 test1 的請求分組。我們將 Host 配置為精確匹配型別，值為 127.0.0.1；將 Path 配置為字首匹配型別，值為 /test/ 。具體的配置如下圖所示：

此時我們可以預見，所有請求 Host 為 127.0.0.1 並且請求路徑以 /test/ 開頭的請求都會歸類到名為 test1 的分組中去。此時我們訪問一個匹配該請求分組的 URL，如 ​​http://127.0.0.1/test/demo​​，在 AHAS 控制檯-介面詳情監控頁面可以看到 test1 這個分組的訪問量監控。

接下來，我們要對名為 test1 的請求分組進行流量控制，我們既可以在介面詳情的 Tab 頁，也可以在規則管理的 Tab 頁中新增一條流控規則：

即完成了對 test1 請求分組的流控配置。這條流控規則的意思是，在一秒以內，該分組內請求次數超過 10 的請求將會被攔截，閾值生效維度為單機維度。預設情況下，請求被攔截後會返回 429 Too Many Requests 狀態碼，我們也可以通過 ConfigMap 或直接在控制檯配置流控觸發後的返回邏輯。

如果此時我們使用壓測工具發起 QPS 大於 10 的流量，具體的效果會如下圖所示（介面詳情監控）：

若我們希望針對某個請求分組的叢集訪問總量進行精確控制，可以配置叢集流控規則，配置總閾值即可，而無需關心閘道器例項數與負載均衡情況。

綜上，我們對 Ingress/Nginx 閘道器進行流控控制，需要先要定義好一個的請求分組，然後再針對這個分組配置相應的流控規則即可，完整的流程可以參考以下流程圖：

以上就是在阿里雲容器服務 ACK 叢集上的 Ingress 流控實踐的一個例子，如果是自建的 Ingress 或者 Nginx，也可以參考以下兩篇文章快速接入:

點選​​此處​​，前往 AHAS 官網檢視更多！

相關文章