微服务平台之全链路追踪

前言：

随着微服务架构技术的普及和广泛在企业应用中落地，由于微服务架构本身的特性，架构由一系列相对独立的细粒度的服务组成，一个完整的业务逻辑调用请求的背后可能牵涉后端几个、几十个甚至上百个服务接口，每个服务可能是由不同的团队开发，使用了不同的编程语言，还有可能部署在不同的机器上，分布在不同的数据中心，对于这样的一个逻辑调用关系，如果在调用过程中发生问题，比如说调用失败，或者调用过程响应很慢，如何在这样一个分布式环境下快速定位问题所在、快速分析业务处理中的响应慢的瓶颈在哪？多个微服务之间存在调用关系，如何在系统运行时总览一个系统中微服务间的拓扑关系？如何完整还原一次请求的链路情况？

以上这些问题可以借助链路追踪技术进行解决。链路追踪组件通过在微服务应用中以代码侵入或者非侵入的方式进行数据表示、埋点、传递、收集、存储、展示等技术手段，达到将一次分布式请求还原成调用链路，将一次分布式请求的调用情况集中展示，比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

目录：

1.链路追踪的应用场景

2.链路追踪基本原理

3.链路追踪的Demo实现

4.普元微服务平台的链路追踪应用

1.链路追踪的应用场景

在微服务架构下，分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、分布式数据库、分布式缓存等，使得后台服务构成了一种复杂的分布式网络，这样一个场景下，对于用户的每一次请求调用，后端执行了多少组件间的调用无法知晓，由于分布式的调用，增加了程序调用异常的错误率，在这样的应用场景下，新的架构技术带来了新的问题。

场景下的关键问题

1. 如何在请求发生异常时快速定义问题所在

2. 如何在请求响应慢的时候快速找出慢的原因

3. 如何通过日志文件快速定位问题的根本原因

传统的问题排查手段

一般在系统发生问题时，比如系统异常或者系统性能出现问题时，通常都是从系统记录的日志文件中找出蛛丝马脚，而对于微服务架构下的分布式部署，日志文件的分散，想从日志中查找问题工作量很大。对于用户某一次请求调用后端哪些服务，每个服务执行情况，想从日志中获得更是不可能的事。

对于传统的监控告警平台也紧针对平台资源的监控包括cpu、内存、网络带宽情况等，对业务微服务应用的指标（平均响应时间、慢端点情况等）的监控显得无从下手。

在这样的背景下，新的监控体系下的细分领域-链路追踪问世了。

首先，我们来看看在系统监控的体系下具体的细分领域的专注点：

Logging - 用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是我们诊断问题的依据。

Metrics - 用于记录可聚合的数据。例如，队列的当前深度可被定义为一个度量值，在元素入队或出队时被更新；HTTP 请求个数可被定义为一个计数器，新请求到来时进行累加。

Tracing - 用于记录请求范围内的信息。例如，一次远程方法调用的执行过程和耗时。它是我们排查系统性能问题的利器。

2.链路追踪基本原理

在每个请求调用的入口和出口进行代码埋点记录调用之间的关系、每个调用处理时间点信息。

通过调用关系梳理出一次请求的完整链路还原、请求具体到达哪台机器。

通过每次处理记录的时间点，计算出相关的调用执行时间、响应时间、网络延时。

对调用请求量进行统计。

显示链路拓扑结构、应用依赖关系。

Trace：指一个请求经过后端所有服务的路径，每一条链路都用一个全局唯一的traceid来标识。

Span：链路中的调用由span来表示，每个span由spanid和parentid来标识，可以记录调用的父子关系。

Timestamp：调用点的时间戳，记录每个执行点的时间信息。

如果想知道一个接口在哪个环节出现了问题，就必须清楚该接口调用了哪些服务，以及调用的顺序，如果把这些服务串起来，看起来就像链条一样，我们称其为调用链。

到现在，已经知道调用顺序和层级关系了，但是接口出现问题后，还是不能找到出问题的环节，如果某个服务有问题，那个被调用执行的服务一定耗时很长，要想计算出耗时，上述的三个标识还不够，还需要加上时间戳，时间戳可以更精细一点，精确到微秒级。

只记录发起调用时的时间戳还算不出耗时，要记录下服务返回时的时间戳，有始有终才能算出时间差，既然返回的也记了，就把上述的三个标识都记一下吧，不然区分不出是谁的时间戳。

转载地址：https://cloud.tencent.com/developer/article/1688624