灰度发布攻略

需求背景

在当前的业务需求推进下，每周发版后的不稳定因素较多，从而导致客户及业务部门使用体验不佳。
因此灰度（金丝雀）发布成为了我们在业务体验上不得不面对的需求。此处也退而求其次，考虑了一下蓝绿发布的方案，但是蓝绿发布的成本较高（需要copy一份现有环境的基础设施），且在我们的业务场景下，蓝绿发布的优势并不明显。
然而灰度发布本身也容易带有歧义，比如灰度发布的对象是谁？灰度发布的范围是什么？灰度发布的流量是多少？灰度发布的时间是多久？灰度发布的流程是什么？灰度发布的结果如何评估？等等。

需求分析

综上所述，首先我们需要明确灰度需求：

如何定义灰度发布的对象？是对于某些新功能新模块的灰度发布，还是对于新的业务场景的灰度发布？
灰度发布的范围是什么？是根据特定用户进行灰度，还是根据用户流量比例进行灰度？
灰度发布的时间周期以及发布的结果如何评估？
灰度发布的流程制定

技术测诉求

目前对于技术测的环境要求如下：

灵活可控，可根据特定用户进行灰度，也可根据用户流量比例进行灰度
流量降级，当灰度版本出现问题时，能够快速降级
配置简单，能够快速接入。尽量对代码进行最小幅度的修改
可观测性，便于排查问题，且利于对灰度发布的结果进行评估

技术方案及适配度

对于微服务框架而言，灰度即意味着流量精细化管控。因此我们可以从服务治理的角度出发，来解决灰度发布的问题。

基于Dubbo实现

当前我们的微服务框架是spring cloud alibaba，服务治理基于dubbo。较为主流的方式是通过标签路由的功能完成流量的隔离与降级。

具体实现可参考此文档

最终效果如下：

标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的

优势

1. 适配度较高

2. 业务代码无需改动

劣势

1. 可观测性较差，无法直观的监控灰度环境状态。排查问题需要另外切入

2. 网关测的流量判断需要依赖于dubbo。比如我们的网关服务，就是一个非dubbo的服务，因此无法通过标签路由进行灰度。因此要做到特定用户灰度的场景，需要在网关层进行特定用户的灰度判断，然后将请求转发到指定的灰度环境中。这样就会导致网关层的代码改动量较大。

基于公有云微服务平台实现

这里以腾讯云TSF举例
腾讯云TSF是一个兼容spring cloud alibaba的PaaS平台。提供服务治理，监控等功能，可以与腾讯云的其他产品进行无缝对接。TSF的灰度发布功能是通过灰度路由来实现的。具体实现可参考此文档

最终效果如下：

该平台对于dubbo的接入是通过mesh改造，将服务治理的功能下沉到云原生基础设施之中。接入文档

优势

业务代码无需改动，接入简单
实用性较强，包括可视化的灰度配置，限流，服务降级等功能。并且可以与腾讯云的k8s等产品进行无缝对接
可观测性较好，可以直观的观察到灰度状态

劣势

基础设施的改动较大，需要摒弃nacos，shenyu网关等已用的中间件。会被迫走向腾讯云的闭环
由于Dubbo 2.x采用的是接口级服务发现，所以接入mesh时需要每个接口都要进行定义

基于自建微服务网格实现

服务网格属于第三代微服务架构模式，其核心是通过sidecar的方式将服务治理的功能下沉到云原生基础设施之中。目前主流的服务网格产品有istio，linkerd，envoy等。这些产品都提供了流量控制的功能，可以实现灰度发布的需求。
腾讯云的TSF即是在envoy的基础上进行改造而来的。因此我们也可以通过自建服务网格的方式来实现灰度发布的需求。

优势

可控性较强，可以定制化的实现灰度发布的需求

劣势

改动量相当大。首先是要将服务通信方式从dubbo rpc这类私有协议转向http/restful，或者框架升级到dubbo3（dubbo3不向下兼容，改动也挺大）
运维测使用istio成本较高，需要额外的学习与维护成本