做包装盒效果图的网站,多元国际二维码入口,威海高区有没有建设局的网站,北京东城网站建设通过之前的N篇博文介绍#xff0c;实际上我们已经能够通过使用它们搭建起一个基础的微服务架构系统来实现我们的业务需求了。但是#xff0c;随着业务的发展#xff0c;我们的系统规模也会变得越来越大#xff0c;各微服务间的调用关系也变得越来越错综复杂。通常一个由客户…通过之前的N篇博文介绍实际上我们已经能够通过使用它们搭建起一个基础的微服务架构系统来实现我们的业务需求了。但是随着业务的发展我们的系统规模也会变得越来越大各微服务间的调用关系也变得越来越错综复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果在复杂的微服务架构系统中几乎每一个前端请求都会形成一条复杂的分布式服务调用链路在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时候对于每个请求全链路调用的跟踪就变得越来越重要通过实现对请求调用的跟踪可以帮助我们快速的发现错误根源以及监控分析每条请求链路上的性能瓶颈等好处。
针对上面所述的分布式服务跟踪问题Spring Cloud Sleuth提供了一套完整的解决方案。在本章中我们将详细介绍如何使用Spring Cloud Sleuth来为我们的微服务架构增加分布式服务跟踪的能力。
快速入门
在介绍各种概念与原理之前我们先通过实现一个简单的示例对存在服务调用的应用增加一些sleuth的配置实现基本的服务跟踪功能以此来对Spring Cloud Sleuth有一个初步的了解随后再逐步展开介绍实现过程中的各个细节部分。
准备工作
在引入Sleuth之前我们先按照之前章节学习的内容来做一些准备工作构建一些基础的设施和应用
服务注册中心eureka-server这里不做赘述直接使用之前构建的工程。或者直接使用我的公益eureka注册中心下面的例子使用该注册中心。 微服务应用trace-1实现一个REST接口/trace-1调用该接口后将触发对trace-2应用的调用。具体实现如下 创建一个基础的Spring Boot应用在pom.xml中增加下面依赖
parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version1.5.10.RELEASE/version relativePath/ /parentdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId/dependencydependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-eureka/artifactId/dependencydependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-ribbon/artifactId/dependencydependencyManagement dependencies dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-dependencies/artifactId versionDalston.SR5/version typepom/type scopeimport/scope /dependency /dependencies/dependencyManagement创建应用主类并实现/trace-1接口并使用RestTemplate调用trace-2应用的接口。具体如下
RestControllerEnableDiscoveryClientSpringBootApplicationpublic class TraceApplication { private final Logger logger Logger.getLogger(getClass()); Bean LoadBalanced RestTemplate restTemplate() { return new RestTemplate(); } RequestMapping(value /trace-1, method RequestMethod.GET) public String trace() { logger.info(call trace-1); return restTemplate().getForEntity(http://trace-2/trace-2, String.class).getBody(); } public static void main(String[] args) { SpringApplication.run(TraceApplication.class, args); }}application.properties中将eureka.client.serviceUrl.defaultZone参数指向eureka-server的地址具体如下
spring.application.nametrace-1server.port9101eureka.client.serviceUrl.defaultZonehttp://eureka.didispace.com/eureka/微服务应用trace-2实现一个REST接口/trace-2供trace-1调用。具体实现如下 创建一个基础的Spring Boot应用pom.xml中的依赖与trace-1相同 创建应用主类并实现/trace-2接口具体实现如下
RestControllerEnableDiscoveryClientSpringBootApplicationpublic class TraceApplication { private final Logger logger Logger.getLogger(getClass()); RequestMapping(value /trace-2, method RequestMethod.GET) public String trace() { logger.info(call trace-2); return Trace; } public static void main(String[] args) { SpringApplication.run(TraceApplication.class, args); }}application.properties中将eureka.client.serviceUrl.defaultZone参数指向eureka-server的地址另外还需要设置不同的应用名和端口号具体如下
spring.application.nametrace-2server.port9102eureka.client.serviceUrl.defaultZonehttp://eureka.didispace.com/eureka/在实现了上面内容之后我们可以将eureka-server、trace-1、trace-2三个应用都启动起来并通过postman或curl等工具来对trace-1的接口发送请求http://localhost:9101/trace-1我们可以得到返回值Trace同时还能在它们的控制台中分别获得下面的输出
-- trace-1INFO 25272 --- [nio-9101-exec-2] ication$$EnhancerBySpringCGLIB$$36e12c68 : call trace-1-- trace-2INFO 7136 --- [nio-9102-exec-1] ication$$EnhancerBySpringCGLIB$$52a02f0b : call trace-2实现跟踪
在完成了准备工作之后接下来我们开始进行本章的主题内容为上面的trace-1和trace-2来添加服务跟踪功能。通过Spring Cloud Sleuth的封装我们为应用增加服务跟踪能力的操作非常简单只需要在trace-1和trace-2的pom.xml依赖管理中增加spring-cloud-starter-sleuth依赖即可具体如下
dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-sleuth/artifactId/dependency到这里实际上我们已经为trace-1和trace-2实现服务跟踪做好了基础的准备重启trace-1和trace-2后再对trace-1的接口发送请求http://localhost:9101/trace-1。此时我们可以从它们的控制台输出中窥探到sleuth的一些端倪。
-- trace-1INFO [trace-1,f410ab57afd5c145,a9f2118fa2019684,false] 25028 --- [nio-9101-exec-1] ication$$EnhancerBySpringCGLIB$$d8228493 : call trace-1-- trace-2INFO [trace-2,f410ab57afd5c145,e9a377dc2268bc29,false] 23112 --- [nio-9102-exec-1] ication$$EnhancerBySpringCGLIB$$e6cb4078 : call trace-2从上面的控制台输出内容中我们可以看到多了一些形如[trace-1,f410ab57afd5c145,a9f2118fa2019684,false]的日志信息而这些元素正是实现分布式服务跟踪的重要组成部分它们每个值的含义如下
第一个值trace-1它记录了应用的名称也就是application.properties中spring.application.name参数配置的属性。第二个值f410ab57afd5c145Spring Cloud Sleuth生成的一个ID称为Trace ID它用来标识一条请求链路。一条请求链路中包含一个Trace ID多个Span ID。第三个值a9f2118fa2019684Spring Cloud Sleuth生成的另外一个ID称为Span ID它表示一个基本的工作单元比如发送一个HTTP请求。第四个值false表示是否要将该信息输出到Zipkin等服务中来收集和展示。
上面四个值中的Trace ID和Span ID是Spring Cloud Sleuth实现分布式服务跟踪的核心。在一次服务请求链路的调用过程中会保持并传递同一个Trace ID从而将整个分布于不同微服务进程中的请求跟踪信息串联起来以上面输出内容为例trace-1和trace-2同属于一个前端服务请求来源所以他们的Trace ID是相同的处于同一条请求链路中。
本文完整示例
读者可以根据喜好选择下面的两个仓库中查看trace-1和trace-2两个项目
GithubGitee
如果您对这些感兴趣欢迎star、follow、收藏、转发给予支持
本文内容部分节选自我的《Spring Cloud微服务实战》但对依赖的Spring Boot和Spring Cloud版本做了升级。
