关注△mikechen的互联网架构△，10年+BAT架构经验倾囊相授
大家好，我是 mikechen | 陈睿 。
随着微服务系统拆分后，急需链路追踪有故障的服务，今天就重点讲解微服务链路追踪@mikechen
什么是微服务链路追踪
微服务链路追踪，全称是Microservices Distributed Tracing，是在分布式系统中跟踪和监控微服务间相互调用的过程的一种技术手段。
为什么用微服务链路追踪？
随着业务访问量越来越大，比如：典型的淘宝从早期的单体开始往分布式微服务演变，系统也随之进行各种拆分，看似简单的一个应用，后台可能有几十个甚至几百个服务在支撑。
一个前端的请求，比如：一次下订单请求，可能需要多次的服务调用：商品、用户、店铺等系统调用过程，最后才能完成。
当请求变慢或者不可用时，我们无法得知是哪个后台服务引起的，这时就需要解决如何快速定位服务故障点。
主要解决以下3点问题：
1.动态展示服务的链路；
2.分析服务链路的瓶颈并对其进行调优；
3.快速进行服务链路的故障发现。
微服务链路追踪有哪些？
目前市面上的链路追踪组件有：Zipkin分布式跟踪系统，以及Naver的Pinpoint、Apache的HTrace、阿AL里的鹰眼Tracing、京J东的Hydra、新X浪的Watchman，美M团点评的CAT，Skywalking等。
微服务链路追踪的原理
这里我就以Zipkin为例给大家讲解下具体的链路追踪的原理，当然，你如果用别的分布式跟踪系统，链路追踪的原理也是大同小异的。
我以Zipkin为例，谈谈链路追踪的原理。
1.ZipKin架构
ZipKin可以分为两部分：
一部分是ZipKin Server：用来作为数据的采集存储、数据分析与展示；
一部分是ZipKin Client：基于不同的语言及框架封装的一些列客户端工具，这些工具完成了追踪数据的生成与上报功能。
整体架构如下：
2.Zipkin核心组件
zipkin(服务端)包含四个组件，分别是collector、storage、search、web UI。
1)collector(信息收集器)
collector接受或者收集各个应用传输的数据。
2)storage(存储组件)
zipkin 默认直接将数据存在内存中，此外支持使用Cassandra、ElasticSearch 和 Mysql。
3)search (查询进程)
它提供了简单的JSON API来供外部调用查询。
4)web UI (服务端展示平台)
主要是提供简单的web界面，用图表将链路信息清晰地展示给开发人员。
3.Zipkin核心结构
当用户发起一次调用时，Zipkin 的客户端会在入口处为整条调用链路生成一个全局唯一的 trace id，并为这条链路中的每一次分布式调用生成一个 span id。
一个 trace 由一组 span 组成，可以看成是由 trace 为根节点，span 为若干个子节点的一棵树，如下图所示：
4.Zipkin的工作流程
一个应用的代码发起HTTP get请求，经过Trace框架拦截，大致流程如下图所示:
1）把当前调用链的Trace信息添加到HTTP Header里面；
2）记录当前调用的时间戳；
3）发送HTTP请求，把trace相关的header信息携带上；
4）调用结束之后，记录当前调用话费的时间；
5）然后把上面流程产生的 信息汇集成一个span，把这个span信息上传到zipkin的Collector模块。
以上，是微服务链路追踪原理的详细解析，欢迎评论区留言交流或拓展。
我是 mikechen | 陈睿 ，关注【mikechen的互联网架构】，10年+BAT架构技术倾囊相授。
本文已同步我的技术博客 www.mikechen.cc，更新至我原创的《30W+字大厂架构技术合集》中。
