2.1 服务治理技术概述

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

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

第一阶段： 自研微服务

阿里巴巴的微服务拆分实践进行的很早，从 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 的形态，对于服务治理的控制台来说，需要统一的对多种数据面进行控制。