微服務架構下的問題
在大型系統的微服務化構建中，一個系統會被拆分成許多模塊。這些模塊負責不同的功能，組合成系
統，最終可以提供豐富的功能。在這種架構中，一次請求往往需要涉及到多個服務。互聯網應用構建在
不同的軟件模塊集上，這些軟件模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、
有可能布在了幾千台服務器，橫跨多個不同的數據中心，也就意味着這種架構形式也會存在一些問題：
- 如何快速發現問題？
- 如何判斷故障影響范圍？
- 如何梳理服務依賴以及依賴的合理性？
- 如何分析鏈路性能問題以及實時容量規划？
分布式鏈路追蹤（Distributed Tracing），就是將一次分布式請求還原成調用鏈路，進行日志記錄，性
能監控並將 一次分布式請求的調用情況集中展示。比如各個服務節點上的耗時、請求具體到達哪台機器
上、每個服務節點的請求狀態等等。
目前業界比較流行的鏈路追蹤系統如：Twitter的Zipkin，阿里的鷹眼，美團的Mtrace，大眾點評的
cat等，大部分都是基於google發表的 Dapper。Dapper闡述了分布式系統，特別是微服務架構中鏈路
追蹤的概念、數據表示、埋點、傳遞、收集、存儲與展示等技術細節。
Sleuth概述
簡介
Spring Cloud Sleuth 主要功能就是在分布式系統中提供追蹤解決方案，並且兼容支持了 zipkin，你只
需要在pom文件中引入相應的依賴即可。
相關概念
Spring Cloud Sleuth 為Spring Cloud提供了分布式根據的解決方案。它大量借用了Google Dapper的
設計。先來了解一下Sleuth中的術語和相關概念。
Spring Cloud Sleuth采用的是Google的開源項目Dapper的專業術語。
Span ：基本工作單元，例如，在一個新建的span中發送一個RPC等同於發送一個回應請求給
RPC，span通過一個64位ID唯一標識，trace以另一個64位ID表示，span還有其他數據信息，比
如摘要、時間戳事件、關鍵值注釋(tags)、span的ID、以及進度ID(通常是IP地址)
span在不斷的啟動和停止，同時記錄了時間信息，當你創建了一個span，你必須在未來的某個時刻停止它。
Trace ：一系列spans組成的一個樹狀結構，例如，如果你正在跑一個分布式大數據工程，你可能
需要創建一個trace。
Annotation ：用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結束
cs - Client Sent - 客戶端發起一個請求，這個annotion描述了這個span的開始
sr - Server Received - 服務端獲得請求並准備開始處理它，如果將其sr減去cs時間戳便可得到
網絡延遲
ss - Server Sent - 注解表明請求處理的完成(當請求返回客戶端)，如果ss減去sr時間戳便可得
到服務端需要的處理請求時間
cr - Client Received - 表明span的結束，客戶端成功接收到服務端的回復，如果cr減去cs時間
戳便可得到客戶端從服務端獲取回復的所有所需時間。
鏈路追蹤Sleuth入門
接下來通過之前的項目案例整合Sleuth，完成入門案例的編寫
（1） 配置依賴
修改微服務工程引入Sleuth依賴
<!--sleuth鏈路追蹤--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>
2） 修改配置文件
修改application.yml添加日志級別
logging:
level:
root: info
org.springframework.web.servlet.DispatcherServlet: DEBUG
org.springframework.cloud.sleuth: DEBUG
然后開始調用
網關服務日志
訂單服務日志
商品服務日志
