Spring Cloud Sleuth集成Zipkin结果分析

接着前面一篇文章，https://bbs.huaweicloud.com/blogs/281532，我们来看看整个实践过程的结果展示。

调用结果展示

我们相继启动Eureka Server、Zipkin Server以及两个客户端服务Service-A/B。

交叉访问A/B服务的接口，即：

• http://localhost:9002/api/service-b：通过服务A调用服务B；
• http://localhost:9003/api/service-a：通过服务B调用服务A。

访问http://localhost:9411，首先看一下Zipkin UI的首页：

上图，我们点击了Find Traces按钮，展示了监控到的多个Traces。UI提供多种维度的查询，读者可以自行尝试一下。下面看一下A与B之间的依赖关系图：

可以看到，服务A与服务B之间的相互依赖，服务A调用服务B，服务B也调用服务A。

在服务A调用服务B的请求中，选择其中的一个请求Trace如下：

可以看到在该请求的调用链中存在三个Span，服务A与服务B之间的调用顺序以及每个Span的耗时都有在图中显示。

需要注意的是，某一个Trace，页面中展示的是合并的Span，这意味着，如果有两个Span，如SR（Server Received）和 SS（Server Sent）或者 CR（Client Received）和CS（Client Sent），发送给Zipkin服务器，他们将会被合并为一个Span。

可以点进去看一下调用服务B时的Span具体信息：

在Span中，记录了客户端的地址，调用的方法、URL以及具体的Controller和方法名。在左下角还有Span的关系，所属的Trace以及父SpanId。

当请求出现错误时，在Span的详细信息中，会显示具体的堆栈信息，如图所示。

小结 不足之处

需要注意的是，如果客户端服务的配置不设置采样率，即spring.sleuth.sampler.probability使用默认的10%采样率时，可能刷新几次并不会看到任何数据。如果调大此值为1，可以看到信息收集就会更及时。但是当这样调整后，会发现rest接口调用速度比0.1的情况下慢了很多，即使在10%的采样率下，多次刷新客户端服务的接口，会发现对同一个请求两次耗时信息相差非常大。如果去掉spring-cloud-sleuth后再进行测试，会发现并没有这种情况，可以看到HTTP调用方式追踪服务调用链路会给我们业务程序性能带来一定的影响。

可以看出上述方案的缺陷是：

• 客户端向zipkin-server程序发送数据使用的是http的方式通信，每次发送的时候涉及到连接和发送过程；
• 当我们的zipkin-server程序关闭或者重启过程中，因为客户端收集信息的发送采用http的方式会被丢失。

针对上述所提出的问题，相应的改进措施是：

首先，客户端数据的发送尽量减少业务线程的时间消耗，采用异步等方式发送收集信息；
其次，客户端与zipkin-server之间增加缓存类的中间件，例如redis、MQ等，在zipkin-server程序挂掉或重启过程中，客户端依旧可以正常的发送自己收集的信息。

下篇文章将会介绍如何改进上述问题，并进行改进。