微服務架構都是通過業務來劃分各個服務，然後對外暴露接口。一個接口可能有多個服務共同完成。例如：前幾篇文章中說的管理者服務和訂單服務都需要調用使用者服務，也可以說它們依賴使用者服務。這隻是比較簡單的業務。若是你的系統比較龐大。業務層次比較複雜。一個接口可能需要更多個業務協同完成。倘若，某個服務發生了故障，或者響應較慢。那麼它所關聯的所有接口，都會受到影響。但是這麼多個服務，你怎麼知道是哪個服務發生了故障或者網絡逾時呢？此時，就要對這個服務所涉及的整條鍊路進行追蹤。分析每一個服務的可用性和響應時間，這樣就可以及時做出修複。這就需要Zipkin。
Zipkin介紹
Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages both the collection and lookup of this data. Zipkin’s design is based on the Google Dapper paper.
Applications are instrumented to report timing data to Zipkin. The Zipkin UI also presents a Dependency diagram showing how many traced requests went through each application. If you are troubleshooting latency problems or errors, you can filter or sort all traces based on the application, length of trace, annotation, or timestamp. Once you select a trace, you can see the percentage of the total trace time each span takes which allows you to identify the problem application
上面是Zipkin官網給出的。很多讀者看到這個會想：妖怪吧~這麼大一串英文，看得懂個鬼。當然，我也是看不懂的，就認識那幾個單詞。但是可以使用翻譯工具進行翻譯啊。比如：谷歌翻譯。通過翻譯，了解大概意思。
Zipkin是一種分布式跟蹤系統。 它有助于收集解決微服務架構中的延遲問題所需的時序資料。 它管理這些資料的收集和查找。 Zipkin的設計基于Google Dapper論文。
應用程式用于向Zipkin報告時序資料。 Zipkin UI還提供了一個依賴關系圖，顯示了每個應用程式通過的跟蹤請求數。 如果要解決延遲問題或錯誤，可以根據應用程式，跟蹤長度，注釋或時間戳對所有跟蹤進行篩選或排序。 選擇跟蹤後，您可以看到每個跨度所需的總跟蹤時間百分比，進而可以識别問題應用程式。
上面就是翻譯後的結果。簡便點說，就是Zipkin使用UI界面，更加直覺的顯示了請求中的相關資料。
再講Zipkin之前，先講一下Spring Cloud Sleuth，它可以應用于計劃任務 、多線程服務或複雜的Web請求，尤其是在一個由多個服務組成的系統中，通過添加獨特的辨別符來使用日志跟蹤和診斷問題，并能輕松的內建Logback、SLF4J日志架構。動手實際操作，更能直覺的反應。
Sleuth的基本使用
首先在每一個服務中添加限制。因為Zipkin的限制檔案中已經有Sleuth，是以，直接導入Zipkin的限制即可。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
Sleuth要對請求進行采樣，而它預設的probability是0.1，即10%。在開發環境中，可以設定采集所有資訊。即設定為1
spring:
sleuth:
sampler:
probability: 1
這裡需要使用日志來跟蹤，是以，在需要的地方打上日志即可。啟動服務，通路使用者服務。http://localhost:9999/api/user/v1.0/user
清楚的看到日志格式：[application.name，traceId，spanId，export]
- application.name：就是目前服務的應用名稱，即使用者服務(user-service)
- traceId：為請求鍊路配置設定的id，唯一辨別。
- spanId：表示一個基本的工作單元，一個請求可以包含多個步驟，每個步驟都擁有自己的spanId。一個請求包含一個TraceId，多個SpanId。
- export：是否将該資訊輸出到類似Zipkin這樣的聚合器進行展示。
可以通過traceId來分辨目前請求來自哪個服務。Sleuth的用法還有很多，這裡就講一下基礎，下面回歸主題。
Zipkin的基本使用
官網提供了三種方式，來啟動Zipkin。
(1)使用docker來建構鏡像。
docker run -d -p 9411:9411 openzipkin/zipkin
(2)直接下載下傳一個zipkin.jar
curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar
(3)通過源碼進行建構
# get the latest source
git clone https://github.com/openzipkin/zipkin
cd zipkin
# Build the server and also make its dependencies
./mvnw -DskipTests --also-make -pl zipkin-server clean install
# Run the server
java -jar ./zipkin-server/target/zipkin-server-*exec.jar
這裡我就選擇第一種，使用docker來建構，不熟悉docker的朋友，可以去學習一下docker。菜鳥教程，包括各個作業系統的安裝和基本使用，都寫的很詳細。因為我的docker安裝在linux系統上的，是以，使用虛拟機啟動centos7。執行上面的指令。然後啟動docker。啟動Zipkin鏡像。
通路：http://192.168.145.101:9411 就能看到Zipkin的界面了。
初次通路，裡面什麼都沒有，接下來，就讓應用程式與Zipkin進行關聯。
需要在配置檔案中，指明Zipkin的位址。
spring:
zipkin:
base-url: http://192.168.145.101:9411/
這裡的ip位址和端口都是可變的，部落客放的是自己本機的位址，是以，要想測試的朋友，自行修改。
配置完成，接着重新啟動服務。就以管理者服務調用使用者服務為例。通路：http://localhost:9999/api/admin/v1.0/admin?userId=1 位址後，重新整理Zipkin的管理界面。點選查找按鈕。
可以看到，上面顯示了每次調用接口的記錄，點進去就可以檢視詳細的資訊。
點選服務名稱，可以看到請求耗時、請求方式、接口的路徑、控制層的名稱、方法名稱、以及traceId和spanId。
不僅如此，還可以檢視服務之間的依賴關系。
基本上Zipkin的基本使用就講完了，知識點很零散。畢竟部落客剛入猿圈不久，如果文章中出現了什麼錯誤，希望各位猿友指出。
工作996，生病ICU