传送门

Spring Cloud Alibaba系列之nacos：(1)安装

Spring Cloud Alibaba系列之nacos：(2)单机模式支持mysql

Spring Cloud Alibaba系列之nacos：(3)服务注册发现

Spring Cloud 系列之OpenFeign：(4)集成OpenFeign

Spring Cloud 系列之OpenFeign：(5)OpenFeign的高级用法

Spring Cloud 系列之OpenFeign：(6)OpenFeign的链路追踪

Spring Cloud 系列之OpenFeign：(7)链路追踪sleuth+zipkin

sleuth属于什么类型的日志追踪系统

在Spring Cloud 系列之OpenFeign：(6)OpenFeign的链路追踪中，通过MDC实现了一个简易的链路追踪服务。如果是要自己实现链路追踪，类似借助MDC这种机制，对于单系统或相近的几个系统，技术选型范围可控，虽然需要在系统中通过编码改造也是一个不错的选择。

前面一节又演示了Spring Cloud 系列之OpenFeign：(7)链路追踪sleuth+zipkin。如果是基于SpringCloud架构，直接使用sleuth是非常方便的。sleuth负责打印收集日志，交予zipkin展示存储展示。

基于日志的追踪

不论是选择上面两种方式的哪一种，其基本原理都是基于日志打印的：基于日志的追踪思路是将 Trace、Span 等信息直接输出到应用日志中，然后随着所有节点的日志归集过程汇聚到一起，再从全局日志信息中反推出完整的调用链拓扑关系：

对于sleuth这种基于日志的追踪，有一个好处就是日志追踪对网络消息完全没有侵入性，对应用程序只有很少量的侵入性（应用配置），对性能的影响也非常低。但是也有对应的缺点：

缺点是直接依赖于日志归集过程，日志本身不追求绝对的连续与一致，这就导致了基于日志的追踪，往往不如其他两种追踪实现来的精准。
还有一个问题是，由于业务服务的调用与日志的归集并不是同时完成的，也通常不由同一个进程完成，有可能发生业务调用已经顺利结束了，但由于日志归集不及时或者精度丢失，导致日志出现延迟或缺失记录，进而产生追踪失真的情况
引用自一个完整的分布式追踪系统是什么样子的？

基于服务的追踪

除了sleuth这种基于日志的追踪，现在比较流行的还有基于服务的追踪系统，比如skywalking

服务追踪的实现思路是通过某些手段给目标应用注入追踪探针（Probe），比如针对 Java 应用，一般就是通过 Java Agent 注入的。

探针在结构上可以看作是一个寄生在目标服务身上的小型微服务系统，它一般会有自己专用的服务注册、心跳检测等功能，有专门的数据收集协议，可以把从目标系统中监控得到的服务调用信息，通过另一次独立的 HTTP 或者 RPC 请求，发送给追踪系统。

因此，基于服务的追踪会比基于日志的追踪消耗更多的资源，也具有更强的侵入性，而换来的收益就是追踪的精确性与稳定性都有所保证，不必再依靠日志归集来传输追踪数据。