微服务架构之分布式追踪(Zipkin)

　　在微服务架构中，由于服务之间做了拆分，一次请求往往要涉及多个服务的调用，不同的服务可能由不同的团队开发，使用不同的编程语言，还有可能部署在不同的机器上，分布在不同的数据中心。当请求出现异常问题时，我们需要知道本次请求调用了哪些服务，又是哪个服务引起的错误，如果靠人肉的方式，到每个服务去查找代码，查看日志，那么无疑是十分痛苦的，这时候分布式追踪系统应运而生。

服务追踪的作用

　　除了能够快速定位请求失败的原因之外，服务追踪系统还需要记录调用经过的每一条链路上的耗时，这样在我们分析追踪数据时，就可以快速定位系统的瓶颈在哪里，针对耗时较长的链路，做出针对性的优化。通过追踪系统的链路可视化功能，可以更直观的看到请求的调用链路，及服务之间的依赖关系，我们可以凭此评估链路的调用是否合理，优化链路调用。同时链路追踪系统大多都集成了 生成系统调用关系网络拓扑的功能，它可以将整套系统间的服务调用关系完整的，直观的展示出来，通过网络拓扑可以更好的优化系统架构，找出系统层级间不合理的地方。

服务追踪的原理

　　要理解服务追踪的原理，首先必须搞懂一些基本概念：traceId、spanId、annonation 等。

• 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 就可以定位某一次 RPC 请求在系统调用中所处的位置，以及它的上下游依赖分别是谁。
• annotation：用于业务自定义埋点数据，可以是业务感兴趣的想上传到后端的数据，比如一次请求的用户 UID。

　　简单的总结一下，traceId 是用于串联某一次请求在系统中经过的所有路径，spanId 是用于区分系统不同服务之间调用的先后关系，而 annotation 是用于业务自定义一些自己感兴趣的数据，在上传 traceId 和 spanId 这些基本信息之外，添加一些自己感兴趣的信息。