Spring Boot + Spring Cloud 构建微服务系统(八):分布式链路追踪(Sleuth、Zipkin)

技术背景

在微服务架构中,随着业务发展,系统拆分导致系统调用链路愈发复杂,一个看似简单的前端请求可能最终需要调用很多次后端服务才能完成,那么当整个请求出现问题时,我们很难得知到底是哪个服务出了问题导致的,这时就需要解决一个问题,如何快速定位服务故障点,于是,分布式系统调用链追踪技术就此诞生了。

ZipKin

Zipkin 是一个由Twitter公司提供并开放源代码分布式的跟踪系统,它可以帮助收集服务的时间数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。

每个服务向zipkin报告定时数据,zipkin会根据调用关系通过Zipkin UI生成依赖关系图,展示了多少跟踪请求经过了哪些服务,该系统让开发者可通过一个 Web 前端轻松的收集和分析数据,例如用户每次请求服务的处理时间等,可非常方便的监测系统中存在的瓶颈。

Zipkin提供了可插拔数据存储方式:In-Memory、MySql、Cassandra以及Elasticsearch。我们可以跟根据需求选择不同的存储方式,生成环境一般都需要持久化。我们这里采用elasticsearch作为zipkin的数据存储器。

Spring Cloud Sleuth

一般而言,一个分布式服务追踪系统,主要有三部分组成:数据收集、数据存储和数据展示。

Spring Cloud Sleuth为服务之间的调用提供链路追踪,通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外,Sleuth还可以帮助我们:

耗时分析: 通过Sleuth可以很方便的了解到每个采样请求的耗时,从而分析出哪些服务调用比较耗时。

可视化错误: 对于程序未捕捉的异常,可以通过集成Zipkin服务界面上看到。

链路优化: 对于调用比较频繁的服务,可以针对这些服务实施一些优化措施。

spring cloud sleuth可以结合zipkin,将信息发送到zipkin,利用zipkin的存储来存储信息,利用zipkin ui来展示数据。

实现案例

在早前的Spring Cloud版本里是需要自建zipkin服务端的,但是从SpringCloud2.0 以后,官方已经不支持自建Server了,改成提供编译好的jar包供用户使用。
因为我用的是2.0以后的版本,自建Servcer的方式请自行百度。这里我们是使用docker方式部署zipkin服务,并采用elasticsearch作为zipkin的数据存储器。

下载镜像

此前请先安装好docker环境,使用以下命令分别拉取zipkin和elasticsearch镜像。

1docker pull openzipkin/zipkin 2docker pull docker.elastic.co/elasticsearch/elasticsearch:6.3.0

通过 docker images 查看下载镜像。

编写启动文件

创建如下文件夹结构。

1dockerfile 2 |- elasticsearch 3 | |- data 4 |- docker-compose.yml

docker-compose.yml

1version: "3" 2services: 3 4 elasticsearch: 5 image: docker.elastic.co/elasticsearch/elasticsearch:6.3.0 6 container_name: elasticsearch 7 restart: always 8 networks: 9 - elk 10 ports: 11 - "9200:9200" 12 - "9300:9300" 13 volumes: 14 - ../elasticsearch/data:/usr/share/elasticsearch/data 15 16 zipkin: 17 image: openzipkin/zipkin:latest 18 container_name: zipkin 19 restart: always 20 networks: 21 - elk 22 ports: 23 - "9411:9411" 24 environment: 25 - STORAGE_TYPE=elasticsearch 26 - ES_HOSTS=elasticsearch 27 28networks: 29 elk:

关于docker-compose.yml 文件格式及相关内容请自行百度了解。

启动服务

命令模式进入dockerfile目录,执行启动命令如下。

docker-compose up -d

执行过程如下图所示。

执行完成之后,通过 docker ps 命令查看,发现zipkin和elasticsearch确实启动起来了。

到这里,zipkin服务端就搭建起来了,访问 http://localhost:9411,效果如下,因为还没有客户端,所以还没有数据。

 

zipkin服务端已经搭建完成了,接下来我们来实现客户端。

添加依赖

修改 spring-cloud-consul-consumer 项目Maven配置,添加zipkin依赖。

pom.xml

1<dependency> 2 <groupId>org.springframework.cloud</groupId> 3 <artifactId>spring-cloud-starter-zipkin</artifactId> 4</dependency>

添加配置

修改配置文件,添加如下zipkin配置。

1spring: 2 zipkin: 3 base-url: http://localhost:9411/ 4 sleuth: 5 sampler: 6 probability: 1 #样本采集量,默认为0.1,为了测试这里修改为1,正式环境一般使用默认值。

application.yml

测试效果

先后启动注册中心、服务提供者、服务消费者。

反复访问几次 http://localhost:8521/ribbon/call,产生zipkin数据。

 

再次访问 http://localhost:9411, 发现出现了我们刚刚访问的服务,选择并点击追踪。

点击追踪之后,页面显示了相关的服务调用信息。

 

点击调用记录查看详情页面,可以看到每一个服务所耗费的时间和顺序。

源码下载

码云:https://gitee.com/liuge1988/spring-cloud-demo.git


作者:朝雨忆轻尘
出处:https://www.cnblogs.com/xifengxiaoma/
版权所有,欢迎转载,转载请注明原文作者及出处。

点赞
收藏

评论区

加载中...

相关推荐

Opentracing + Uber Jaeger 全链路灰度调用链,Nepxion Discovery

当网关和服务在实施全链路分布式灰度发布和路由时候,我们需要一款追踪系统来监控网关和服务走的是哪个灰度组,哪个灰度版本,哪个灰度区域,甚至监控从HttpHeader头部全程传递的灰度规则和路由策略。这个功能意义在于:不仅可以监控全链路中基本的调用信息,也可以监控额外的灰度信息,有助于我们判断灰度发布和路由是否执行准确,一旦有问题,也可以快速定位

APM监控

一,基础知识储备分布式跟踪的目标一个分布式系统由若干分布式服务构成,每一个请求会经过多个业务系统并留下足迹,但是这些分散的数据对于问题排查,或是流程优化都很有限,要能做到追踪每个请求的完整链路调用,收集链路调用上每个服务的性能数据,计算性能数据和比对性能指标(SLA),甚至能够再反馈到服务治理中,那么这就是分布式跟踪的目标。分布式跟踪的目的

Spring Cloud(三):服务容错保护——Spring Cloud Hystrix

  在微服务架构中,通常会出现服务不可用的现象,假设A为服务提供者,B为A服务的调用者,C、D为B服务的调用者,那么当A服务不可用之后,随着时间的推移就会导致B服务不可用,B服务的不可用可能会导致C、D服务的不可用,最终导致整个系统的不可用,为了解决这种级联失败的问题,在分布式架构中出现了断路器等一系列服务保护机制。  在SpringCloud中使用H

SpringCloud系列:利用SpringCloud Sleuth和Zipkin实现分布式服务调用链跟踪(一)

一、概述在单体应用时代,接口缓慢能够被迅速定位和发现,而随着分布式微服务的流行,服务之间的调用关系越来越复杂,错中复杂的调用关系使得我们想找到某一个接口的效率缓慢变得非常困难,而分布式服务调用跟踪组件就解决了这个问题。Sleuth是SprinCloud在分布式系统中提供追踪解决方案,zipkin是基于GoogleDapper的分布式链路调用监

Dubbo链路追踪——生成全局ID(traceId)

全局traceId关于链路追踪,在微服务的趋势下,一次调用的日志信息分布在不同的机器上或目录下,当需要看一条链路调用所有的日志信息时,这是个比较困难的地方,我们虽然有ELK,Sentry等日志异常收集分析工具,但是如何把信息串起来也是一个关键的问题。我们一般的做法是在系统调用开始时生成一个traceId,并且它伴随着一

Spring Cloud Sleuth 分布式服务追踪

随着业务的发展,系统规模也会变得越来越大,各微服务间的调用关系也变得越来越错综复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果,在复杂的微服务架构系统中,几乎每一个前端请求都会形成一条复杂的分布式服务调用链路,在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时