认识达内从这里开始

微服务架构技术随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，微服务技术迭代与应用分析。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。