Spring Cloud Sleuth + Zipkin 鏈路監控

原文：https://blog.csdn.net/hubo_88/article/details/80878632

 

在微服務系統中，隨着業務的發展，系統會變得愈來愈大，那麼各個服務之間的調用關係也就變得愈來愈複雜。一個 HTTP 請求會調用多個不一樣的微服務來處理返回最後的結果，在這個調用過程當中，可能會由於某個服務出現網絡延遲太高或發送錯誤致使請求失敗，這個時候，對請求調用的監控就顯得尤其重要了。Spring Cloud Sleuth 提供了分佈式服務鏈路監控的解決方案。下面介紹 Spring Cloud Sleuth 整合 Zipkin 的解決方案。

（一）簡介
Zipkin 是 Twitter 的一個開源項目，它基於 Google Dapper 實現的。咱們可使用它來收集各個服務器上請求鏈路的跟蹤數據，並經過它提供的 REST API 接口來輔助查詢跟蹤數據以實現對分佈式系統的監控程序，從而及時發現系統中出現的延遲太高問題。除了面向開發的 API 接口以外，它還提供了方便的 UI 組件來幫助咱們直觀地搜索跟蹤信息和分析請求鏈路明細，好比能夠查詢某段時間內各用戶請求的處理時間等。

Zipkin 和 Config 結構相似，分爲服務端 Server，客戶端 Client，客戶端就是各個微服務應用。

（二）搭建 Zipkin 服務端
在 Spring Boot 2.0 版本以後，官方已不推薦本身搭建定製了，而是直接提供了編譯好的 jar 包。詳情能夠查看官網：https://zipkin.io/pages/quickstart.html

能夠在終端使用如下命令：

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar
使用 docker 的方式

docker run -d -p 9411:9411 openzipkin/zipkin
任一方式啓動後，訪問 http://localhost:9411，能夠看到服務端已經搭建成功

 

（三）搭建 Zipkin 客戶端
建立兩個服務，spring-cloud-service一、spring-cloud-service2，service1 實現一個 REST 接口 /service1，該接口裏調用 service2 應用。

3.1 建立 spring-cloud-service1
3.1.1 引入依賴，pom 文件：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>spring-cloud-componets</artifactId>
<groupId>com.geny</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>

<artifactId>spring-cloud-service1</artifactId>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
3.1.2 配置文件：
server:
port: 8481
spring:
application:
name: service1
zipkin:
base-url: http://192.168.174.128:9411/
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
logging:
level:
root: debug
3.1.3 啓動類
@SpringBootApplication
@EnableEurekaClient
@RestController
public class Service1Application {

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

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

@RequestMapping(value = "service1", method = RequestMethod.GET)
public String service1() {
return restTemplate().getForObject("http://service2/service2", String.class);
}
}
3.2 建立 spring-cloud-service2
service2 的 pom.xml 文件、配置文件是同樣的，只須要修改相應的端口和應用名稱便可。

啓動類以下：

@SpringBootApplication
@EnableEurekaClient
@RestController
public class Service2Application {

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


@RequestMapping(value = "service2", method = RequestMethod.GET)
public String service2() {
return "Hi,I'm Service2!";
}
}
3.3 驗證
依次啓動 eureka-server、spring-cloud-service一、spring-cloud-service2，訪問 http://localhost:8481/service1

 

接口訪問已經成功，此時，咱們查看一下控制檯的日誌輸出：

 

從上面的控制檯輸出內容中，咱們能夠看到多了一些如 [service1,450165b378a38236,92377ff04d8a9cfb,false] 的日誌信息，而這些元素正是實現分佈式服務跟蹤的重要組成部分，每一個值的含義以下：

第一個值：service1，它記錄了應用的名稱
第二個值：450165b378a38236，是 Spring Cloud Sleuth 生成的一個 ID，稱爲 Trace ID，它用來標識一條請求鏈路。一條請求鏈路中包含一個 Trace ID，多個 Span ID。
第三個值：92377ff04d8a9cfb，是 Spring Cloud Sleuth 生成的另一個 ID，稱爲 Span ID，它表示一個基本的工做單元，好比發送一個 HTTP 請求。
第四個值：false，它表示是否要將該信息輸出到 Zipkin Server 中來收集和展現。
上面四個值中的 Trace ID 和 Span ID 是 Spring Cloud Sleuth 實現分佈式服務跟蹤的核心。在一次請求中，會保持並傳遞同一個 Trance ID，從而將整個fenbu分佈於不一樣微服務進程中的請求跟蹤信息串聯起來。

下面咱們訪問 Zipkin Server 端，http://192.168.174.128:9411/

 

 

發現服務名下並無看到咱們的應用，這是爲何呢？

這是由於 Spring Cloud Sleuth 採用了抽樣收集的方式來爲跟蹤信息打上收集標記，也就是上面看到的第四個值。爲何要使用抽樣收集呢？理論上應該是收集的跟蹤信息越多越好，能夠更好的反映出系統的實際運行狀況，可是在高併發的分佈式系統運行時，大量請求調用會產生海量的跟蹤日誌信息，若是過多的收集，會對系統性能形成必定的影響，因此 Spring Cloud Sleuth 採用了抽樣收集的方式。

既然如此，那麼咱們就須要把上面第四個值改成 true，開發過程當中，咱們通常都是收集所有信息。

Sleuth 默認採樣算法的實現是 Reservoir sampling，具體的實現類是 PercentageBasedSampler，默認的採樣比例爲: 0.1，即 10%。咱們能夠經過 spring.sleuth.sampler.probability 來設置，所設置的值介於 0 到 1 之間，1 則表示所有采集

修改配置文件以下:

server:
port: 8481
spring:
application:
name: service1
zipkin:
base-url: http://192.168.174.128:9411/
  sleuth:
sampler:
probability: 1.0
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
logging:
level:
root: debug
再次啓動 spring-cloud-service一、spring-cloud-service2，訪問 http://localhost:8481/service1

查看後臺日誌：

 

這個時候，第四個值已經爲true了，再訪問 http://192.168.174.128:9411/

 

能夠看到已經有咱們的服務調用記錄了

選擇 service1，點擊 Find Trances，能夠看到咱們的服務調用記錄

點擊記錄就能夠清楚的看到咱們的服務調用鏈路關係，能夠看到每個服務所所耗費的時間

 

點擊依賴分析，能夠看到服務之間的依賴關係

 

 

源碼下載：https://github.com/shmilyah/spring-cloud-componets