服务追踪 Zipkin

centos7的ip地址为172.23.105.79,拉取openzipkin/zipkin镜像，docker pull openzipkin/zipkin

构建容器，docker run -d -p 9411:9411 openzipkin/zipkin

访问一下: http://172.23.105.79:9411,出现Zipkin界面就是成功了,如果没有成功，防火墙须对端口9411开放

这是一个展示台,还需要将服务连上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://172.23.105.79:9411
  sleuth:
    sampler:
      probability: 1

在开发环境下probability可以设置为1,正式环境设置1会占带宽,流量,切记,提示一下这个配置名字官方换过一次,之前叫percentage,都是一样的,一个是几率的意思,一个是百分比的意思，正式环境一般默认0.1

分布式追踪系统

核心步骤一般有三个:

①数据采集

②数据存储

③查询展示

在数据采集过程中,由于不同服务的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

猜你喜欢