服务追踪的作用

服务追踪系统原理

服务追踪系统的鼻祖，Google 发布的一篇的论文 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure。

核心理念就是调用链：通过一个全局唯一的 ID 将分布在各个服务节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。

可以说后面的诞生各种服务追踪系统都是基于 Dapper 衍生出来的，比较有名的有 Twitter 的 Zipkin、阿里的鹰眼、美团的 MTrace 等。

应该将整个请求链路看成树状或图状.

服务追踪系统可以分为三层：

数据埋点的流程：

以红色方框里圈出的 A 调用 B 的过程为例，一次 RPC 请求可以分为四个阶段：

CS（Client Send）阶段 : 客户端发起请求，并生成调用的上下文。
SR（Server Recieve）阶段 : 服务端接收请求，并生成上下文。
SS（Server Send）阶段 : 服务端返回请求，这个阶段会将服务端上下文数据上报，下面这张图可以说明上报的数据有：traceId=123456，spanId=0.1，appKey=B，method=B.method，start=103，duration=38。
CR（Client Recieve）阶段 : 客户端接收返回结果，这个阶段会将客户端上下文数据上报，上报的数据有：traceid=123456，spanId=0.1，appKey=A，method=B.method，start=103，duration=38。