springcloud 2.0 服务链路追踪踩坑以及一些小小的理解

在微服务系统中，随着业务的发展，系统会变得越来越大，这样一来各个服务之间的调用关系也就变得越来越复杂。一个 HTTP 请求会调用多个不同的服务接口来处理返回最后的结果，在这个调用过程中，可能会因为某个服务出现网络延迟或异常导致请求失败。Spring Cloud Sleuth+Zikpin可以帮助我们快速定位异常服务,跟踪请求的调用链路。

代码实现

由三个工程组成:一个zipkin-server,它的主要作用是收集调用数据，并展示；一个member-server,对外暴露一个getMember接口；一个order-server,对外暴露getOrder接口和info接口；这两个service可以相互调用

zipkin-server端:

springcloud2.0之前需要自己搭建一个Zikpin Server服务;2.0之后官方提供了完整的jar包实现这一功能,只要启动运行即可

java –jar zipkin.jar (默认端口9411)

zipkin client端:

由于zipkin默认的采用频率是0.1,测试的时候我选择设置采样频率为1;这样更方便学习

在启动类里加上如下代码,注入Bean:

  @Bean
    public Sampler defaultSampler() {
        return Sampler.ALWAYS_SAMPLE;
    }

接下来就开始踩坑了

我的请求路径是 这样的:

getOrder(order-server)---->getMember(member-server)--->info(order-server)

 

但是在zikpin的展示页面,该次请求被拆分成了两个独立的trace

这个原因目前还不清楚,代码没什么问题。后来我想着通过bean注入的方式无法实现,就尝试了配置文件去设置采样频率

由于网上比较都是使用的1.5版本搭建的服务,我一开始使用的

spring.sleuth.sampler.percentage = 1.0 ,但是一直没有生效,然后去看了springcloud官网上的设置,发现从2.0该配置变成了如下:

我在项目的配置文件中设置spring.sleuth.sampler.probability = 1.0 同时去掉了之前注入bean的代码

测试运行结果和预期比较一致

我观察了下该trace的json,通过traceId和spanId分析了下执行过程

    
                                                                              parentId                            tranceId                  spanId
order-server提供getOrder接口(server)                    null                         53a1e40ac156a71c    53a1e40ac156a71c

order-server调用getMember (client)                  53a1e40ac156a71c    53a1e40ac156a71c    10113c2e75e079c5
member-server提供getMember接口 (server)    53a1e40ac156a71c     53a1e40ac156a71c    10113c2e75e079c5

会员调用order-server info接口(client)               10113c2e75e079c5      53a1e40ac156a71c    8e210f5c7a87408a

这里链路的分析结果和我实际调用的结果一致

 

我的理解:client表示调用服务方,server表示服务提供方

比方说:这里我在order-server里调用了member-server的getMember接口,那么order-server是client ，member-server是server;

同一个服务可以既是server又是client