【Spring开发】SpringCloud服务端高级框架第1篇:微服务保护,1.初识Sentinel【附代码文档】

🏆🏆🏆教程全知识点简介:微服务保护、服务异步通信、消息中间件部署、分布式事务、搜索引擎、缓存、数据同步以及相关组件的安装配置等技术要点。在微服务保护方面,介绍了 Sentinel 的基础知识,包括雪崩问题、超时处理、舱壁模式、断路器机制,以及不同服务保护技术的对比;讲解了流量控制(簇点链路、流控模式、热点参数限流)、隔离与降级(FeignClient 整合 Sentinel、线程隔离)、授权规则(自定义异常结果)及规则持久化(规则管理模式与 pull 模式),并演示了基于 Nacos 的规则持久化改造。服务异步通信部分探讨了消息可靠性(生产者消息确认、Return 回调、ConfirmCallback)、死信交换机、TTL 队列等高级应用。RabbitMQ 部署指南涵盖了单机部署、DelayExchange 插件安装、集群部署、镜像模式等内容。分布式事务部分介绍了 CAP 定理、BASE 理论、常见解决方案,Seata 的基础与部署(TC 服务部署、Nacos 配置、数据库表创建)、多种事务模式(XA 模式及优缺点、四种模式对比)和高可用架构。分布式搜索引擎章节讲解了 Elasticsearch 的原理(ELK 技术栈、倒排索引)、索引库与文档操作、RestAPI 与 RestClient 的使用、排序与高亮、酒店搜索案例(分页、竞价排名、广告标记、算分函数)、自动补全、数据同步(同步调用、监听 binlog)、集群搭建与脑裂问题、分片存储测试,以及单点 ES、Kibana、IK 分词器安装。缓存部分介绍了 Redis 持久化(RDB 与 AOF 对比)、单机安装 Redis、Redis 集群、多级缓存(JVM 进程缓存、Caffeine)、请求参数处理、Tomcat 查询、HTTP 工具与 CJSON 工具类、Redis 缓存查询。数据同步与网关部分包括 Canal 安装(开启 MySQL 主从、设置权限)、OpenResty 安装(开发库、目录结构、环境变量配置)及运行流程。

📚📚👉👉👉 https://gitee.com/xiaoshuai112/Backend/blob/master/Spring/SpringCloud服务端高级框架/note.md 🍅🍅
✨ 本教程项目亮点
🧠 知识体系完整:覆盖从基础原理、核心方法到高阶应用的全流程内容
💻 全技术链覆盖:完整前后端技术栈,涵盖开发必备技能
🚀 从零到实战:适合 0 基础入门到提升,循序渐进掌握核心能力
📚 丰富文档与代码示例:涵盖多种场景,可运行、可复用
🛠 工作与学习双参考:不仅适合系统化学习,更可作为日常开发中的查阅手册
🧩 模块化知识结构:按知识点分章节,便于快速定位和复习
📈 长期可用的技术积累:不止一次学习,而是能伴随工作与项目长期参考
🎯🎯🎯全教程总章节
🚀🚀🚀本篇主要内容
微服务保护
1.初识Sentinel
1.1.雪崩问题及解决方案
1.1.1.雪崩问题
微服务中,服务间调用关系错综复杂,一个微服务往往依赖于多个其它微服务。
如图,如果服务提供者I发生了故障,当前的应用的部分业务因为依赖于服务I,因此也会被阻塞。此时,其它不依赖于服务I的业务似乎不受影响。
但是,依赖服务I的业务请求被阻塞,用户不会得到响应,则tomcat的这个线程不会释放,于是越来越多的用户请求到来,越来越多的线程会阻塞:
服务器支持的线程和并发数有限,请求一直阻塞,会导致服务器资源耗尽,从而导致所有其它服务都不可用,那么当前服务也就不可用了。
那么,依赖于当前服务的其它服务随着时间的推移,最终也都会变的不可用,形成级联失败,雪崩就发生了:
1.1.2.超时处理
解决雪崩问题的常见方式有四种:
•超时处理:设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待
1.1.3.仓壁模式
方案2:仓壁模式
仓壁模式来源于船舱的设计:
船舱都会被隔板分离为多个独立空间,当船体破损时,只会导致部分空间进入,将故障控制在一定范围内,避免整个船体都被淹没。
于此类似,我们可以限定每个业务能使用的线程数,避免耗尽整个tomcat的资源,因此也叫线程隔离。
1.1.4.断路器
断路器模式:由断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务,拦截访问该业务的一切请求。
断路器会统计访问某个服务的请求数量,异常比例:
当发现访问服务D的请求异常比例过高时,认为服务D有导致雪崩的风险,会拦截访问服务D的一切请求,形成熔断:
1.1.5.限流
流量控制:限制业务访问的QPS,避免服务因流量的突增而故障。
1.1.6.总结
什么是雪崩问题?
- 微服务之间相互调用,因为调用链中的一个服务故障,引起整个链路都无法访问的情况。
[MyBatis-Spring 集成]
可以认为:
限流是对服务的保护,避免因瞬间高并发流量而导致服务故障,进而避免雪崩。是一种预防措施。
超时处理、线程隔离、降级熔断是在部分服务故障时,将故障控制在一定范围,避免雪崩。是一种补救措施。
1.2.服务保护技术对比
在SpringCloud当中支持多种服务保护技术:
- [Netfix Hystrix]
- [Sentinel]
- [Resilience4J]
早期比较流行的是Hystrix框架,但目前国内实用最广泛的还是阿里巴巴的Sentinel框架,这里我们做下对比:
Sentinel | Hystrix | |
---|---|---|
隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
熔断降级策略 | 基于慢调用比例或异常比例 | 基于失败比率 |
实时指标实现 | 滑动窗口 | 滑动窗口(基于 RxJava) |
规则配置 | 支持多种数据源 | 支持多种数据源 |
扩展性 | 多个扩展点 | 插件的形式 |
基于注解的支持 | 支持 | 支持 |
限流 | 基于 QPS,支持基于调用关系的限流 | 有限的支持 |
流量整形 | 支持慢启动、匀速排队模式 | 不支持 |
系统自适应保护 | 支持 | 不支持 |
控制台 | 开箱即用,可配置规则、查看秒级监控、机器发现等 | 不完善 |
常见框架的适配 | Servlet、Spring Cloud、Dubbo、gRPC 等 | Servlet、Spring Cloud Netflix |
1.3.Sentinel介绍和安装
2.流量控制
雪崩问题虽然有四种方案,但是限流是避免服务因突发的流量而发生故障,是对微服务雪崩问题的预防。我们先学习这种模式。
2.1.簇点链路
当请求进入微服务时,首先会访问DispatcherServlet,然后进入Controller、Service、Mapper,这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。
默认情况下sentinel会监控SpringMVC的每一个端点(Endpoint,也就是controller中的方法),因此SpringMVC的每一个端点(Endpoint)就是调用链路中的一个资源。
例如,我们刚才访问的order-service中的OrderController中的端点:/order/{orderId}
流控、熔断等都是针对簇点链路中的资源来设置的,因此我们可以点击对应资源后面的按钮来设置规则:
- 流控:流量控制
- 降级:降级熔断
- 热点:热点参数限流,是限流的一种
- 授权:请求的权限控制
2.1.快速入门
2.1.1.示例
点击资源/order/{orderId}后面的流控按钮,就可以弹出表单。
表单中可以填写限流规则,如下:
其含义是限制 /order/{orderId}这个资源的单机QPS为1,即每秒只允许1次请求,超出的请求会被拦截并报错。
2.1.2.练习:
需求:给 /order/{orderId}这个资源设置流控规则,QPS不能超过 5,然后测试。
1)首先在sentinel控制台添加限流规则
2)利用jmeter测试
如果没有用过jmeter,可以参考课前资料提供的文档《Jmeter快速入门.md》
课前资料提供了编写好的Jmeter测试样例:
打开jmeter,导入课前资料提供的测试样例:
