Micro-service architecture of the "call chain monitoring."

"Call chain monitor" is only after the rise of micro-monitoring services and some models of a new pandemic. Because in our traditional single project application, the concept of service chain / call chain does not exist, so there is no demand chain monitoring the call.

When we start micro-service architecture, many of our services become distributed, and service and we had to split after split, a user's request comes, will in turn go through different service nodes for processing, processing is complete and then returns the results to the user. Then the entire processing chain, if there is any one node delay or problem, are likely to lead to the final result is abnormal, sometimes even different service nodes are developed by different teams, deployed in different servers on, then in such a complex environment, we want to troubleshoot a specific chain is which service node is a problem, is not easy.

So we thought of a way, this request will go through each node are recorded, forming a complete call chain monitoring system, so in the event of a request to call abnormal situation, just go to the investigation of this call will be able to clear the log chain to see where the error link.

First, why the need to "call chain monitoring"?

"Call chain monitoring" is a very important service in the micro-architecture part. In addition it can help us locate the problem outside, but also help to project members clearly understand the project deployment structure, after all, a few hundreds of micro-services, I believe that after running a long time, the structure of the project is probably the case in the picture below in this case, development teams and even architects do not necessarily have a very clear understanding of the network structure of the project, let alone optimize the system.

Well, I said so much, we came to the following specific look at the "call chain monitoring" role in which:

1. Project Network topology:

   We can link information "call chain monitoring" recorded in the project to generate a network topology map calls. By this picture, we can know the relationship between the system call for each service is like, and what systems rely on the service. And may also play a role in monitoring global service, easy to grasp the state of the system architect.

2. Quickly locate the problem:

   This effect has been talking about earlier, under the micro-service architecture, locate the problem becomes very complex, a request may go through multiple service nodes, then there is such a call chain monitoring system will allow developers to quickly locate the problem and the corresponding module.

3. Optimization system:

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

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、错误次数、失败率、响应时间等。

   

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技术 等。