Spring Cloud構建微服務架構：分散式服務跟蹤（入門）
透過之前的N篇博文介紹，實際上我們已經能夠透過使用它們搭建起一個基礎的微服務架構系統來實現我們的業務需求了。但是，隨著業務的發展，我們的系統規模也會變得越來越大，各微服務間的呼叫關係也變得越來越錯綜複雜。通常一個由客戶端發起的請求在後端系統中會經過多個不同的微服務呼叫來協同產生最後的請求結果，在複雜的微服務架構系統中，幾乎每一個前端請求都會形成一條複雜的分散式服務呼叫鏈路，在每條鏈路中任何一個依賴服務出現延遲過高或錯誤的時候都有可能引起請求最後的失敗。這時候對於每個請求全鏈路呼叫的跟蹤就變得越來越重要，透過實現對請求呼叫的跟蹤可以幫助我們快速的發現錯誤根源以及監控分析每條請求鏈路上的效能瓶頸等好處。
針對上面所述的分散式服務跟蹤問題，Spring Cloud Sleuth提供了一套完整的解決方案。在本章中，我們將詳細介紹如何使用Spring Cloud Sleuth來為我們的微服務架構增加分散式服務跟蹤的能力。
原文地址：http：//blog。didispace。com/spring-cloud-starter-dalston-8-1/
快速入門
在介紹各種概念與原理之前，我們先透過實現一個簡單的示例，對存在服務呼叫的應用增加一些sleuth的配置實現基本的服務跟蹤功能，以此來對Spring Cloud Sleuth有一個初步的瞭解，隨後再逐步展開介紹實現過程中的各個細節部分。
準備工作
在引入Sleuth之前，我們先按照之前章節學習的內容來做一些準備工作，構建一些基礎的設施和應用：
服務註冊中心：
eureka-server
，這裡不做贅述，直接使用之前構建的工程。或者直接使用我的公益eureka註冊中心，下面的例子使用該註冊中心。
微服務應用：
trace-1
，實現一個REST介面
/trace-1
，呼叫該介面後將觸發對
trace-2
應用的呼叫。具體實現如下：
建立一個基礎的Spring Boot應用，在
pom。xml
中增加下面依賴：
org。springframework。boot
spring-boot-starter-parent
1。5。10。RELEASE
org。springframework。boot
spring-boot-starter-web
org。springframework。cloud
spring-cloud-starter-eureka
org。springframework。cloud
spring-cloud-starter-ribbon
org。springframework。cloud
spring-cloud-dependencies
Dalston。SR5
pom
import
建立應用主類，並實現
/trace-1
介面，並使用
RestTemplate
呼叫
trace-2
應用的介面。具體如下：
@RestController
@EnableDiscoveryClient
@SpringBootApplication
public
class
TraceApplication
{
private
final
Logger
logger
=
Logger
。
getLogger
（
getClass
（））；
@Bean
@LoadBalanced
RestTemplate
restTemplate
（）
{
return
new
RestTemplate
（）；
}
@RequestMapping
（
value
=
“/trace-1”
，
method
=
RequestMethod
。
GET
）
public
String
trace
（）
{
logger
。
info
（
“===call trace-1===”
）；
return
restTemplate
（）。
getForEntity
（
“http：//trace-2/trace-2”
，
String
。
class
）。
getBody
（）；
}
public
static
void
main
（
String
［］
args
）
{
SpringApplication
。
run
（
TraceApplication
。
class
，
args
）；
}
}
application。properties
中將
eureka。client。serviceUrl。defaultZone
引數指向eureka-server的地址，具體如下：
spring
。
application
。
name
=
trace
-
1
server
。
port
=
9101
eureka
。
client
。
serviceUrl
。
defaultZone
=
http
：
//eureka。didispace。com/eureka/
微服務應用：
trace-2
，實現一個REST介面
/trace-2
，供
trace-1
呼叫。具體實現如下：
建立一個基礎的Spring Boot應用，
pom。xml
中的依賴與
trace-1
相同
建立應用主類，並實現
/trace-2
介面，具體實現如下：
@RestController
@EnableDiscoveryClient
@SpringBootApplication
public
class
TraceApplication
{
private
final
Logger
logger
=
Logger
。
getLogger
（
getClass
（））；
@RequestMapping
（
value
=
“/trace-2”
，
method
=
RequestMethod
。
GET
）
public
String
trace
（）
{
logger
。
info
（
“===
）；
return
“Trace”
；
}
public
static
void
main
（
String
［］
args
）
{
SpringApplication
。
run
（
TraceApplication
。
class
，
args
）；
}
}
application。properties
中將
eureka。client。serviceUrl。defaultZone
引數指向eureka-server的地址，另外還需要設定不同的應用名和埠號，具體如下：
spring
。
application
。
name
=
trace
-
2
server
。
port
=
9102
eureka
。
client
。
serviceUrl
。
defaultZone
=
http
：
//eureka。didispace。com/eureka/
在實現了上面內容之後，我們可以將
eureka-server
、
trace-1
、
trace-2
三個應用都啟動起來，並透過postman或curl等工具來對
trace-1
的介面傳送請求
http：//localhost：9101/trace-1
，我們可以得到返回值
Trace
，同時還能在它們的控制檯中分別獲得下面的輸出：
—— trace-1
INFO
25272
——-
［
nio-9101-exec-2
］
ication
$$
EnhancerBySpringCGLIB
$$
36e12c68 ：
===
===
—— trace-2
INFO
7136
——-
［
nio-9102-exec-1
］
ication
$$
EnhancerBySpringCGLIB
$$
52a02f0b ：
===
===
實現跟蹤
在完成了準備工作之後，接下來我們開始進行本章的主題內容，為上面的
trace-1
和
trace-2
來新增服務跟蹤功能。透過Spring Cloud Sleuth的封裝，我們為應用增加服務跟蹤能力的操作非常簡單，只需要在
trace-1
和
trace-2
的
pom。xml
依賴管理中增加
spring-cloud-starter-sleuth
依賴即可，具體如下：
org。springframework。cloud
spring-cloud-starter-sleuth
到這裡，實際上我們已經為
trace-1
和
trace-2
實現服務跟蹤做好了基礎的準備，重啟
trace-1
和
trace-2
後，再對
trace-1
的介面傳送請求
http：//localhost：9101/trace-1
。此時，我們可以從它們的控制檯輸出中，窺探到sleuth的一些端倪。
—— trace-1
INFO
［
trace-1，f410ab57afd5c145，a9f2118fa2019684，false
］
25028
——-
［
nio-9101-exec-1
］
ication
$$
EnhancerBySpringCGLIB
$$
d8228493 ：
===
===
—— trace-2
INFO
［
trace-2，f410ab57afd5c145，e9a377dc2268bc29，false
］
23112
——-
［
nio-9102-exec-1
］
ication
$$
EnhancerBySpringCGLIB
$$
e6cb4078 ：
===
===
從上面的控制檯輸出內容中，我們可以看到多了一些形如
［trace-1，f410ab57afd5c145，a9f2118fa2019684，false］
的日誌資訊，而這些元素正是實現分散式服務跟蹤的重要組成部分，它們每個值的含義如下：
第一個值：
trace-1
，它記錄了應用的名稱，也就是
application。properties
中
spring。application。name
引數配置的屬性。
第二個值：
f410ab57afd5c145
，Spring Cloud Sleuth生成的一個ID，稱為Trace ID，它用來標識一條請求鏈路。一條請求鏈路中包含一個Trace ID，多個Span ID。
第三個值：
a9f2118fa2019684
，Spring Cloud Sleuth生成的另外一個ID，稱為Span ID，它表示一個基本的工作單元，比如：傳送一個HTTP請求。
第四個值：
false
，表示是否要將該資訊輸出到Zipkin等服務中來收集和展示。
上面四個值中的
Trace ID
和
Span ID
是Spring Cloud Sleuth實現分散式服務跟蹤的核心。在一次服務請求鏈路的呼叫過程中，會保持並傳遞同一個
Trace ID
，從而將整個分佈於不同微服務程序中的請求跟蹤資訊串聯起來，以上面輸出內容為例，
trace-1
和
trace-2
同屬於一個前端服務請求來源，所以他們的
Trace ID
是相同的，處於同一條請求鏈路中。
本文完整示例：
讀者可以根據喜好選擇下面的兩個倉庫中檢視
trace-1
和
trace-2
兩個專案：
Github：https：//github。com/dyc87112/SpringCloud-Learning/
Gitee：https：//gitee。com/didispace/SpringCloud-Learning/
如果您對這些感興趣，歡迎star、follow、收藏、轉發給予支援！
本文內容部分節選自我的《Spring Cloud微服務實戰》，但對依賴的Spring Boot和Spring Cloud版本做了升級。
