Zipkin的概述
Zipkin 是 Twitter 的一個開源項目，它基於 Google Dapper 實現，它致力於收集服務的定時數據，以
解決微服務架構中的延遲問題，包括數據的收集、存儲、查找和展現。 我們可以使用它來收集各個服務
器上請求鏈路的跟蹤數據，並通過它提供的 REST API 接口來輔助我們查詢跟蹤數據以實現對分布式系
統的監控程序，從而及時地發現系統中出現的延遲升高問題並找出系統性能瓶頸的根源。除了面向開發
的 API 接口之外，它也提供了方便的 UI 組件來幫助我們直觀的搜索跟蹤信息和分析請求鏈路明細，比
如：可以查詢某段時間內各用戶請求的處理時間等。 Zipkin 提供了可插拔數據存儲方式：In-
Memory、MySql、Cassandra 以及 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 項目來當注冊中心。
一個 Zipkin 服務端。
多個微服務，這些微服務中配置 Zipkin 客戶端。
在項目的pom.xml文件中添加下面依賴
<!--里面包含兩個依賴-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
2. 修改配置
主要修改兩個配置：
-
base-url:zipkin地址,默認值是："http://192.168.180.113:9411/" -
probability: 采集日志的百分比，默認值是：0.1，由於測試中需要才改成1,生產環境就使用默認值
#zipkin服務所在地址 zipkin: base-url: http://192.168.180.113:9411/ #配置采樣百分比,開發環境可以設置為1，表示全部，生產就用默認 sleuth: sampler: probability: 1
3. 開啟Zipkin
docker中有現成的鏡像直接拉去下來使用
拉去鏡像 docker pull docker.io/openzipkin/zipkin 啟動容器 [root@topcheer ~]# docker run -d -p 9411:9411 --name myzipkin 17c2bb09f482 5a1707edb7a6c57887537577f7e5775b3f5313fe6b5f703f71b453763d61a506 [root@topcheer ~]# docker ps -l CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5a1707edb7a6 17c2bb09f482 "/busybox/sh run.sh" 6 seconds ago Up 4 seconds 9410-9411/tcp myzipkin [root@topcheer ~]#
