微服务链路追踪Spring Cloud Sleuth整合Zipkin解析

前言

如果在开发过程中，你还在靠查看服务器日志来寻找服务与服务之间的报错信息，那么这篇一定要来看下，通常在我们开发环境自测的时候，我们会将代码发布到开发环境，然后无论是通过postMan请求，还是通过页面请求，遇到报错的信息，我们都会去服务器上去看时实的日志，来寻找报错信息；

如果涉及到多个服务调用，这个时候会登陆多个服务器去查看服务的报错信息，这仅仅是在我们开发环境自测的时候我们会去这么操作；如果是在生产环境，还依靠这种方式，那么多少就会显得比较low了，这时候我们就要快速的定位到故障服务，就要引入“服务调用链路”的概念。

何为调用链路

一个大型分布式微服务系统往往由若干个微服务组成，这些微服务部署在若干个服务器上，为了实现高可用还会采取集群的方式，若干个服务相互调用就形成了调用链网络。

服务之间的调用出现异常、超时、宕机，某一个服务出现这样的情况，都会导致整个调用链路出现问题， 在出现这样问题的时候就要及时的解决，来避免整个业务系统的不可用，这个时候就必须快速定位问题。

Zipkin + Sleuth

作为为微服务提供调用链路支持的其实有很多组件，包括SkyWalking、CAT、Pinpoint、Zipkin + Sleuth，这些组件的实现方式、接入方式、颗粒度、traceid查询等方面可能有不同，但是最终目的其实都一样，就是把请求的链路记录下来供开发人员排错参考，这里我因为我项目使用的是Spring Cloud，协议也是使用的http，所选择的是 Spring Cloud Sleuth更加匹配项目，集成也相对容易。

Zipkin

Zipkin分布式追踪系统，简单的说在一个西瓜摊，里面的瓜有大有小、有熟有生、有好有坏，所有的瓜都混杂在一起，我们很难去找到比较合适的瓜买走， Zipkin所做的就是追踪分析，找到好的瓜，然后将坏的瓜卖不出去的瓜进行剔除。

这离涉及到几个概念，也是链路追踪的核心。

• Traceld：用来标记服务调用链的标记，包括所有在请求链中的服务，都使用的一个链路追踪ID
• SpanId：区域ID，调用链中某个服务的专属ID，无论是调用者和被调用者都会产生自己的SpanId
• ParentId：父级ID，调用者的生成的SpanId，在去请求下游服务，SpanId会成为下游服务的ParentId，用来标记上下游的关系。

Spring Cloud Sleuth

可以理解为基于Zipkin的一个封装，sleuth可以记录调用的情况，而Zipkin可以收集这些调用信息。

Zipkin启动

下面基于Spring Cloud Sleuth整合Zipkin

docker run zipkin：

docker run -d  -p 9411:9411 openzipkin/zipkin

Zipkin 启动完成

引入jar

使用的框架版本 spring-cloud.version：Hoxton.SR4 spring-boot.version：2.2.6.RELEASE

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

引入sleuth和zipkin，nacos配置

sleuth:
    enabled: true
    sampler:
      rate: 100
 # 设置 Sleuth 收集信息的百分比
zipkin:
    sender:
      type: web
    base-url: http://127.0.0.1:9411/

⚠️ zipkin:sender:type: web （这里type类型可以支持多种，web、kafka、rabbit、activemq都可以支持），这里只做web类型的演示。

服务调用测试

System2 服务提供feig接口，供system服务调用

@FeignClient(contextId = "iTestServiceClient", value = "Lxlxxx-system2", fallbackFactory = TestServiceFallbackFactory.class)
public interface ITestServiceClient {
    /**
     * 服务调用测试方法
     * @return
     */
    @GetMapping("/test/method")
    public String testRequestMethod();
}

system服务调System2的feign接口

@RestController
@Slf4j
public class TestController {
    @Autowired
    private ITestServiceClient iTestServiceClient;
    @GetMapping("/testMethod")
    public void testMethod(){
        log.info("通过feign调用system2服务～～～～～～～～～");
        iTestServiceClient.testRequestMethod();
    }
}

我这边注册了两个服务 分别是Lxlxxx-system 和 Lxlxxx-system2分服务

Zipkin查看调用情况

总结

由上面可见，可以很清楚的看出微服务之间的调用情况，当然这些调用的日志也是可以通过ES进行持久化的，这样可以保证Zipkin重启后，链路信息不会丢失，这里就不做展示了，有兴趣的朋友也可以将ES集成进去。

当然，Spring Cloud Sleuth 结合 Zipkin不光可以对微服务进行追踪，如果请求量较大也可以集成消息中间件，Sleuth将日志推给MQ，然后Zipkin去MQ队列获取服务调用日志，可以调用链在我们对服务监控、排查问题，起到了至关重要的作用。

以上就是微服务链路追踪Spring Cloud Sleuth整合Zipkin解析的详细内容，更多关于Spring Cloud Sleuth整合Zipkin的资料请关注脚本之家其它相关文章！

最新评论