跳转到内容
云栖回顾 | 2024 云栖大会微服务和网关相关演讲材料点此了解

2.1 服务治理技术概述

正如第一章所说,服务治理从趋势上来说正在向无侵入,和业务解耦的方向发展。首先介绍一下阿里巴巴内部在服务治理技术形态上的演进路线。

阿里巴巴服务治理技术演进路线

服务治理架构图_2-1-1 第二章第一节第一张图.png

第一阶段: 自研微服务

阿里巴巴的微服务拆分实践进行的很早,从 2008 年就开始了,当时的单体应用已经无法承载业务迭代的速度,由五彩石项目开始了微服务化的改造,在这个改造过程中,也逐步诞生了服务框架,消息队列,数据库分库分表,等三大中间件。在这个阶段的服务治理能力是通过 SDK 方式直接依赖在框架里面的。每个中间件都有自己独立的 SDK 依赖,服务治理能力的升级需要借助框架 SDK 的升级来解决,升级成本是很高的。

第二阶段:Fat-SDK

随着中间件接入数量的增加,业务升级成本不断攀升,从 2013 年起诞生了代号 “Pandora” 的项目,主要有2个目标,一是解决中间件和业务依赖的冲突问题,二是解决服务治理升级效率的问题。同一个组件,业务和中间件的可能依赖不同的版本,最常见的例如日志,序列化组件等等,如果大家共享一个版本则会出现中间件的升级影响到业务,或者出现不兼容的情况。Pandora 提供了一个轻量的隔离容器,通过类加载器隔离的方式,将中间件和业务的依赖互相隔离,而中间件和中间件之间的依赖也能互相隔离。另外,通过 Fat-SDK 的方式,将所有中间件一次性打包交付给业务方升级。这一点和 Maven 引入的 bom 的思路类似,但是相比 bom 来说每个 Pandora 的插件都可以享有独立的依赖。通过这种方式,业务不再需要单独升级某个中间件,而是一次性把所有的中间件完成升级,从而大幅提升了中间件升级的效率。

第三阶段:One Java Agent

随着业务的进一步发展,中间件的数量逐步增加, Pandora 的方式也遇到了相当的问题,也就是如果要把一个 Pandora 的版本在全集团内全部推平,需要长达1年的时间才能完成。这是因为即使是 Pandora 的方式,也需要业务修改代码,升级,验证,发布,这些并非业务真正关心,业务更希望专注于自身业务的发展。通常借助双十一大促这样的机会,才有可能完成中间件的升级。这也给服务治理的形态带来新的挑战。2019 年,阿里推出了 One Java Agent 的形态,把服务治理的能力下沉到 Java Agent 的形式,通过无侵入的方式,实现了中间件的迭代升级,进一步提升了升级效率。

第四阶段:One Mesh

Java Agent 通常只能解决 Java 语言构建的微服务,针对非 Java 语言构建的微服务体系,阿里也借助 Service Mesh 的方式,把服务治理能力下沉到 sidecar,实现了和业务的解耦。通过 sidecar 的方式,不同语言的能力无需重复开发,sidecar 的升级也可以做到透明,对业务无感。

值得注意的是,无论是 SDK 的形态,还是 Agent 的形态,还是 sidecar 的形态,对于服务治理的控制台来说,需要统一的对多种数据面进行控制。