传送门:SpringCloud版本Hoxton SR5 --- 第一讲:认识先看Sleuth、Zipkin、Elasticsearch 可以完成的功能,或者说他在项目中的定位和作用。
Sleuth比较正式的一些功能描述:(上面那篇文章也有举例说明)
spring Cloud Sleuth为 spring Cloud提供了分布式跟踪的解决方案,它大量借用了Google Dapper、 Twitter Zipkin和 Apache HTrace的设计,先来了解一下 Sleuth的术语, Sleuth借用了 Dapper的术语。span(跨度):基本工作单元。 span用一个64位的id唯一标识。除ID外,span还包含其他数据,例如描述、时间戳事件、键值对的注解(标签), spanID、span父 ID等。 span被启动和停止时,记录了时间信息。初始化 span被称为"rootspan",该 span的 id和 trace的 ID相等。trace(跟踪):一组共享"rootspan"的 span组成的树状结构称为 traceo trac也用一个64位的 ID唯一标识, trace中的所有 span都共享该 trace的 IDannotation(标注): annotation用来记录事件的存在,其中,核心annotation用来定义请求的开始和结束。CS( Client sent客户端发送):客户端发起一个请求,该 annotation描述了span的开 始。SR( server Received服务器端接收):服务器端获得请求并准备处理它。如果用 SR减去 CS时间戳,就能得到网络延迟。c)SS( server sent服务器端发送):该 annotation表明完成请求处理(当响应发回客户端时)。如果用 SS减去 SR时间戳,就能得到服务器端处理请求所需的时间。CR( Client Received客户端接收): span结束的标识。客户端成功接收到服务器端的响应。如果 CR减去 CS时间戳,就能得到从客户端发送请求到服务器响应的所需的时间
上面的这些功能,不是很理解,暂时就不说了。
先说一下,这个不是看日志的。只是可以看出微服务调用链中,哪个微服务出问题。
日志需要另一项技术:SpringCloud版本Hoxton SR5 --- 第九讲:分布式日志收集-Elasticsearch+Logstash+Kibana(ELK)
最上面的那个链接其实已经说了Sleuth 和 Zipkin分别完成的功能,这里就再详细的提一嘴:
都知道,当我们再单体项目中一台服务器跑遍整个项目,项目某个地方出了问题,可以直接Linux上看日志。但是微服务架构不行,因为相同功能的项目,可能会部署到10台服务器上,然后调用的时候,通过Ribbon负载均衡决定到底调用哪一台服务器完成调用功能。这时候如果要看日志,通常情况下,是不是A服务调B服务,但是B服务有10台服务器,你怎么知道调用的是哪台服务器?但是微服务更多呢?频繁的切换服务器查看调用失败的问题,你不吐,我都要看吐。
所以这时候出现一个技术:Spring Cloud Sleuth(链路跟踪),他有一个Trace Id,当第一个调用传入服务器的时候,他就给这个调用设置一个Trace ID,然后当这个调用继续访问其他服务器的时候,Sleuth就让这个Trace ID跟着这个调用接口传递下去,这样就能清晰的获取到每一个请求经过了哪些服务器,调用了哪些接口。
还没完,还有一个Span ID,当所有的微服务都整合了SpringCloud Sleuth之后,一个请求过来,调用到的每个服务器接口的时候都会生成一个Span ID,如果每个Span ID的生成时间相减,是不是就可以获取调用过程的时间 ?程序员就可以通过展示的时间,来判断某个接口是不是需要优化。
所以:Sleuth的作用主要就是标记请求的调用链、获取每个请求调用开始时间。
上面我们知道了每个请求的调用经过的服务器和调用的接口,还有每个调用开始的时间,但是上面仅仅是采集数据。当我们采集到数据之后,我们还需要将这些数据通过Zipkin的客户端发送给Zipkin服务端。而Zipkiin服务端拿到数据之后,就通过Trace ID开始整合,将Trace ID相同的数据整合到一起,并根据Span ID创建的时间,计算出每个服务、组件之间调用的时间,然后通过Zipkiin提供的UI界面,提供查询功能,显示出来。你以为就大功告成了 ?还没有。
作为程序员都知道,健壮性、高可用是必不可少的。Zipkin虽然整合了数据,并提供了UI界面,但是所有数据都是保存在内存中的。他没有持久化到硬盘。所以当Zipkin重启之后,所有数据都会立即清空。所以需要将这些调用链信息保存到硬盘中,这时候使用官方提供的Elasticsearch持久化保存信息。(Zipkiin整合Elasticsearch很简单,将Elasticsearch的连接地址交给Zipkini,然后启动Zipkin就好了)
到这里,几乎可以说,大功告成了,但是实际开发中,通常会用到rabbitmq、kafka这种通讯工具作为调用链。所以需要打印使用mq的调用信息,就需要Zipkin整合mq(Zipkin自己提供了整合,但是mq的连接地址、用户名、密码,你需要交给Zipkin)
现在就正式开始:
客户端:
每一个调用的需要打印调用链信息的微服务都需要做如下操作:
添加依赖:<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
每一个调用的微服务都需要在配置文件添加如下配置:
spring:##################################################### zipkin ########################################################zipkin:base-url: http://47.**.1**.61:9411/ #指定Zipkin server地址############################################### Spring cloud sleuth #################################################sleuth:sampler:probability: 1.0 #request采样的数量 默认是0.1 也即是10% 顾名思义 采取10%的请求数据 因为在分布式系统中,数据量可能会非常大,因此采样非常重要。这里暂时设置为全部采集。
好了,就这么简单。
服务端:Zipkin的服务端,官网建议直接使用它提供的jar包,或者他提供的docker镜像进行部署。
我是使用的Docker'镜像,下面的链接直接跳转Docker运行Zipkin的服务端:
Zipkin服务端部署及整合RabbitMq传送门:Docker运行Zipkin-Server、整合rabbitmq
为了将日志信息持久化,提供下面的链接:
Zipkin整合Elasticsearch传送门:docker之Elasticsearch镜像安装及运行、整合Zipkin
到这里Spring Cloud Sleuth 的使用,就完成了。