本文主要详细阐述了在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面向用户做深度技术交流的线下活动，后面也会继续举办，欢迎参加。
