灰度釋出在 UCloud 大規模虛擬網路中的應用

本文主要詳細闡述了在 UCloud 的虛擬網路裡，如何利用 ServiceMesh 技術在虛擬網路控制面以及利用可程式設計交換機在轉發麵實現灰度釋出。

ServiceMesh 實現控制麵灰度

在控制面，早期灰度釋出採用 APIGW 的方式實現。APIGW 通常僅部署在使用者流量的入口，完全灰度釋出就需要完整地部署兩套系統。但在微服務化的時代，任何一個微服務發生變更都需要完整地部署兩套系統，這不僅成本高且嚴重影響產品變更速度。ServiceMesh 以類似於將 APIGateway 部署到本地，同時提供集中化控制的方式，完美地解決了這些問題。 

UCloud 的輕量級 ServiceMesh 平臺基於 Istio，繼續使用 Envoy 代理，修改 Pilot 在保留完整的 DSL 支援的基礎上實現了脫離 K8S 執行。

因此網路團隊對 Pilot 做了高度定製，從而更能滿足自身的需求。

◈ 定製方案一：按賬號灰度。在 GRPC 或者 HTTP 請求中新增自定義 Header x-ucloud-routeby，x-ucloud-routeby 採用 Cookie 的編碼格式，在其中包含賬戶資訊，配置 Envoy 根據該 Header 進行策略路由。

◈ 定製方案二：採用顯式代理而不是 IPTables 透明引流的方式和 Envoy 整合，支援 HTTP 1.0、HTTP 2.0 和 gRPC。在配置了 Envoy 的 Proxy Port 情況下，透過 Envoy 接入 ServiceMesh；如果配置域名且沒有配置 Envoy 的 Proxy，則自動採用 ETCD gRPC 命名與發現的方式；如果配置 IP 地址和埠，則直連指定地址。

◈ 定製方案三：採用 docker-compose 管理容器實現 sidecar。新方案中仍然採用容器的方式打包和部署微服務，但採用 Host 的網路方式簡化了現存服務的網路通訊方式。透過這種方式實現了一個簡單的服務管理、版本管理、叢集管理、路由策略管理層，為叢集中的每臺 Node（虛擬機器或物理伺服器）生成 docker-compose 配置檔案，從而部署和管理每臺 Node 的服務。

可程式設計交換機實現轉發麵灰度

在轉發麵灰度的方案選擇上，團隊採用了可程式設計交換機（基於 Barefoot Tofino 晶片）來實現灰度閘道器，替換普通交換機實現強灰度能力。 

灰度閘道器最大提供 64 個 100G 的介面、6.4T 頻寬，PPS 效能可達 4400 兆，延遲為 us 級別，能夠很好支援網路寬頻的高效能要求。灰度閘道器可以提供：一致性雜湊 ECMP 的能力；可以基於任意定製欄位（包括內層虛擬網路地址以及租戶 ID）計算雜湊；在計算雜湊前優先應用灰度規則，可以根據任意欄位定製灰度規則，最小粒度可以做到按 TCP 流來灰度。

轉發麵灰度示例

有了上述這些新工具，可以透過部署新的策略實現更加細粒的灰度釋出，具體方案為：可程式設計交換機 BGP 宣告叢集 VIP 引流，根據選擇欄位計算一致性雜湊後將流量量分發給後端伺服器，並按照選擇欄位（VNI、源地址、目的地址）配置灰度規則。

灰度步驟如下：

以上內容最早發表於 UCloud 10 月 12 日在上海主辦的 Tech Talk 第一期活動。Tech Talk 是 UCloud 面向使用者做深度技術交流的線下活動，後面也會繼續舉辦，歡迎參加。