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版本作了升級。