建站
咨詢
售后
建站咨詢
新聞中心
前言Hi,大家好,我是麥洛,今天帶大家來了解一下SpringCloud Sleuth,這篇文章主要向大家介紹一下以下內(nèi)容
我們提供的服務(wù)有：網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、屯昌ssl等。為上1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的屯昌網(wǎng)站制作公司
Sleuth介紹
你或許曾經(jīng)聽過這么一句話,一個新技術(shù)的出現(xiàn)是為了解決一個痛點問題。在介紹Sleuth之前,我們需要了解一下在沒有Sleuth之前,我們的微服務(wù)遇到了什么問題?
1.微服務(wù)的現(xiàn)狀?
前段時間在一個交流群吹水,一個大佬說他們公司總共有上百個微服務(wù)。假如這句話真實，那么他們公司微服務(wù)調(diào)用可能會如下圖所示:
來自網(wǎng)絡(luò)的這張圖很好的說明了微服務(wù)調(diào)用之間的復(fù)雜性。每一次前端請求往往需要涉及到多個服務(wù)。這些服務(wù)有可能是由不同的團隊開發(fā)、可能使用不同的編程語言來實現(xiàn)、有可能布在了幾千臺服務(wù)器，橫跨多個不同的數(shù)據(jù)中心。因此，就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問題的工具，以便發(fā)生故障的時候，能夠快速定位和解決問題。所以，鏈路追蹤這個思想就被人提了出來，而我們今天要討論的Sleuth就是借鑒該思想演變來的分布式追蹤解決方案。
2.微服務(wù)跟蹤解決了什么問題?
微服務(wù)跟蹤(sleuth)其實是一個工具,它在整個分布式系統(tǒng)中能跟蹤一個用戶請求的過程(包括數(shù)據(jù)采集，數(shù)據(jù)傳輸，數(shù)據(jù)存儲，數(shù)據(jù)分析，數(shù)據(jù)可視化)，捕獲這些跟蹤數(shù)據(jù)，就能構(gòu)建微服務(wù)的整個調(diào)用鏈的視圖，這是調(diào)試和監(jiān)控微服務(wù)的關(guān)鍵工具。SpringCloudSleuth有4個特點
Sleuth基本術(shù)語
Spring Cloud Sleuth采用的是Google的開源項目Dapper的專業(yè)術(shù)語。
- Span：基本工作單元，發(fā)送一個遠(yuǎn)程調(diào)度任務(wù) 就會產(chǎn)生一個Span，Span是一個64位ID唯一標(biāo)識的，Trace是用另一個64位ID唯一標(biāo)識的，Span還有其他數(shù)據(jù)信息，比如摘要、時間戳事件、Span的ID、以及進度ID。
- Trace：一系列Span組成的一個樹狀結(jié)構(gòu)。請求一個微服務(wù)系統(tǒng)的API接口，這個API接口，需要調(diào)用多個微服務(wù)，調(diào)用每個微服務(wù)都會產(chǎn)生一個新的Span，所有由這個請求產(chǎn)生的Span組成了這個Trace。
- Annotation：用來及時記錄一個事件的，一些核心注解用來定義一個請求的開始和結(jié)束 。這些注解包括以下：
- cs - Client Sent -客戶端發(fā)送一個請求，這個注解描述了這個Span的開始
- sr - Server Received -服務(wù)端獲得請求并準(zhǔn)備開始處理它，如果將其sr減去cs時間戳便可得到網(wǎng)絡(luò)傳輸?shù)臅r間。
- ss - Server Sent (服務(wù)端發(fā)送響應(yīng))–該注解表明請求處理的完成(當(dāng)請求返回客戶端)，如果ss的時間戳減去sr時間戳，就可以得到服務(wù)器請求的時間。
- cr - Client Received (客戶端接收響應(yīng))-此時Span的結(jié)束，如果cr的時間戳減去cs時間戳便可以得到整個請求所消耗的時間。
Sleuth入門案例
首先我們搞一個項目,大概如下面樣子
我們引入下面的依賴
org.springframework.boot spring-boot-starter-web org.springframework.cloud spring-cloud-starter-sleuth org.projectlombok lombok org.springframework.boot spring-boot-starter-test test org.junit.vintage junit-vintage-engine
我們創(chuàng)建一個測試類:
- package com.milo.sleuth.controller;
- import lombok.extern.slf4j.Slf4j;
- import org.springframework.web.bind.annotation.RequestMapping;
- import org.springframework.web.bind.annotation.RestController;
- @RestController
- @Slf4j
- public class Example {
- @RequestMapping("/")
- String home() {
- log.info("Hello world!");
- return "Hello World!";
- }
- }
啟動項目以后,我們訪問一下:
這時候,我們來看看日志情況:
我們來看看它們分別代表什么意思
- 第一個就是我們服務(wù)名稱,對應(yīng)我們配置文件中的spring.application.name
- 第二個就是traceId
- 第三個就是spanId
雖然我們現(xiàn)在通過日志文件也可以識別調(diào)用路徑,貌似并不是很方便,很直觀,接下里我們來了解一下Zipkin
Zipkin介紹
Zipkin是一個分布式跟蹤系統(tǒng)。它有助于收集解決服務(wù)體系結(jié)構(gòu)中的延遲問題所需的時序數(shù)據(jù)。功能包括該數(shù)據(jù)的收集和查找。
如果您在日志文件中有跟蹤ID，則可以直接跳至該跟蹤ID。否則，您可以基于諸如服務(wù)，操作名稱，標(biāo)簽和持續(xù)時間之類的屬性進行查詢。將為您匯總一些有趣的數(shù)據(jù)，例如服務(wù)中花費的時間百分比以及操作是否失敗。
Zipkin UI還提供了一個依賴關(guān)系圖，該關(guān)系圖顯示了每個應(yīng)用程序中跟蹤了多少個請求。這對于識別包括錯誤路徑或?qū)Σ毁澇墒褂玫姆?wù)的調(diào)用在內(nèi)的匯總行為可能會有所幫助。
需要對應(yīng)用程序進行“儀表化”以將跟蹤數(shù)據(jù)報告給Zipkin。這通常意味著配置跟蹤器或儀器庫。向Zipkin報告數(shù)據(jù)的最流行方法是通過HTTP或Kafka，盡管存在許多其他選項，例如Apache ActiveMQ，gRPC和RabbitMQ。提供給UI的數(shù)據(jù)存儲在內(nèi)存中，或持久存儲在受支持的后端(例如Apache Cassandra或Elasticsearch)中。
Sleuth整合Zipkin
Zipkin 分為兩端，一個是 Zipkin 服務(wù)端，一個是 Zipkin 客戶端，客戶端也就是微服務(wù)的應(yīng)用，客戶端會配置服務(wù)端的 URL 地址，一旦發(fā)生服務(wù)間的調(diào)用的時候，會被配置在微服務(wù)里面的 Sleuth 的監(jiān)聽器監(jiān)聽，并生成相應(yīng)的 Trace 和 Span 信息發(fā)送給服務(wù)端。發(fā)送的方式有兩種，一種是消息總線的方式如 RabbitMQ 發(fā)送，還有一種是 HTTP 報文的方式發(fā)送。
客戶端
首先,在剛剛的依賴文件中,我們加一個新成員
org.springframework.cloud spring-cloud-starter-zipkin
接著修改配置文件
- # 應(yīng)用名稱
- spring:
- application:
- name: springcloud-sleuth
- # 應(yīng)用服務(wù) WEB 訪問端口
- server:
- port: 9876
- zipkin:
- base-url: http://localhost:9411/ # 服務(wù)端地址
- sender:
- type: web # 數(shù)據(jù)傳輸方式，web 表示以 HTTP 報文的形式向服務(wù)端發(fā)送數(shù)據(jù)
- sleuth:
- sampler:
- probability: 1.0 # 收集數(shù)據(jù)百分比，默認(rèn) 0.1（10%）
服務(wù)端
Zipkin的服務(wù)端是一個可執(zhí)行的jar文件,我們需要去下載
- “下載地址:https://search.maven.org/remote_content?g=io.zipkin&a=zipkin-server&v=LATEST&c=exec
上面地址默認(rèn)下載最新版本,大家也可以去下面的網(wǎng)址下載指定版本
現(xiàn)在我們啟動jar包
- “java -jar zipkin-server-2.23.2-exec.jar
測試效果
接下來我們訪問一下http://localhost:9411/zipkin/,結(jié)果如下:
環(huán)境搭架好了,現(xiàn)在我們測試一把,看看接入Zipkin之后,我們會看到什么效果?
我們訪問http://localhost:9876/之后,點擊Zipkin控制臺的Run Query查詢一下,看到如下效果:
繼續(xù)點擊show,我們?nèi)タ纯丛斍?/p>
果然很強大,執(zhí)行時間,什么請求方式,請求路徑,那個類,那個方法一目了然
鑒于我們剛剛新建的只是一次很簡單的調(diào)用,不足以模擬微服務(wù)場景,接下來我們來看一個復(fù)雜一點的場景;
這里為了偷懶,我們就不去創(chuàng)建自己的微服務(wù),使用官方給我們提供的測試案例brave-example,如下所示
我們把代碼搞下來,這個項目好像整合了好多技術(shù)的測試案例,看不懂,我就研究了下面的這個跑起來測試一下
我們用idea把這個項目導(dǎo)入進來,大概長這個鬼樣子
- Backend代表后端服務(wù)
- Frontend代表前端服務(wù)
現(xiàn)在,我們首先保證我們Zipkin的服務(wù)端是ok的,這時候你首先啟動后端服務(wù),然后啟動前端服務(wù),其實就是執(zhí)行以下main方法,接下來我們訪問一下http://127.0.0.1:8081/,如下圖所示
現(xiàn)在我們?nèi)ipkin查詢一下,發(fā)現(xiàn)了一個新大陸,開心
就行show一下,看看里面啥情況
總結(jié)
本篇文章主要介紹了Sleuth的入門知識,并且整合Zipkin來可視化顯示調(diào)用鏈路的整體情況,但是目前Zipkin數(shù)據(jù)存在于內(nèi)存中,我們可以在接入Elasticsearch等工具來做數(shù)據(jù)持久化。謝謝大家，今天的分享就到這里。
- 源碼 https://gitee.com/milogenius/milogenius-springcloud
- 模塊:springcloud-sleut
網(wǎng)站標(biāo)題：一篇帶給你SpringCloudSleuth入門介紹
瀏覽路徑：http://fisionsoft.com.cn/article/dhcdcso.html
