SpringCloud中微服务跟踪的示例分析

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

创新互联建站-专业网站定制、快速模板网站建设、高性价比章贡网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式章贡网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖章贡地区。费用合理售后完善，十载实体公司更值得信赖。

微服务跟踪概述

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

实际问题与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集群，销售服务依赖了“图书服务”和“支付服务”。

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