Spring Cloud Sleuth和Zipkin的基本概念

    当服务服务化或者微服务进行管理后，服务模块之前的调用拓扑非常的复杂。并且当每一个模块又有多个分布式集群等复杂的情况时，一个请求可能会调用后端的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）