參考：Spring Cloud（十二）：分布式鏈路跟蹤 Sleuth 與 Zipkin【Finchley 版】
Spring Cloud Sleuth 是Spring Cloud的一個組件，主要功能是在分布式系統中提供服務鏈路追蹤的解決方案。
微服務架構是一個分布式架構，微服務系統按業務划分服務單元，一個微服務系統往往有很多個服務單元。由於服務單元數量眾多，業務的復雜性較高，如果出現了錯誤和異常，很難去定位。主要體現在一個請求可能需要調用很多個服務，而內部服務的調用復雜性決定了問題難以定位。所以在微服務架構中，必須實現分布式鏈路追蹤，去跟進一個請求到底有哪些服務參與，參與的順序又是怎樣的，從而達到每個請求的步驟清晰可見，出了問題能夠快速定位的目的。
現今業界分布式服務跟蹤的理論基礎主要來自於 Google 在2010年發的一篇論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最為廣泛的開源實現是 Twitter 的 Zipkin，為了實現平台無關、廠商無關的分布式服務跟蹤，CNCF 發布了布式服務跟蹤標准 Open Tracing。國內，淘寶的 “鷹眼”、京東的 “Hydra”、大眾點評的 “CAT”、新浪的 “Watchman”、唯品會的 “Microscope”、窩窩網的 “Tracing” 都是這樣的系統。
Spring Cloud Sleuth 也為我們提供了一套完整的解決方案。在本章中，我們將詳細介紹如何使用 Spring Cloud Sleuth + Zipkin 來為我們的微服務架構增加分布式服務跟蹤的能力。
Spring Cloud Sleuth
一般的，一個分布式服務跟蹤系統主要由三部分構成：
- 數據收集
- 數據存儲
- 數據展示
根據系統大小不同，每一部分的結構又有一定變化。譬如，對於大規模分布式系統，數據存儲可分為實時數據和全量數據兩部分，實時數據用於故障排查（Trouble Shooting），全量數據用於系統優化；數據收集除了支持平台無關和開發語言無關系統的數據收集，還包括異步數據收集（需要跟蹤隊列中的消息，保證調用的連貫性），以及確保更小的侵入性；數據展示又涉及到數據挖掘和分析。雖然每一部分都可能變得很復雜，但基本原理都類似。
服務追蹤的追蹤單元是從客戶發起請求（request）抵達被追蹤系統的邊界開始，到被追蹤系統向客戶返回響應（response）為止的過程，稱為一個 trace。每個 trace 中會調用若干個服務，為了記錄調用了哪些服務，以及每次調用的消耗時間等信息，在每次調用服務時，埋入一個調用記錄，稱為一個 span。這樣，若干個有序的 span 就組成了一個 trace。在系統向外界提供服務的過程中，會不斷地有請求和響應發生，也就會不斷生成 trace，把這些帶有 span 的 trace 記錄下來，就可以描繪出一幅系統的服務拓撲圖。附帶上 span 中的響應時間，以及請求成功與否等信息，就可以在發生問題的時候，找到異常的服務；根據歷史數據，還可以從系統整體層面分析出哪里性能差，定位性能優化的目標。
Spring Cloud Sleuth 為服務之間調用提供鏈路追蹤。通過 Sleuth 可以很清楚的了解到一個服務請求經過了哪些服務，每個服務處理花費了多長。從而讓我們可以很方便的理清各微服務間的調用關系。此外 Sleuth 可以幫助我們：
- 耗時分析: 通過 Sleuth 可以很方便的了解到每個采樣請求的耗時，從而分析出哪些服務調用比較耗時;
- 可視化錯誤: 對於程序未捕捉的異常，可以通過集成 Zipkin 服務界面上看到;
- 鏈路優化: 對於調用比較頻繁的服務，可以針對這些服務實施一些優化措施。
Spring Cloud Sleuth 可以結合 Zipkin，將信息發送到 Zipkin，利用 Zipkin 的存儲來存儲信息，利用 Zipkin UI 來展示數據。
這是 Spring Cloud Sleuth 的概念圖：
Zipkin
Zipkin 是 Twitter 的一個開源項目，它基於 Google Dapper 實現，它致力於收集服務的定時數據，以解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。
我們可以使用它來收集各個服務器上請求鏈路的跟蹤數據，並通過它提供的 REST API 接口來輔助我們查詢跟蹤數據以實現對分布式系統的監控程序，從而及時地發現系統中出現的延遲升高問題並找出系統性能瓶頸的根源。除了面向開發的 API 接口之外，它也提供了方便的 UI 組件來幫助我們直觀的搜索跟蹤信息和分析請求鏈路明細，比如：可以查詢某段時間內各用戶請求的處理時間等。
Zipkin 提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。接下來的測試為方便直接采用 In-Memory 方式進行存儲，生產推薦 Elasticsearch。
上圖展示了 Zipkin 的基礎架構，它主要由 4 個核心組件構成：
- Collector：收集器組件，它主要用於處理從外部系統發送過來的跟蹤信息，將這些信息轉換為 Zipkin 內部處理的 Span 格式，以支持后續的存儲、分析、展示等功能。
- Storage：存儲組件，它主要對處理收集器接收到的跟蹤信息，默認會將這些信息存儲在內存中，我們也可以修改此存儲策略，通過使用其他存儲組件將跟蹤信息存儲到數據庫中。
- RESTful API：API 組件，它主要用來提供外部訪問接口。比如給客戶端展示跟蹤信息，或是外接系統訪問以實現監控等。
- Web UI：UI 組件，基於 API 組件實現的上層應用。通過 UI 組件用戶可以方便而有直觀地查詢和分析跟蹤信息。
快速上手
Zipkin 分為兩端，一個是 Zipkin 服務端，一個是 Zipkin 客戶端，客戶端也就是微服務的應用。
客戶端會配置服務端的 URL 地址，一旦發生服務間的調用的時候，會被配置在微服務里面的 Sleuth 的監聽器監聽，並生成相應的 Trace 和 Span 信息發送給服務端。
發送的方式主要有兩種，一種是 HTTP 報文的方式，還有一種是消息總線的方式如 RabbitMQ。
不論哪種方式，我們都需要：
- 一個 Eureka 服務注冊中心，這里我們就用之前的
eureka-server項目來當注冊中心。 - 一個 Zipkin 服務端。
- 兩個微服務應用。gateway-service作為服務網關工程，負責請求的轉發，同時也作為鏈路追蹤客戶端，負載產生鏈路數據，並上傳給Zipkin服務端。user-service是一個服務提供者，對外暴漏API接口，同時作為鏈路追蹤客戶端，負載產生鏈路數據。
方式一：HTTP
Zipkin 服務端
關於 Zipkin 的服務端，在使用 Spring Boot 2.x 版本后，官方就不推薦自行定制編譯了，反而是直接提供了編譯好的 jar 包來給我們使用，詳情請看 upgrade to Spring Boot 2.0 NoClassDefFoundError UndertowEmbeddedServletContainerFactory · Issue #1962 · openzipkin/zipkin · GitHub
並且以前的@EnableZipkinServer也已經被打上了@Deprecated
If you decide to make a custom server, you accept responsibility for troubleshooting your build or configuration problems, even if such problems are a reaction to a change made by the OpenZipkin maintainers. In other words, custom servers are possible, but not supported.
EnableZipkinServer.java - github.com/openzipkin/zipkin/blob/master/zipkin-server/src/main/java/zipkin/server/EnableZipkinServer.java
簡而言之就是：私自改包，后果自負。
所以官方提供了一鍵腳本（Windows下需要安裝curl，不過如果你安裝了Git客戶端，可以直接在Git Bash中使用）
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/ 就能看到如下界面，嗯還有漢化看起來不錯
至此服務端就 OK 了。
微服務應用
構建User Service
新建Module工程user-service，作為服務提供者，對位暴漏API接口，pom文件繼承主maven工程的pom文件，引入eureka client、zipkin的起步依賴，其中zipkin的依賴中包含了sleuth的起步依賴。
<?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"> <modelVersion>4.0.0</modelVersion> <groupId>com.cralor</groupId> <artifactId>user-service</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <name>user-service</name> <description>Demo project for Spring Boot</description> <parent> <groupId>com.cralor</groupId> <artifactId>chap11-sleuth</artifactId> <version>0.0.1-SNAPSHOT</version> <relativePath/> <!-- lookup parent from repository --> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> </properties>
<dependencies> <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-sleuth</artifactId>--> <!--</dependency>--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>
配置文件中，指定程序名user-service，端口號8762，服務注冊地址http://localhost:8761/eureka/，Zipkin Server地址http://localhost:9411。Spring Cloud Sleuth 有一個 Sampler 策略，可以通過這個實現類來控制采樣算法。采樣器不會阻礙 span 相關 id 的產生，但是會對導出以及附加事件標簽的相關操作造成影響。 Sleuth 默認采樣算法的實現是 Reservoir sampling，具體的實現類是 PercentageBasedSampler，默認的采樣比例為: 0.1(即 10%)。不過我們可以通過spring.sleuth.sampler.probability來設置，所設置的值介於 0.0 到 1.0 之間，1.0 則表示全部采集。
server:
port: 8762
spring:
application:
name: user-service
sleuth:
sampler:
probability: 1.0 # 將采樣比例設置為 1.0，也就是全部都需要。默認是 0.1
zipkin:
base-url: http://localhost:9411 # 指定了 Zipkin 服務器的地址
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
在UserController類建一個“/user/hi”的API接口，對外提供服務
@RestController @RequestMapping("/user") public class UserController { @GetMapping("/hi") public String hi(){ return "i'm cralor"; } }
構建Gateway Service
新建工程gateway-service作為服務網關，將請求轉發到user-service。作為zipkin客戶端，上傳鏈路數據到zipkin服務器。pom文件引入eureka client、zipkin和zuul的依賴。
<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-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
配置文件中指定程序名gateway-service，端口號5000，服務注冊地址http://localhost:8761/eureka/，Zipkin Server地址http://localhost:9411。以“/user-api/**”開頭的請求轉發到服務名為user-service的服務。
server:
port: 5000
spring:
application:
name: gateway-service
sleuth:
sampler:
probability: 1.0 # 將采樣比例設置為 1.0，也就是全部都需要。默認是 0.1
zipkin:
base-url: http://localhost:9411 # 指定了 Zipkin 服務器的地址
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
zuul:
routes:
api-a:
path: /user-api/**
serviceId: user-service #將以"/user-api/**"開頭的Uriqq轉發到服務名為user-service的服務
啟動類加上@EnableZuulProxy注解，開啟zuul代理功能。
@EnableZuulProxy @SpringBootApplication public class GatewayServiceApplication { public static void main(String[] args) { SpringApplication.run(GatewayServiceApplication.class, args); } }
啟動Zipkin服務器，依次啟動eureka-server、user-service和gateway-service，瀏覽器訪問http://localhost:5000/user-api/user/hi，顯示
訪問Zipkin服務器http://localhost:9411/zipkin/，點擊 Find Traces 會看到有一條記錄
點擊記錄進去頁面，可以看到每一個服務所耗費的時間和順序
點擊依賴分析，可以看到項目之間的調用關系
方式二：消息總線 RabbitMQ
因為之前說的 Zipkin 不再推薦我們來自定義 Server 端了，所以在最新版本的 Spring Cloud 依賴管理里已經找不到 zipkin-server 了。
那么如果直接用官方提供的 jar 包怎么從 RabbitMQ 中獲取 trace 信息呢？
我們可以通過環境變量讓 Zipkin 從 RabbitMQ 中讀取信息，就像這樣：
java -jar zipkin.jar --zipkin.collector.rabbitmq.addressed=localhost
通過這種方式可以啟動zipkin然后使用rabbitmq進行鏈路追蹤。另外在zipkin中配置的rabbitmq的用戶名和密碼是guest、guest如果你的rabbitmq用戶名密碼不是這個也要修改配置啟動。
zipkin.jar的yml配置文件內容可在此處查看：https://github.com/openzipkin/zipkin/blob/master/zipkin-server/src/main/resources/zipkin-server-shared.yml
這是配置文件的截圖
關於 Zipkin 的 Client 端，也就是微服務應用，我們就在之前的基礎上修改，只要在他們的依賴里都引入spring-cloud-stream-binder-rabbit就好了，別的不用改。
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-stream-binder-rabbit</artifactId> </dependency>
不過為了說明是通過 RabbitMQ 傳輸的信息，將spring.zipkin.base-url均改為http://localhost:9412/，即指向一個錯誤的地址。
分別重啟 user-service、gateway-service 工程，並啟動 Zipkin Serve。瀏覽器訪問http://localhost:5000/user-api/user/hi，http://localhost:9411/zipkin/，查看 RabbitMQ Admin（http://localhost:15672/）
（😭我使用RabbitMQ這個只成功了一次，后來Zipkin Serve就接受不到了，還在找原因...😥）
請參考：https://windmt.com/2018/04/24/spring-cloud-12-sleuth-zipkin/
案例代碼地址：https://github.com/cralor7/springcloud
