在一個微服務體系中，對於應用之間的通信、接口調用如何做到跟蹤和監控，一直是一個比較難的問題。
比如A是做商品服務開發的，而B是做訂單服務開發的，B在下單的時候需要調用到商品服務的查詢商品庫存接
口和查詢商品明細接口，才能夠完成下單流程。現在出現的問題就是下單很慢，要耗時20s。多麼恐怖的耗時，
我一個用戶，真金白銀買你的東西，你卻半天不讓我下單成功，不想賣直說好吧。
看到沒有，在這個過程中，就算最終能夠下單成功，也避免不了用戶對商家的抱怨與不滿，要是多來幾次，
你就永遠的失去這個客戶了。所以老闆命令B必須找出原因，爲什麼下個單這麼慢？B最開始想採用打log的方式，
後來發現這樣很不科學，訂單服務中除了調用商品服務還要調用積分服務，用戶服務等等，所以爲了儘可能對代
碼改動小而又能夠準確定位各個服務間調用存在的問題，B選擇了使用分佈式追蹤系統（distributed tracing system）。
SpringCloud提供了組件Sleuth，該組件實現了分佈式追蹤解決方案，具體是個什麼東西，可以參考官網描述：
Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud, borrowing heavily from Dapper, Zipkin
and HTrace. For most users Sleuth should be invisible, and all your interactions with external systems should be
instrumented automatically. You can capture data simply in logs, or by sending it to a remote collector service.
簡單來說就是Sleuth實現了一個分佈式追蹤解決方案，其中大量借鑑了Dapper，Zipkin等成熟分佈式追蹤系統。對於用戶來說
Sleuth本身是不可見的，我們可以在日誌或者遠程收集器上看到追蹤記錄。
這裏我們重點需要知道的是，Sleuth本身是不可見的，我們如果想要具體的追蹤記錄需要到日誌或者一些分佈式追蹤系統（比如Zipkin）
中去查看，這裏我使用的是Zipkin。Zipkin又是個啥玩意兒？
Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures.
Features include both the collection and lookup of this data.
If you have a trace ID in a log file, you can jump directly to it. Otherwise, you can query based on attributes such as service,
operation name, tags and duration. Some interesting data will be summarized for you, such as the percentage of time spent
in a service, and whether or not operations failed.
Zipkin最重要的特徵就是collect和lookup，可以幫助我們收集應用發來的span（span是指一個跨度，如order調用product接口，
這個過程就是一個跨度）並提供UI界面展示查找這些記錄。這樣我們就可以很方便的定位問題。
接下來看下如何使用Sleuth和Zipkin吧！
引入依賴
<!--包含sleuth和zipkin--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
這個依賴同時包含了sleuth和zipkin
調整日誌級別
logging:
level:
root: INFO
org.springframework.web.servlet.DispatcherServlet: DEBUG
org.springframework.cloud.sleuth: DEBUG
下載Zipkin
先去官網看下下載方式
最方便的，用docker下載安裝，在安裝了docker的機器上執行
docker run -d -p 9411:9411 openzipkin/zipkin
docker ps查看一下進程起沒起來
然後在應用裏面配置zipkin地址
zipkin: base-url: http://localhost:9411/ sender: type: web
再配置一下sleuth的抽樣比例
sleuth:
sampler:
probability: 1
抽樣比例是什麼意思呢？比如我配置成0.1，那麼就是每10個服務間的調用，會有一個的追蹤記錄被髮送到zipkin
存儲分析，而這裏默認值就是0.1，爲了演示效果我配置成1，就是所有的服務間調用的記錄都會被髮送到zipkin上
然後我們啓動訂單服務和商品服務，訪問訂單服務，訂單服務會調用商品服務，那麼理論上就會在日誌
和zipkin上看到記錄。
先看日誌
可以看到這裏有調用的記錄被打出來，格式是這樣的：[product,fc6f693f47d9d5d1,fc6f693f47d9d5d1,true]
其中product代表當前的服務，fc6f693f47d9d5d1是traceId，後面的fc6f693f47d9d5d1是spanId，還有個
parentId是可選的，相關的spanId擁有同一個traceId，後面true表示要將span發送到遠程服務上去，那我們現在就
可以看下zipkin上有沒有相關信息：
通過查看order和product的追蹤記錄就可以發現，product的get接口getProductList耗時最久，用了3.228s
這就是一個分佈式服務追蹤系統的基本功能了。除了這些，還有更多高級功能等待你去使用，參考下面的鏈接去看看吧：
https://spring.io/projects/spring-cloud-sleuth
本文到此結束，謝謝各位看官閱讀！