一、前言

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

二、Istio

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

Istio

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

三、Dubbo

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

image.png

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

image.png

相比于 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 选举),实例的注册信息在集群的所有节点间并不是强一致的,所以需要客户端能够支持负载均衡以及失败重试。

image.png

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

springCloud

五、小结

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

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

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

点赞(4) 打赏

Comment list 共有 0 条评论

暂无评论
立即
投稿
发表
评论
返回
顶部