开发者

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

目录
    开发者_C学习
  • 前言
  • 何为调用链路
  • Zipkin + Sleuth
    • Zipkin
    • Spring Cloud Sleuth
    • Zipkin启动
    • 引入jar
    • 服务调用测试
  • 总结

    前言

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

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

    何为调用链路

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

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

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

    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解析

    Spring Cloud Sleuth

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

    Zipkin启动

    下面基于Spring Cloud Sleuth整合Zipkin

    docker run zipkin:

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

    Zipkin 启动完成

    微服务链路追踪Spring Cloud Sleuth整合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分服务

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

    Zipkin查看调用情况

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

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

    总结

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

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

    以上就是微服务链路追踪Spring Cloud Sleuth整合Zipkin解析的详细内容,更多关于Spring Cloud Sleuth整合Zipkin的资料请关python注我们其它相关文章!

    0

    上一篇:

    下一篇:

    精彩评论

    暂无评论...
    验证码 换一张
    取 消

    最新开发

    开发排行榜