本文主要詳細闡述了在UCloud的虛擬網(wǎng)絡里，如何利用ServiceMesh技術在虛擬網(wǎng)絡控制面以及利用可編程交換機在轉發(fā)面實現(xiàn)灰度發(fā)布。
ServiceMesh實現(xiàn)控制面灰度
在控制面，早期灰度發(fā)布采用APIGW的方式實現(xiàn)。APIGW通常僅部署在用戶流量的入口，完全灰度發(fā)布就需要完整地部署兩套系統(tǒng)。但在微服務化的時代，任何一個微服務發(fā)生變更都需要完整地部署兩套系統(tǒng)，這不僅成本高且嚴重影響產(chǎn)品變更速度。ServiceMesh以類似于將APIGateway部署到本地，同時提供集中化控制的方式，***地解決了這些問題。
UCloud的輕量級ServiceMesh平臺基于Istio，繼續(xù)使用Envoy代理，修改Pilot在保留完整的DSL支持的基礎上實現(xiàn)了脫離K8S運行。
因此網(wǎng)絡團隊對Pilot做了高度訂制，從而更能滿足自身的需求。

 訂制方案一：按賬號灰度。在GRPC或者HTTP請求中添加⾃自定義Header x-ucloud-routeby，x-ucloud-routeby采用Cookie的編碼格式，在其中包含賬戶信息，配置Envoy根據(jù)該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實現(xiàn)sidecar。新方案中仍然采用container的方式打包和部署微服務，但采用Host的網(wǎng)絡方式簡化了現(xiàn)存服務的網(wǎng)絡通信方式。通過采用docker-compose管理container實現(xiàn)sidecar，實現(xiàn)了一個簡單的服務管理、版本管理、集群管理、路由策略管理層，為集群中的每臺Node（VM或物理服務器）生成docker-compose配置文件，從而部署和管理每臺Node的服務。
可編程交換機實現(xiàn)轉發(fā)面灰度
在轉發(fā)面灰度的方案選擇上，團隊采用了可編程交換機（基于Barefoot Tofino芯片）來實現(xiàn)灰度網(wǎng)關，替換普通交換機實現(xiàn)強灰度能力。
灰度網(wǎng)關***提供64個100G的接口提供6.4T帶寬，PPS性能可達4400兆，延遲為us級別，能夠很好支持網(wǎng)絡寬帶的高性能要求。灰度網(wǎng)關可以提供：一致性哈希ECMP的能力；可以基于任意定制字段（包括內(nèi)層虛擬網(wǎng)絡地址以及租戶ID）計算哈希；在計算哈希前優(yōu)先應用灰度規(guī)則，可以根據(jù)任意字段定制灰度規(guī)則，最小粒度可以做到按TCP流來灰度。

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

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