9.3.5 使用Zipkin跟踪事务

 

    让我们以一个场景来开始这一节。假设你是EagleEye 应用程序的一名开发人员，并且你在这周处于待命状态。你从客户那里收到一张工单，他抱怨说EagleEye应用程序的某一部分现在运行缓慢。你怀疑是许可证服务导致的，但问题是，为什么它会运行缓慢呢？问题究竟出在了哪里呢？许可证服务依赖于组织服务，而这两个服务都对不同的数据库进行调用。究竟是哪个服务表现不佳？此外，你知道这些服务正在不断被迭代更新，因此有人可能添加了一个新的服务调用。了解参与用户事务的所有服务以及它们的性能时间对于支持分布式架构（如微服务架构）是至关重要的。

    接下来，你将开始使用Zipkin来观察来自组织服务的两个事务（它们由Zipkin服务进行跟踪）。组织服务是一个简单的服务，它只对单个数据库进行调用。你所要做的就是使用POSTMAN向组织服务发送两个调用（对http://localhost:5555/api/organizationservice/v1/organizations/e254f8c-c442-4ebe-a82a-e2fc1d1ff78a发起GET请求）。

 

组织服务调用将流经Zuul API网关，然后再将调用定向到下游组织服务实例。

    调用了两次组织服务之后，转到http://localhost:9411，看看Zipkin已经捕获的跟踪结果。从界面左上角的下拉框中选择“organizationservice”，然后点击“Find traces”按钮。图9-11展示了操作后的Zipkin查询界面。

图9-11　可以在Zipkin的查询界面选择想要跟踪的服务以及一些基本的查询过滤器

 

现在，如果读者查看图9-11中的屏幕截图，就会发现Zipkin捕获了两个事务，每个事务都被分解为一个或多个跨度（span）。在Zipkin中，一个跨度代表一个特定的服务或调用，Zipkin会捕获每一个跨度的计时信息。图9-11中的每一个事务都包含3个跨度：两个跨度在Zuul网关中，还有一个是组织服务。记住，Zuul网关不会盲目地转发HTTP调用。它接收传入的HTTP调用并终止这个调用，然后构建一个新的到目标服务的调用（在本例中是组织服务）。原始调用的终止是因为Zuul要添加前置过滤器、路由过滤器以及后置过滤器到进入该网关的每一个调用。这就是我们在Zuul服务中看到两个跨度的原因。

 

通过Zuul对组织服务的两次调用分别用了3.204 s和77.2365 ms。因为查询的是组织服务调用（而不是Zuul网关调用），从图9-11中可以看到组织服务在总事务时间中占了92%和72%。

    让我们深入了解运行时间最长的调用（3.204 s）的细节。读者可以通过点击事务并深入了解细节来查看更多详细信息。图9-12展示了点击了解更多细节后的详细信息。

图9-12　可以使用Zipkin查看事务中每个跨度所用的时间

    在图9-12中可以看到，从Zuul角度来看，整个事务大约需要3.204 s。然而，Zuul发出的组织服务调用耗费了整个调用过程3.204 s中的2.967 s。图中展示的每个跨度都可以深入到更多的细节。点击组织服务跨度，并查看可以从这个调用中看到哪些额外的细节。图9-13展示了这个调用的细节。

 

 

图9-13　点击单个跨度会获得更多关于调用时间和HTTP调用细节的详细信息

    图9-13中最有价值的信息之一是客户端（Zuul）何时调用组织服务、组织服务何时接收到调用以及组织服务何时作出响应等分解信息。这种类型的计时信息在检测和识别网络延迟问题方面是非常宝贵的。

    9.3.6　可视化更复杂的事务

    如果想要确切了解服务调用之间存在哪些服务依赖关系，该怎么办？我们可以通过Zuul调用许可证服务，然后向Zipkin查询许可证服务的跟踪。这项工作可以通过对许可证服务的http://localhost:5555/api/licensing/v1/organizations/e254f8c-c442-4ebe-a82a-e2fc1d1ff78a/licenses/f3831f8c-c338-4ebe-a82a-e2fc1d1ff78a端点进行GET调用来完成。

    图9-14展示了调用许可证服务的详细跟踪。

 

图9-14　查看许可证服务调用如何从Zuul流向许可证服务然后流向组织服务的跟踪详情

    在图9-14中，可以看到对许可证服务的调用涉及4个离散的HTTP调用。首先是对Zuul网关的调用，然后从Zuul网关到许可证服务，接下来许可证服务通过Zuul调用组织服务。