微服务架构之「 调用链监控 」

2020-07-02 00:00:00 微服 请求 调用 服务 监控

「 调用链监控 」是在微服务兴起后才有的一种新流行的监控模式。因为在我们传统单体应用的项目中，不存在服务链/调用链的概念，所以也就根本没有调用链监控的需求了。

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

因此大家就想到了一个办法，将这个请求经过的每一个节点都记录下来，形成一个完整的调用链监控系统，那么一旦发生请求调用异常的情况，只需要去排查这个调用链日志就能很清楚看到出错的环节在哪儿。

一、为什么需要「 调用链监控 」？

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

好了，说了这么多，咱们下面就来具体看一下「调用链监控」的作用有哪些：

  1. 项目网络拓扑图：
    我们可以根据「调用链监控」中记录的链路信息，给项目生成一张网络调用的拓扑图。通过这张图，我们就可以知道系统中的各个服务之间的调用关系是怎样的，以及系统依赖了哪些服务。并且还可以起到监控全局服务的作用，便于架构师掌握系统的状态。
  2. 快速定位问题：
    这个作用前面一直在讲，微服务架构下，问题定位就变得非常复杂了，一个请求可能会经过多个服务节点，那么有这么一套调用链监控系统就能让开发人员快速的定位到问题和相应模块。
  3. 优化系统：
    优化系统也是「调用链监控」很重要的一个功能。因为我们记录了请求在调用链上每一个环节的信息，我们就可以通过这个来找出系统的瓶颈，做出针对性的优化。还可以分析这个调用路径是否合理，是否调用了不必要的服务节点，是否有更近、响应更快的服务节点。通过对调用链路的分析，我们就可以找出优质的调用路径，从而提高系统的性能。
  4. 提高团队成员自律：
    上面都是系统层面的作用。但如果有了「调用链监控」之后，对团队开发人员的帮助也是非常大的。因为团队所有成员都可以通过这个调用链监控系统看到系统各个模块的状态，相当于给了开发同学一个放大镜，以前开发同学完成项目交付后，只要没有出现问题，可能不太关心系统的优化，但是有这个调用链监控系统之后，哪个模块性能高，哪个模块问题大，一眼就能分辨，通过这么一个看板，开发同学慢慢的也会对自己负责的模块有更多的责任感，也会很自觉的去优化自己的模块。这种习惯的养成，对研发团队而言，非常的重要。

二、「 调用链监控」的原理？

在调用链监控系统中，有几个核心概念需要了解：

  • Trace:
    Trace是指一次请求调用的链路过程，trace id 是指这次请求调用的ID。在一次请求中，会在网络的开始生成一个全局的用于标识此次请求的trace id，这个trace id在这次请求调用过程中无论经过多少个节点都会保持不变，并且在随着每一层的调用不停的传递。终，可以通过trace id将这一次用户请求在系统中的路径全部串起来。
  • Span:
    Span是指一个模块的调用过程，一般用span id来标识。在一次请求的过程中会调用不同的节点/模块/服务，每一次调用都会生成一个新的span id来记录。这样，就可以通过span id来定位当前请求在整个系统调用链中所处的位置，以及它的上下游节点分别是什么。
  • Annotation:
    是指附属信息，可以用于附属在每一个Span上自定义的数据。

具体参考下图：

从图中可见，一次请求只有一个的trace id=12345，在请求过程中的任何环节都不会改变。在这个请求的调用链中，SpanA调用了SpanB，然后SpanB又调用了SpanC和SpanD，每一次Span调用都会生成一个自己的span id，并且还会记录自己的上级span id是谁。通过这些id，整个链路基本上就都能标识出来了。

好了，了解了核心概念之后，我们再来看一下它具体是如何工作的，下面选取Twitter开源的Zipkin原理图作为参考：

所有的调用链监控系统都由 数据埋点采集、数据存储处理、数据分析展示 几大部分组成，Zipkin也不例外。

图中左上角Reporter部分集成到应用程序中采集数据，并将数据上报，由Collector进行收集，然后通过Storage模块负责存储，落地到存储系统中（Zipkin用的是Cassandra）。而API模块是可以将处理后的数据提供对外服务的，UI模块就是数据统计展示层了。

三、「 调用链监控」的应用？

了解了调用链监控的原理之后，我们再看看目前业内有哪些主流的开源调用链监控系统：

  • CAT
    CAT是由大众点评开源的一款调用链监控系统，基于JAVA开发的。有很多互联网企业在使用，热度非常高。它有一个非常强大和丰富的可视化报表界面，这一点其实对于一款调用链监控系统而来非常的重要。在CAT提供的报表界面中有非常多的功能，几乎能看到你想要的任何维度的报表数据。
    CAT有个很大的优势就是处理的实时性，CAT里大部分系统是分钟级统计。
    CAT主要提供的报表有：


  1. Transaction报表：
    主要是监控一段代码运行情况，如：运行次数、QPS、错误次数、失败率、响应时间等。


  1. Event报表：
    主要是监控一行代码/一个事件运行次数，如：程序中某个事件运行了多少次、错误了多少次等。Event报表的整体结构与Transaction报表几乎一样，只缺少响应时间的统计。
  2. Problem报表：
    主要是统计项目在运行过程中出现的问题，根据Transaction与Event的数据分析出来系统可能出现的异常，比如访问较慢等。


  1. Heartbeat报表：
    以一分钟为周期，定期向服务端汇报当前运行的一些状态，如：JVM状态、Memory、Thread等。


  1. Business报表：
    业务监控报表，如订单指标、支付数据等业务指标。
  • Open Zipkin
    Zipkin由Twitter开源，支持的语言非常多，基于 Google Dapper 的论文设计而来，国内外很多公司都在用，文档资料也很丰富。在上面讲原理的环节已经介绍过了Zipkin，这里就不赘述了，下面是示例图：


  • Naver Pinpoint
    Pinpoint中的服务关系依赖图做得非常棒，超出市面上任何一款产品。另外，Pinpoint因为采用字节码增强方式去埋点，所以在埋点的时候是不需要修改业务代码的，非侵入式的，非常适合项目已经完成之后再增加调用链监控的时候去使用的方案。但是也是由于采用字节码增强的方式，所以它目前仅支持JAVA语言。


以上，就是对微服务架构中「 调用链监控」的一些思考。

在微服务架构的系列文章中，前面已经通过文章介绍过了「服务注册 」、「服务网关 」、「配置中心 」、「 监控系统 」，大家可以翻阅历史文章查看。

另外，为了方便小伙伴们交流微服务架构相关的技术，我创建了一个「 聊聊架构与微服务 」的交流群。

添加微信后拉你进群：WH-IT-er，加微信时备注：微服务加群。

本文原创发布于微信公众号「 不止思考 」，欢迎关注。涉及 思维认知、个人成长、架构、大数据、Web技术 等。

相关文章