1. 程式人生 > >Spring Cloud構建微服務架構:分散式服務跟蹤(跟蹤原理)

Spring Cloud構建微服務架構:分散式服務跟蹤(跟蹤原理)

通過上一篇《分散式服務跟蹤(入門)》的例子,我們已經通過Spring Cloud Sleuth往微服務應用中添加了實現分散式跟蹤具備的基本要素。下面通過本文來詳細說說實現分散式服務跟蹤的一些要點。

分散式系統中的服務跟蹤在理論上並不複雜,它主要包括下面兩個關鍵點:

  • 為了實現請求跟蹤,當請求傳送到分散式系統的入口端點時,只需要服務跟蹤框架為該請求建立一個唯一的跟蹤標識,同時在分散式系統內部流轉的時候,框架始終保持傳遞該唯一標識,直到返回給請求方為止,這個唯一標識就是前文中提到的 TraceID。通過 TraceID的記錄,我們就能將所有請求過程日誌關聯起來。

  • 為了統計各處理單元的時間延遲,當請求達到各個服務元件時,或是處理邏輯到達某個狀態時,也通過一個唯一標識來標記它的開始、具體過程以及結束,該標識就是我們前文中提到的Span ID,對於每個Span來說,它必須有開始和結束兩個節點,通過記錄開始Span和結束Span的時間戳,就能統計出該Span的時間延遲,除了時間戳記錄之外,它還可以包含一些其他元資料,比如:事件名稱、請求資訊等。

在快速入門示例中,我們輕鬆實現了日誌級別的跟蹤資訊接入,這完全歸功於 spring-cloud-starter-sleuth元件的實現。在Spring Boot應用中,通過在工程中引入 spring-cloud-starter-sleuth依賴之後, 它會自動的為當前應用構建起各通訊通道的跟蹤機制,比如:

  • 通過諸如RabbitMQ、Kafka(或者其他任何Spring Cloud Stream繫結器實現的訊息中介軟體)傳遞的請求

  • 通過Zuul代理傳遞的請求

  • 通過 RestTemplate發起的請求

在快速入門示例中,由於 trace-1trace-2發起的請求是通過 RestTemplate實現的,所以 spring

-cloud-starter-sleuth元件會對該請求進行處理,在傳送到 trace-2之前sleuth會為在該請求的Header中增加實現跟蹤需要的重要資訊,主要有下面這幾個(更多關於頭資訊的定義我們可以通過檢視 org.springframework.cloud.sleuth.Span的原始碼獲取):

  • X-B3-TraceId:一條請求鏈路(Trace)的唯一標識,必須值

  • X-B3-SpanId:一個工作單元(Span)的唯一標識,必須值

  • X-B3-ParentSpanId::標識當前工作單元所屬的上一個工作單元,Root Span(請求鏈路的第一個工作單元)的該值為空

  • X-B3-Sampled:是否被抽樣輸出的標誌,1表示需要被輸出,0表示不需要被輸出

  • X-Span-Name:工作單元的名稱

我們可以通過對 trace-2的實現做一些修改來輸出這些頭部資訊,具體如下:

  1. @RequestMapping(value ="/trace-2", method =RequestMethod.GET)

  2. publicString trace(HttpServletRequest request){

  3.    logger.info("===<call trace-2, TraceId={}, SpanId={}>===",

  4.            request.getHeader("X-B3-TraceId"), request.getHeader("X-B3-SpanId"));

  5. return"Trace";

  6. }

通過上面的改造,我們再執行快速入門的示例內容,併發起對 trace-1的介面訪問,我們可以得到如下輸出內容。其中在 trace-2的控制檯中,輸出了當前正在處理的 TraceIDSpanId資訊。

  1. -- trace-1

  2. INFO [trace-1,a6e9175ffd5d2c88,8524f519b8a9e399,true]10532---[nio-9101-exec-2] icationEnhancerBySpringCGLIB27aa9624 :===<call trace-1>===

  3. -- trace-2

  4. INFO [trace-2,a6e9175ffd5d2c88,ce60dcf1e2ed918f,true]1208---[nio-9102-exec-3] icationEnhancerBySpringCGLIBa7d84797 :===<call trace-2,TraceId=a6e9175ffd5d2c88,SpanId=be4949ec115e554e>===

為了更直觀的觀察跟蹤資訊,我們還可以在 application.properties中增加下面的配置:

  1. logging.level.org.springframework.web.servlet.DispatcherServlet=DEBUG

通過將Spring MVC的請求分發日誌級別調整為 DEBUG級別,我們可以看到更多跟蹤資訊:

  1. -- trace-1

  2. 2016-11-2709:26:52.663 DEBUG [trace-1,a6e9175ffd5d2c88,a6e9175ffd5d2c88,true]10532---[nio-9101-exec-2] o.s.web.servlet.DispatcherServlet:DispatcherServlet with name 'dispatcherServlet' processing GET request for[/trace-1]

  3. 2016-11-2709:26:52.666 DEBUG [trace-1,a6e9175ffd5d2c88,a6e9175ffd5d2c88,true]10532---[nio-9101-exec-2] o.s.web.servlet.DispatcherServlet:Last-Modified value for[/trace-1] is:-1

  4. 2016-11-2709:26:52.685 DEBUG [trace-1,a6e9175ffd5d2c88,8524f519b8a9e399,true]10532---[nio-9101-exec-2] o.s.web.servlet.DispatcherServlet:NullModelAndView returned to DispatcherServlet with name 'dispatcherServlet': assuming HandlerAdapter completed request handling

  5. 2016-11-2709:26:52.685 DEBUG [trace-1,a6e9175ffd5d2c88,a6e9175ffd5d2c88,true]10532---[nio-9101-exec-2] o.s.web.servlet.DispatcherServlet:Successfully completed request

  6. -- trace-2

  7. 2016-11-2709:26:52.673 DEBUG [trace-2,a6e9175ffd5d2c88,be4949ec115e554e,true]1208---[nio-9102-exec-3] o.s.web.servlet.DispatcherServlet:DispatcherServlet with name 'dispatcherServlet' processing GET request for[/trace-2]

  8. 2016-11-2709:26:52.679 DEBUG [trace-2,a6e9175ffd5d2c88,be4949ec115e554e,true]1208---[nio-9102-exec-3] o.s.web.servlet.DispatcherServlet:Last-Modified value for[/trace-2] is:-1

  9. 2016-11-2709:26:52.682 DEBUG [trace-2,a6e9175ffd5d2c88,ce60dcf1e2ed918f,true]1208---[nio-9102-exec-3] o.s.web.servlet.DispatcherServlet:NullModelAndView returned to DispatcherServlet with name 'dispatcherServlet': assuming HandlerAdapter completed request handling

  10. 2016-11-2709:26:52.683 DEBUG [trace-2,a6e9175ffd5d2c88,be4949ec115e554e,true]1208---[nio-9102-exec-3] o.s.web.servlet.DispatcherServlet:Successfully completed request

完整示例:

讀者可以根據喜好選擇下面的兩個倉庫中檢視 trace-1trace-2兩個專案:

  • Github:https://github.com/dyc87112/SpringCloud-Learning/

  • Gitee:https://gitee.com/didispace/SpringCloud-Learning/

如果您對這些感興趣,歡迎star、follow、收藏、轉發給予支援!

本文內容部分節選自我的《Spring Cloud微服務實戰》,但對依賴的Spring Boot和Spring Cloud版本做了升級。

相關推薦

Spring Cloud構建服務架構分散式服務跟蹤收集原理【Dalston版】

                在本節內容之前,我們已經對如何引入Sleuth跟蹤資訊和搭建Zipkin服務端分析跟蹤延遲的過程做了詳細的介紹,相信大家對於Sleuth和Zipkin已經有了一定的感性認識。接下來,我們介紹一下關於Zipkin收集跟蹤資訊的過程細節,以幫助我們更好地理解Sleuth生產跟蹤資訊

Spring Cloud構建服務架構分散式服務跟蹤跟蹤原理

通過上一篇《分散式服務跟蹤(入門)》的例子,我們已經通過Spring Cloud Sleuth往微服務應用中添加了實現分散式跟蹤具備的基本要素。下面通過本文來詳細說說實現分散式服務跟蹤的一些要點。分散式系統中的服務跟蹤在理論上並不複雜,它主要包括下面兩個關鍵點:為了實現請求跟

Spring Cloud構建服務架構服務消費基礎

消費 ring str frame emp default class a template pom.xml 使用LoadBalancerClient在Spring Cloud Commons中提供了大量的與服務治理相關的抽象接口,包括DiscoveryClient、這裏我

Spring Cloud構建服務架構服務註冊與發現 Eureka

Spring Cloud構建微服務架構:服務註冊與發現Eureka 【Dalston版】 原創   2018-04-10  宗野   Spring Cloud 已經

Spring Cloud構建服務架構服務容錯保護Hystrix服務降級

tro sco load 服務架構 延遲 正常 map ati href 動手試一試 在開始使用Spring Cloud Hystrix實現斷路器之前,我們先拿之前實現的一些內容作為基礎,其中包括: eureka-server工程:服務註冊中心,端口:1001 eurek

Spring Cloud構建服務架構服務消費Ribbon

Spring Cloud Ribbon Spring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端負載均衡的工具。它是一個基於HTTP和TCP的客戶端負載均衡器。它可以通過在客戶端中配置ribbonServerList來設定服務端列表去輪詢訪問以達到均衡負載的作用。 當Rib

Spring Cloud構建服務架構服務消費Feign

Spring Cloud Feign Spring Cloud Feign是一套基於Netflix Feign實現的宣告式服務呼叫客戶端。它使得編寫Web服務客戶端變得更加簡單。我們只需要通過建立介面並用註解來配置它既可完成對Web服務介面的繫結。它具備可插拔的註解支援,包括Feign註解、JAX-RS註解

Spring Cloud構建服務架構服務註冊與發現Eureka、Consul

Spring Cloud簡介 Spring Cloud是一個基於Spring Boot實現的雲應用開發工具,它為基於JVM的雲應用開發中涉及的配置管理、服務發現、斷路器、智慧路由、微代理、控制匯流排、全域性鎖、決策競選、分散式會話和叢集狀態管理等操作提供了一種簡單的開發方式。 Spring Cloud包含

Spring Cloud構建服務架構服務註冊與發現Eureka

1. Spring Cloud簡介 Spring Cloud是一個基於Spring Boot實現的雲應用開發工具,它為基於JVM的雲應用開發中涉及的配置管理、服務發現、斷路器、智慧路由、微代理、控制匯流排、全域性鎖、決策競選、分散式會話和叢集狀態管理等操作提供了

Spring Boot + Spring Cloud 構建服務系統分散式鏈路追蹤Sleuth、Zipkin

技術背景 在微服務架構中,隨著業務發展,系統拆分導致系統呼叫鏈路愈發複雜,一個看似簡單的前端請求可能最終需要呼叫很多次後端服務才能完成,那麼當整個請求出現問題時,我們很難得知到底是哪個服務出了問題導致的,這時就需要解決一個問題,如何快速定位服務故障點,於是,分散式系統呼叫鏈追蹤技術就此誕生了。 ZipKin

Spring Cloud構建服務架構分散式配置中心

先來回顧一下,在前文中我們完成了什麼: 構建了config-server,連線到Git倉庫 在Git上建立了一個config-repo目錄,用來儲存配置資訊 構建了config-client,來獲取Git中的配置資訊 在本文中,我們繼續來看看Spring Cloud

Spring Cloud構建服務架構 分散式配置中心高可用與動態重新整理【Dalston版】

高可用問題 傳統作法 通常在生產環境,Config Server與服務註冊中心一樣,我們也需要將其擴充套件為高可用的叢集。在之前實現的config-server基礎上來實現高可用非常簡單,不需要我們為這些服務端做任何額外的配置,只需要遵守一個配置規則:將所有的Config Server都指向同一

Spring Cloud構建服務架構 分散式配置中心加密解密

在微服務架構中,我們通常都會採用DevOps的組織方式來降低因團隊間溝通造成的巨大成本,以加速微服務應用的交付能力。這就使得原本由運維團隊控制的線上資訊將交由微服務所屬組織的成員自行維護,其中將會包括大量的敏感資訊,比如:資料庫的賬戶與密碼等。很顯然,如果我們直接將敏感資訊以明文的方式儲存於微服務應用的

Spring Cloud構建服務架構分散式配置中心

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <versio

Spring Cloud構建服務架構Hystrix監控面板

在上一篇《服務容錯保護(hystrix斷路器)》的介紹中,我們提到斷路器是根據一段時間窗內的請求情況來判斷並操作斷路器的開啟和關閉狀態的。而這些請求情況的指標資訊都是HystrixCommand和HystrixObservableCommand例項在執行過程中記錄的重要度

Spring-Boot:Spring Cloud構建服務架構

xmlns art 超時 客戶 微服務架構 cover lns created 搭建 概述:   從上一篇博客《Spring-boot:5分鐘整合Dubbo構建分布式服務》 過度到Spring Cloud,我們將開始學習如何使用Spring Cloud 來搭建微服務。繼續采

Spring Cloud構建服務架構分布式配置中心

post ast github 構造 clas mas files cli .class 在本文中,我們將學習如何構建一個基於Git存儲的分布式配置中心,並對客戶端進行改造,並讓其能夠從配置中心獲取配置信息並綁定到代碼中的整個過程。 準備配置倉庫 準備一個git倉庫,可

Spring Cloud構建服務架構—創建“服務註冊中心”

springboot springcloud mybatis eureka config 創建一個基礎的Spring Boot工程,命名為eureka-server,並在pom.xml中引入需要的依賴內容: <parent> <groupId>org.springf

Spring Cloud構建服務架構服務註冊與發現

springboot springcloud mybatis eureka config Spring Cloud簡介Spring Cloud是一個基於Spring Boot實現的雲應用開發工具,它為基於JVM的雲應用開發中涉及的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局

Spring Cloud構建服務架構-創建“服務提供方”

spring Spring Cloud Spring Boot config 下面我們創建提供服務的客戶端,並向服務註冊中心註冊自己。本文我們主要介紹服務的註冊與發現,所以我們不妨在服務提供方中嘗試著提供一個接口來獲取當前所有的服務信息。 首先,創建一個基本的Spring Boot應用。命名為