Spring Cloud中微服务跟踪的示例分析

64次阅读
没有评论

共计 1705 个字符,预计需要花费 5 分钟才能阅读完成。

这篇文章主要介绍了 Spring Cloud 中微服务跟踪的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让丸趣 TV 小编带着大家一起了解一下。

微服务跟踪概述

  先对微服务跟踪的相关概念,做一个基本的讲解。

实际问题与 Sleuth

  前面章节中,我们使用 Spring Cloud 来搭建服务集群,不论是 Eureka 服务器、服务实例,还是配置服务器、网关等节点,都可以横向扩展。一旦集群中的服务数量增多,并且它们之间存在复杂的依赖关系,那么管理它们将会变成一件很棘手的事情。

  当外部用户向集群发起请求,这些请求将会调用多个服务,每个服务又会依赖其他的服务,此时,如果出现异常、超时等情况,排查问题将变得非常困难。我们需要很清楚知道,服务出现了什么问题,这些问题出在哪个环节。

  为了能解决这些问题,Spring Cloud 提供了 Sleuth 框架作为解决方案,Sleuth 可以与 Zipkin、Apache HTrace 和 ELK 等数据分析、服务跟踪系统进行整合,为服务跟踪、解决问题提供了便利。

服务跟踪系统

  目前有许多的分布式跟踪系统,例如 Zipkin、HTrace 等,这些系统可以帮助我们收集一些,由服务实时产生的数据(主要是日志),通过这些数据可以分析出分布式系统的健康状态、服务调用过程、调用耗时等指标,为优化系统、解决问题提供了依据。

  读者需要区别两个基本的概念:服务跟踪和数据分析,数据分析系统(例如 ELK 等)收集了服务集群所产生的数据后,也可以实现服务监控、服务跟踪等功能,但明显数据分析系统的概念更为广泛、抽象。本书将会介绍服务跟踪系统 Zipkin,同样也会介绍著名的数据分析平台 ELK。

Sleuth 基本概念

 Sleuth 借鉴了 Google Dapper 的设计,先了解以下两个概念:

Trace:表示整个跟踪的过程,从用户发起请求,到最终的响应。一次跟踪包含多个跨度,这些跨度以树状结构进行保存。

Span:跨度,表示一次调用的过程,一次跟踪包含多次的调用过程。假设用户向 A 服务发送请求,A 服务又要调用 B 服务,那么此时将会产生两个跨度:用户调用 A 服务、A 服务调用 B 服务。

  图 10- 1 简单地描述了跨度的概念。

图 10-1 跨度

  如图 10-1,用户或外部程序调用 A 服务,此次调用看作是跨度 A,A 服务还要调用 B 服务,在跨度 A 的基础上会产生跨度 B,跨度 B 是跨度 A 的一部分,在 Sleuth 的设计上,跨度 A 是 B 的父跨度。因此在整个跟踪过程中,这些跨度是树状结构的。

  除了跟踪和跨度外,还要了解一下 Annotation(事件标识),它主要用于记录事件的存在,主要包括以下几个事件标识:

cs:Client Sent,表示客户端发送了请求,这个标识意味着跨度的开始。例如前面的 A 服务向 B 服务发送请求,A 服务就是客户端。

sr:Server Received,表示服务端接收到请求,并开始进行处理。

ss:Server Sent,表示服务器端完成请求的处理,并对客户端做出响应。

cr:Client Received,表示客户端接收到响应,意味着整个跨度的结束。

项目准备

  在使用 Sleuth 前,先准备本章的测试项目,本章主要以一个微服务集群为基础,该集群包括以下项目:

test-eureka-server:Eureka 服务器,端口为 8761。

test-book-service:图书微服务,主要提供根据 id 查询图书的服务,端口为 8081。

test-pay-service:支付微服务,主要提供支付服务,端口为 8082。

test-sale-service:销售微服务,会调用图书服务和支付服务,端口为 8083。

  以上的项目,均可以在 codes\10 目录找到对应的源码,几个项目的结构请见图 10-2。

图 10-2 测试项目结构

  以上几个测试项目是一个简单的 Spring Cloud 集群,销售服务依赖了“图书服务”和“支付服务”。

感谢你能够认真阅读完这篇文章,希望丸趣 TV 小编分享的“Spring Cloud 中微服务跟踪的示例分析”这篇文章对大家有帮助,同时也希望大家多多支持丸趣 TV,关注丸趣 TV 行业资讯频道,更多相关知识等着你来学习!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计1705字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)