本文主要詳細闡述了在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 naming and discovery的方式； 如果配置IP地址和端口，則直連指定地址；

    訂制方案三：采用docker-compose管理container實現sidecar。新方案中仍然采用container的方式打包和部署微服務，但采用Host的網絡方式簡化了現存服務的網絡通信方式。通過采用docker-compose管理container實現sidecar，實現了一個簡單的服務管理、版本管理、集群管理、路由策略管理層，為集群中的每臺Node（VM或物理服務器）生成docker-compose配置文件，從而部署和管理每臺Node的服務。
可編程交換機實現轉發面灰度
在轉發面灰度的方案選擇上，團隊采用了可編程交換機（基于Barefoot Tofino芯片）來實現灰度網關，替換普通交換機實現強灰度能力。
灰度網關***提供64個100G的接口提供6.4T帶寬，PPS性能可達4400兆，延遲為us級別，能夠很好支持網絡寬帶的高性能要求。灰度網關可以提供：一致性哈希ECMP的能力；可以基于任意定制字段（包括內層虛擬網絡地址以及租戶ID）計算哈希；在計算哈希前優先應用灰度規則，可以根據任意字段定制灰度規則，最小粒度可以做到按TCP流來灰度。

轉發面灰度示例
有了上述這些新工具，可以通過部署新的策略實現更加細粒的灰度發布，具體方案為：可編程交換機BGP宣告集群VIP引流，根據選擇字段計算一致性哈希后將流量量分發給后端服務器，并按照選擇字段（VNI、源地址、目的地址）配置灰度規則。
灰度步驟如下：
 按VM的粒度將流量量切換到灰度后端服務器器
 切換完成后立刻自動回歸測試，根據路由表自動生成監測地址列表，并Ping檢測網絡互通性
 測試通過則逐步增加灰度的VM地址
 直到整個VPC的流量量全部切換到灰度后端服務器器
 再切換一個新的VPC，直到所有分片內的VPC都切換到新的灰度后端服務器
 完成灰度發布

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