一、前言

公司的服务基本上都是容器化应用，也有自研的 CICD 平台，为了支持灰度发布的能力，于是从架构 SDK 和基础设施 2 方面切入考虑。
公司的服务有 300 来个，Java 应用离不开 Spring 生态，但是已有的技术栈并没有使用 Spring 全家桶，在服务发现里用了 Dubbo 协议。因为我们的应用都容器化了，所以基础设施方面就考虑到了 Kubernetes 生态的 Istio。
支持灰度的方案很多，单个服务要实现灰度是挺容易的，但在实际生产中要做一个通用、简便的方案是有难度的，需要考虑多种技术栈的并存问题，业务调用链的错综复杂，多种中间件在灰度场景中的支持问题（网关、MQ、数据库等），该文并不详述我司灰度的具体方案，而是该背景中 3 个核心架构的对比：Dubbo、SpringCloud、Istio。

二、Istio

Istio 是 kubernetes 网格化服务中落地的一个明星产物，采用边车的架构模式，对已有系统代码无侵入（不需要改代码能比较方便接入），对语言、协议的支持也都比较丰富。

基于 Istio 的灰度方案被我们否决了，因为他的网络流量是基于 k8s 的 service 实现的，而我们 Dubbo 应用是基于容器 IP 的直连方案，所以芭比Q了。从这边可以看出 dubbo 并不是云原生里面一个好的实践，他把服务的转发负载直接在软件 sdk 层面实现了，而这些能力如果下放到基础设施，不仅效率能得到提升也可以跟代码层解耦。

三、Dubbo

dubbo 是 SOA 时代的产物，所以跟云原生有点出入可以理解。服务提供者直接将自己的 IP 注册到注册中心，消费者拿着 IP 直接访问生产者。dubbo 的负载均衡一般是由客户端来实现的，当然也可以通过配置来更改其它方案。

在分布式 CAP 理论中，dubbo 由于选用 ZK 作为注册中心，ZK 由于 leader 选举时间比较长，而且选举期间集群是不可用的，所以没办法保证可用性只满足了 CP 定律。
在云原生时代，dubbo 也看到了自身的不足，积极推出了 dubbo3 全面拥抱云原生，支持基于 Kubernetes API Server 和 DNS 的服务发现体系。

相比于 2.x 版本中的基于接口粒度的服务发现机制，3.x 引入了全新的基于应用粒度的服务发现机制

1. 降低 Dubbo 地址的单机内存消耗（50%），降低注册中心集群的存储与推送压力（90%）
2. 打通与其他异构微服务体系的地址互发现障碍。新模型使得 Dubbo3 能实现与异构微服务体系如Spring Cloud、Kubernetes Service、gRPC 等，在地址发现层面的互通， 为连通 Dubbo 与其他微服务体系提供可行方案。

回到灰度的话题中，由于公司用的是 dubbo2，无法依靠云原生基础设施实现灰度。同时 dubbo2 也无法轻易升级到 dubbo3，毕竟这个涉及到整个公司技术栈的问题，有改动成本和服务稳定性因素在里面。最终我们用的是 dubbo tag 路由的机制来实现灰度的。
标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。

四、SpringCloud

springCloud 基于 http 的服务治理比 dubbo 更服务云原生的基础架构，他的流量是有经过 k8s service 层的。
http 协议比 rpc 更为通用，语言限制更低，但是 rpc 的协议报文比较小，大对象传输过程消耗的带宽比较小。
相比与 dubbo zk (cp),spring eureka 满足了 AP 定律：多实例的注册中心，只要一个可用就能提供服务（不用复杂的 leader 选举），实例的注册信息在集群的所有节点间并不是强一致的，所以需要客户端能够支持负载均衡以及失败重试。

springCloud 的灰度方案可以基于 http 的 header，在客户端入口下发 header 规则，网关解析 header 进行转发。或者透传到所有服务自行解析处理。

五、小结

如果没有技术债务，小公司还是建议直接选择 springcloud 在云原生的路上会更好走。全链路的通用灰度方案在生产中确实是个难点，比如说 MQ 消费如果也要灰度那又要如何支持。
灰度细分下去可以分为：

• 蓝绿部署
• 金丝雀发布
• A、B 测试

有的是为了验证服务的可用性，有的是为了测试产品的用户接受情况，如果根据具体的业务定制相关灰度会更简单些。整个 CICD 基础设施提供一定能力 + 具体业务具体定制我觉得更实在些。