Spring Cloud Sleuth
一般的,一個分佈式服務跟蹤系統,主要有三部分:數據收集、數據存儲和數據展示。根據系統大小不同,每一部分的結構又有一定變化。譬如,對於大規模分佈式系統,數據存儲可分爲實時數據和全量數據兩部分,實時數據用於故障排查(troubleshooting),全量數據用於系統優化;數據收集除了支持平臺無關和開發語言無關係統的數據收集,還包括異步數據收集(需要跟蹤隊列中的消息,保證調用的連貫性),以及確保更小的侵入性;數據展示又涉及到數據挖掘和分析。雖然每一部分都可能變得很複雜,但基本原理都類似。
服務追蹤的追蹤單元是從客戶發起請求(request)抵達被追蹤系統的邊界開始,到被追蹤系統向客戶返回響應(response)爲止的過程,稱爲一個“trace”。每個 trace 中會調用若干個服務,爲了記錄調用了哪些服務,以及每次調用的消耗時間等信息,在每次調用服務時,埋入一個調用記錄,稱爲一個“span”。這樣,若干個有序的 span 就組成了一個 trace。在系統向外界提供服務的過程中,會不斷地有請求和響應發生,也就會不斷生成 trace,把這些帶有span 的 trace 記錄下來,就可以描繪出一幅系統的服務拓撲圖。附帶上 span 中的響應時間,以及請求成功與否等信息,就可以在發生問題的時候,找到異常的服務;根據歷史數據,還可以從系統整體層面分析出哪裏性能差,定位性能優化的目標。
Spring Cloud Sleuth爲服務之間調用提供鏈路追蹤。通過Sleuth可以很清楚的瞭解到一個服務請求經過了哪些服務,每個服務處理花費了多長。從而讓我們可以很方便的理清各微服務間的調用關係。此外Sleuth可以幫助我們:
- 耗時分析: 通過Sleuth可以很方便的瞭解到每個採樣請求的耗時,從而分析出哪些服務調用比較耗時;
- 可視化錯誤: 對於程序未捕捉的異常,可以通過集成Zipkin服務界面上看到;
- 鏈路優化: 對於調用比較頻繁的服務,可以針對這些服務實施一些優化措施。
spring cloud sleuth可以結合zipkin,將信息發送到zipkin,利用zipkin的存儲來存儲信息,利用zipkin ui來展示數據。
這是Spring Cloud Sleuth的概念圖:
ZipKin
Zipkin 是一個開放源代碼分佈式的跟蹤系統,由Twitter公司開源,它致力於收集服務的定時數據,以解決微服務架構中的延遲問題,包括數據的收集、存儲、查找和展現。
每個服務向zipkin報告計時數據,zipkin會根據調用關係通過Zipkin UI生成依賴關係圖,顯示了多少跟蹤請求通過每個服務,該系統讓開發者可通過一個 Web 前端輕鬆的收集和分析數據,例如用戶每次請求服務的處理時間等,可方便的監測系統中存在的瓶頸。
Zipkin提供了可插拔數據存儲方式:In-Memory、MySql、Cassandra以及Elasticsearch。接下來的測試爲方便直接採用In-Memory方式進行存儲,生產推薦Elasticsearch。
快速上手
創建zipkin-server項目
項目依賴
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
</dependency>
</dependencies>
啓動類
@SpringBootApplication
@EnableEurekaClient
@EnableZipkinServer
public class ZipkinApplication {
public static void main(String[] args) {
SpringApplication.run(ZipkinApplication.class, args);
}
}
使用了@EnableZipkinServer
註解,啓用Zipkin服務。
配置文件
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8761/eureka/
server:
port: 9000
spring:
application:
name: zipkin-server
配置完成後依次啓動示例項目:spring-cloud-eureka
、zipkin-server
項目。剛問地址:http://localhost:9000/zipkin/
可以看到Zipkin後臺頁面
項目添加zipkin支持
在項目spring-cloud-producer
和spring-cloud-zuul
中添加zipkin的支持。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
Spring應用在監測到Java依賴包中有sleuth和zipkin後,會自動在RestTemplate的調用過程中向HTTP請求注入追蹤信息,並向Zipkin Server發送這些信息。
同時配置文件中添加如下代碼:
spring:
zipkin:
base-url: http://localhost:9000
sleuth:
sampler:
percentage: 1.0
spring.zipkin.base-url指定了Zipkin服務器的地址,spring.sleuth.sampler.percentage將採樣比例設置爲1.0,也就是全部都需要。
Spring Cloud Sleuth有一個Sampler策略,可以通過這個實現類來控制採樣算法。採樣器不會阻礙span相關id的產生,但是會對導出以及附加事件標籤的相關操作造成影響。 Sleuth默認採樣算法的實現是Reservoir sampling,具體的實現類是PercentageBasedSampler,默認的採樣比例爲: 0.1(即10%)。不過我們可以通過spring.sleuth.sampler.percentage來設置,所設置的值介於0.0到1.0之間,1.0則表示全部採集。
這兩個項目添加zipkin之後,依次進行啓動。
進行驗證
這樣我們就模擬了這樣一個場景,通過外部請求訪問Zuul網關,Zuul網關去調用spring-cloud-producer
對外提供的服務。
四個項目均啓動後,在瀏覽器中訪問地址:http://localhost:8888/producer/hello?name=neo
兩次,然後再打開地址:http://localhost:9000/zipkin/
點擊對應按鈕進行查看。
點擊查找看到有兩條記錄
點擊記錄進去頁面,可以看到每一個服務所耗費的時間和順序
點擊依賴分析,可以看到項目之間的調用關係
歡迎大家一起學習研究相關技術願意瞭解框架技術:貳一四七七七五六叄叄