以案例聊聊SpringCloud分布式系统的架构者（八）

其实聊到这了，分布式系统也就是微服务架构也就差不多了。在实际的研发中用的也就是这些东西。那么整个的系统在日后的使用过程中慢慢的就会发现一个问题。这个问题我们看下图：

上图中A系统中的A1服务需要调用B系统中的B1服务，但是我们可以看到B系统中的B1服务又调用着C系统中的C2服务。那么问题来了，如果A1在调用B1时发生了超时甚至链接不上，此时A1会想当然的认为B1的服务出现了问题，可是这样想当然的认为的准确率只有50%，因为B1中调用了C1这个服务，如果是C1的服务出现了问题，那么也会导致A1在调用B1时出现超时等情况。那么有什么办法可以在出现问题的时候准确的追踪到问题的根本的原因呢？回答那必须是有啊——用ZipKin来进行追踪。

先看看ZipKin是个什么东西。它的官网地址为：https://zipkin.io/

然后进入官网看看关于它的介绍：

这里面说了个什么意思呢？大致为：

Zipkin是一个分布式跟踪系统。它有助于收集解决服务体系结构中的延迟问题所需的时间数据。功能包括收集和查找这些数据。如果日志文件中有跟踪ID，则可以直接跳转到它。否则，您可以基于服务、操作名称、标记和持续时间等属性进行查询。将为您总结一些有趣的数据，例如在服务中花费的时间百分比，以及操作是否失败。一句话综合概括起来就是：ZipKin是分布式系统中一个用于收集查找各个子系统的日志，它的追踪方式多元化可以基于服务、操作名称、服务名称等来追踪查询。接下来我们快速的搭建一个ZipKinServer出来。

第一步：创建项目添加依赖。注意将SpringBoot的版本变为1.5.21的版本

创建好以后手动添加下面的两个依赖：

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-server</artifactId>
    <version>2.4.5</version>
</dependency>

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-autoconfigure-ui</artifactId>
    <version>2.4.5</version>
</dependency>

第二步：先只修改端口号

server.port=9411

第三步：在启动类上添加注解

第四步：在浏览中访问

能看到这个页面说明Zipkin的跟踪器就构建好了。下一篇我们继续聊服务之间相互调用在Zinkin中的表现