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 級別，能夠很好支持網絡寬帶的高性能要求?；叶染W關可以提供：一致性哈希 ECMP 的能力；可以基于任意定制字段（包括內層虛擬網絡地址以及租戶 ID）計算哈希；在計算哈希前優先應用灰度規則，可以根據任意字段定制灰度規則，最小粒度可以做到按 TCP 流來灰度。
轉發面灰度示例
有了上述這些新工具，可以通過部署新的策略實現更加細粒的灰度發布，具體方案為：可編程交換機 BGP 宣告集群 VIP 引流，根據選擇字段計算一致性哈希后將流量量分發給后端服務器，并按照選擇字段（VNI、源地址、目的地址）配置灰度規則。
灰度步驟如下：
1. 按 VM 的粒度將流量量切換到灰度后端服務器器；2. 切換完成后立刻自動回歸測試，根據路由表自動生成監測地址列表，并 Ping 檢測網絡互通性；3. 測試通過則逐步增加灰度的VM地址；4. 直到整個 VPC 的流量量全部切換到灰度后端服務器器；5. 再切換一個新的 VPC，直到所有分片內的 VPC 都切換到新的灰度后端服務器；6. 完成灰度發布。
