skywalking微服务架构无法自动追踪sql 微服务追踪与监控

　　这篇随笔我们学习目标是通过整合Spring Cloud Sleuth+Zipkin搭建我们分布式跟踪系统。微服务对比单体服务存在很多优势，但也有弊端的地方，比如性能监控，构建部署等等，服务治理工作好坏，是衡量一个微服务架构好坏的关键。试想下这样的一个场景，当你系统拥有上百个微服务应用，并且一个请求过来获取需要经过几十个微服务才能返回结果，如果有天突然一个请求超时了，你该如何分析这个请求超时问题出现在哪个节点呢？这时候如果有一套完整分布式服务跟踪系统，要分析这个场景就容易多了。它能对对微服务各个节点服务调用跟踪，监控分析请求在每个节点好性能情况。是服务治理的重要的一环节。

　　下图是我为了这次学习构造的一个调用链场景，通过这例子去学习搭建我们的分布式服务跟踪系统。

　　注册中心： 高可用的双Eureka做注册中心

　　WebA : 重用之前随笔的WebA微服务实例，对外暴露/web/hello接口

　　ServiceA: 重用之前随笔的ServiceA微服务实例，这里为了简单只使用单实例。WebA实例的/web/hello接口将会调用此服务，形成一条简单的调用链。

　　Zipkin  : Zipkin是Twitter开源项目，Sleuth通过整合Zipkin收集各个服务请求链路上的跟踪数据，它不仅提供了可视化的界面查看每个调用链情况，还提供了REST API接口给我们根据自身业务开发一些功能。

　　Kafka : Zipkin支持各个服务通过http请求把跟踪数据发送给它，但实际场景中我们希望中间使用个中间件(比如Kafka)接受所有跟踪数据，然后Zipkin去消费这些数据，避免直接访问对Zipkin造成压力。

　　WebA、ServiceA、Kafka在之前的随笔已经有搭建过了，不作详细说明。

　　　　　　　　　　　　　　

 

一、 搭建ZipKin Server

　　pom.xml添加依赖。spring-cloud-sleuth-zipkin-stream帮我们封装了需要使用中间件的依赖，同时为了能使用具体中间件Kafka，我们还需要引入对应的绑定器。

<dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-stream-kafka</artifactId>
        </dependency>
        <dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-autoconfigure-ui</artifactId>
        </dependency>
    </dependencies>

 　　

application.properties

spring.application.name=zipkin-server
server.port=9411
eureka.client.serviceUrl.defaultZone=http://localhost:5001/eureka/,http://localhost:5002/eureka/

 

启动类。注意这里我们要支持Kafka,所以需要@EnableZipkinStreamServer，别加错了。

package com.pumkpin;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.sleuth.zipkin.stream.EnableZipkinStreamServer;

@EnableZipkinStreamServer
@SpringBootApplication
public class Application {

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

 

二、WebA、ServiceA改动

这里做的改动主要是让WebA、ServiceA能把请求的跟踪数据上报到Kafka , Zipkin会作为消费者去消费这些数据，通过分析、整合，最终把整个调用链和依赖关系通过可视化界面呈现出来。

改动的地方很小，只需要添加对应的依赖即可，因为我们这里使用的中间件是Kafka，如果我们的Kafka是使用默认配置的话(端口9092),spring-cloud-starter-stream-kafka依赖有默认的自动化配置(详情看上一篇随笔)，也就是说我们服务不需要添加额外配置也可以连接上。　

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-stream</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-stream-kafka</artifactId>
        </dependency>

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

 

 三、运行

　　首先启动按照上一篇随笔的方法启动kafka。然后依次启动Eureka、WebA、ServiceA、Zipkin Server。

　　访问：http://localhost:9411。可以看到Zipkin Server可视化界面。

　　

　　访问WebA的接口.http://localhost:8080/web/hello.可以看到如下输出。整合了Spring Cloud Sleuth看到日志输入格式变了。日志前面多了

　　[web-a,768620d770881e5f,67943247a8d2a237,true]，其中依次表示的请求的服务名、Sleuth生成Trace ID、Sleuth生成Span ID、最后一个ture/false表示是否将该信息上报到Zipkin，默认Zikpin是采取抽样策略的，所以并不是每个请求的跟踪信息都会上报到Zikpin。Trace ID 和 Span ID都是Sleuth生成的，这些ID是用于生成调用链的重要元素。

　　

　　另外，如果Kafka使用的版本是上一篇随笔版本kafka_2.10-0.10.0.1，可能在WebA服务控制台下会看到如下异常。这些因为我学习的Spring Cloud依赖Kafka客户端版本是kafka_2.10-0.8.2.2造成。不过我该异常并不会影响到正常使用，就是会经常出现这个异常日志，十分烦人。解决方法很简单要么升级Spring Cloud 依赖Kafka Stream的版本，要么使用低版本的kafka_2.10-0.8.2.2,我使用了后者的方法确实能解决该问题。

　　

　　最后我们在打开Zipkin的界面，根据条件筛选，然后查询出请求的详细调用链情况、接口耗时、依赖关系等。

 

　　

 

四、总结

　　这是Spring Cloud 学习系列的最后一篇随笔。通过这几篇随笔总算对Spring Cloud有了一个大概的认识。同时可以看到Spring Cloud的入门其实是比较简单的, 但如果要应用于生产环境就要考虑更多东西，比方说这个分布式跟踪系统就是必须的，还要之前每一篇随笔的内容都需要更加深入认识，才能投入使用。同时在结束这个系列后，就可以多看看贴近生产级别的最佳实践了。

 

五、参考资料

Spring Cloud微服务实战-翟永超。本系列的学习都是参考该书籍学习的，同时源码使用的Spring Boot和Spring Cloud的版本也与该书保持一致。