微服务--Sentinel(实现:服务高可用)

内存溢出:OOM

服务器挂掉的原因:
1.激增流量打垮:

1.流量突然飙升,导致CPU上升,出现挂机

2.负载不均:比如一个实例长期未重启,导致磁盘写满降低响应时间等。

3.线程池满,单点故障??

4.激增流量打垮冷系统(数据库连接未创建,缓存未预热:比如说:党费缴纳:交党费那天给客户提醒,然后大量请求进来,缓存数据未预热,导致大量请求数据库,数据库访问时间变慢,导致同一节点数据库访问变慢,导致支付系统响应时间变慢)

5.消息传递速度过快,导致消息处理积压。(MQ)

2.被其他服务拖垮

1.满SQL查询卡爆连接池

2.第三方服务不响应,卡满线程池

3.业务调用持续出现异常,产生大量副作用

3.异常处理
服务雪崩效应:因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程,叫做服务雪崩效应
容错机制:
1.超时机制(常用容错机制):

场景:服务提供者不可用导致消费者请求线程强制等待,造成系统资源耗尽

作用:一旦超时,就释放资源,一定程度抑制资源耗尽的问题

2.服务限流:

服务达到QPS最大值,则进行限流,可直接拒绝:当前使用人数较多,请稍后再试。(nginx\mq、sentinel)

3.隔离:
4.服务熔断:

远程服务不稳定或网络抖动时暂时关闭,叫:服务熔断。

当依赖的服务有大量的超时时,会让新的请求再去访问根本没有意义,只会无畏的消耗现有资源。

1.出现慢SQL,慢SQL导致应用越来越慢,最后整个应用卡挂了

2.依赖第三方服务,第三方服务突然不响应,造成应用线程被挂在第三方应用上无法返回,最后自己线程耗尽,无法处理新的请求

3.程序内部某个方法持续异常,这个时候调用这个方法毫无意义,而且影响主业务流程

5.服务降级(是服务熔断的兜底计划:有熔断就要服务降级)

强依赖:如订单等,直接提示客户失败不作后续处理(如订单)

弱依赖:可先记录一条数据,后续通过定时任务或者调度实现补偿机制(如积分)

降级策略:支持:基于响应时间和失败比率进行降级;

流量整形:支持慢启动,匀速器模式(压测时刚开始启动比较慢???是否与此相关?)

持久化:支持持久化:注册中心,放数据库(hystrix:放git,svn等文件内存中)

实现流控规则:
QPS:每秒的访问数:设置1;则一秒钟只能处理一次访问

线程数:设置1的话,一个线程在处理中,则下一个线程会流控,等前面处理完了再进行处理

@SentinelResource 注解:改善接口中资源定义和被流控降级后的处理方式

降级规则:(1s内执行n次,出现m次异常,就出发异常。)

1.异常数:触发熔断策略:异常数,异常比例、慢调用比例

2.出发熔断最小请求书:

3、统计时长:默认1s

熔断持续时长:单位:秒,

一旦出发熔断,再次请求对应接口就会出发降级方法(降级方法:比如提示客户稍后再试)

10秒后--处于半开状态,如果第一次触发请求就异常,则会再次熔断。不会根据熔断设计规则熔断

流控模式:

1.直接

2.关联:关联资源

使用场景:下单:插入,影响查询(通过生成订单出发查询订单的限流)

3.链路:入口资源;流控效果:快速失败(直接报错);排队等待;warm up(慢慢处理)

链路默认为收敛方式:需要将配置修改为:false

场景:

针对激增流量处理:warm up(慢慢处理),党费的限流设置就可以设置成链路流控

针对脉冲流量处理:排队等待,

熔断降级策略:

1.慢调用比例

比例阈值0.1、最小请求数:10,最大RT,熔断时长。1秒钟10次请求,,如果一次出现慢调用时,触发降级规则:

2.异常比例

比例阈值:0.1 熔断时长 10s,最小请求数5;10次请求里面1次失败,则触发熔断降级

3.异常数

异常数:1,熔断时长:10s,最小请求数10;10次请求中一次异常,则触发熔断。

热点参数流控:热点流控规则

何为热点:即经常访问的数据;很多时候,我们希望统计某个热点数据中访问频次最高的数据,并对其访问进行限制。

常用场景:

热点商品访问/操作控制

用户/IP 防刷 (如秒杀)如防止暴力破解

实现原理:热点淘汰策略(LRU)+TOKEN Rucket流控

设置:限流模式:QPS模式,参数索引 0(第几个参数),单机阈值:10(所有参数值设置的公共阈值),统计窗口时长:1秒,是否集群;一秒钟之内的阈值为10

单机阈值:1.假设 参数大部分是热点参数,那单机阈值主要针对热点参数进行流控,后续额外针对普通流量进行流控;

2.假设 参数大部分是普通参数,那单机阈值主要针对普通参数进行流控,后续额外针对热点流量进行流控;

编辑后出现高级选项:参数额外(与上面额外一个意思)项:参数类型,参数值;

系统保护规则(系统兜底方案)

阈值类型:load自适应、CPU使用率、入口QPS(入口平均访问量)、线程数、RT、LOAD

规则持久化sentinel+nacals(注册中心)

1.原始模式:重启后消失,不建议在生产使用

2.拉模式:pull模式

3.推模式:push模式:(生产常用)

一般做法:配置中心控制台/Sentinel控制台-->配置中心(NACOS注册中心)-->Sentinel数据源-->Sentinel

GATWAY整合sentinel

配置数据:网关流控规则:

API类型:ROUT ID/API 分组;API名称;针对请求属性:勾选后增加**{** 参数属性:Client ip,Remote Host,Head,url 参数,Cookies;名称:;匹配属性;匹配模式:精确、子串、正则;匹配串:};阈值类型:QPS/线程数;QPS阈值间隔;流控方式:快速失败,匀速排队;Burst size;

相关推荐
周杰伦_Jay8 小时前
【Spring Cloud Alibaba】微服务组件详解:电商场景落地实践
微服务·云原生·架构
老前端的功夫9 小时前
Vue 3 性能深度解析:从架构革新到运行时的全面优化
javascript·vue.js·架构
生骨大头菜11 小时前
使用python实现相似图片搜索功能,并接入springcloud
开发语言·python·spring cloud·微服务
O***p60415 小时前
前端的“复杂性红线”:如何在超大型应用时代构建可持续演进的前端架构?
前端·架构
狗哥哥15 小时前
🚀 拒绝重复造轮子!在 Vue3 项目中打造一套企业级“统一上传服务”(支持分片、秒传、断点续传)
vue.js·架构
min18112345616 小时前
分公司组织架构图在线设计 总部分支管理模板
大数据·人工智能·信息可视化·架构·流程图
码界奇点16 小时前
基于微服务架构的悟空人力资源管理系统设计与实现
spring cloud·微服务·云原生·架构·毕业设计·源代码管理
weixin_4166600717 小时前
豆包与DeepSeek底层大模型的深度解析:技术架构、设计理念与生态分野
人工智能·ai·架构·deepseek
狗哥哥18 小时前
前端权限系统的“断舍离”:从安全防线到体验向导的架构演进
vue.js·架构
小安同学iter18 小时前
天机学堂-排行榜功能-day08(六)
java·redis·微服务·zset·排行榜·unlink·天机学堂