标签：walking 调用 服务 字节 Zipkin Sk 链路 拦截

前言

微服务架构将原先业务链条中的各个环节（节点或过程），如用户、产品、订单、支付拆分实现成独立的服务运行，一定程度上提高了系统的容错能力，例如支付服务失败时，用户依然可以通过产品及订单服务，达到查看订单和浏览产品的目的。随着微服务应用开发框架（如springboot）和容器技术（如K8）越来越成熟，微服务的开发和运维趋于标准化。这些都是微服务的愈发流行的原因。同时，随着业务复杂度的提高，越来越多的微服务被开发和集成进来，服务管理的重要性不言而喻。本文以服务调用的链路管理为题，浅谈微服务治理中链路管理的主流技术如何实践。

链路管理，主要指记录服务的调用链路，通常用来定位不合理的服务设计，如链路过长带来的服务耗时问题、链路过长带来的服务稳定性风险、循环依赖等。链路管理，需要考虑哪些方面的问题，如何实现？

1. 首先，需要知道有哪些服务以及他们的服务状态（服务注册和发现机制），这个目前可以直接通过spring cloud的Eureka实现，当然也可以通过dubbo+zookeeper实现；
2. 有了服务清单之后，我们需要在每个服务调用的地方拦截并记录，记录调用堆栈，从发起服务到链尾。这一步自己实现起来有较多的工作，譬如统一服务调用规则、AOP拦截、调用链数据结构定义、调用信息采集发送及存储等。
3. 最后，是链路数据的采集、存储、发送以及最终的图形化展示。

有了这个思路之后，我们再来看目前主流的链路解决方案，Twitter的Zipkin，以及Apache的在孵化项目Skwalking。当然还有些比较热的方案，如韩国的开源项目Pinpoint和美团的CAT。这些方案从实现技术上大致可分为两个派系，拦截派，字节码增强派。拦截派做法通过代理类拦截请求，将链路信息发送给服务器，Zipkin和CAT都属于这种类型，不过CAT需要代码侵入，即代码中增加埋点，而Zipkin直接通过SpringCloud的Sleuth无缝对接SpringBoot的微服务。字节码增强技术，通过JVMTI接口提供的javaagent（区别于JDK动态代理和CGLIB代理），利用字节码操作技术（ASM），在类加载并实例化之前对class进行转换，之后运行中将信息采集并发送给代理服务器(探针)，如skwalking的Agent服务。关于两种方式的比较，小结如下：

Zipkin实践

Sk*walking实践

标签：walking,调用,服务,字节,Zipkin,Sk,链路,拦截
来源： https://blog.51cto.com/10705830/2433647

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。