Spring Cloud 系列之 Sleuth 鏈路追蹤（一）

隨着微服務架構的流行，服務按照不一樣的維度進行拆分，一次請求每每須要涉及到多個服務。互聯網應用構建在不一樣的軟件模塊集上，這些軟件模塊，有多是由不一樣的團隊開發、可能使用不一樣的編程語言來實現、有可能布在了幾千臺服務器，橫跨多個不一樣的數據中心。所以，就須要一些能夠幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，可以快速定位和解決問題。在複雜的微服務架構系統中，幾乎每個前端請求都會造成一個複雜的分佈式服務調用鏈路。一個請求完整調用鏈可能以下圖所示：

　　隨着服務的愈來愈多，對調用鏈的分析會愈來愈複雜。它們之間的調用關係也許以下：

　　隨着業務規模不斷增大、服務不斷增多以及頻繁變動的狀況下，面對複雜的調用鏈路就帶來一系列問題：

• 如何快速發現問題？
• 如何判斷故障影響範圍？
• 如何梳理服務依賴以及依賴的合理性？
• 如何分析鏈路性能問題以及實時容量規劃？

　　

　　而鏈路追蹤的出現正是爲了解決這種問題，它能夠在複雜的服務調用中定位問題，還能夠在新人加入後臺團隊以後，讓其清楚地知道本身所負責的服務在哪一環。

　　除此以外，若是某個接口忽然耗時增長，也沒必要再逐個服務查詢耗時狀況，咱們能夠直觀地分析出服務的性能瓶頸，方便在流量激增的狀況下精準合理地擴容。

　　

什麼是鏈路追蹤

　　

　　「鏈路追蹤」一詞是在 2010 年提出的，當時谷歌發佈了一篇 Dapper 論文：Dapper，大規模分佈式系統的跟蹤系統，介紹了谷歌自研的分佈式鏈路追蹤的實現原理，還介紹了他們是怎麼低成本實現對應用透明的。

　　單純的理解鏈路追蹤，就是指一次任務的開始到結束，期間調用的全部系統及耗時（時間跨度）均可以完整記錄下來。

　　其實 Dapper 一開始只是一個獨立的調用鏈路追蹤系統，後來逐漸演化成了監控平臺，而且基於監控平臺孕育出了不少工具，好比實時預警、過載保護、指標數據查詢等。

　　除了谷歌的 Dapper，還有一些其餘比較有名的產品，好比阿里的鷹眼、大衆點評的 CAT、Twitter 的 Zipkin、Naver（著名社交軟件LINE的母公司）的 PinPoint 以及國產開源的 SkyWalking（已貢獻給 Apache） 等。

　　

什麼是 Sleuth

　　

　　Spring Cloud Sleuth 爲 Spring Cloud 實現了分佈式跟蹤解決方案。兼容 Zipkin，HTrace 和其餘基於日誌的追蹤系統，例如 ELK（Elasticsearch 、Logstash、 Kibana）。

　　Spring Cloud Sleuth 提供瞭如下功能：

• 鏈路追蹤：經過 Sleuth 能夠很清楚的看出一個請求都通過了那些服務，能夠很方便的理清服務間的調用關係等。
• 性能分析：經過 Sleuth 能夠很方便的看出每一個採樣請求的耗時，分析哪些服務調用比較耗時，當服務調用的耗時隨着請求量的增大而增大時， 能夠對服務的擴容提供必定的提醒。
• 數據分析，優化鏈路：對於頻繁調用一個服務，或並行調用等，能夠針對業務作一些優化措施。
• 可視化錯誤：對於程序未捕獲的異常，能夠配合 Zipkin 查看。

　　

專業術語

　　

　　點擊連接觀看：Sleuth 專業術語視頻（獲取更多請關注公衆號「哈嘍沃德先生」）

　　

Span

　　

　　基本工做單位，一次單獨的調用鏈能夠稱爲一個 Span，Dapper 記錄的是 Span 的名稱，以及每一個 Span 的 ID 和父 ID，以重建在一次追蹤過程當中不一樣 Span 之間的關係，圖中一個矩形框就是一個 Span，前端從發出請求到收到回覆就是一個 Span。

開始跟蹤的初始跨度稱爲root span。該跨度的 ID 的值等於跟蹤 ID。

　　Dapper 記錄了 span 名稱，以及每一個 span 的 ID 和父 span ID，以重建在一次追蹤過程當中不一樣 span 之間的關係。若是一個 span 沒有父 ID 被稱爲 root span。全部 span 都掛在一個特定的 Trace 上，也共用一個 trace id。

　　

Trace

　　

　　一系列 Span 組成的樹狀結構，一個 Trace 認爲是一次完整的鏈路，內部包含 n 多個 Span。Trace 和 Span 存在一對多的關係，Span 與 Span 之間存在父子關係。

　　舉個例子：客戶端調用服務 A 、服務 B 、服務 C 、服務 F，而每一個服務例如 C 就是一個 Span，若是在服務 C 中另起線程調用了 D，那麼 D 就是 C 的子 Span，若是在服務 D 中另起線程調用了 E，那麼 E 就是 D 的子 Span，這個 C -> D -> E 的鏈路就是一條 Trace。若是鏈路追蹤系統作好了，鏈路數據有了，藉助前端解析和渲染工具，能夠達到下圖中的效果：

Annotation

　　

　　用來及時記錄一個事件的存在，一些核心 annotations 用來定義一個請求的開始和結束。

• cs - Client Sent：客戶端發起一個請求，這個 annotation 描述了這個 span 的開始；
• sr - Server Received：服務端得到請求並準備開始處理它，若是 sr 減去 cs 時間戳即可獲得網絡延遲；
• ss - Server Sent：請求處理完成（當請求返回客戶端），若是 ss 減去 sr 時間戳即可獲得服務端處理請求須要的時間；
• cr - Client Received：表示 span 結束，客戶端成功接收到服務端的回覆，若是 cr 減去 cs 時間戳即可獲得客戶端從服務端獲取回覆的全部所需時間。

　　

實現原理

　　

　　首先感謝張以諾製做的實現原理圖。

　　若是想知道一個接口在哪一個環節出現了問題，就必須清楚該接口調用了哪些服務，以及調用的順序，若是把這些服務串起來，看起來就像鏈條同樣，咱們稱其爲調用鏈。

　　想要實現調用鏈，就要爲每次調用作個標識，而後將服務按標識大小排列，能夠更清晰地看出調用順序，咱們暫且將該標識命名爲 spanid。

　　實際場景中，咱們須要知道某次請求調用的狀況，因此只有 spanid 還不夠，得爲每次請求作個惟一標識，這樣才能根據標識查出本次請求調用的全部服務，而這個標識咱們命名爲 traceid。

　　如今根據 spanid 能夠輕易地知道被調用服務的前後順序，但沒法體現調用的層級關係，正以下圖所示，多個服務多是逐級調用的鏈條，也多是同時被同一個服務調用。

　　因此應該每次都記錄下是誰調用的，咱們用 parentid 做爲這個標識的名字。

　　到如今，已經知道調用順序和層級關係了，可是接口出現問題後，仍是不能找到出問題的環節，若是某個服務有問題，那個被調用執行的服務必定耗時很長，要想計算出耗時，上述的三個標識還不夠，還須要加上時間戳，時間戳能夠更精細一點，精確到微秒級。

　　只記錄發起調用時的時間戳還算不出耗時，要記錄下服務返回時的時間戳，善始善終才能算出時間差，既然返回的也記了，就把上述的三個標識都記一下吧，否則區分不出是誰的時間戳。

　　雖然能計算出從服務調用到服務返回的總耗時，可是這個時間包含了服務的執行時間和網絡延遲，有時候咱們須要區分出這兩類時間以方便作針對性優化。那如何計算網絡延遲呢？咱們能夠把調用和返回的過程分爲如下四個事件。

• Client Sent 簡稱 cs，客戶端發起調用請求到服務端。
• Server Received 簡稱 sr，指服務端接收到了客戶端的調用請求。
• Server Sent 簡稱 ss，指服務端完成了處理，準備將信息返給客戶端。
• Client Received 簡稱 cr，指客戶端接收到了服務端的返回信息。

　　假如在這四個事件發生時記錄下時間戳，就能夠輕鬆計算出耗時，好比 sr 減去 cs 就是調用時的網絡延遲，ss 減去 sr 就是服務執行時間，cr 減去 ss 就是服務響應的延遲，cr 減 cs 就是整個服務調用執行的時間。

　　其實 span 內除了記錄這幾個參數以外，還能夠記錄一些其餘信息，好比發起調用服務名稱、被調服務名稱、返回結果、IP、調用服務的名稱等，最後，咱們再把相同 parentid 的 span 信息合成一個大的 span 塊，就完成了一個完整的調用鏈。

　　

環境準備

　　

　　sleuth-demo 聚合工程。SpringBoot 2.2.4.RELEASE、Spring Cloud Hoxton.SR1。

• eureka-server：註冊中心
• eureka-server02：註冊中心
• gateway-server：Spring Cloud Gateway 服務網關
• product-service：商品服務，提供了根據主鍵查詢商品接口 http://localhost:7070/product/{id} 根據多個主鍵查詢商品接口 http://localhost:7070/product/listByIds
• order-service：訂單服務，提供了根據主鍵查詢訂單接口 http://localhost:9090/order/{id} 且訂單服務調用商品服務。

　　

　　

入門案例

　　

　　點擊連接觀看：Sleuth 入門案例視頻（獲取更多請關注公衆號「哈嘍沃德先生」）

　　

添加依賴

　　

　　在須要進行鏈路追蹤的項目中（服務網關、商品服務、訂單服務）添加 spring-cloud-starter-sleuth 依賴。

<!-- spring cloud sleuth 依賴 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>

　　

記錄日誌

　　

　　在須要鏈路追蹤的項目中添加 logback.xml 日誌文件，內容以下（logback 日誌的輸出級別須要是 DEBUG 級別）：

　　注意修改 <property name="log.path" value="${catalina.base}/gateway-server/logs"/> 中項目名稱。

　　日誌核心配置：%d{yyyy-MM-dd HH:mm:ss.SSS} [${applicationName},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-}] [%thread] %-5level %logger{50} - %msg%n

<?xml version="1.0" encoding="UTF-8"?>
<!-- 日誌級別從低到高分爲TRACE < DEBUG < INFO < WARN < ERROR < FATAL，若是設置爲WARN，則低於WARN的信息都不會輸出 -->
<!-- scan: 當此屬性設置爲true時，配置文件若是發生改變，將會被從新加載，默認值爲true -->
<!-- scanPeriod: 設置監測配置文件是否有修改的時間間隔，若是沒有給出時間單位，默認單位是毫秒。當scan爲true時，此屬性生效。默認的時間間隔爲1分鐘。 -->
<!-- debug: 當此屬性設置爲true時，將打印出logback內部日誌信息，實時查看logback運行狀態。默認值爲false。 -->
<configuration scan="true" scanPeriod="10 seconds">
    <!-- 日誌上下文名稱 -->
    <contextName>my_logback</contextName>
    <!-- name的值是變量的名稱，value的值是變量定義的值。經過定義的值會被插入到logger上下文中。定義變量後，可使「${}」來使用變量。 -->
    <property name="log.path" value="${catalina.base}/gateway-server/logs"/>
    <!-- 加載 Spring 配置文件信息 -->
    <springProperty scope="context" name="applicationName" source="spring.application.name" defaultValue="localhost"/>
    <!-- 日誌輸出格式 -->
    <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} [${applicationName},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-}] [%thread] %-5level %logger{50} - %msg%n"/>

    <!--輸出到控制檯-->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <!--此日誌appender是爲開發使用，只配置最底級別，控制檯輸出的日誌級別是大於或等於此級別的日誌信息-->
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>DEBUG</level>
        </filter>
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
            <!-- 設置字符集 -->
            <charset>UTF-8</charset>
        </encoder>
    </appender>

    <!-- 輸出到文件 -->
    <!-- 時間滾動輸出 level爲 DEBUG 日誌 -->
    <appender name="DEBUG_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在記錄的日誌文件的路徑及文件名 -->
        <file>${log.path}/log_debug.log</file>
        <!--日誌文件輸出格式-->
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
            <charset>UTF-8</charset> <!-- 設置字符集 -->
        </encoder>
        <!-- 日誌記錄器的滾動策略，按日期，按大小記錄 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 日誌歸檔 -->
            <fileNamePattern>${log.path}/debug/log-debug-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日誌文件保留天數-->
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <!-- 此日誌文件只記錄debug級別的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>DEBUG</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 時間滾動輸出 level爲 INFO 日誌 -->
    <appender name="INFO_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在記錄的日誌文件的路徑及文件名 -->
        <file>${log.path}/log_info.log</file>
        <!--日誌文件輸出格式-->
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
            <charset>UTF-8</charset>
        </encoder>
        <!-- 日誌記錄器的滾動策略，按日期，按大小記錄 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 天天日誌歸檔路徑以及格式 -->
            <fileNamePattern>${log.path}/info/log-info-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日誌文件保留天數-->
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <!-- 此日誌文件只記錄info級別的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>INFO</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 時間滾動輸出 level爲 WARN 日誌 -->
    <appender name="WARN_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在記錄的日誌文件的路徑及文件名 -->
        <file>${log.path}/log_warn.log</file>
        <!--日誌文件輸出格式-->
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
            <charset>UTF-8</charset> <!-- 此處設置字符集 -->
        </encoder>
        <!-- 日誌記錄器的滾動策略，按日期，按大小記錄 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${log.path}/warn/log-warn-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <!-- 每一個日誌文件最大100MB -->
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日誌文件保留天數-->
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <!-- 此日誌文件只記錄warn級別的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>WARN</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 時間滾動輸出 level爲 ERROR 日誌 -->
    <appender name="ERROR_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 正在記錄的日誌文件的路徑及文件名 -->
        <file>${log.path}/log_error.log</file>
        <!--日誌文件輸出格式-->
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
            <charset>UTF-8</charset> <!-- 此處設置字符集 -->
        </encoder>
        <!-- 日誌記錄器的滾動策略，按日期，按大小記錄 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${log.path}/error/log-error-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                <maxFileSize>100MB</maxFileSize>
            </timeBasedFileNamingAndTriggeringPolicy>
            <!--日誌文件保留天數-->
            <maxHistory>15</maxHistory>
            <!-- 日誌量最大 10 GB -->
            <totalSizeCap>10GB</totalSizeCap>
        </rollingPolicy>
        <!-- 此日誌文件只記錄ERROR級別的 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <!-- 對於類路徑以 com.example.logback 開頭的Logger,輸出級別設置爲warn,而且只輸出到控制檯 -->
    <!-- 這個logger沒有指定appender，它會繼承root節點中定義的那些appender -->
    <!-- <logger name="com.example.logback" level="warn"/> -->

    <!--經過 LoggerFactory.getLogger("myLog") 能夠獲取到這個logger-->
    <!--因爲這個logger自動繼承了root的appender，root中已經有stdout的appender了，本身這邊又引入了stdout的appender-->
    <!--若是沒有設置 additivity="false" ,就會致使一條日誌在控制檯輸出兩次的狀況-->
    <!--additivity表示要不要使用rootLogger配置的appender進行輸出-->
    <logger name="myLog" level="INFO" additivity="false">
        <appender-ref ref="CONSOLE"/>
    </logger>

    <!-- 日誌輸出級別及方式 -->
    <root level="DEBUG">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="DEBUG_FILE"/>
        <appender-ref ref="INFO_FILE"/>
        <appender-ref ref="WARN_FILE"/>
        <appender-ref ref="ERROR_FILE"/>
    </root>

</configuration>

　　

訪問

　　

　　訪問：http://localhost:9000/order-service/order/1 ，結果以下：

　　服務網關打印信息：

[gateway-server,95aa725089b757f8,95aa725089b757f8]

　　商品服務打印信息

[product-service,95aa725089b757f8,e494e064842ce4e8]

　　訂單服務打印信息

[order-service,95aa725089b757f8,f4ee41a6dcf08717]

　　經過打印信息能夠得知，整個鏈路的 traceId 爲：95aa725089b757f8，spanId 爲：e494e064842ce4e8 和 f4ee41a6dcf08717。

　　查看日誌文件並非一個很好的方法，當微服務愈來愈多日誌文件也會愈來愈多，查詢工做會變得愈來愈麻煩，Spring 官方推薦使用 Zipkin 進行鏈路跟蹤。Zipkin 能夠將日誌聚合，並進行可視化展現和全文檢索。

　　

使用 Zipkin 進行鏈路跟蹤

　　

什麼是 Zipkin

　　

　　

　　Zipkin 是 Twitter 公司開發貢獻的一款開源的分佈式實時數據追蹤系統（Distributed Tracking System），基於 Google Dapper 的論文設計而來，其主要功能是彙集各個異構系統的實時監控數據。

　　它能夠收集各個服務器上請求鏈路的跟蹤數據，並經過 Rest API 接口來輔助咱們查詢跟蹤數據，實現對分佈式系統的實時監控，及時發現系統中出現的延遲升高問題並找出系統性能瓶頸的根源。除了面向開發的 API 接口以外，它還提供了方便的 UI 組件，每一個服務向 Zipkin 報告計時數據，Zipkin 會根據調用關係生成依賴關係圖，幫助咱們直觀的搜索跟蹤信息和分析請求鏈路明細。Zipkin 提供了可插拔數據存儲方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。

　　分佈式跟蹤系統還有其餘比較成熟的實現，例如：Naver 的 PinPoint、Apache 的 HTrace、阿里的鷹眼 Tracing、京東的 Hydra、新浪的 Watchman，美團點評的 CAT，Apache 的 SkyWalking 等。

　　

工做原理

　　

　　共有四個組件構成了 Zipkin：

• Collector：收集器組件，處理從外部系統發送過來的跟蹤信息，將這些信息轉換爲 Zipkin 內部處理的 Span 格式，以支持後續的存儲、分析、展現等功能。
• Storage：存儲組件，處理收集器接收到的跟蹤信息，默認將信息存儲在內存中，能夠修改存儲策略使用其餘存儲組件，支持 MySQL，Elasticsearch 等。
• Web UI：UI 組件，基於 API 組件實現的上層應用，提供 Web 頁面，用來展現 Zipkin 中的調用鏈和系統依賴關係等。
• RESTful API：API 組件，爲 Web 界面提供查詢存儲中數據的接口。

　　

　　Zipkin 分爲兩端，一個是 Zipkin 服務端，一個是 Zipkin 客戶端，客戶端也就是微服務的應用，客戶端會配置服務端的 URL 地址，一旦發生服務間的調用的時候，會被配置在微服務裏面的 Sleuth 的監聽器監聽，並生成相應的 Trace 和 Span 信息發送給服務端。發送的方式有兩種，一種是消息總線的方式如 RabbitMQ 發送，還有一種是 HTTP 報文的方式發送。

　　

服務端部署

　　

　　服務端是一個獨立的可執行的 jar 包，官方下載地址：https://search.maven.org/remote_content?g=io.zipkin&a=zipkin-server&v=LATEST&c=exec，使用 java -jar zipkin.jar 命令啓動，端口默認爲 9411。咱們下載的 jar 包爲：zipkin-server-2.20.1-exec.jar，啓動命令以下：

java -jar zipkin-server-2.20.1-exec.jar

　　

　　訪問：http://localhost:9411/ 結果以下：

　　目前最新版界面。

　　

　　以前舊版本界面。

　　

客戶端部署

　　

　　點擊連接觀看：Zipkin 客戶端部署視頻（獲取更多請關注公衆號「哈嘍沃德先生」）

　　

添加依賴

　　

　　在須要進行鏈路追蹤的項目中（服務網關、商品服務、訂單服務）添加 spring-cloud-starter-zipkin 依賴。

<!-- spring cloud zipkin 依賴 -->
<dependency> 
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

　　

配置文件

　　

　　在須要進行鏈路追蹤的項目中（服務網關、商品服務、訂單服務）配置 Zipkin 服務端地址及數據傳輸方式。默認即以下配置。

spring:
  zipkin:
    base-url: http://localhost:9411/ # 服務端地址
    sender:
      type: web                      # 數據傳輸方式，web 表示以 HTTP 報文的形式向服務端發送數據
  sleuth:
    sampler:
      probability: 1.0               # 收集數據百分比，默認 0.1（10%）

　　

訪問

　　

　　訪問：http://localhost:9000/order-service/order/1 結果以下：

　　

　　新版操做以下：

　　訪問：http://localhost:9411/ 根據時間過濾點擊搜索結果以下：

　　

　　點擊對應的追蹤信息可查看請求鏈路詳細。

　　

　　經過依賴能夠查看鏈路中服務的依賴關係。

　　

　　舊版操做以下：

　　訪問：http://localhost:9411/ 點擊查找結果以下：

　　

　　點擊對應的追蹤信息可查看請求鏈路詳細。

　　

　　經過依賴能夠查看鏈路中服務的依賴關係。

　　

　　Zipkin Server 默認存儲追蹤數據至內存中，這種方式並不適合生產環境，一旦 Server 關閉重啓或者服務崩潰，就會致使歷史數據消失。Zipkin 支持修改存儲策略使用其餘存儲組件，支持 MySQL，Elasticsearch 等。

下一篇咱們講解 Sleuth 基於 Zipkin 存儲鏈路追蹤數據至 MySQL，Elasticsearch 以及使用 MQ 存儲鏈路追蹤數據至 MySQL，Elasticsearch，記得關注噢～

　　本文采用 知識共享「署名-非商業性使用-禁止演繹 4.0 國際」許可協議。

　　你們能夠經過 分類 查看更多關於 Spring Cloud 的文章。

　　

　　🤗 您的點贊和轉發是對我最大的支持。

　　📢 掃碼關注 哈嘍沃德先生「文檔 + 視頻」每篇文章都配有專門視頻講解，學習更輕鬆噢 ~