问题背景
在微服务架构系统中,一个应用往往被拆分多个微服务,因此一次请求就需要调用多个微服务。这些微服务可能是由不同的开发团队维护、使用不同的编程语言实现、部署在不同的机房、每个微服务部署的服务器数量差异很大(几十台到几千台)、横跨多个数据中心等,归结成一点,就是部署情况和调用情况复杂。
因此,需要一些可以帮助理解系统行为、进行性能分析的工具,以便在发生故障的时候,能够快速定位和解决问题。全链路监控就是为解决上面这些问题产生的,可参考谷歌论文(Google Dapper,
https://bigbully.github.io/Dapper-translation/)。
在微服务系统架构中,几乎每个前端请求都需要由一个复杂的分布式服务调用链处理,如下图。要想理解这类系统的行为,就需要监控那些横跨在不同微服务、不同机器间的关联动作。
在业务规模不断增大、微服务不断增多及频繁变更的情况下,复杂的调用链带来一系列问题:
- 如何快速发现问题
- 如何确定故障影响范围
- 如何梳理服务依赖以及依赖的合理性
- 如何分析链路性能以及实时容量规划
另外,我们还需要关注每个微服务调用的性能指标,例如:
- 吞吐量,组件、平台、物理设备的吞吐量(TPS)。
- 响应时间,整体调用的响应时间和各个微服务的响应时间。
- 错误记录,单位时间内的异常次数。
全链路性能监控能从整体到局部展示各项指标,将跨应用的所有调用链上的性能信息集中展现,方便度量整体性能和局部性能,方便找到故障的来源,缩短故障排查时间。有了全链路监控工具,我们就能够
- 请求链路追踪,快速定位故障。可以通过调用链结合业务日志快速定位错误信息。
- 可视化:对各个调用阶段的进行性能分析。
- 依赖优化:各个调用环节的可用性、梳理服务依赖关系以及优化。
- 数据分析,优化链路:可以得到用户的行为路径,汇总分析业务场景。
目标要求
选择全链路监控组件有哪些要求呢,总结如下: