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

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

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

所以你们就想到了一个办法，将这个请求通过的每个节点都记录下来，造成一个完整的调用链监控系统，那么一旦发生请求调用异常的状况，只须要去排查这个调用链日志就能很清楚看到出错的环节在哪儿。

1、为何须要「 调用链监控 」？

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

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

1. 项目网络拓扑图：

   咱们能够根据「调用链监控」中记录的链路信息，给项目生成一张网络调用的拓扑图。经过这张图，咱们就能够知道系统中的各个服务之间的调用关系是怎样的，以及系统依赖了哪些服务。而且还能够起到监控全局服务的做用，便于架构师掌握系统的状态。

2. 快速定位问题：

   这个做用前面一直在讲，微服务架构下，问题定位就变得很是复杂了，一个请求可能会通过多个服务节点，那么有这么一套调用链监控系统就能让开发人员快速的定位到问题和相应模块。

3. 优化系统：

   优化系统也是「调用链监控」很重要的一个功能。由于咱们记录了请求在调用链上每个环节的信息，咱们就能够经过这个来找出系统的瓶颈，作出针对性的优化。还能够分析这个调用路径是否合理，是否调用了没必要要的服务节点，是否有更近、响应更快的服务节点。经过对调用链路的分析，咱们就能够找出最优质的调用路径，从而提升系统的性能。

4. 提升团队成员自律：

   上面都是系统层面的做用。但若是有了「调用链监控」以后，对团队开发人员的帮助也是很是大的。由于团队全部成员均可以经过这个调用链监控系统看到系统各个模块的状态，至关于给了开发同窗一个放大镜，之前开发同窗完成项目交付后，只要没有出现问题，可能不太关心系统的优化，可是有这个调用链监控系统以后，哪一个模块性能高，哪一个模块问题大，一眼就能分辨，经过这么一个看板，开发同窗慢慢的也会对本身负责的模块有更多的责任感，也会很自觉的去优化本身的模块。这种习惯的养成，对研发团队而言，很是的重要。

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

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

• 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模块就是数据统计展现层了。

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

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

• CAT

  CAT是由大众点评开源的一款调用链监控系统，基于JAVA开发的。有不少互联网企业在使用，热度很是高。它有一个很是强大和丰富的可视化报表界面，这一点其实对于一款调用链监控系统而来很是的重要。在CAT提供的报表界面中有很是多的功能，几乎能看到你想要的任何维度的报表数据。

  CAT有个很大的优点就是处理的实时性，CAT里大部分系统是分钟级统计。

  CAT主要提供的报表有：

1. Transaction报表：

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

2. Event报表：

   主要是监控一行代码/一个事件运行次数，如：程序中某个事件运行了多少次、错误了多少次等。Event报表的总体结构与Transaction报表几乎同样，只缺乏响应时间的统计。

3. Problem报表：

   主要是统计项目在运行过程当中出现的问题，根据Transaction与Event的数据分析出来系统可能出现的异常，好比访问较慢等。

4. Heartbeat报表：

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

5. Business报表：

   业务监控报表，如订单指标、支付数据等业务指标。

• Open Zipkin

  Zipkin由Twitter开源，支持的语言很是多，基于 Google Dapper 的论文设计而来，国内外不少公司都在用，文档资料也很丰富。在上面讲原理的环节已经介绍过了Zipkin，这里就不赘述了，下面是示例图：

• Naver Pinpoint

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

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

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

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

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

 

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