问题

在服务中,有一个接口,该A接口中又调用了其他服务的B、C、D接口,出现一个请求耗时大的问题,这时候并不知道该B、C、D接口中哪个接口造成的耗时量,然后比如确定C服务接口出现的耗时量大,但是C服务又是另个开发人员负责,通知他你的接口耗时大,于是他就去看代码,可能他的C接口又包含着D服务接口,光想着就觉得这个套路怎么这么恶心,总是需要解决的问题,靠日志输出打点方式查看某个接口的耗时也觉得low,不方便,逐步学习研究,Spring Cloud提供了相关的组件Sleuth来优化以上问题,下面做个学习笔记

链路监控 Spring Cloud Sleuth

sleuth 翻译是侦察的意思,学习了之后sleuth操作的点不多,重点在侦察,就是怎么看指标信息

maven引入依赖,结束

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

再来访问一个服务中的接口,在控制台以sleuth方式打印出相关的信息,格式如下:

...INFO [product,84189hh321,h32eh823,false] 25612-[xxxxx] xxxxx

第一个product为服务的名字

第二个TraceId, 一条链路的唯一标识,比如A中包含BCD接口,那么请求A时,BCD中出现的TraceId都一致

第三个SpanId,一个基本单元,一条链路请求中可以包含多个Spanid,可以理解成基本的工作元素,比如一个请求

第四个false,那肯定会有true,该链路的信息是否要输出到其他服务进行展示

服务之间使用feign进行通信,给feign加上日志级别,配置yml

logging:
  level:
    org.springframework.cloud.netflix.feign: debug

spring cloud正式版本配置feign的包路径有所不同,如下

logging:
  level:
    org.springframework.cloud.openfeign: debug

配置完了之后,每次请求都会打印出日志信息在控制台

还是在控制台看,这样总不好,需要一个友好的控制台一类的监控窗口,找到了一个工具---Zipkin

Zipkin

大多数组件的官网都是以io结尾,比如zipkin的官网地址:zipkin.io。 spring的官网地址: spring.io

在左侧边栏的Quickstart中,有说明几种使用方式,这边使用docker方式

不得不说这个镜像下的很吃力,试了多次才搞定,并运行他

访问一下: http://localhost:9411,出现下面界面就是成功了,功于docker

这是一个展示台,还需要将服务连上zipkin,继续套路,在maven中加入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

spring-cloud-starter-zipkin包含spring-cloud-starter-sleuth和spring-cloud-sleuth-zipkin,所以使用一个就可以,之前测试的删掉

配置yml,向zipkin展示信息,配置完就可以访问接口,在zipkin就会有相关信息

spring:
  zipkin:
    base-url: http://localhost:9411
  sleuth:
    sampler:
      probability: 1
      percentage: 1
//傻办法,如果选一个,无法暴露调用链,就换一个试试[probability,percentage]

在开发环境下probability可以设置为1,正式环境设置1会占带宽,流量,切记,提示一下这个配置名字官方换过一次,有的叫percentage,都是一样的,一个是几率的意思,一个是百分比的意思,按自己的springcloud版本来设置即可

到信息台了,就是点点点,看看看,大家都会,就不多说明了

分布式追踪系统

核心步骤一般有三个:

数据采集
数据存储
查询展示

在数据采集过程中,由于不同服务的API并不是完全兼容的,这就引起如果希望切换追踪系统,往往会有较大改动,就出现了一个OpenTracing规范,为解决不同分布式系统API不兼容的问题

OpenTracing的优势: 提供与平台无关、厂商无关的API,使开发人员更容易入手操作,比如更换追踪系统的实现

行业俗话: 一流的做标准,二流的做平台,三流的做产品

有一些产品都跟进OpenTracing标准,比如有zipkin、tracer、jaeger、grpc等等

OpenTracing的重要的概念Trace就是调用链,是通过归属该调用链的Span来定义,Trace和Span源自Google的开源项目,叫做Dapper的专业术语,还有一个术语叫Annotation,看着很熟悉,是用来即时记录一个事件,一些核心注解用来定义一个请求的开始和结束,可以理解成是Span生命周期的头尾快照,包含发生时间,事件类型等信息,事件类型有以下四种 :

cs (Client Send) : 客户端发起请求的时间
cr (Client Received) : 客户端收到处理完请求的时间
ss (Server Send) : 服务端处理完逻辑的时间
sr (Server Received) : 服务端收到调用端请求的时间

从以上可以简单的概括,其将请求的生命周期转化成四种类型,最终计算时间减一下就得出来了

客户端调用时间= cr - cs

服务端调用时间= sr - ss

在官网闲逛,发现一张图,帮助学习分析 Zipkin

这图是Zipkin的架构图,绿色部分是Zipkin四个核心的组件: Collector,Storage,API,UI;

Collector是收集组件,用于处理从外部系统发送过来的跟踪信息,然后将信息转化成可以内部处理的Span格式,用于后续的存储、分析、展示

Storage是储存,默认存在内存中,如果服务重新启动会清空历史数据,如果需要持久化储存数据,需要修改储存策略,可以存到Mysql、ES等地方

API是提供给外部访问的restful接口,比如给客户端展示跟踪信息,外部访问实现监控等等

UI是基于API实现的上层应用,通过该组件直观的查询跟踪信息,之前也测试过了,在页面上很方便的查询请求的各种信息,服务之间的依赖关系

微服务往往做着做着就越来越大,服务之间的关系也是从线条到网状结构,搞不清谁和谁有关系,这样从请求链中可以直观的体现

就学到这边,突然意识到Spring Cloud主要组件似乎已经全部走了一遍了,鸡冻,知新而温故,串着的走一套,加油

---------------------------------------------------------------

来源：oschina

链接：https://my.oschina.net/u/3829444/blog/1860535

标签

Zipkin

Spring

Spring Cloud

SpringCloud 微服务 (十六) 服务追踪 Zipkin

问题

链路监控 Spring Cloud Sleuth

Zipkin

分布式追踪系统