(黑马资料)什么是调用链监控

1.架构的演进历史

单体应用

架构说明：

全部功能集中在一个项目内（All in one）。

在单体应用的年代，分析线上问题主要靠日志以及系统级别的指标。修改系统任意一个功能模块点都需要进行发版。

微服务架构

架构说明：

将系统服务层完全独立出来，抽取为一个一个的微服务。

当我们开始微服务架构之后，服务变成分布式的了，并且对服务进行了拆分。当用户的一个请求进来，会依次经过不同的服务节点进行处理，处理完成后再返回结果给用户。那么在整个处理的链条中，如果有任何一个节点出现了延迟或者问题，都有可能导致最终的结果出现异常，有的时候不同的服务节点甚至是由不同的团队开发的、部署在不同的服务器上，那么在这么错综复杂的环境下，我们想要排查出是链条中的具体哪个服务节点出了问题，其实并不容易。如下图片很形象的解释了在微服务架构下的复杂调用关系：

2 .调用链监控的需求

调用链监控是在微服务架构中非常重要的一环。它除了能帮助我们定位问题以外，还能帮助项目成员清晰的去了解项目部署结构，毕竟一个几十上百的微服务，相信在运行时间久了之后，项目的结构会出现上述非常复杂的调用链，在这种情况下，团队开发者甚至是架构师都不一定能对项目的网络结构有很清晰的了解，那就更别谈系统优化了。

这里我们会使用到调用链监控工具，那么首先我们先对调用链监控工具提出我们的需求：

1.线上的服务是否运行正常。是不是有一些服务已经宕机了，但是我们没有发现呢？如何快速发现已经宕机的服务？

2.来自用户的一笔调用失败了，到底是哪个服务导致的错误，我们需要能够快速定位到才能做到修复。

3.用户反映，我们的系统很“慢”。如何知道究竟慢在何处？

从上述问题可以看出，微服务架构下，如果没有一款强大的调用链监控工具，势必会产生如下问题：

  • 问题处理不及时，影响用户的体验
  • 不同应用的负责人不承认是自己的问题导致失败，容易出现“扯皮”
  • 服务之间的调用关系难以梳理，可能会存在很多错误的调用关系
  • 由于没有具体的数据，团队成员对自己的应用性能不在意

3 .调用链监控的原理

在2010年，google发表了一篇名为“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”的论文，在文中介绍了google生产环境中大规模分布式系统下的跟踪系统Dapper的设计和使用经验。而如今很多的调用链系统如zipkin/pinpoint等系统都是基于这篇文章而实现的。

接下来我们就简单的介绍一下Dapper中调用链监控的原理：

如上图所示，这是一个查询订单的简单业务，他有如下的步骤：

1.前端浏览器发起请求到订单服务，订单服务会从数据库中查询出对应的订单数据。订单数据中包含了商品的ID，所以还需要查询商品信息。

2.订单服务发起一笔调用，通过rpc的方式，远程调用商品服务的查询商品信息接口。

3.订单服务组装数据，返回给前端。

这几个步骤中，有几个核心概念需要了解：

  • Trace:

    Trace是指一次请求调用的链路过程，trace id 是指这次请求调用的ID。在一次请求中，会在网络的最开始生成一个全局唯一的用于标识此次请求的trace id，这个trace id在这次请求调用过程中无论经过多少个节点都会保持不变，并且在随着每一层的调用不停的传递。最终，可以通过trace id将这一次用户请求在系统中的路径全部串起来。

  • Span:

    Span是指一个模块的调用过程，一般用span id来标识。在一次请求的过程中会调用不同的节点/模块/服务，每一次调用都会生成一个新的span id来记录。这样，就可以通过span id来定位当前请求在整个系统调用链中所处的位置，以及它的上下游节点分别是什么。

那么回到上面的案例中，查询订单数据和查询商品数据这两个过程，就分别是两个span,我们记为span A和B。B的parent也就是父span就是A。这两个span都拥有同一个Trace Id：1。

并且在信息收集过程中，会记录调用的开始时间，结束时间，从中计算出调用的耗时。

这样，就可以清楚的知道，每笔调用：

  • 经过了哪几个服务以及服务的调用顺序
  • 每个服务过程的耗时