Spring Cloud构建微服务架构：分布式服务跟踪（入门）【Dalston版】

经过以前的N篇博文介绍，实际上咱们已经可以经过使用它们搭建起一个基础的微服务架构系统来实现咱们的业务需求了。可是，随着业务的发展，咱们的系统规模也会变得愈来愈大，各微服务间的调用关系也变得愈来愈错综复杂。一般一个由客户端发起的请求在后端系统中会通过多个不一样的微服务调用来协同产生最后的请求结果，在复杂的微服务架构系统中，几乎每个前端请求都会造成一条复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟太高或错误的时候都有可能引发请求最后的失败。这时候对于每一个请求全链路调用的跟踪就变得愈来愈重要，经过实现对请求调用的跟踪能够帮助咱们快速的发现错误根源以及监控分析每条请求链路上的性能瓶颈等好处。

针对上面所述的分布式服务跟踪问题，Spring Cloud Sleuth提供了一套完整的解决方案。在本章中，咱们将详细介绍如何使用Spring Cloud Sleuth来为咱们的微服务架构增长分布式服务跟踪的能力。

快速入门

在介绍各类概念与原理以前，咱们先经过实现一个简单的示例，对存在服务调用的应用增长一些sleuth的配置实现基本的服务跟踪功能，以此来对Spring Cloud Sleuth有一个初步的了解，随后再逐步展开介绍实现过程当中的各个细节部分。

准备工做

在引入Sleuth以前，咱们先按照以前章节学习的内容来作一些准备工做，构建一些基础的设施和应用：

• 服务注册中心：eureka-server，这里不作赘述，直接使用以前构建的工程。或者直接使用个人公益eureka注册中心，下面的例子使用该注册中心。

• 微服务应用：trace-1，实现一个REST接口/trace-1，调用该接口后将触发对trace-2应用的调用。具体实现以下：

  • 建立一个基础的Spring Boot应用，在pom.xml中增长下面依赖：

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
       <version>1.5.10.RELEASE</version>
    <relativePath/> 
</parent>
<dependency>
      <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-ribbon</artifactId>
</dependency>
<dependencyManagement>
       <dependencies>
           <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-dependencies</artifactId>
               <version>Dalston.SR5</version>
               <type>pom</type>
               <scope>import</scope>
           </dependency>
       </dependencies>
</dependencyManagement>

• 建立应用主类，并实现/trace-1接口，并使用RestTemplate调用trace-2应用的接口。具体以下：

@RestController
@EnableDiscoveryClient
@SpringBootApplication
public class TraceApplication {

    private final Logger logger = Logger.getLogger(getClass());

    @Bean
    @LoadBalanced
    RestTemplate restTemplate() {
        return new RestTemplate();
    }

    @RequestMapping(value = "/trace-1", method = RequestMethod.GET)
    public String trace() {
        logger.info("===call trace-1===");
        return restTemplate().getForEntity("http://trace-2/trace-2", String.class).getBody();
    }

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

}

• application.properties中将eureka.client.serviceUrl.defaultZone参数指向eureka-server的地址，具体以下：

spring.application.name=trace-1
server.port=9101

eureka.client.serviceUrl.defaultZone=http://eureka.didispace.com/eureka/

• 微服务应用：trace-2，实现一个REST接口/trace-2，供trace-1调用。具体实现以下：

  • 建立一个基础的Spring Boot应用，pom.xml中的依赖与trace-1相同
  • 建立应用主类，并实现/trace-2接口，具体实现以下：

@RestController
@EnableDiscoveryClient
@SpringBootApplication
public class TraceApplication {

    private final Logger logger = Logger.getLogger(getClass());

    @RequestMapping(value = "/trace-2", method = RequestMethod.GET)
    public String trace() {
        logger.info("===<call trace-2>===");
        return "Trace";
    }

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

}

• application.properties中将eureka.client.serviceUrl.defaultZone参数指向eureka-server的地址，另外还须要设置不一样的应用名和端口号，具体以下：

spring.application.name=trace-2
server.port=9102
eureka.client.serviceUrl.defaultZone=http://eureka.didispace.com/eureka/

在实现了上面内容以后，咱们能够将eureka-server、trace-1、trace-2三个应用都启动起来，并经过postman或curl等工具来对trace-1的接口发送请求http://localhost:9101/trace-1，咱们能够获得返回值Trace，同时还能在它们的控制台中分别得到下面的输出：

-- trace-1
INFO 25272 --- [nio-9101-exec-2] ication$$EnhancerBySpringCGLIB$$36e12c68 : ===<call trace-1>===

-- trace-2
INFO 7136 --- [nio-9102-exec-1] ication$$EnhancerBySpringCGLIB$$52a02f0b : ===<call trace-2>===

实现跟踪

在完成了准备工做以后，接下来咱们开始进行本章的主题内容，为上面的trace-1和trace-2来添加服务跟踪功能。经过Spring Cloud Sleuth的封装，咱们为应用增长服务跟踪能力的操做很是简单，只须要在trace-1和trace-2的pom.xml依赖管理中增长spring-cloud-starter-sleuth依赖便可，具体以下：

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

到这里，实际上咱们已经为trace-1和trace-2实现服务跟踪作好了基础的准备，重启trace-1和trace-2后，再对trace-1的接口发送请求http://localhost:9101/trace-1。此时，咱们能够从它们的控制台输出中，窥探到sleuth的一些端倪。

-- trace-1
INFO [trace-1,f410ab57afd5c145,a9f2118fa2019684,false] 25028 --- [nio-9101-exec-1] ication$$EnhancerBySpringCGLIB$$d8228493 : ===<call trace-1>===

-- trace-2
INFO [trace-2,f410ab57afd5c145,e9a377dc2268bc29,false] 23112 --- [nio-9102-exec-1] ication$$EnhancerBySpringCGLIB$$e6cb4078 : ===<call trace-2>===

从上面的控制台输出内容中，咱们能够看到多了一些形如 [trace-1,f410ab57afd5c145,a9f2118fa2019684,false]的日志信息，而这些元素正是实现分布式服务跟踪的重要组成部分，它们每一个值的含义以下：

• 第一个值：trace-1，它记录了应用的名称，也就是application.properties中spring.application.name参数配置的属性。
• 第二个值：f410ab57afd5c145，Spring Cloud Sleuth生成的一个ID，称为Trace ID，它用来标识一条请求链路。一条请求链路中包含一个Trace ID，多个Span ID。
• 第三个值：a9f2118fa2019684，Spring Cloud Sleuth生成的另一个ID，称为Span ID，它表示一个基本的工做单元，好比：发送一个HTTP请求。
• 第四个值：false，表示是否要将该信息输出到Zipkin等服务中来收集和展现。

上面四个值中的Trace ID和Span ID是Spring Cloud Sleuth实现分布式服务跟踪的核心。在一次服务请求链路的调用过程当中，会保持并传递同一个Trace ID，从而将整个分布于不一样微服务进程中的请求跟踪信息串联起来，以上面输出内容为例，trace-1和trace-2同属于一个前端服务请求来源，因此他们的Trace ID是相同的，处于同一条请求链路中。

原文地址： http://blog.didispace.com/spr...

本文完整示例：

读者能够根据喜爱选择下面的两个仓库中查看trace-1和trace-2两个项目：

• Github：https://github.com/dyc87112/SpringCloud-Learning/
• Gitee：https://gitee.com/didispace/SpringCloud-Learning/

若是您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！

本文内容部分节选自个人《Spring Cloud微服务实战》，但对依赖的Spring Boot和Spring Cloud版本作了升级。