几个id就生成调用链拓扑图，微服务全链路监控系统5分钟弄懂_调用链路图

问题背景

在微服务架构系统中，一个应用往往被拆分多个微服务，因此一次请求就需要调用多个微服务。这些微服务可能是由不同的开发团队维护、使用不同的编程语言实现、部署在不同的机房、每个微服务部署的服务器数量差异很大（几十台到几千台）、横跨多个数据中心等，归结成一点，就是部署情况和调用情况复杂。

因此，需要一些可以帮助理解系统行为、进行性能分析的工具，以便在发生故障的时候，能够快速定位和解决问题。全链路监控就是为解决上面这些问题产生的，可参考谷歌论文（Google Dapper，
https://bigbully.github.io/Dapper-translation/）。

在微服务系统架构中，几乎每个前端请求都需要由一个复杂的分布式服务调用链处理，如下图。要想理解这类系统的行为，就需要监控那些横跨在不同微服务、不同机器间的关联动作。

在业务规模不断增大、微服务不断增多及频繁变更的情况下，复杂的调用链带来一系列问题：

1. 如何快速发现问题
2. 如何确定故障影响范围
3. 如何梳理服务依赖以及依赖的合理性
4. 如何分析链路性能以及实时容量规划

另外，我们还需要关注每个微服务调用的性能指标，例如：

1. 吞吐量，组件、平台、物理设备的吞吐量（TPS）。
2. 响应时间，整体调用的响应时间和各个微服务的响应时间。
3. 错误记录，单位时间内的异常次数。

全链路性能监控能从整体到局部展示各项指标，将跨应用的所有调用链上的性能信息集中展现，方便度量整体性能和局部性能，方便找到故障的来源，缩短故障排查时间。有了全链路监控工具，我们就能够

1. 请求链路追踪，快速定位故障。可以通过调用链结合业务日志快速定位错误信息。
2. 可视化：对各个调用阶段的进行性能分析。
3. 依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
4. 数据分析，优化链路：可以得到用户的行为路径，汇总分析业务场景。

目标要求

选择全链路监控组件有哪些要求呢，总结如下：