微服务架构将原先业务链条中的各个环节（节点或过程），如用户、产品、订单、支付拆分实现成独立的服务运行，一定程度上提高了系统的容错能力，例如支付服务失败时，用户依然可以通过产品及订单服务，达到查看订单和浏览产品的目的。随着微服务应用开发框架（如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实践

先看下Zipkin运行架构

左侧应用服务，同时也是Zipkin-clinet，Eureka-client， 中间是依赖，包括Zipkin-server和Eureka-server，最右侧是WebUI展示及开发接口。

Sk*walking实践

如何通过Zipkin或Sk*walking实现链路追踪

原文：https://blog.51cto.com/10705830/2433647