在微服務框架中,一個由客戶端發起的請求在後端系統中會通過多個不一樣的服務節點調用來協同產生最後的請求結果,每個前端請求都會造成一條複雜的分佈式服務調用鏈路,鏈路中的任何一環出現高延時或錯誤都會引發整個請求最後的失敗。java
Spring Cloud Sleuth爲Spring Cloud實現了一種分佈式跟蹤解決方案。git
完整的調用鏈路:一條鏈路經過Trace Id惟一標識,Span標識發起的請求信息,各span經過parent id關聯起來。spring
下載地址:https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/shell
運行zipkin:後端
$ java -jar zipkin-server-2.12.9-exec.jar
訪問:localhost:9411/zipkin/
app
本次鏈路追蹤的演示,選擇不新建項目,選取老項目演示。框架
選取cloud-provider-payment8001
做爲服務的提供者,選取cloud-consumer-order80
做爲服務的消費者。maven
倆服務都添加配置pom.xml分佈式
<!--包含了sleuth+zipkin--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>
倆服務都添加配置yml
spring: application: name: cloud-payment-service # 服務名稱! zipkin: base-url: http://localhost:9411 # 監控中心 sleuth: sampler: #採樣率值介於 0 到 1 之間,1 則表示所有采集 probability: 1
服務提供者提供測試接口
@GetMapping("/payment/zipkin") public String paymentZipkin(){ return "payment zipkin !"; }
服務消費者提供測試接口
@GetMapping("/consumer/payment/zipkin") public String paymentZipkin(){ return restTemplate.getForObject("http://localhost:8001" + "/payment/zipkin/",String.class); }
依次啓動7001,80,8001模塊,消費者調用測試接口,產生調用鏈路,進入zipkin管理頁面,能夠觀測調用鏈路的響應狀況等。
本系列文章爲《尚硅谷SpringCloud教程》的學習筆記【版本稍微有些不一樣,後續遇到bug再作相關說明】,主要作一個長期的記錄,爲之後學習的同窗提供示例,代碼同步更新到Gitee:https://gitee.com/tqbx/spring-cloud-learning,而且以標籤的形式詳細區分每一個步驟,這個系列文章也會同步更新。