本文分享自华为云社区《云原生微服务治理技术朝无代理架构的演进之路》，作者： 杨奕 华为云技术规划专家。

微服务治理技术发展趋势

对于云原生的归纳，业界从来没有停止过演进。但是总体来讲，微服务和容器化基本上是两个永恒不变的话题。今天这篇文章重点来谈谈微服务架构的演进。

微服务这个词，比较公认的官方正式介绍来自 Martin Fowler 在 2014 年发布的 Microservices 一书。但是实际上，其解决的服务解耦的问题，最早可以追述到 SOA (Service-Oriented Architecture，面向服务的架构)。下面这种图 (参考链接 ) 比较好的诠释了服务的演进历程。从最早的 SOA，到本世纪 10 年代的微服务，到最后的云原生微服务架构的 Servicemesh，核心都是为了解决在企业的复杂业务场景下，让各服务以解耦方式各自独立快速迭代。

图例 1：服务架构的演进历程：SOA -> 微服务框架 -> 云原生

总体来讲，微服务的迭代发展到目前为止，分为三个阶段。

• SOA：该阶段针对政企场景的烟囱式架构，通过集中式中心网关方式，解决异构应用之间的快速集成问题。该阶段，服务治理功能集中在中心网关上，性能和可靠性上也都有较大问题。

• 微服务框架：主要针对大规模高并发场景，通过去中心网关、做厚客户端的方式，使得企业内部应用可快速解耦和横向扩容，以满足业务快速发展需求。该阶段，服务治理功能一般通过 SDK，部署在业务程序上，辅以注册中心和配置中心进行服务管理。虽然性能和可靠性得到解决，但是服务治理逻辑和业务逻辑存在一定程度耦合，在应用生命周期迭代上存在一定问题。

• 云原生 Service Mesh：将更多的服务治理能力沉淀到云平台上，应用只关注业务逻辑，服务治理和应用彻底解耦，应用快速迭代得到解放。该阶段，服务治理功能以代理边车方式沉淀到容器内，应用时在运行时挂载边车即可，具体的服务治理控制逻辑由云平台(如图中 Kubernetes/Service Mesh)承接。

在以上架构图中，SOA 不是本文重点。关于 SOA 到微服务的演进，感兴趣可以参考文章 《 SOA 和微服务的区别》 一文。本文以下章节重点介绍其他的 微服务框架 和 云原生 Service Mesh 这两个阶段的微服务治理架构特点。

微服务框架 架构

如前文所述，微服务的的名词比较正式被普及可归公于 Martin Fowler 在 2014 年撰写的 Microservices 一书。但是实际上，国内的微服务起源反而更早。比较出名的是是阿里早期的 HSF 和 Dubbo。正如“ Dubbo 和 HSF 在阿里巴巴的实践：携手走向下一代云原生微服务 ”一文中所述，阿里最早在 2008 年就开始了微服务方面的实际尝试，虽然可能在当时，其团队并未真正意识到自己开发的其实是下一代微服务架构。

文摘 1：Dubbo 阿里内部的演进历史

Dubbo 项目诞生于 2008 年，起初只在一个阿里内部的系统使用；2011 年，阿里 B2B 决定将整个项目开源 ，仅用了一年时间就收获了来自不同行业的大批用户；2014 年，由于内部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴捐献至 Apache 毕业的项目。

在海外，虽然 RPC 框架类组件尘出不穷，但是真正将服务治理纳入一体，而且几乎成为事实标准的，当属 Spring Cloud 。虽然项目是 2016 年才开始正式发布，但论流行程度，不光在世界范围论堪称一哥，在中国国内，风头也几乎盖过 Dubbo。

图例 2：Dubbo 和 SpringCloud 在国内的搜索热度。蓝色是 Dubbo，红色是 SpringCloud

Dubbo 和 SpringCloud 的具体发展历程，这里不多做介绍，大家可以翻翻其他相关介绍。这里重点突出一个两套框架的一个共同特点，无论是 Dubbo，以及后来的 SpringCloud，都不光是一套 RPC 框架。其除了方便研发直接基于 RPC 模式开发微服务架构的业务以外，自身还有很多扩展点，方便服务治理开发人员以独立 Jar 包方式进行服务治理功能的单独开发。比如：Dubbo 比较耳熟能详的是自身的基于 SPI 扩展点机制来实现服务治理；而 SpringCloud 则是通过 SpringBoot 机制，通过开发者开发 starter 包来实现服务治理。两者基本都能做到服务治理功能对业务代码解耦。例如 SpringCloud，对于引入新的服务治理功能，很多时候对于开发者来说只需要引入一个 starter 的 pom 依赖。不过这也引入一个问题，任何服务治理的功能升级，虽然对于业务代码来说只是更新配置文件，但是毕竟还是动了业务代码，这也给服务治理功能的升级带来潜在阻力。随着业务规模增长，该问题也会被指数级放大。

基于以上问题，需要指出一个极其重要的但是容易被忽略大家忽略的事实，就是微服务治理能否在一个大厂内能否大规模铺开使用，很重要的因素是服务治理能否和业务在软件开发和发布上解耦。阿里之所以微服务内部推广和演进比较顺利，笔者认为很大原因是阿里内部采用的微服务框架 HSF 很早集成了Pandora 容器 这项技术。这个不起眼的技术，其实起了一个至关重要的作用：服务治理功能和业务功能在代码上彻底解耦，治理功能的 jar 包可以在不改变业务代码情况下单独发布；且在此基础上实现了治理功能和业务功能类隔离，防止类冲突。

图例 3：据阿里巴巴 微服务 实践 一文介绍，通过 Pandora，业务和中间件逻辑发布得到完全解耦。

阿里内部的 Pandora 容器技术，虽然在外曝光度不高。但是在阿里的服务治理领域起到了至关重要的作用。正是因为有了 Pandora，阿里的业务开发人员才能做到 "治理功能万千重，我自岿然不动"。阿里历史上每年双 11 前几个月，在业务近乎无感情况下，微服务框架批量搞几次大版本升级，也基本就能满足每年大促的服务治理需求。

而其他如采用 SpringCloud 技术栈的大厂，在没有类似 Pandora 容器的隔离技术情况下，随着业务规模增长，服务治理能力的演进将越来越痛苦。每发布一个重要版本或重要补丁，服务治理团队就需要思考如何去说服上千个业务方进行 SDK 升级，就成了一件让人非常头疼的事。因此，服务治理功能如何和业务功能在架构上如何解耦，就成了后来微服务治理一个刚需。这也是后续 Istio 等边车服务治理方案兴起的一大原因。

云原生 Proxy (边车代理) 服务治理架构

在 CloudNative 时代的服务治理架构中，Service-mesh 因为其对应用的无侵入性，成为了云原生服务治理的一个经典流派。而在 Service-mesh 流派中，Istio 又是其中一个代表作。Istio 的兴起，其实核心是因为解决了两个问题。

• 多语言架构下的服务治理功能统一。无论是 java、go、c++等语言，只要通讯协议一致，理论上都可以通过边车进程来进行服务治理。

• 通过代理进程方式，实现治理功能对业务代码的非侵入，架构上和业务充分解耦。

图例 4：Istio 社区 中火了 5 年的书店 demo 程序，集 python、ruby、node.js、java 等各类开发语言

关于 Istio 的功能和架构介绍，网上文章多如牛毛，本文就不赘诉了。但是这里核心讲下 Istio 在实践中遇到的几个问题。

• 非侵入的兼容性。本来非侵入是 istio 的主打优势，但是社区版的 istio 有个核心问题，就是是基于 gRPC 协议构建的。这就使得 istio 在国内落地时，面对国内 dubbo 治理框架是个事实标准之一的情况，显得有点水土不服。这在大多数云厂商的 istio 商业版中对 Dubbo 的各种“蹩脚”支持可见一斑。虽然 dubbo 社区也在主动朝 3.0 开始演进，兼容 gRPC 协议，但是其成熟度仍尚存很长距离。

• 服务治理，功能也很丰富，但是有缺陷。在长长的 xDS 协议的功能列表中，从服务注册发现，到限流降级，到馄饨工程，可谓玲珑满面。但是基于 Proxy 边车的服务治理方案中，一大硬伤是 Proxy 边车进程毕竟是个和业务无关的进程，本身无法侵入到业务进程，因此任何需要在业务进程透传标识的场景全部都不支持。典型比如分布式链路 Tracing ID 的透传，还比如一些全链路灰度发布的路由标的透传，等。以上两个问题，都可参考 Proxyless Service Mesh 在百度的实践与思考 一文中有详细阐述。

图例 5：百度在 Proxy Service Mesh 实践中因为边车无法侵入进程，所遇到的问题

• 架构上，由于采用了单独进程，无论是性能和运维上，和 SDK 流派相比还是有差距。一方面，在各种基准性能测试中，额外的响应时间稳定增加 1.7ms 以上，参见 istio Performance and Scalability 。另外一方面，在落地时，sidecar conatiner 的规格设置也是个令人头疼的问题：vcpu 和内存设得小了，性能不够；设得大了，浪费资源；按应用各自性能特点设置，又造成额外管理成本。

图例 6：Istio 社区中最新发布的性能测试。测试现实，增加边车，性能损耗至少增加 1.5ms

基于以上各种原因，原生的 istio 的落地实践中，都多少处于叫好不叫座的尴尬境界。接下来就 Proxy 边车治理方案的问题，说说为啥最近 Proxyless 边车治理方案开始逐渐异军突起。

云原生 Proxyless (无代理) 服务治理 架构

Proxyless 服务治理，原本出处是 gRPC Proxyless Service Mesh . 原文本意是基于 gRPC，结合 xDS 协议，做了一个服务治理框架。gRPC Proxyless Service Mesh 的提出，笔者认为，本质上是因为 proxy 治理架构的各种各样的问题，导致 istio 团队重新思考适基于现成的 xDS 协议，把服务治理的大部分功能重新做到了框架内部。从架构上看起来 gRPC Proxyless Service Mesh 更像是走了一次微服务框架流派的历史倒车，把业务和治理框架耦合在了一起。

图例 7：左边是 gRPC Proxyless Service Mesh 最新发表的架构图，右侧是 Dubbo 几乎 10 年前的架构图，是不是何其相似

那么有没有一种 Proxyless 边车方案，既能具备边车方案的各种解耦优点，又能一定程度上克服 Proxy 带来的问题呢？答案是 Javaagent。

Javaagent 的字节码增强技术很早就有。真正发挥商业价值的地方其实是在 2015 年前后的所谓 APM 元年，其被大量使用在 APM 领域。但是这个 javaagent 这个技术在服务治理领域火起来的，也是最近两年的事。这里面主要发生两件值得一提的事：

• Apache Skywalking 这个开源 APM 工具，作为国内 Apache 的顶级项目，把 javaagent 技术在国内好好普及了一把。最终结果是各个互联网中小厂商基本上 java 进程上都挂了一个 skywalking javaagent 的同时，该技术都普遍接受。 （笔者见过不少政企和互联网厂商，甚至挂了一个 skywalking javaagent 的同时，又挂了一个基于 skywalking 修改的 javaagent，其使用场景涵盖各种服务治理场景。）

• 基于对 javaagent 技术的接受基础上，以 Java 技术栈为主的各类互联网大厂和云厂商开始内外大量使用 Javaagent 技术做服务治理和相关商业化产品。总体上讲，之前业界对 javaagent 做服务治理基本上都持观望态度。现在基本上也不质疑了，大家现在思考的问题都变成了怎么把 javaagent 在服务治理领域如何发挥到极致。

为啥 javaagent 技术这么火？这是因为其相比传统 SDK 和 Servicemesh 技术：

• 非侵入架构：这点和 Sidecar 架构类似，治理能力开箱即用，业务方代码务虚改造，上车成本极低。而且相比传统边车技术，没有额外进程，运行态和开发态的差异进一步降低。

• 治理功能和业务代码升级解耦：相比 SDK 升级动辄需要去各业务方推广，非侵入这块这块能力确实比 SDK 实际体验好太多。试想一下，治理功能快速迭代的同时，业务方只需晚上滚动重启一下即可获得新的治理功能，这对服务治理团队和业务团队都是一种生产力的解放。

• 相比传统边车方案，性能更好，资源消耗更低 ：毕竟传统边车方案动辄 2ms 以上的延时增加，以及额外的进程资源开销，对业务都是不小的负担。而 javaagent 这块由于采用和 SDK 雷同的 AOP 服务治理方式，性能几乎和 SDK 持平。

• 治理场景多样：实践证明，在场景上，Javaagent > SDK > 边车架构。Javaagent 的场景比边车方案多，这个好理解，毕竟 Javaagent 可以注入到用户进程中，完成很多流量标透传的场景，这块是边车架构无法做到的。但是 Javaagent 为何场景比 SDK 方案还要多？这是因为一般如 Dubbo, SpringCloud 等治理方案，其默认需要对应的 RPC 函数提供相应的函数埋点。但是很多服务治理场景，如流量录制回放，对应的一些远程调用，如 Redis 调用，本身并不提供函数埋点，因此通过 SDK 来拦截流量进行录制和回访就无从谈起。而基于 Javaagent 的字节码增强技术则没有这个限制。

图例 8：(原创首发)Javaagent 对其他服务治理对比的优势

当然，Javaagent 的服务治理技术也并非银弹。

• Javaagent 最大的问题是服务治理场景只能用于 Java。如果您所在公司，主流开发预言是非 Java 类，那么还是放弃吧。但是如果您所在公司，主流开发语言是 java, 但是有很多长尾应用语言是其他语种怎么办？这里开发者可以考虑 传统边车 + javaagent 方案，javaagent 负责主流的 Java 语言微服务的服务治理，而传统边车方案负责其他多语言的服务治理。至于两者的服务治理打通，业界也有很多方案，如 Javaagent 同时对接基本的 xDS 协议，也可以完成两者服务的打通。

• 这里也稍微提个不大不小的问题，就是当多个 javaagent 对同一个类进行增强的时候，有时候会产生增强冲突的异常。其实这块很多场景是因为各类 javaagent 开发不规范的原因，是完全可以避免的。相关详细的问题就不展开了，大家如果敢兴趣的话，可以去看下相关文章 记一次多个 JavaAgent 同时使用的 类增强 冲突问题及分析 。这里就摘出要文章核心摘要：

文摘 2："记一次多个 JavaAgent 同时使用的类增强冲突问题及分析" 文中对避免 Javaagent 冲突的建议。

严格遵守字节码增强的使用要求和限制。

无论是 Byte Buddy、Javassist 还是 ASM，底层实现都离不开 JDK1.5 之后引入的 Instrumentation 接口。既然官方接口的设计理念是 reTransformClasses()增强类时不能新增、删除或者重命名字段和方法，不能更改方法的签名，也不能更改类的继承关系，那作为 JavaAgent 的框架开发者，应该不要做出超越上述限制的设计，否则极易导致 JavaAgent 之间的兼容性问题出现。不仅仅是这个接口，JavaAgent 框架的开发者也需要遵循所有的字节码增强的底层接口的设计理念，毕竟有规则才有秩序。

华为云的 sermant 开源项目

用 javaagent 做服务治理很想，但是实际上手怎么搞？ 华为云在早期接触的很多客户场景中，发现很多架构团队都是拿已有的开源的 javaagent 相关的项目上手魔改做自己的服务治理能力。但是做着做着很快发现了几个问题。

• 我们目标的服务治理功能很多，但是一般开源项目如 pinpoint, skywalking 等增强的点就那么一个，比如如果在服务调用增强点上实施了链路追踪逻辑以后，再加其他比如限流降级功能，就需要在 Plugin 中写很多限流降级逻辑，这些代码逻辑会和已有的开源项目的原生治理逻辑纠缠不清。

• 很多服务治理功能本身逻辑可能比较重，有其自身的三方依赖依赖库。但是世面上已有的 Javaagent，并不支持针对组件级别的类隔离机制。

• 服务治理场景有很多通用逻辑，除了方便快速的对特定函数接口做增强以外，还包括可替换的实时配置中心，基于 RPC 的 Tag 透传，通用的 Metrics 上报机制。能否把这些能力都沉淀出来，以 SDK API 方式暴露给开发者直接使用，这样可以极大提高服务治理的开发效率。

以上几个原因，促使我们思考是否应该做一个新的 javaagent 服务治理项目，来解决以上问题。这就是 sermant 项目由来。我们希望通过 Sermant 项目。

• 服务治理功能以插件形式装载到 javaagent 中，不同插件间可以做到对同一个业务函数增强点进行不同增强，且互不冲突。最终所有服务治理统一到一个 javaagent 中，降低资源损耗。

• 服务治理插件之间同时需要做到类隔离，以降低不通版本的三方库依赖造成的类加载冲突风险。

• javaagent 本身能提供一层厚度适中的 framework 能力，帮助插件快速开发服务治理能力。项目之初，我们提出至少三个目标需要尝试实现：

• 实时配置中心抽象。无论用 ZooKeeper, Nacos, 还是 Servicecomb，都不影响插件使用统一 framework 提供的实时配置的能力。以此做到实时配置连接收敛。

• payload 数据透传能力。我们希望 framework 提供 SDK，无论是 tracing id 透传，还是全链路灰度标透传，都能基于数据透传能力快速开发治理功能。

• 监控能力。按照规范开发的插件最后都能在后端平台上对所有的 javaagent 和其加载的 plugin 做统一监控。

图例 9：Sermant 的框架、插件架构

路走对了，就不怕远。到今天，在公司内外生态伙伴的贡献下，Sermant 名下已有各类服务治理插件已多达数十种，场景覆盖包括 服务注册发现改造、服务契约查询、服务血缘关系发现、服务双注册、配置治理、流量录制回放、限流降级、优雅上下线、全流量标签路由、同机房调用优先、故障注入、性能监控、等等。我们同时将规划更多的框架层能力，以辅助增强 Sermant 服务治理总体能力，进一步降低插件开发难度。这包括：插件动态插拔能力，应用无需重启应用，即可在线升级服务治理功能；插件增强顺序动态调配，对于同一个函数增强点，不同插件可以按需调整顺序，如性能监控插件在限流降级插件之前生效，以保证服务治理逻辑正确；等等。

如果您对以上细节感兴趣，我们诚挚欢迎你来社区使用 Sermant 。

图例 10：Sermant 的社区介绍

欢迎使用 Sermant

Sermant 社区当前快速成长中，当前开源代码仓地址：https://github.com/huaweicloud/Sermant

Sermant 目前部分服务治理功能已在华为云产品中提供商业化服务，华为云用户可在 微服务引擎 CSE 中使用相关功能: https://www.huaweicloud.com/product/cse.html

政企客户亦可在最新的 HCS 产品中使用相关 Sermant 功能。该功能在 ROMA-Factory 已支持部分场景的 PoC。

点击关注，第一时间了解华为云新鲜技术~