spring cloud 分布式链路跟踪(集成zipkin)

标签：base   href   auto   来讲   地址   configure   gap   html   kpi   

篇写了分布式链路追踪  spring cloud 分布式链路追踪

这样的链路追踪虽然可以解决问题 但日志太过于分散 如果微服务过多 就会变的相当复杂

zipkin就可以帮我们把链路调用的过程全部收集起来

它就像注册中心一样 分为客户端和服务端 想要使用 首先建一个模块 当作他的服务端

首先添加如下依赖

compile ‘io.zipkin.java:zipkin-server‘
compile ‘io.zipkin.java:zipkin-autoconfigure-ui‘

在配置文件中配置它的端口号以及项目名

server:
  port: 9999
spring:
  application:
    name: zikpin-server

然后在他的启动类加上@EnableZipkinServer

@EnableZipkinServer
@SpringBootApplication
public class ZikpinServerProvider {

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

它就表示这个是Zipkin的服务端

之后需要在客户端也加入依赖

    compile group: ‘org.springframework.cloud‘, name: ‘spring-cloud-sleuth-zipkin‘

在客户端进行配置

spring: 
    zipkin:
        base-url: http://localhost:9999 #代表zipkin服务端的地址
    sleuth:
        sampler:
           percentage: 1.0  #代表提交链路到zipkin的频率 下面细讲

运行localhost:9999 

 可以看到这个页面 这个就是zipkin的主页面 他就可以非常具体形象的体现出微服务之间的链路及他们的调用 还有耗费的时间、性能等

我们运行一个方法 用微服务调用另一个微服务试一下 如果对这个不会 可以查看我之前的一篇 spring cloud eureka 微服务之间的调用

然后选择时间 进行查询 可以看到

已经看到我们这次请求调用了两个微服务 

我们也可以在右上角 根据id查找调用链 来根据请求的id来查找 需要引入sleuth 

具体可以参考我的一篇博客 spring cloud 分布式链路追踪

然后来讲一讲上面的

 sleuth:
        sampler:
           percentage: 1.0

后面的值可以输入0.1-1.0之间 代表百分之多少

它的意思就是 有百分之多少的请求会上传到zipkin 就比如我们百分之五十 那就上传了一次 第二次就不上传 只通过日志的形式显示

为什么要用这个东西呢 

我们微服务之间进行调用 本来就有耗费的资源以及限制 因为要调用另外一个微服务 现在还需要上传到zipkin 那就非常影响性能

如果上传到zipkin需要三十秒 那么微服务就什么都不能做 必须等这三十秒之后才能做别的事情 所以如果上传量特别大的话 可以仅上传一些作为采样

也可以把链路信息上传到消息队列中 这样就可以解耦合 对效率不会有影响 然后zipkin再从消息队列进行下载 可以用kafka之类的 这个我以后会另外再写一篇博客细讲

以上就是集成了zipkin的分布式链路跟踪

spring cloud 分布式链路跟踪(集成zipkin)

标签：base   href   auto   来讲   地址   configure   gap   html   kpi   

原文地址：https://www.cnblogs.com/wangkee/p/9306408.html