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

问题

在服务中,有一个接口,该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版原本设置便可

到信息台了,就是点点点,看看看,你们都会,就很少说明了

 

分布式追踪系统

核心步骤 通常有三个: 

1. 数据采集
2. 数据存储
3. 查询展现

在数据采集过程当中,因为不一样服务的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主要组件彷佛已经所有走了一遍了,鸡冻,知新而温故,串着的走一套,加油

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