分布式链路追踪原理 (散布式链路追踪技术概论 JAVA)

目录1.概述2.基于日志的成功2.1.成功思维2.2.sleuth2.2.可视化3.基于agent的成功4.咨询作者1.概述当驳回散布式架构后，一次性恳求会在多个服务之间流转，组成单次调用链的服务往往都扩散在不同的主机上，这就会带来一个疑问，缺点难以溯源，动员恳求，而后恳求报错，究竟是调用链中哪一环出了疑问，很难以定位，这时刻就须要用...。

目录

1.概述

2.基于日志的成功

2.1.成功思维

2.2.sleuth

2.2.可视化

3.基于agent的成功

4.咨询作者

---

1.概述

当驳回散布式架构后，一次性恳求会在多个服务之间流转，组成单次调用链的服务往往都扩散在不同的主机上。这就会带来一个疑问：

缺点难以溯源。

动员恳求，而后恳求报错，究竟是调用链中哪一环出了疑问？很难以定位。这时刻就须要用到链路追踪技术了。所谓的链路追踪技术，也就是想方法让散布式系统中的单次恳求的链路调用成为可被追踪的，便于在发生缺点的时刻启动极速的定位溯源。

目前有两套成功思绪：

• 基于日志来成功，罕用到的有Sleuth、zipkin

• 基于agent来成功，罕用到的有skywaiking

本文着重于引见链路追踪的概念和大略体系，sleuth、zipkin、skywalking详细的详细教程会在后续有文章推出启动详细引见。

2.基于日志的成功

2.1.成功思维

当散布式系统中的一次性恳求报错时，如何定位失误？大家的第一反响或者都是去挨着看链路上各个服务的日志。这是必需的，由于只能从这里下手。查这些日志的环节中有个很费事的疑问——如何将不同服务间的日志对起来？一次性调用在调用链的上一个服务留下了一条日志，我怎样知道这条日志对应着链路的下一个节点的哪条日志喃？所以要给每一次性恳求一个编号。基于这个思维，于是有了规范日志格局规范——OpenTracing。

OpenTracing规则了规范的日志格局如下：

服务ID，服务称号。

trace ID，每一次性恳求，调用链上的各个服务trace ID是相反的，也就是每一次性恳求的编号。

span ID，各个服务不同，用来区分链路上的不同节点。

导出标识，

2.2.sleuth

依赖：

这里咱们搭建了一个便捷的微服务集群，而后在APP、AuthenticationCenter、Bis中均引入sleuth:

AuthenticationCenter，鉴权中心，用来登录失掉token，校验token能否非法。

APP，服务提供方。

Bis，Bis调用AuthenticationCenter登录，而后校验token能否非法，非法的话，再去调用APP中提供的服务：

最后去访问bis，会看到：

bis的日志：

AuthenticationCenter的日志：

APP的日志：

可以看到Bis中一个方法中收回的一切恳求在下游的trace ID全是分歧的，只是span ID不同。

2.2.可视化

光有了日志，启动疑问排查还是要一条条的翻，还是很繁琐。所以配套发生了可视化工具，由推特开发的——zipkin。其能对规范opentracing格局的日志启动搜集和展现：

成果图：

3.基于agent的成功

skywalking是基于java agent来成功的，java agent是jkd 1.5引入的新个性，准许在main方法之前执行premain方法，来成功一些预备举措。对于 java gent，其在很多中央都有经常使用到，博主后续会有文章专门体系化的引见java agent，并用java agent+字节码增强的形式来对类启动增强和监控，此处不开展。

sky walking的经常使用很便捷，用-agent来启动即可：

-Dskywalking.agent.service_name，运行的称号。

-Dskywalking.logging.file_name，数据须要上行到哪里。

skywalking领有愈加的弱小和细粒度的图形监控界面。

4.咨询作者

商务协作、各种交换：