微服务学习之路（五）——追踪微服务调用

追踪微服务调用的背景——快速定位服务调用失败的原因。

除此还有如下几个作用：

一、优化系统瓶颈

　　通过记录调用经过的每一条链路上的耗时，快速定位整个系统的瓶颈所在，做出针对性的优化。

二、优化链路调用

　　通过服务追踪可以分析调用所经过的路径，然后评估是否合理。比如一个服务调用下游依赖了多个服务，通过链路分析，可以评估是否每个依赖都是必须的，是否可以通过优化业务来减少服务依赖。

三、生成网络拓扑

　　通过服务追踪系统中记录的链路信息，可以生成一张系统的网络拓扑调用图，反应系统依赖了哪些服务，以及服务之间的调用的关系是什么样的。在网络拓扑图上还可以把服务调用的详细信息标出来，起到服务监控作用。

四、透明传输数据

　　除了服务追踪，业务上还经常与一种需求，期望把用户数据，从调用的开始一直往下传，以便系统中各个服务都能获取到这个信息。比如业务想做一些A/B测试，这时候能通过服务追踪系统，把A/B测试的开关逻辑一直往下传递，经过的每一层服务都能获取到这个开关值，就能够统一进行A/B测试。

服务追踪系统原理

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

由此衍生出：Twitter的Zipkin、阿里的鹰眼、美团MTrace（如下图）等

　　traceId：用户标识某一次具体的请求ID。当用户的请求进入系统后，会在RPC调用网络的第一层生成一个全局唯一的traceId，并且会随着每一层的RPC调用，不断往后传递，这样通过traceId就可以把一次用户请求在系统中调用的路径串联起来。

　　spanId：用于标识一次RPC调用在分布式请求中位置。当用户的请求进入系统中，处在RPC调用网络的第一层A时spanId初始值是0，进入下一层RPC调用B的时候spanId是0.1，继续进入下一层RPC调用C时spanId时0.1.1，而与B处在同一层RPC调用E的spanId时0.2，这样的话，通过spanId就可以通过spanId就可以定位某一次RPC请求在系统调用中所处的位置，以及它的上下游依赖是谁。

　　annotation：用于业务自定义埋点数据，可以时业务感兴趣的想上传到后端的数据，比如一次请求的用户UID。

服务追踪系统的架构

 服务追踪系统架构图如上，可以分为三层

　　数据采集层——负责数据埋点并上报

　　数据处理层——负责数据的存储与计算

　　数据展示层——负责数据的图形化展示。

原文：https://www.cnblogs.com/gzhcsu/p/11411530.html