在微服務系統中，隨著業務的發展，系統會變得越來越大，這樣一來各個服務之間的調用關系也就變得越來越復雜。一個 HTTP 請求會調用多個不同的服務接口來處理返回最后的結果，在這個調用過程中，可能會因為某個服務出現網絡延遲或異常導致請求失敗。Spring Cloud Sleuth+Zikpin可以幫助我們快速定位異常服務,跟蹤請求的調用鏈路。

代碼實現

由三個工程組成:一個zipkin-server,它的主要作用是收集調用數據，并展示；一個member-server,對外暴露一個getMember接口；一個order-server,對外暴露getOrder接口和info接口；這兩個service可以相互調用

zipkin-server端:

springcloud2.0之前需要自己搭建一個Zikpin Server服務;2.0之后官方提供了完整的jar包實現這一功能,只要啟動運行即可

java –jar zipkin.jar (默認端口9411)

zipkin client端:

由于zipkin默認的采用頻率是0.1,測試的時候我選擇設置采樣頻率為1;這樣更方便學習

在啟動類里加上如下代碼,注入Bean:

? @Bean
?? ?public Sampler defaultSampler() {
?? ??? ?return Sampler.ALWAYS_SAMPLE;
?? ?}

接下來就開始踩坑了

我的請求路徑是?這樣的:

getOrder(order-server)---->getMember(member-server)--->info(order-server)

?

但是在zikpin的展示頁面,該次請求被拆分成了兩個獨立的trace

這個原因目前還不清楚,代碼沒什么問題。后來我想著通過bean注入的方式無法實現,就嘗試了配置文件去設置采樣頻率

由于網上比較都是使用的1.5版本搭建的服務,我一開始使用的

spring.sleuth.sampler.percentage = 1.0 ,但是一直沒有生效,然后去看了springcloud官網上的設置,發現從2.0該配置變成了如下:

我在項目的配置文件中設置spring.sleuth.sampler.probability = 1.0 同時去掉了之前注入bean的代碼

測試運行結果和預期比較一致

我觀察了下該trace的json,通過traceId和spanId分析了下執行過程

? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? parentId? ? ? ? ? ? ? ? ? ? ? ? ? ? tranceId? ? ? ? ? ? ? ? ? spanId
order-server提供getOrder接口(server) ? ? ? ? ? ? ? ? ? ?null? ? ? ? ? ? ? ? ? ? ? ? ?53a1e40ac156a71c ? ?53a1e40ac156a71c

order-server調用getMember (client) ? ? ? ? ? ? ? ? ?53a1e40ac156a71c? ? 53a1e40ac156a71c ? ?10113c2e75e079c5
member-server提供getMember接口 (server) ? ?53a1e40ac156a71c? ? ?53a1e40ac156a71c ? ?10113c2e75e079c5

會員調用order-server info接口(client) ? ? ? ? ? ? ? 10113c2e75e079c5? ? ? 53a1e40ac156a71c ? ?8e210f5c7a87408a

這里鏈路的分析結果和我實際調用的結果一致

?

我的理解:client表示調用服務方,server表示服務提供方

比方說:這里我在order-server里調用了member-server的getMember接口,那么order-server是client ，member-server是server;

同一個服務可以既是server又是client

?

?

?

?

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的springcloud 2.0 服务链路追踪踩坑以及一些小小的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。