摘要：本文基于对微服务治理技术从SOA, 微服务框架，到云原生架构的历史发展总结，提出了一种新的基于Javaagent技术的新一代无代理架构的服务治理技术，并介绍了其相关的代表性开源项目Sermant。
本文分享自华为云社区《云原生微服务治理技术朝无代理架构的演进之路》，作者： 杨奕｜华为云技术规划专家。
对于云原生的归纳，业界从来没有停止过演进。但是总体来讲，微服务和容器化基本上是两个永恒不变的话题。今天这篇文章重点来谈谈微服务架构的演进。
微服务这个词，比较公认的官方正式介绍来自 Martin Fowler 在2014年发布的 Microservices 一书。但是实际上，其解决的服务解耦的问题，最早可以追述到SOA (Service-Oriented Architecture，面向服务的架构)。下面这种图 (参考链接 ) 比较好的诠释了服务的演进历程。从最早的SOA，到本世纪10年代的微服务，到最后的云原生微服务架构的Servicemesh，核心都是为了解决在企业的复杂业务场景下，让各服务以解耦方式各自独立快速迭代。
图例1：服务架构的演进历程：SOA -> 微服务框架 -> 云原生
总体来讲，微服务的迭代发展到目前为止，分为三个阶段。
在以上架构图中，SOA不是本文重点。关于SOA到微服务的演进，感兴趣可以参考文章 《 SOA 和微服务的区别》 一文。本文以下章节重点介绍其他的 微服务框架 和 云原生 Service Mesh 这两个阶段的微服务治理架构特点。
如前文所述，微服务的的名词比较正式被普及可归公于 Martin Fowler 在2014年撰写的 Microservices 一书。但是实际上，国内的微服务起源反而更早。比较出名的是是阿里早期的HSF和Dubbo。正如“ Dubbo 和 HSF 在阿里巴巴的实践：携手走向下一代云原生微服务 ”一文中所述，阿里最早在2008年就开始了微服务方面的实际尝试，虽然可能在当时，其团队并未真正意识到自己开发的其实是下一代微服务架构。
”Dubbo项目诞生于2008年，起初只在一个阿里内部的系统使用；2011年，阿里B2B决定将整个项目开源，仅用了一年时间就收获了来自不同行业的大批用户；2014年，由于内部团队调整，Dubbo暂停更新；2017年9月，Dubbo 3重启开源，在2019年5月由Apache孵化毕业，成为第二个由阿里巴巴捐献至Apache毕业的项目。“
文摘1：Dubbo阿里内部的演进历史
在海外，虽然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等边车服务治理方案兴起的一大原因。
在CloudNative时代的服务治理架构中，Service-mesh因为其对应用的无侵入性，成为了云原生服务治理的一个经典流派。而在Service-mesh流派中，Istio又是其中一个代表作。Istio的兴起，其实核心是因为解决了两个问题。
图例4：Istio社区中火了5年的书店demo程序，集 python、ruby、node.js、java 等各类开发语言
关于Istio的功能和架构介绍，网上文章多如牛毛，本文就不赘诉了。但是这里核心讲下Istio在实践中遇到的几个问题。
图例5：百度在 Proxy Service Mesh 实践中因为边车无法侵入进程，所遇到的问题
图例6：Istio社区中最新发布的性能测试。测试现实，增加边车，性能损耗至少增加1.5ms
基于以上各种原因，原生的istio的落地实践中，都多少处于叫好不叫座的尴尬境界。接下来就Proxy边车治理方案的问题，说说为啥最近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这个技术在服务治理领域火起来的，也是最近两年的事。这里面主要发生两件值得一提的事：
为啥javaagent技术这么火？这是因为其相比传统SDK和Servicemesh技术：
图例8：(原创首发)Javaagent对其他服务治理对比的优势
当然，Javaagent的服务治理技术也并非银弹。
"严格遵守字节码增强的使用要求和限制。无论是Byte Buddy、Javassist还是ASM，底层实现都离不开JDK1.5之后引入的Instrumentation接口。既然官方接口的设计理念是reTransformClasses()增强类时不能新增、删除或者重命名字段和方法，不能更改方法的签名，也不能更改类的继承关系，那作为JavaAgent的框架开发者，应该不要做出超越上述限制的设计，否则极易导致JavaAgent之间的兼容性问题出现。不仅仅是这个接口，JavaAgent框架的开发者也需要遵循所有的字节码增强的底层接口的设计理念，毕竟有规则才有秩序。"
文摘2："记一次多个JavaAgent同时使用的类增强冲突问题及分析" 文中对避免Javaagent冲突的建议。
用javaagent做服务治理很想，但是实际上手怎么搞？ 华为云在早期接触的很多客户场景中，发现很多架构团队都是拿已有的开源的 javaagent 相关的项目上手魔改做自己的服务治理能力。但是做着做着很快发现了几个问题。
以上几个原因，促使我们思考是否应该做一个新的javaagent服务治理项目，来解决以上问题。这就是sermant项目由来。我们希望通过Sermant项目，
图例9：Sermant 的框架、插件架构
路走对了，就不怕远。到今天，在公司内外生态伙伴的贡献下，Sermant名下已有各类服务治理插件已多达数十种，场景覆盖包括 服务注册发现改造、服务契约查询、服务血缘关系发现、服务双注册、配置治理、流量录制回放、限流降级、优雅上下线、全流量标签路由、同机房调用优先、故障注入、性能监控、等等。我们同时将规划更多的框架层能力，以辅助增强Sermant服务治理总体能力，进一步降低插件开发难度。这包括：插件动态插拔能力，应用无需重启应用，即可在线升级服务治理功能；插件增强顺序动态调配，对于同一个函数增强点，不同插件可以按需调整顺序，如性能监控插件在限流降级插件之前生效，以保证服务治理逻辑正确；等等。
如果您对以上细节感兴趣，我们诚挚欢迎你来社区使用Sermant。
图例10：Sermant的社区介绍
Sermant社区当前快速成长中，当前开源代码仓地址：https://github.com/huaweicloud/Sermant
Sermant目前部分服务治理功能已在华为云产品中提供商业化服务，华为云用户可在 微服务引擎 CSE 中使用相关功能: https://www.huaweicloud.com/product/cse.html
政企客户亦可在最新的HCS产品中使用相关Sermant功能。该功能在ROMA-Factory已支持部分场景的PoC。