Spring Cloud构建微服务架构:分布式服务跟踪(整合zipkin)【Dalston版】
通过上一篇《分布式服务跟踪(整合logstash)》,我们虽然已经能够利用ELK平台提供的收集、存储、搜索等强大功能,对跟踪信息的管理和使用已经变得非常便利。但是,在ELK平台中的数据分析维度缺少对请求链路中各阶段时间延迟的关注,很多时候我们追溯请求链路的一个原因是为了找出整个调用链路中出现延迟过高的瓶颈源,亦或是为了实现对分布式系统做延迟监控等与时间消耗相关的需求,这时候类似ELK这样的日志分析系统就显得有些乏力了。对于这样的问题,我们就可以引入Zipkin来得以轻松解决。
Zipkin简介
Zipkin是Twitter的一个开源项目,它基于Google Dapper实现。我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的API接口之外,它也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等。
上图展示了Zipkin的基础架构,它主要有4个核心组件构成:
Collector:收集器组件,它主要用于处理从外部系统发送过来的跟踪信息,将这些信息转换为Zipkin内部处理的Span格式,以支持后续的存储、分析、展示等功能。
Storage:存储组件,它主要对处理收集器接收到的跟踪信息,默认会将这些信息存储在内存中,我们也可以修改此存储策略,通过使用其他存储组件将跟踪信息存储到数据库中。
RESTful API:API组件,它主要用来提供外部访问接口。比如给客户端展示跟踪信息,或是外接系统访问以实现监控等。
Web UI:UI组件,基于API组件实现的上层应用。通过UI组件用户可以方便而有直观地查询和分析跟踪信息。
HTTP收集
在Spring Cloud Sleuth中对Zipkin的整合进行了自动化配置的封装,所以我们可以很轻松的引入和使用它,下面我们来详细介绍一下Sleuth与Zipkin的基础整合过程。主要分为两步:
第一步:搭建Zipkin Server
创建一个基础的Spring Boot应用,命名为
zipkin-server
,并在pom.xml
中引入Zipkin Server的相关依赖,具体如下:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.7.RELEASE</version>
<relativePath/>
</parent>
<dependencies>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Brixton.SR5</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
创建应用主类
ZipkinApplication
,使用@EnableZipkinServer
注解来启动Zipkin Server,具体如下:@EnableZipkinServer
@SpringBootApplication
public class ZipkinApplication {
public static void main(String[] args) {
SpringApplication.run(ZipkinApplication.class, args);
}
}
在
application.properties
中做一些简单配置,比如:设置服务端口号为9411
(客户端整合时候,自动化配置会连接9411
端口,所以在服务端设置了端口为9411
的话,客户端可以省去这个配置)。
spring.application.name=zipkin-server
server.port=9411
创建完上述工程之后,我们将其启动起来,并访问
http://localhost:9411/
,我们可以看到如下图所示的Zipkin管理页面:第二步:为应用引入和配置Zipkin服务
在完成了Zipkin Server的搭建之后,我们还需要对应用做一些配置,以实现将跟踪信息输出到Zipkin Server。我们以之前实现的
trace-1
和trace-2
为例,对它们做以下改造内容:在
trace-1
和trace-2
的pom.xml
中引入spring-cloud-sleuth-zipkin
依赖,具体如下所示。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
在
trace-1
和trace-2
的application.properties
中增加Zipkin Server的配置信息,具体如下所示(如果在zip-server
应用中,我们将其端口设置为9411
,并且均在本地调试的话,该参数也可以不配置,因为默认值就是http://localhost:9411
)。
spring.zipkin.base-url=http://localhost:9411
测试与分析
到这里我们已经完成了接入Zipkin Server的所有基本工作,我们可以继续将
eureka-server
、trace-1
和trace-2
启动起来,然后我们做一些测试实验,以对它的运行机制有一些初步的理解。我们先来向
trace-1
的接口发送几个请求:http://localhost:9101/trace-1
,当我们在日志中出现跟踪信息的最后一个值为true
的时候,说明该跟踪信息会输出给Zipkin Server,所以此时我们可以去Zipkin Server的管理页面中选择合适的查询条件后,点击FindTraces
,就可以查询出刚才在日志中出现的跟踪信息了(也可以根据日志中的Trace ID,在页面的右上角输入框中来搜索),具体如下页面所示:点击下方
trace-1
端点的跟踪信息,我们还可以得到Sleuth收集到的跟踪到详细信息,其中包括了我们关注的请求时间消耗等。点击导航栏中的
Dependencies
菜单,我们还可以查看Zipkin Server根据跟踪信息分析生成的系统请求链路依赖关系图:消息中间件收集
Spring Cloud Sleuth在整合Zipkin时,不仅实现了以HTTP的方式收集跟踪信息,还实现了通过消息中间件来对跟踪信息进行异步收集的封装。通过结合Spring Cloud Stream,我们可以非常轻松的让应用客户端将跟踪信息输出到消息中间件上,同时Zipkin服务端从消息中间件上异步地消费这些跟踪信息。
接下来,我们基于之前实现的
trace-1
和trace-2
应用以及zipkin-server
服务端做一些改造,以实现通过消息中间件来收集跟踪信息。改造的内容非常简单,只需要我们做项目依赖和配置文件做一些调整就能马上实现,下面我们分别对客户端和服务端的改造内容做详细说明:第一步:修改客户端
trace-1
和trace-2
为了让
trace-1
和trace-2
在产生跟踪信息之后,能够将抽样记录输出到消息中间件中,我们除了需要之前引入的spring-cloud-starter-sleuth
依赖之外,还需要引入zipkin对Spring Cloud Stream的扩展依赖spring-cloud-sleuth-stream
以及基于Spring Cloud Stream实现的消息中间件绑定器依赖,以使用RabbitMQ为例,我们可以加入如下依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-stream</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>
在
application.properties
配置中去掉HTTP方式实现时使用的spring.zipkin.base-url
参数,并根据实际部署情况,增加消息中间件的相关配置,比如下面这些关于RabbitMQ的配置信息:
spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=springcloud
spring.rabbitmq.password=123456
第二步:修改
zipkin-server
服务端为了让
zipkin-server
服务端能够从消息中间件中获取跟踪信息,我们只需要在pom.xml
中引入针对消息中间件收集封装的服务端依赖spring-cloud-sleuth-zipkin-stream
,同时为了支持具体使用的消息中间件,我们还需要引入针对消息中间件的绑定器实现,比如以使用RabbitMQ为例,我们可以在依赖中增加如下内容:<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
</dependency>
其中,
spring-cloud-sleuth-zipkin-stream
依赖是实现从消息中间件收集跟踪信息的核心封装,其中包含了用于整合消息中间件的核心依赖、zipkin服务端的核心依赖、以及一些其他通常会被使用的依赖(比如:用于扩展数据存储的依赖、用于支持测试的依赖等)。但是,需要注意的是这个包里并没有引入zipkin
的前端依赖zipkin-autoconfigure-ui
,为了方便使用,我们在这里也引用了它。测试与分析
在完成了上述改造内容之后,我们继续将
eureka-server
、trace-1
和trace-2
、zipkin-server
都启动起来,同时确保RabbitMQ也处于运行状态。此时,我们可以在RabbitMQ的控制页面中看到一个名为sleuth
的交换器,它就是zipkin的消息中间件收集器实现使用的默认主题。最后,我们使用之前的验证方法,通过向
trace-1
的接口发送几个请求:http://localhost:9101/trace-1
,当有被抽样收集的跟踪信息时(调试时我们可以设置AlwaysSampler
抽样机制来让每个跟踪信息都被收集),我们可以在RabbitMQ的控制页面中发现有消息被发送到了sleuth
交换器中,同时我们再到zipkin服务端的Web页面中也能够搜索到相应的跟踪信息,那么我们使用消息中间件来收集跟踪信息的任务到这里就完成了。完整示例:
读者可以根据喜好选择下面的两个仓库中查看
trace-1
和trace-2
两个项目:Github:https://github.com/dyc87112/SpringCloud-Learning/
Gitee:https://gitee.com/didispace/SpringCloud-Learning/
如果您对这些感兴趣,欢迎star、follow、收藏、转发给予支持!
本文内容部分节选自我的《Spring Cloud微服务实战》,但对依赖的Spring Boot和Spring Cloud版本做了升级。
更多内容,请点击《Spring Cloud微服务架构汇总》
推荐阅读
Spring Cloud构建微服务架构:分布式服务跟踪(跟踪原理)
Spring Cloud构建微服务架构:分布式服务跟踪(入门)
Spring Cloud Gateway真的有那么差吗?
Netflix 的上线工具 Spinnaker
长按指纹
一键关注
点击 “阅读原文” 看看本号其他精彩内容
Spring Cloud构建微服务架构:分布式服务跟踪(整合zipkin)【Dalston版】相关推荐
- Spring Cloud构建微服务架构:分布式服务跟踪(整合logstash)【Dalston版】
通过之前的<入门示例>,我们已经为两个由SpringCloud构建的微服务项目 trace-1和 trace-2引入了Spring Cloud Sleuth的基础模块 spring-clo ...
- Spring Cloud构建微服务架构:分布式服务跟踪(跟踪原理)
通过上一篇<分布式服务跟踪(入门)>的例子,我们已经通过Spring Cloud Sleuth往微服务应用中添加了实现分布式跟踪具备的基本要素.下面通过本文来详细说说实现分布式服务跟踪的一 ...
- Spring Cloud构建微服务架构:分布式配置中心【Dalston版】
Spring Cloud Config是Spring Cloud团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分.其中服务端也称为 ...
- Spring Cloud构建微服务架构:服务容错保护(Hystrix断路器)
断路器 断路器模式源于Martin Fowler的Circuit Breaker一文."断路器"本身是一种开关装置,用于在电路上保护线路过载,当线路中有电器发生短路时," ...
- Spring Cloud构建微服务架构(七)消息总线(续:Kafka)
Spring Cloud Bus除了支持RabbitMQ的自动化配置之外,还支持现在被广泛应用的Kafka.在本文中,我们将搭建一个Kafka的本地环境,并通过它来尝试使用Spring Cloud B ...
- Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)【Dalston版】
前言 在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与订阅的方式互相依赖.由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服 ...
- Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)【Dalston版】
前言 在上一篇<Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)>中,我们已经体验了如何使用@HystrixCommand来为一个依赖资源定义服务降级逻辑.实 ...
- Spring Cloud构建微服务架构:服务容错保护(Hystrix断路器)【Dalston版】
前言 在前两篇<Spring Cloud构建微服务架构:服务容错保护(Hystrix服务降级)>和<Spring Cloud构建微服务架构:服务容错保护(Hystrix依赖隔离)&g ...
- Spring Cloud构建微服务架构:Hystrix监控面板【Dalston版】
在上一篇<服务容错保护(hystrix断路器)>的介绍中,我们提到断路器是根据一段时间窗内的请求情况来判断并操作断路器的打开和关闭状态的.而这些请求情况的指标信息都是HystrixComm ...
最新文章
- 算法和编程面试题精选TOP50!(附代码+解题思路+答案)
- linux yum配置文件 yum.conf 简介
- leetcode算法题--最多的不重叠子字符串★★
- IDEA快速入门(Mac版)
- python+opencv获取最小外接矩形
- Linux——进程系列知识详述(操作系统、PCB进程控制块、查看进程状态等)
- HDU4394(数论中的广搜)
- jodconverter水印java,OpenOffice实现Office转Pdf(支持自定义添加水印、页眉、页脚)
- 【POJ - 1947】Rebuilding Roads (树形dp,背包问题,树形背包dp)
- asp net html.dropdownlist viewdata 指定选中项_ASP.NET Web API基础(05)--- 基于JWT的身份认证 - 高原秃鹫...
- VideoLan 0.8.6b test 1
- 等宽字体与非等宽字体_我最喜欢的等宽字体
- 学子商城网站的设计与实现
- 杂题 P1640 [SCOI2010]连续攻击游戏
- Win10连接上了wifi但是打开浏览器显示网络异常,诊断网络发现错误“远程计算机或者设备将不接受连接
- JVM参数-X和-XX的区别
- WebSphere概述
- Python 基础|while 循环语句
- 图像特征之SURF特征匹配
- 南理工计算机学院基础实验中心,数学实验教学中心
热门文章
- linux 崩溃文件 coredump 简介
- 分析和解密已加密的路由器固件
- 安全开发流程(SDL)
- 关于sql注入之cookie注入
- PHP的错误机制总结
- Android--相机预览及拍照临时文件/SurfaceView
- Openstack-mitakaCentos7.2双节点搭建--(一)基础服务搭建
- 单招计算机应用基础试题及答案,对口单招计算机应用基础模拟试题
- 主机电源全是黑线怎么短接_汽车胎压监测即将成为强制标准,听听老司机怎么说...
- INSTALL PARSE FAILED INCONSISTENT CERTIFICATES错误解决方法