作者：魁予、十眠
如何落地可灰度、可觀測、可回滾的安全生產三板斧能力，滿足業務高速發展情況下快速迭代和小心驗證的訴求，是企業在微服務化深入過程中必須要面對的問題。在雲原生流行的當下，這個問題又有了一些新的思路與解法。
Kubernetes Ingress 閘道器
我們先從 Ingress 閘道器談起，聊一下通過 Ingress 配置路由轉發。
Kubernetes 叢集內的網路與外部是隔離的，即在 Kubernetes 叢集外部無法直接訪問叢集內部的服務，如何讓將 Kubernetes 叢集內部的服務提供給外部使用者呢？Kubernetes 社群有三種方案：NodePort、LoadBalancer、Ingress，下圖是對這三種方案的對比：
通過對比可以看到 Ingress 是更適合業務使用的一種方式，可以基於其做更復雜的二次路由分發，這也是目前使用者主流的選擇。
隨著雲原生應用微服務化深入，使用者需要面對複雜路由規則配置、支援多種應用層協議（HTTP、HTTPS和 QUIC 等）、服務訪問的安全性以及流量的可觀測性等訴求。Kubernetes 希望通過 Ingress 來標準化叢集入口流量的規則定義，但實際業務落地時需要的功能點要遠比 Ingress 提供的多，為了滿足不斷增長的業務訴求，讓使用者輕鬆應對雲原生應用的流量管理，各類 Ingress-Provider 也都在 Ingress 的標準下進行各種擴充套件。
各種 Ingress-Provider 如何路由轉發
下面我會簡單介紹 Kubernetes 下的各種 Ingress 閘道器的實現，以及如何配置路由轉發規則等。
Nginx Ingress
Nginx Ingress 由資源物件 Ingress、Ingress Controller、Nginx 三部分組成，Ingress Controller 用以將 Ingress 資源例項組裝成 Nginx 配置檔案（nginx.conf），並重新載入 Nginx 使變更的配置生效。Ingress-nginx 是 Kubernetes 社群提供的 Ingress 控制器，最容易部署，但是受效能限制，功能較為單一，且更新 Nginx 配置需要 reload。
1、基於 Nginx Ingress Controller 配置路由轉發
基於部署了 Nginx Ingress Controller 元件的 Kubernetes 叢集，可以實現路由轉發功能，能夠根據域名、路徑進行路由轉發，也能夠支援基於 Ingress 的 Annotations 進行簡單規則的灰度流量管理，如權重、Header 等。在當下趨勢中，Nginx Ingress 依舊是使用最廣泛的。
ALB Ingress
1、ALB 產品介紹
應用型負載均衡 ALB（Application Load Balancer）是阿里雲推出的專門面向 HTTP、HTTPS 和 QUIC 等應用層負載場景的負載均衡服務，具備超強彈性及大規模七層流量處理能力。
2、ALB 特性
- 彈性自動伸縮： ALB 同時提供域名與 VIP（Virtual IP address），支援對多臺雲伺服器進行流量分發以擴充套件應用系統的服務能力，通過消除單點故障來提升應用系統的可用性。ALB 允許您自定義可用區組合，並支援在可用區間彈性縮放，避免單可用區資源瓶頸。
- 高階的協議： 支援 ALB 支援應用傳輸協議 QUIC，在實時音視訊、互動直播和遊戲等移動網際網路應用場景中，訪問速度更快，傳輸鏈路更安全可靠。ALB 同時支援 gRPC 框架，可實現海量微服務間的高效 API 通訊。
- 基於內容的高階路由： ALB 支援基於 HTTP 標頭、Cookie、HTTP 請求方法等多種規則來識別特定業務流量，並將其轉發至不同的後端伺服器。同時 ALB 還支援重定向、重寫以及自定義 HTTPS 標頭等高階操作。
- 安全加持“ALB 自帶分散式拒絕服務 DDoS（Distributed Denial of Service）防護，一鍵整合 Web 應用防火牆（Web Application Firewall，簡稱 WAF）。同時 ALB 支援全鏈路 HTTPS 加密，可以實現與客戶端或後端伺服器的 HTTPS 互動；支援 TLS 1.3 等高效安全的加密協議，面向加密敏感型業務，滿足 Zero-Trust 新一代安全技術架構需求；支援預製的安全策略，您可以自定義安全策略。
- 雲原生應用： 在雲原生時代，PaaS 平臺將下沉到基礎設施，成為雲的一部分。隨著雲原生逐步成熟，網際網路、金融、企業等諸多行業新建業務時選擇雲原生部署，或對現有業務進行雲原生化改造。ALB 與容器服務 Kubernetes 版（Alibaba Cloud Container Service for Kubernetes，簡稱 ACK）深度整合，是阿里雲的官方雲原生 Ingress 閘道器。
- 彈性靈活的計費： ALB 通過彈性公網 IP（Elastic IP Address，簡稱 EIP）和共享頻寬提供公網能力，實現公網靈活計費；同時採用了更先進的、更適合彈性業務峰值的基於容量單位（LCU）的計價方案。
3、基於 ALB Ingress Controller 配置路由轉發
ALB Ingress Controller 通過 API Server 獲取 Ingress 資源的變化，動態地生成AlbConfig，然後依次建立 ALB 例項、監聽、路由轉發規則以及後端伺服器組。Kubernetes 中 Service、Ingress 與 AlbConfig 有著以下關係：
- Service 是後端真實服務的抽象，一個 Service 可以代表多個相同的後端服務。
- Ingress 是反向代理規則，用來規定 HTTP/HTTPS 請求應該被轉發到哪個 Service 上。例如：根據請求中不同的 Host 和 URL 路徑，讓請求轉發到不同的 Service 上。
- AlbConfig 是在 ALB Ingress Controller 提供的 CRD 資源，使用 AlbConfig CRD 來配置 ALB 例項和監聽。一個 AlbConfig 對應一個 ALB 例項。
ALB Ingress 基於阿里雲應用型負載均衡 ALB（Application Load Balancer）之上提供更為強大的 Ingress 流量管理方式，相容 Nginx Ingress，具備處理複雜業務路由和證照自動發現的能力，支援 HTTP、HTTPS 和 QUIC 協議，完全滿足在雲原生應用場景下對超強彈性和大規模七層流量處理能力的需求。
APISIX Ingress
APISIX Ingress 跟 Kubernetes Ingress Nginx 的區別主要在於 APISIX Ingress 是以 Apache APISIX 作為實際承載業務流量的資料面。如下圖所示，當使用者請求到具體的某一個服務/API/網頁時，通過外部代理將整個業務流量/使用者請求傳輸到 Kubernetes 叢集，然後經過 APISIX Ingress 進行後續處理。
從上圖可以看到，APISIX Ingress 分成了兩部分。一部分是 APISIX Ingress Controller，作為控制面它將完成配置管理與分發。另一部分 APISIX Proxy Pod 負責承載業務流量，它是通過 CRD(Custom Resource Definitions) 的方式實現的。Apache APISIX Ingress 除了支援自定義資源外，還支援原生的 Kubernetes Ingress 資源。
1、基於 APISIX Ingress Controller 的應用路由
如上圖所示，我們部署了 APISIX Ingress Controller 元件的叢集，能夠實現基於Ingress 資源和自定義資源 ApisixRoute 進行路由配置，控制器監聽資源的變更事件，呼叫 apisix-admin api 進行規則的持久化儲存。流量經過 APISIX 配置的 LoadBalancer 型別 Service 閘道器從 ETCD 中同步配置，並將請求轉發到上游。
APISIX Ingress Controller 基於 Apache APISIX，支援 Kubernetes 中的 Ingress 資源進行路由配置，也支援通過自定義資源對接到 APISIX 的路由、外掛、上游等資源配置。支援動態配置路由規則、熱插拔外掛、更豐富的路由規則支援，APISIX 雲原生閘道器也能夠提供可觀測、故障注入、鏈路追蹤等能力。使用高可靠 ETCD 叢集作為配置中心，進行 apisix 配置的儲存和分發。
MSE 雲原生閘道器 Ingress
MSE 雲原生閘道器是阿里雲推出的下一代閘道器，將傳統的流量閘道器和微服務閘道器合並，在降低 50%資源成本的同時為使用者提供了精細化的流量治理能力，支援 ACK 容器服務、Nacos、Eureka、固定地址、FaaS 等多種服務發現方式，支援多種認證登入方式快速構建安全防線，提供全方面、多視角的監控體系，如指標監控、日誌分析以及鏈路追蹤。
1、基於 MSE 雲原生閘道器 Ingress Controller 的應用路由
上圖是 MSE 雲原生閘道器在多叢集模式下對業務應用進行流量管理的應用場景。MSE 雲原生閘道器與阿里雲容器服務 ACK 深度整合，可以做到自動發現服務以及對應的端點資訊並動態秒級生效。使用者只需簡單在 MSE 管控平臺關聯對應的 Kubernetes ACK 叢集，通過在路由管理模組中配置路由來對外暴露 ACK 中服務即可，同時可以按叢集維度進行流量分流以及故障轉移。此外，使用者可以為業務路由實施額外的策略，如常見的限流、跨域或者重寫。
MSE 雲原生閘道器提供的流量治理能力與具體的服務發現方式解耦，無論後端服務採用何種服務發現方式，雲原生閘道器以統一的互動體驗來降低上手門檻，滿足使用者業務日益增長的流量治理訴求。
上文介紹了 Nginx Ingress、ALB Ingress、APISIX Ingress 以及 MSE 雲原生閘道器Ingress 這五種 Ingress 的路由轉發與配置，我們可以按照自己的業務需求與複雜度按需選擇合適的 Ingress 實現。
假設我們已經配好了 Ingress 的路由轉發，那麼在多應用環境下，我們該如何簡單地玩轉全鏈路灰度呢？
基於 Ingress 實現全鏈路流量灰度
我們基於全鏈路灰度的實踐，提出了“泳道”這一個概念，當然這一概念在分散式軟體領域並非新詞。
名詞解釋
- 泳道 ： 為相同版本應用定義的一套隔離環境。只有滿足了流控路由規則的請求流量才會路由到對應泳道里的打標應用。一個應用可以屬於多個泳道，一個泳道可以包含多個應用，應用和泳道是多對多的關係。
- 泳道組： 泳道的集合。泳道組的作用主要是為了區分不同團隊或不同場景。
- 基線： 指業務所有服務都部署到了這一環境中。未打標的應用屬於基線穩定版本的應用，我們這裡指穩定的線上環境。
- 入口應用： 微服務體系內的流量入口。入口應用可以是 Ingress 閘道器、或者是自建的 Spring Cloud Gateway、Netflix Zuul Gateway 引擎型別閘道器或者 Spring Boot、Spring MVC、Dubbo 應用等。
為什麼要區分出入口應用？因為全鏈路灰度場景下，我們只需對入口應用進行路由轉發的規則配置，後續微服務只需要按照透傳的標籤進行染色路由（實現“泳道”的流量閉環能力）。
從上圖中可以看到，我們分別建立了泳道 A 與泳道 B，裡面涉及了交易中心、商品中心兩個應用，分別是標籤標籤 2，其中 A 泳道分流了線上 30%的流量，B 泳道分流了線上 20%的流量，基線環境（即未打標的環境）分流了線上 50%的流量。
全鏈路灰度的技術解析
我們通過在 deployment 上配置註解 alicloud.service.tag: gray 標識應用灰度版本，並帶標註冊到註冊中心中，在灰度版本應用上開啟全鏈路泳道(經過機器的流量自動染色)，支援灰度流量自動新增灰度 x-mse-tag: gray 標籤，通過擴充套件 consumer 的路由能力將帶有灰度標籤的流量轉發到目標灰度應用。
基於各種 Ingress 閘道器的全鏈路灰度
基於全鏈路灰度能力搭配合適的入口路由閘道器即可實現全鏈路流量灰度，如上述使用 Ingress-Nginx、Ingress-APISIX、ALB、MSE 雲原生閘道器均可以作為流量入口。
全鏈路灰度的產品實現
功能性與易用性是產品化必須思考的點，我們需要從使用者的視角出發，端到端思考全流程該如何去實踐、如何去落地。在阿里雲上關於微服務全鏈路灰度能力有以下兩款產品都提供了完整的全鏈路灰度解決方案。
MSE 全鏈路灰度方案
全鏈路灰度作為 MSE 微服務治理專業版中的核心功能，具備以下六大特點：
- 全鏈路隔離流量泳道
<!---->
- 通過設定流量規則對所需流量進行'染色'，'染色'流量會路由到灰度機器。
- 灰度流量攜帶灰度標往下游傳遞，形成灰度專屬環境流量泳道，無灰度環境應用會預設選擇未打標的基線環境。
- 端到端的穩定基線環境
未打標的應用屬於基線穩定版本的應用，即穩定的線上環境。當我們將釋出對應的灰度版本程式碼，然後可以配置規則定向引入特定的線上流量，控制灰度程式碼的風險。
- 流量一鍵動態切流
流量規則定製後，可根據需求進行一鍵停啟，增刪改查，實時生效。灰度引流更便捷。
- 低成本接入，基於 Java Agent 技術實現無需修改一行業務程式碼
MSE 微服務治理能力基於 Java Agent 位元組碼增強的技術實現，無縫支援市面上近 5 年的所有 Spring Cloud 和 Dubbo 的版本，使用者不用改一行程式碼就可以使用，不需要改變業務的現有架構，隨時可上可下，沒有繫結。只需開啟 MSE 微服務治理專業版，線上配置，實時生效。
- 可觀測能力
<!---->
- 具備泳道級別的單應用可觀測能力
- 具備全鏈路應用的可觀測能力，可以從全域性視角觀察流量是否存在逃逸情況。灰沒灰到，一目瞭然。
- 具備無損上下線能力，使得釋出更加絲滑
應用開啟 MSE 微服務治理後就具備無損上下線能力，大流量下的釋出、回滾、擴容、縮容等場景，均能保證流量無損。
1、建立流量泳道組
需要將泳道中涉及的應用新增到泳道組涉及應用中
2、建立流量泳道
在使用泳道功能前，我們預設已經存在了一個包含所有服務在內的基線（未達標）環境。
我們需要去部署隔離版本的應用 Deployment，同時去給他們打上標籤，並且給泳道選擇對應一一關聯的標籤（test 泳道關聯 gray 標籤）
然後需要去配置流量入口的 Ingress 規則，比如訪問 www.base.com 路由到 A 應用的 base 版本，訪問 www.gray.com 路由到 A 應用的 gray 版本。
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: spring-cloud-a-base
spec:
rules:
- host: www.base.com
http:
paths:
- backend:
serviceName: spring-cloud-a-base
servicePort: 20001
path: /
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: spring-cloud-a-gray
spec:
rules:
- host: www.gray.com
http:
paths:
- backend:
serviceName: spring-cloud-a-gray
servicePort: 20001
path: /EDAS 全鏈路灰度方案
1、EDAS 產品介紹
EDAS 是應用託管和微服務管理的雲原生 PaaS 平臺，提供應用開發、部署、監控、運維等全棧式解決方案，同時支援 Spring Cloud 和 Apache Dubbo 等微服務執行環境，助力您的應用輕鬆上雲。
在 EDAS 平臺中，使用者可以通過 WAR 包、JAR 包或映象等多種方式快速部署應用到多種底層伺服器叢集，免叢集維護，能夠輕鬆部署應用的基線版本和灰度版本。EDAS 無縫接入了 MSE 微服務治理能力，部署在 EDAS 的應用無需額外安裝 Agent 即可零程式碼入侵獲得應用無損上下線、金絲雀釋出、全鏈路流量控制等高階特性。
目前 EDAS 支援微服務應用為入口的全鏈路灰度能力，下面簡單介紹在 EDAS 中的配置全鏈路灰度流量的方法。
2、建立流量泳道組和泳道
在建立泳道時需要選擇入口型別，目前僅支援部署在 EDAS 中的入口應用作為泳道入口應用，需要將泳道中涉及的基線版本和灰度版本新增到泳道組涉及應用中。
在建立泳道時支援基於路徑配置規則定向引入特定的線上流量，配置打標流量應用形成灰度環境鏈路。泳道支援基於 Cookie、Header、Parameter 進行流量控制。
配置泳道成功後，可以在全鏈路流量控制介面選擇目標泳道組進行流量觀測，包括入口應用總的監控圖、未打標部分監控圖和打標部分監控圖，及泳道組內所有應用的監控圖。
3、應用路由作為流量入口實現全鏈路灰度
EDAS 平臺支援使用者為 Kubernetes 應用基於 Nginx Ingress 建立應用路由，結合 EDAS 對全鏈路流控的支援，使用者能夠直接在 EDAS 控制檯實現使用 Nginx Ingress 作為流量入口閘道器的全鏈路灰度。
在 EDAS 平臺中部署基線版本應用、灰度版本應用、入口應用後，根據上述建立流量泳道組和泳道的步驟建立灰度泳道後，可以為入口應用繫結 Kubernetes 的 Service 資源以提供流量入口。可以為入口應用配置 LoadBalancer 型別 Service，以提供入口應用的對外訪問，也可以基於 Kubernetes 叢集中已有的 Nginx Ingress 閘道器，為入口應用配置 ClusterIP 型別 Service 並配置應用路由，以避免額外分配公網 IP。
下面簡單介紹為入口應用配置應用路由作為流量入口的方法。
在部署完成的應用詳情頁面，支援進行應用的訪問方式配置，在這裡可以選擇為入口應用繫結 LoadBalancer 型別 Service 以直接對外訪問，也可以建立 ClusterIP 型別 Service，如下圖：
配置成功後，可以在 EDAS 應用路由頁面點選建立應用路由，選擇該入口應用所在的叢集，名稱空間，應用名稱，上述步驟建立的服務名稱及埠以配置 Ingress 資源，如下圖：
配置成功後，即可使用該 Ingress 資源配置的域名和路徑並結合在泳道中配置的灰度流量規則實現全鏈路灰度。
4、更進一步
EDAS 中的全鏈路流量控制目前僅支援部署在 EDAS 中的入口應用作為流量入口，在Kubernetes 主導的雲原生化趨勢下，EDAS 將支援使用 Ingress 作為流量入口，使用者不需要額外部署閘道器應用，直接使用 Ingress 資源配置轉發規則即可作為流量入口。不僅如此，EDAS 也將支援 ALB Ingress、APISIX Ingress 以及 MSE 雲原生閘道器 Ingress，並且在這個基礎上全鏈路灰度能力也會進一步升級，支援基於各種 Ingress-Provider 閘道器的全鏈路灰度能力。
尾
我們發現在雲原生抽象的 Ingress 下，再談全鏈路灰度，一切問題都變得更加標準化與簡單起來。本文通過介紹各種 Ingress 閘道器實現的路由轉發能力，再配合上基於“泳道”實現的 Ingress 全鏈路灰度方案，企業可以快速落地全鏈路灰度這個微服務核心能力。
點選文末“ 此處 ”，瞭解更多產品相關~