簡介：微服務的穩定性一直是開發者非常關注的話題。隨着業務從單體架構向分布式架構演進以及部署方式的變化，服務之間的依賴關係變得越來越複雜，業務系統也面臨著巨大的高可用挑戰。

微服務的穩定性一直是開發者非常關注的話題。隨着業務從單體架構向分布式架構演進以及部署方式的變化，服務之間的依賴關係變得越來越複雜，業務系統也面臨著巨大的高可用挑戰。應用高可用服務 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 的流量，具體的效果會如下圖所示（接口詳情監控）：