当服务服务化或者微服务进行管理后，服务模块之前的调用拓扑非常的复杂。并且当每一个模块又有多个分布式集群等复杂的情况时，一个请求可能会调用后端的N多台服务，那么在追查问题的时候是非常麻烦的。一般不同的小组会负责不同的服务模块，则跨团队的协作是非常麻烦的。比如电商平台中，当一个请求进入后，api网关会根据URI会分发到不同的服务模块，比如当前调用到了订单系统，订单系统可能会去查下商品系统。我们原来的商品系统会根据业务分为好几个子系统，有的子系统还有自己的服务模块，总共商品有上百台服务器。那么在问题追踪的时候可以想象。。。（那么服务链路追踪太重要了）
一、常见的业界开源解决方案
1、Dapper（谷歌）
2、Zikpin（腾讯），与Spring Cloud Sleuth结合的比较好
3、Eagleeye（阿里）
4、pinpoint
5、skywalking
二、服务追踪原理
1、Trace
由一组Trace Id相同的Span串联形成一个树状结构。为了实现请求跟踪，当请求到达分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的标识（即TraceId），同时在分布式系统内部流转的时候，框架始终保持传递该唯一值，直到整个请求的返回。那么我们就可以使用该唯一标识将所有的请求串联起来，形成一条完整的请求链路。
2、Span
代表了一组基本的工作单元。为了统计各处理单元的延迟，当请求到达各个服务组件的时候，也通过一个唯一标识（SpanId）来标记它的开始、具体过程和结束。通过SpanId的开始和结束时间戳，就能统计该span的调用时间，除此之外，我们还可以获取如事件的名称。请求信息等元数据。
3、Annotation
用它记录一段时间内的事件，内部使用的重要注释：
cs（Client Send）客户端发出请求，开始一个请求的生命
sr（Server Received）服务端接受到请求开始进行处理， timestampSR - timestampCS = 网络延迟（服务调用的时间）
ss（Server Send）服务端处理完毕准备发送到客户端， timestampSS - timestampSR = 服务器上的请求处理时间
cr（Client Reveived）客户端接受到服务端的响应，请求结束。 timestampCR - timestampCS = 请求的总时间
三、重要概念
1、spring-cloud-sleuth-zipkin + spring-cloud-starter-sleuth 就相当于直接引入 spring-cloud-starter-zipkin
2、配置
spring.zipkin.enabled=true # 启用
spring.zipkin.base-url=http://127.0.0.1:9411/ # sleuth默认为上报为false， 现设置上报zipkin的服务地址
spring.sleuth.sampler.probability = 1 # span的采样率，默认为 0.1
spring.sleuth.sampler.rate = 10000 # 为了使用速率限制采样器，请设置spring.sleuth.sampler.rate属性以选择每秒间隔 # 接受的trace量，最小数字为0，最大值为2,147,483,647（最大int）