好久沒有寫博客了，主要是最近有些忙，今天忙裏偷閒來一篇。
=======我是華麗的分割線==========
微服務架構是一種分佈式架構，微服務系統按照業務劃分服務單元，一個微服務往往會有很多個服務單元，一個請求往往會有很多個單元參與，一旦請求出現異常，想要去定位問題點真心不容易，因此需要有個東西去跟蹤請求鏈路，記錄一個請求都調用了哪些服務單元，調用順序是怎麼樣的以及在各個服務單元處理的時間長短。常見的服務鏈路追蹤組件有google的dapper、twitter的zipkin、阿里的鷹眼等，它們都是出衆的開源鏈路追蹤組件。
spring cloud 有自己的組件來集成這些開源組件，它就是spring cloud sleuth，它爲服務鏈路追蹤提供了一套完整的解決方案。
今天的主題就是如何使用spring cloud sleuth整合zipkin進行服務鏈路追蹤。本博客將圍繞下面的線索進行展開：
- Server端代碼實現
- Client端代碼實現
- 執行測試
由上面的線索可以發現，zipkin分服務端和客戶端。
客戶端就是我們的服務單元，用來發送鏈路信息到服務端；
服務端用來接收客戶端發送來的鏈路信息，並進行處理，它包括4個部分：
- Collector組件：用來接收客戶端發送的鏈路信息然後整理成zipkin能處理的格式，供後續存儲或向外部提供查詢使用。
- Storage組件：對鏈路信息進行保存，默認存儲在內存，通過配置還可以保存到mysql等地方。
- Restful API組件：對其他服務單元提供api接口進行查詢鏈路信息。
- Web UI組件：調用API 組件的接口並將信息顯示到web 畫面。
廢話不多說，直接上代碼。
一、Server端代碼實現
先給出代碼結構：
結構比較簡單，搭建過程如下：
- 新建maven工程sleuth-zipkin
- 修改pom文件
<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.sam</groupId> <artifactId>sleuth-zipkin</artifactId> <version>0.0.1-SNAPSHOT</version> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.1.RELEASE</version> </parent> <properties> <javaVersion>1.8</javaVersion> </properties> <!-- 使用dependencyManagement進行版本管理 --> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Camden.SR6</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <!-- 引入zipkin-server依賴，提供server端功能 --> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-server</artifactId> </dependency> <!-- 引入zipkin-autoconfigure-ui依賴，用來提供zipkin web ui組件的功能，方便查看相關信息 --> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-autoconfigure-ui</artifactId> </dependency> <!-- 引入eureka依賴 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> </dependencies> </project>
- 新建啓動類
/** * @EnableZipkinServer * * 用於開啓Zipkin Server功能 * */ @EnableZipkinServer @SpringBootApplication @EnableDiscoveryClient public class SleuthZipkinApp { public static void main(String[] args) { SpringApplication.run(SleuthZipkinApp.class, args); } }
- 新建配置文件
server.port=9411 spring.application.name=sleuth-zipkin
#需要使用到eureka服務註冊中心 eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka
二、Client端代碼實現
這裏我們準備使用前面的隨筆中已經實現好的微服務（網關服務api-gateway、消費者hello-consumer和生產者hello-server，可以點擊鏈接查看搭建過程，這裏就不詳細描述了）。在這幾個微服務中都做如下修改：
- 引入依賴
<!-- 引入zipkin 依賴 ，提供zipkin客戶端的功能 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency> - 修改配置文件，追加兩項配置
#指定zipkin服務端的url
spring.zipkin.base-url=http://localhost:9411
#設定樣本收集的比率爲100%
spring.sleuth.sampler.percentage=1.0由於分佈式系統的請求量一般比較大，不可能把所有的請求鏈路進行收集整理，因此sleuth採用抽樣收集的方式，設定一個抽樣百分比。在開發階段，我們一般設定百分比爲100%也就是1。
三、執行測試
- 依次啓動微服務：服務註冊中心eureka、zipkin服務端sleuth-zipkin、網關服務api-gateway、消費者hello-consumer和生產者hello-server
- 訪問http://localhost:1111/,確認4個微服務已經成功註冊到了服務註冊中心
![]()
- 訪問http://localhost:5555/hello-consumer/hello-consumer?accessToken=111，通過zuul 網關進行訪問，
![]()
查看api-gateway控制檯：
2018-07-19 18:02:34.999 INFO [api-gateway,4c384ab23da1ae35,4c384ab23da1ae35,true] 9296 --- [nio-5555-exec-3] com.sam.filter.AccessFilter : send GET request to http://localhost:5555/hello-consumer/hello-consumer 2018-07-19 18:02:45.088 INFO [api-gateway,,,] 9296 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration
請看紅字部分，有4部分，以逗號分隔。第一部分是服務名；第二部分是TranceId，每次請求都會有唯一的tranceId；第三部分是spanId，每個工作單元發送一次請求就會產生一個spanId，每個請求會產生一個tranceId和多個spanId，根據tranceId和spanId就能分析出一個完整的請求都經歷了哪些服務單元；第四部分是boolean型的，用來標記是否需要將該請求鏈路進行抽樣收集發送到zipkin等進行整理。
- 訪問zipkin服務端http://localhost:9411/，查看UI頁面
![]()
選擇api-gateway，然後點擊 "Find Trances"
![]()
能看到請求都經歷了哪些服務節點。再點相關link，可以查看調用順序，並且還能看到在各個服務節點的處理的時間長度。
![]()
切換到依賴畫面，能查看服務節點的依賴關係
![]()
