「コールチェーンモニターは、」唯一のマイクロ監視サービスの台頭と新しいパンデミックのいくつかのモデルの後です。私たちの伝統的な1つのプロジェクトのアプリケーションでは、サービスチェーン/コールチェーンの概念が存在しないため、そのコールを監視全くデマンドチェーンはありません。
我々は分散型になって私たちのサービスの多く、およびサービス、マイクロサービスアーキテクチャを開始し、我々は、分割後に分割していたときに、ユーザの要求が来て、順番に処理するために別のサービスノードを通過します、処理は完了ですその後、ユーザーに結果を返します。次いで、全体の処理チェーン、いずれかのノード遅延や問題がある場合、最終的な結果につながる可能性があるが、時には異なるサービスノードは、異なるチームによって開発され、異なるサーバに異常展開されています、その後、このような複雑な環境の中で、我々は特定のチェーンは、サービスノードに問題があるあるトラブルシューティングするには、容易ではありません。
だから我々は、ログチェーンをクリアすることができます、ちょうどこのコールの調査に行くと、異常事態を呼び出すように要求した場合のように完全なコールチェーンの監視システムを形成し、各ノードを通過します。この要求は記録されている、方法を考えましたどこエラーのリンクを表示します。
まず、なぜ「コールチェーンの監視」する必要がありますか？
「コールチェーンの監視は、」マイクロアーキテクチャの部分で非常に重要なサービスです。また、それは私たちが外で問題を見つけやすくするだけでなく、メンバーが明確にプロジェクトの展開構造を理解投影することができ、結局、マイクロサービスの数百には、私は長い時間を実行した後、プロジェクトの構造は、おそらく下の写真の場合であると信じていますこの場合には、開発チームとさえアーキテクトは、必ずしもプロジェクトのネットワーク構造の非常に明確な理解を持って、ましてやシステムを最適化していません。
まあ、私はそう多くは、私たちは「コールチェーンの監視」役割で、以下の具体的な外観に来たことを特徴とします。
-
プロジェクトネットワークトポロジ：
私たちは、ネットワークトポロジマップの呼び出しを生成するためのプロジェクトに記録された情報「コールチェーンの監視」をリンクすることができます。この写真では、我々は、各サービスのシステムコールとの関係が似ている知ることができ、どのようなシステムでは、サービスに依存しています。そしてまた、グローバルサービスの監視において役割を果たし得る、簡単なシステムアーキテクトの状態を把握します。
-
迅速に問題を探します。
この効果は、複数のサービスノードを経由して要求は、そのようなコールチェーンの監視システムは、開発者が問題を迅速に見つけることができますがあり、問題は非常に複雑になる見つけマイクロサービスアーキテクチャの下で、それ以前の話をされましたおよび対応するモジュール。
-
最適化システム：
优化系统也是「调用链监控」很重要的一个功能。因为我们记录了请求在调用链上每一个环节的信息，我们就可以通过这个来找出系统的瓶颈，做出针对性的优化。还可以分析这个调用路径是否合理，是否调用了不必要的服务节点，是否有更近、响应更快的服务节点。通过对调用链路的分析，我们就可以找出最优质的调用路径，从而提高系统的性能。
-
提高团队成员自律：
上面都是系统层面的作用。但如果有了「调用链监控」之后，对团队开发人员的帮助也是非常大的。因为团队所有成员都可以通过这个调用链监控系统看到系统各个模块的状态，相当于给了开发同学一个放大镜，以前开发同学完成项目交付后，只要没有出现问题，可能不太关心系统的优化，但是有这个调用链监控系统之后，哪个模块性能高，哪个模块问题大，一眼就能分辨，通过这么一个看板，开发同学慢慢的也会对自己负责的模块有更多的责任感，也会很自觉的去优化自己的模块。这种习惯的养成，对研发团队而言，非常的重要。
二、「 调用链监控」的原理？
在调用链监控系统中，有几个核心概念需要了解：
-
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主要提供的报表有：
-
Transaction报表：
主要是监控一段代码运行情况，如：运行次数、QPS、错误次数、失败率、响应时间等。
-
Event报表：
主要是监控一行代码/一个事件运行次数，如：程序中某个事件运行了多少次、错误了多少次等。Event报表的整体结构与Transaction报表几乎一样，只缺少响应时间的统计。
-
Problem报表：
主要是统计项目在运行过程中出现的问题，根据Transaction与Event的数据分析出来系统可能出现的异常，比如访问较慢等。
-
Heartbeat报表：
以一分钟为周期，定期向服务端汇报当前运行的一些状态，如：JVM状态、Memory、Thread等。
-
Business报表：
业务监控报表，如订单指标、支付数据等业务指标。
-
Open Zipkin
Zipkin由Twitter开源，支持的语言非常多，基于 Google Dapper 的论文设计而来，国内外很多公司都在用，文档资料也很丰富。在上面讲原理的环节已经介绍过了Zipkin，这里就不赘述了，下面是示例图：
-
Naver Pinpoint
Pinpoint中的服务关系依赖图做得非常棒，超出市面上任何一款产品。另外，Pinpoint因为采用字节码增强方式去埋点，所以在埋点的时候是不需要修改业务代码的，非侵入式的，非常适合项目已经完成之后再增加调用链监控的时候去使用的方案。但是也是由于采用字节码增强的方式，所以它目前仅支持JAVA语言。
以上，就是对微服务架构中「 调用链监控」的一些思考。
在微服务架构的系列文章中，前面已经通过文章介绍过了「服务注册 」、「服务网关 」、「配置中心 」、「 监控系统 」，大家可以翻阅历史文章查看。
另外，为了方便小伙伴们交流微服务架构相关的技术，我创建了一个「 聊聊架构与微服务 」的交流群。
添加微信后拉你进群：WH-IT-er，加微信时备注：微服务加群
本文原创发布于微信公众号「 不止思考 」，欢迎关注。涉及 思维认知、个人成长、架构、大数据、Web技术 等。
