springcloud入门系列——Sleuth（结合zipkin的链路追踪）

 在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的服务节点调用来协调产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延迟或错误都会引起整个请求最后的失败。

SpringCloud Sleuth提供了一套完整的服务跟踪的解决方案
在分布式系统中提供追踪解决方案并且兼容支持了zipkin

官网：https://cloud.spring.io/spring-cloud-sleuth/reference/html/

Sleuth 负责收集整理，Zipkin负责展现。

Sleuth结合zipkin搭建简单的链路追踪

1. zipkin

下载地址：
https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/
SpringCloud从F版起已不需要自己构建Zipkin Server了，只需调用jar包

cmd运行jar包：java -jar zipkin-server-2.12.9-exec.jar

后面可以通过http://localhost:9411/zipkin/去查看

链路追踪：当一个请求到返回，调用哪个接口用时多少等等都会被记录采集，所以每个服务都要配置以下部分

2、服务提供者8001、80（因为80调用8081，所以都要设置以下步骤（只要经过的服务都要布置））（这里就是要抓取链路调用的服务）

<!--包含了sleuth+zipkin-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

yml：

zipkin:
    base-url: http://localhost:9411
    sleuth:
      sampler:
        probability: 1 #介于0和1之间，1为全部都采取

两个服务都配置后访问80到8081的调用链，打开http://localhost:9411/zipkin/

选择一个服务的调用链：点击查找

出现多个调用链：

任选一个调用链进去查看：

可以看见调用链和各个调用的接口，时间等信息。涉及几个服务、深度等

 

服务追踪原理

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 = 请求的总时间 

上图是对调用链路的一些解释

         当服务服务化或者微服务进行管理后，服务模块之前的调用拓扑非常的复杂。并且当每一个模块又有多个分布式集群等复杂的情况时，一个请求可能会调用后端的N多台服务，那么在追查问题的时候是非常麻烦的。一般不同的小组会负责不同的服务模块，则跨团队的协作是非常麻烦的。比如电商平台中，当一个请求进入后，api网关会根据URI会分发到不同的服务模块，比如当前调用到了订单系统，订单系统可能会去查下商品系统。我们原来的商品系统会根据业务分为好几个子系统，有的子系统还有自己的服务模块，总共商品有上百台服务器。那么在问题追踪的时候可以想象。。。（那么服务链路追踪太重要了）

至此，seluth与zipkin的配置可以对服务的调用链路进行监控。市面上还有其他解决方案，如：

1、Dapper（谷歌）

2、Zikpin，与Spring Cloud Sleuth结合的比较好

3、Eagleeye（阿里）

4、pinpoint

5、skywalking（后面会用SkyWalking Agent APM 搭建一个链路追踪平台）

（这里的netfix组件中不再讲config+bus作为配置中心，因为现在市面比较火热的是Apollo和nacos作为配置中心。stream组件也不讲了，它只支持rabbitmq和kafka，而现在的apache rocketmq是一个非常6的中间件）

下篇讲alibaba的nacos