原文:https://blog.csdn.net/hubo_88/article/details/80878632

在微服务系统中,随着业务的发展,系统会变得越来越大,那么各个服务之间的调用关系也就变得越来越复杂。一个 HTTP 请求会调用多个不同的微服务来处理返回最后的结果,在这个调用过程中,可能会因为某个服务出现网络延迟过高或发送错误导致请求失败,这个时候,对请求调用的监控就显得尤为重要了。Spring Cloud Sleuth 提供了分布式服务链路监控的解决方案。下面介绍 Spring Cloud Sleuth 整合 Zipkin 的解决方案。

(一)简介
Zipkin 是 Twitter 的一个开源项目,它基于 Google Dapper 实现的。我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的 REST API 接口来辅助查询跟踪数据以实现对分布式系统的监控程序,从而及时发现系统中出现的延迟过高问题。除了面向开发的 API 接口之外,它还提供了方便的 UI 组件来帮助我们直观地搜索跟踪信息和分析请求链路明细,比如可以查询某段时间内各用户请求的处理时间等。

Zipkin 和 Config 结构类似,分为服务端 Server,客户端 Client,客户端就是各个微服务应用。

(二)搭建 Zipkin 服务端
在 Spring Boot 2.0 版本之后,官方已不推荐自己搭建定制了,而是直接提供了编译好的 jar 包。详情可以查看官网:https://zipkin.io/pages/quickstart.html

可以在终端使用以下命令:

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar
使用 docker 的方式

docker run -d -p 9411:9411 openzipkin/zipkin
任一方式启动后,访问 http://localhost:9411,可以看到服务端已经搭建成功

(三)搭建 Zipkin 客户端
创建两个服务,spring-cloud-service1、spring-cloud-service2,service1 实现一个 REST 接口 /service1,该接口里调用 service2 应用。

3.1 创建 spring-cloud-service1
3.1.1 引入依赖,pom 文件:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>spring-cloud-componets</artifactId>
<groupId>com.geny</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>

<artifactId>spring-cloud-service1</artifactId>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
3.1.2 配置文件:
server:
port: 8481
spring:
application:
name: service1
zipkin:
base-url: http://192.168.174.128:9411/
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
logging:
level:
root: debug
3.1.3 启动类
@SpringBootApplication
@EnableEurekaClient
@RestController
public class Service1Application {

public static void main(String[] args) {
SpringApplication.run(Service1Application.class,args);
}

@Bean
@LoadBalanced
RestTemplate restTemplate() {
return new RestTemplate();
}

@RequestMapping(value = "service1", method = RequestMethod.GET)
public String service1() {
return restTemplate().getForObject("http://service2/service2", String.class);
}
}
3.2 创建 spring-cloud-service2
service2 的 pom.xml 文件、配置文件是一样的,只需要修改相应的端口和应用名称即可。

启动类如下:

@SpringBootApplication
@EnableEurekaClient
@RestController
public class Service2Application {

public static void main(String[] args) {
SpringApplication.run(Service2Application.class,args);
}

@RequestMapping(value = "service2", method = RequestMethod.GET)
public String service2() {
return "Hi,I'm Service2!";
}
}
3.3 验证
依次启动 eureka-server、spring-cloud-service1、spring-cloud-service2,访问 http://localhost:8481/service1

接口访问已经成功,此时,我们查看一下控制台的日志输出:

从上面的控制台输出内容中,我们可以看到多了一些如 [service1,450165b378a38236,92377ff04d8a9cfb,false] 的日志信息,而这些元素正是实现分布式服务跟踪的重要组成部分,每个值的含义如下:

第一个值:service1,它记录了应用的名称
第二个值:450165b378a38236,是 Spring Cloud Sleuth 生成的一个 ID,称为 Trace ID,它用来标识一条请求链路。一条请求链路中包含一个 Trace ID,多个 Span ID。
第三个值:92377ff04d8a9cfb,是 Spring Cloud Sleuth 生成的另外一个 ID,称为 Span ID,它表示一个基本的工作单元,比如发送一个 HTTP 请求。
第四个值:false,它表示是否要将该信息输出到 Zipkin Server 中来收集和展示。
上面四个值中的 Trace ID 和 Span ID 是 Spring Cloud Sleuth 实现分布式服务跟踪的核心。在一次请求中,会保持并传递同一个 Trance ID,从而将整个fenbu分布于不同微服务进程中的请求跟踪信息串联起来。

下面我们访问 Zipkin Server 端,http://192.168.174.128:9411/

发现服务名下并没有看到我们的应用,这是为什么呢?

这是因为 Spring Cloud Sleuth 采用了抽样收集的方式来为跟踪信息打上收集标记,也就是上面看到的第四个值。为什么要使用抽样收集呢?理论上应该是收集的跟踪信息越多越好,可以更好的反映出系统的实际运行情况,但是在高并发的分布式系统运行时,大量请求调用会产生海量的跟踪日志信息,如果过多的收集,会对系统性能造成一定的影响,所以 Spring Cloud Sleuth 采用了抽样收集的方式。

既然如此,那么我们就需要把上面第四个值改为 true,开发过程中,我们一般都是收集全部信息。

Sleuth 默认采样算法的实现是 Reservoir sampling,具体的实现类是 PercentageBasedSampler,默认的采样比例为: 0.1,即 10%。我们可以通过 spring.sleuth.sampler.probability 来设置,所设置的值介于 0 到 1 之间,1 则表示全部采集

修改配置文件如下:

server:
port: 8481
spring:
application:
name: service1
zipkin:
base-url: http://192.168.174.128:9411/
  sleuth:
sampler:
probability: 1.0
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
logging:
level:
root: debug
再次启动 spring-cloud-service1、spring-cloud-service2,访问 http://localhost:8481/service1

查看后台日志:

这个时候,第四个值已经为true了,再访问 http://192.168.174.128:9411/

可以看到已经有我们的服务调用记录了

选择 service1,点击 Find Trances,可以看到我们的服务调用记录

点击记录就可以清楚的看到我们的服务调用链路关系,可以看到每一个服务所所耗费的时间

点击依赖分析,可以看到服务之间的依赖关系

源码下载:https://github.com/shmilyah/spring-cloud-componets

Spring Cloud Sleuth + Zipkin 链路监控的更多相关文章

  1. 分布式链路追踪之Spring Cloud Sleuth+Zipkin最全教程!

    大家好,我是不才陈某~ 这是<Spring Cloud 进阶>第九篇文章,往期文章如下: 五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强? openFeign夺命连环9问,这谁受得 ...

  2. Spring Cloud Alibaba学习笔记(23) - 调用链监控工具Spring Cloud Sleuth + Zipkin

    随着业务发展,系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成,当整个请求陷入性能瓶颈或不可用时,我们是无法得知该请求是由某个或某些后端服务引起的,这时就需要解决如何 ...

  3. Spring Cloud Sleuth服务链路追踪(zipkin)(转)

    这篇文章主要讲述服务追踪组件zipkin,Spring Cloud Sleuth集成了zipkin组件. 一.简介 Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案, ...

  4. Spring Cloud(十三):Spring Cloud Sleuth服务链路追踪(zipkin)(转)

    这篇文章主要讲述服务追踪组件zipkin,Spring Cloud Sleuth集成了zipkin组件. 一.简介 Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案, ...

  5. Spring Cloud Sleuth+ZipKin+ELK服务链路追踪(七)

    序言 sleuth是spring cloud的分布式跟踪工具,主要记录链路调用数据,本身只支持内存存储,在业务量大的场景下,为拉提升系统性能也可通过http传输数据,也可换做rabbit或者kafka ...

  6. Spring Cloud 微服务六:调用链跟踪Spring cloud sleuth +zipkin

    前言:随着微服务系统的增加,服务之间的调用关系变得会非常复杂,这给运维以及排查问题带来了很大的麻烦,这时服务调用监控就显得非常重要了.spring cloud sleuth实现了对分布式服务的监控解决 ...

  7. 全链路spring cloud sleuth+zipkin

    http://blog.csdn.net/qq_15138455/article/details/72956232 版权声明:@入江之鲸 一.About ZipKin please google 二. ...

  8. Spring Cloud Sleuth Zipkin - (1)

    最近在学习spring cloud构建微服务,很多大牛都提供很多入门的例子帮助我们学习,对于我们这种英语不好的码农来说,效率着实提高不少.这两天学习到追踪微服务rest服务调用链路的问题,接触到zip ...

  9. Spring Cloud Sleuth Zipkin - (2)

    在上一节<spring-cloud-sleuth+zipkin追踪服务实现(一)>中,我们使用zipkin-server.provider.consumer三个程序实现了使用http方式进 ...

随机推荐

  1. Linux性能优化实战学习笔记:第四十九讲

    一.上节回顾 上一期,我们一起梳理了,网络时不时丢包的分析定位和优化方法.先简单回顾一下.网络丢包,通常会带来严重的性能下降,特别是对 TCP 来说,丢包通常意味着网络拥塞和重传,进而会导致网络延迟增 ...

  2. [LeetCode] 839. Similar String Groups 相似字符串组

    Two strings X and Y are similar if we can swap two letters (in different positions) of X, so that it ...

  3. [LeetCode] 904. Fruit Into Baskets 水果装入果篮

    In a row of trees, the i-th tree produces fruit with type tree[i]. You start at any tree of your cho ...

  4. Windows10 WSL下 龙芯3A 交叉编译环境搭建

    记个流水账避免事后忘记怎么搭建的 - - 环境 Key Value 系统 Windows10 WSL系统 Ubuntu 下载工具链 http://www.loongnix.org/index.php/ ...

  5. 《Linux就该这么学》培训笔记_ch02_一些必须掌握的Linux命令

    本文在原来作者的基础上做一些符合自己的修改.原文参考: <Linux就该这么学>培训笔记_ch02_一些必须掌握的Linux命令.     本章的内容虽然多,基本都是书本原话,但是笔记能精 ...

  6. Windbg断点调试.net程序

    程序员都知道,在生产环境中,如果没有系统日志,对问题的分析将非常的困难.即使有日志,有时候也会因为日志记录的不全面,而导致问题不能分析清楚.其实,Windbg里面有Live Debug功能,正好可以借 ...

  7. Redis(六)管道(Pipelining)

    管道技术并不是Redis特有的,管道技术在计算机科学中有很多地方的应用. 来自wiki的解释: In computing, a pipeline, also known as a data pipel ...

  8. v8引擎详解(摘)-- V8引擎是一个JavaScript引擎实现

    随着Web相关技术的发展,JavaScript所要承担的工作也越来越多,早就超越了“表单验证”的范畴,这就更需要快速的解析和执行JavaScript脚本.V8引擎就是为解决这一问题而生,在node中也 ...

  9. java的三种随机数生成方式

    随机数的产生在一些代码中很常用,也是我们必须要掌握的.而java中产生随机数的方法主要有三种: 第一种:new Random() 第二种:Math.random() 第三种:currentTimeMi ...

  10. Cases:Unit Testing with the MSTest Framework

    UnitTesting shanzm 右键-->在新标签页中打开图片,即可查看原图,图片超乎你想像的大! 源代码:https://github.com/shanzm/UnitTesting