1.链路追踪
在一次调用链路中,可能设计到多个微服务,如果在线上,某个微服务出现故障,如何快速定位故障所在的微服务呢?
答:可以使用链路追踪技术
1.1链路追踪介绍
在大型系统的微服务化构建中,一个系统被拆分成了很多微服务。这些模块负责不同的功能,组合成系统,最终可以提供丰富的功能。在这种架构中,一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同团队开发,可能使用不同的编程语言来实现,有可能布置了几千台服务器,横跨多个不同的数据中心【区域】,也就意味着这种架构形式也会存在一些问题:
- 如何快速发现问题?
- 如何判断故障影响范围?
- 如何梳理服务依赖?
- 如何分析链路性能问题以及实时容量规划?
分布式链路追踪(Distributed Tracing),就是将一次分布式请求还原成调用链路,进行==日志记录==,==性能监控==并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时,请求具体到达哪台机器上的IP、每个服务节点的请求状态200 500等等。
1.2 链路追踪使用的组件有哪些?
1.cat:由大众点评开源,基于Java开发的实时应用监控平台,包括实时应用监控,业务监控。集成方案是通过代码埋点的方式实现监控,比如:拦截器,过滤器等。对代码的侵入性很大,集成成本较高,风险较大。
2.pinpoint:Pinpoint是韩国人开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点 是支持多种插件,UI功能强大,接入端无代码侵入。
3.skywalking【未来企业会使用的多】
Skywalking是本土开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能较强,接入端无代码侵入。目前已加入Apache孵化器 -- 开源。
4.Sleuth (日志记录每一条链路上的所有节点,以及这些节点所在的机器和耗时。)
5.zipkin:zipkin由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时数据,以解决微服务架构中的延迟问题,包括:==数据的收集、存储、查找和展现《图形化》==。该产品结合spring-cloud-sleuth 使用较为简单,集成很方便,但是功能较简单。
SpringCloud提供的分布式系统中链路追踪解决方案
1.3 介绍sleuth
springcloud Sleuth主要功能就是在分布式系统中提供追踪解决方案。它大量借用了Google Dapper的设计。
1.Trace (一条完整链路--包含很多span(微服务接口))
由一组Trace Id(贯穿整个链路)相同的Span串联形成一个树状结构。为了实现请求追踪,当请求到达分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的标识(即TraceId),同时在分布式系统内部流转的时候,框架始终保持传递该唯一值,直到整个请求的返回。那么我们就可以使用该唯一标识将所有请求串联起来,形成一条完整的请求链路。
2.Span
代表了一组基本的工作单元。为了统计各处理单元的延迟,当请求到达各个服务组件的时候,也通过一个唯一标识(SpanId)来标记它的开始、具体过程和结束。通过SpanId的开始和结束时间戳,就能统计该span的调用时间,除此之外,我们还可以获取如事件的名称。请求信息等元数据。
3.Annotation用它记录一段事件内的事件,内部使用的重要注释:
- cs(Client Send)客户端发出请求,开始一个请求的命令
- sr(server Received)服务端接受到请求开始进行处理,sr - cs = 网络延迟(服务调用的时间)
- ss(Server Send)服务端处理完毕准备发送到客户端,ss - sr =服务器上的请求处理时间
- cr (Client Reveived) 客户端接受到服务器的响应,请求结束。cr - cs = 请求的总时间
1.4 如何使用sleuth
在每一个微服务中引入相关依赖就可以
<!--父工程-->
<dependencies>
<!--sleuth链路追踪依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
</dependencies>
启动微服务,调用之后,我们可以在控制台观察到sleuth的日志输出
我们可以通过sleuth的日志,观察每个微服务执行的时间。但是这样会非常麻烦。能否把这些sleuth生成的日志,以图形化的形式展示。 --- 我们可以使用zipkin来搜集sleuth生成的日志,并以图形化展示。
1.5 zipkin介绍
Zipkin是Twitter的一个开源项目,它基于Google Dapper实现,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储展现,查找和我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源
除了面向开发的API接口之外,他也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等。
Zipkin提供了可插拔数据存储方式:In-Memory、MySql、Cassandra以及Elasticsearch。
从上面的图可以看出zipkin需要一个服务端,而每个微服务就是客户端。
1.6启动zipkin服务器
启动zipkin
java -jar zipkin-server-2.12.9.exec.jar
浏览器:
http://ip:9411
微服务接入zipkin服务端
(1)引入zipkin依赖
<!--zipkin依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
(2)每个微服务在配置文件中接入zipkin服务端
#zipkin服务端地址
spring.zipkin.base-url=http://localhost:9411
(3)访问一个链路
2.配置中心
商品微服务 -- 搭建n个集群 -- 它的配置一模一样。如果修改某个配置内容。
需要给每个微服务都要修改配置内容
商品微服务和订单微服务他们之间没有公共配置。 -- 需要对每个微服务都要修改
使用配置中心来管理每个微服务的配置文件。
2.1 哪些组件可以作为配置中心
Apollo**------>很多使用apollo**
Apollo是由携程开源的分布式配置中心。特点有很多,比如:配置更新之后可以实时生效,支持灰度发布功能,并且能对所有的配置进行版本管理、操作审计等功能,提供开放平台API。并且资料 也写的很详细。
Disconf
Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效的。
SpringCloud Config
这是Spring Cloud中带的配置中心组件。它和Spring是无缝集成,使用起来非常方便,并且它的配置存储支持Git。不过它没有可视化的操作界面,配置的生效也不是实时的,需要重启或去刷新。
Nacos
这是SpringCloud alibaba技术栈中的一个组件,前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能,我们可以直接使用它作为服务配置中心。
(1)在nacos配置中心创建微服务配置文件
(2)微服务使用配置中心中指定配置文件
<!--nacos配置中心依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
(3)微服务使用配置中心指定配置文件
#微服务的名称
spring.application.name=qy163-product
#指定配置中心的地址
spring.cloud.nacos.config.server-addr=192.168.28.139:8849
(4)在controller验证读取到配置中的内容
@Value("${student.name}") //读取配置文件中student.name的属性值
private String name;
@GetMapping("getInfo")
public String getInfo(){
return name;
}
bootstrap配置文件和application配置文件的区别
bootstrap和application都是SpringBoot项目中的配置文件,他们的区别主要有以下两个方面
(1)加载顺序区别
bootstrap配置文件是比application配置文件优先加载的,因为bootstrap是由spring父上下文加载,而application由子上下文加载
(2)优先级区别
bootstrap加载的配置信息是不能被application的相同配置覆盖的,如果两个配置文件同时存在,也是以bootstrap为主
(3)应用场景区别
bootstrap常见应用场景
1.配置一些固定的,不能被覆盖的属性,用于一些系统级别的参数配置
本地的配置文件是默认不能覆盖远程的配置的
2.一些需要加密/解密的场景
3.当你使用了nacos配置中心时,这时需要在bootstrap配置文件中添加连接到配置中心的配置属性来加载外部配置中心的配置信息。
当配置中心中的内容发生改变时,微服务应该自动收到改变的内容。
2.2 nacos实时刷新
在controller类上加上@RefreshScope注解
2.3 微服务集群共享一个配置文件
应该把每个微服务的配置放入对应配置中心文件中
student.name=王永亮~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~1111
#微服务的名称
spring.application.name=qy163-product
#指定配置中心的地址
spring.cloud.nacos.config.server-addr=192.168.28.139:8848
#端口号
server.port=8081
#数据库配置信息
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/springcloud_product
spring.datasource.username=root
spring.datasource.password=wang134246
#日志
mybatis-plus.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl
#配置文件指定注册中心的地址
#spring.cloud.nacos.discovery.server-addr=192.168.28.139:8849,192.168.28.139:8850,192.168.28.139:8851
#eureka的地址
#eureka.client.service-url.defaultZone=http://localhost:7001/eureka/
#zipkin服务端地址
#spring.zipkin.base-url=http://localhost:9411
2.4 多个微服务共享一些配置内容
(1)nacos创建一个公共配置文件
(2)在微服务bootstrap文件中配置
#引用公共配置的内容
#扩展文件的id
spring.cloud.nacos.config.extension-configs[0].data-id=qy163-data.properties
#扩展文件是否实时刷新
spring.cloud.nacos.config.extension-configs[0].refresh=true
#分组
spring.cloud.nacos.config.extension-configs[0].group=DEFAULT_GROUP