服务降级设计与实践
服务降级定义
当服务整体负载超出预设的上限阈值或即将到来的流量顶,即将会超过预设阈值时,为了保证重要或基本的服务能正常运行,拒绝部分请求或者将一些不重要,[断句]不紧急的服务或任务,[断句]进行服务的延迟使用或暂停使用;
--理解了好长时间才,发现是断句的--
服务降级的目的
当流量高峰期时,在短时间请求量逐渐增大,因为服务的能力有限,导致性能下降,最终出现服务的宕机或者雪崩,所以需要服务降级
--就是要对一些请求拒绝--
服务降级案例
在案例中可以看到,应该是在类似双十一,618等节日,网络流量瞬间上涨,超越预设的阈值,为了保证支付服务等其他重要服务,一些其他不是很重要的服务就都出现了降级,提示拥挤,人多请重试,这就是服务降级,当然不建议提示网络不好用,会被投诉的[捂脸]
服务降级目标
保证核心服务可用;非核心服务弱可用,甚至不可用
- 核心服务:直接和钱沾边,或者间接和钱沾边
- 比如搜索列表,在去支付的路上
- 加入购物车,代表要买了
- 支付,已经准备掏钱了
- 非核心服务:和钱不沾边,或者影响支付
- 我的订单:已经下完单了,不用看
- 退货服务:取消是不可能的
服务降级手段
- 拒绝部分请求
- 拒绝部分老请求
- 减轻微服务请求处理数量
- 确保"新"请求正常响应
- RPC队列方式(请求入队,出队时间处理请求时,检查请求在队列请求时间超过一定时间[比如1秒],直接丢弃)
- --感觉就是消息队列,在队列中超过1秒,还没被消费,直接丢弃--
- 优先级请求方式
- 非核心请求直接丢弃
- 业务紧密
- 随机拒绝方式
- 随机丢弃一定比例的请求
- 网站一会可用,一会不可用
- 关闭部分业务(业务相关)
第一种拒绝部分老的请求是开启机制,第二种优先级是丢弃策略,可以现在网关直接丢弃不是核心请求的请求,然后通过队列记录写入和处理时间获取,在队列中停留的时间,判断是否超出设置的阈值,如果超出直接丢弃
服务层降级架构层次
- 集中式
- 网关层
- 自治式
- 网关层
- 业务逻辑层
- 数据访问层
水平分层架构
因为不同的层次的同样设备的处理能力是不一样的,假设网关层能处理200请求,业务逻辑层只能处理100请求,数据访问层,只能处理50请求
集中式:
直接在网关层砍掉150请求才能符合数据访问层的请求能力,并且是中间隔着业务逻辑层的,并不好知道
自治式:
层层降级,最终砍到数据访问层能处理的请求数量,因为每层都是挨着的所以,容易一些
数据层降级
- 更新请求
- 持久到消息队列
- 只更新缓存
- 读请求
- 读缓存
- 数据补齐
- 消息队列->数据库
新浪微博,在数据流量的高峰期,比如网红发段子,或者一些事件,那么更新的消息数据会写到队列中并写入缓存,其他人拉取的时候,都是读取的缓存,等到流量陷入低峰期时,读取消息队列,并写入到数据库,实现数据补齐
**一般不是用**
服务降级可用策略
自动打开:不依赖人工
演练:保证线上生效
睡觉觉了...