灰度发布在 UCloud 大规模虚拟网络中的应用

本文主要详细阐述了在 UCloud 的虚拟网络里，如何利用 ServiceMesh 技术在虚拟网络控制面以及利用可编程交换机在转发面实现灰度发布。

-- 徐亮

有用的原文链接

请访问文末的“ 原文链接”获得可点击的文内链接、全尺寸原图和相关文章。

致谢

　作者　|　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、源地址、目的地址）配置灰度规则。

灰度步骤如下：

1. 按 VM 的粒度将流量量切换到灰度后端服务器器；

2. 切换完成后立刻自动回归测试，根据路由表自动生成监测地址列表，并 Ping 检测网络互通性；

3. 测试通过则逐步增加灰度的VM地址；

4. 直到整个 VPC 的流量量全部切换到灰度后端服务器器；

5. 再切换一个新的 VPC，直到所有分片内的 VPC 都切换到新的灰度后端服务器；

6. 完成灰度发布。

---

以上内容最早发表于 UCloud 10 月 12 日在上海主办的 Tech Talk 第一期活动。Tech Talk 是 UCloud 面向用户做深度技术交流的线下活动，后面也会继续举办，欢迎参加。