服务降级的设计与实践

服务降级设计与实践

服务降级定义

当服务整体负载超出预设的上限阈值或即将到来的流量顶,即将会超过预设阈值时,为了保证重要或基本的服务能正常运行,拒绝部分请求或者将一些不重要,[断句]不紧急的服务或任务,[断句]进行服务的延迟使用或暂停使用;

--理解了好长时间才,发现是断句的--

服务降级的目的

当流量高峰期时,在短时间请求量逐渐增大,因为服务的能力有限,导致性能下降,最终出现服务的宕机或者雪崩,所以需要服务降级

--就是要对一些请求拒绝--

服务降级案例

在案例中可以看到,应该是在类似双十一,618等节日,网络流量瞬间上涨,超越预设的阈值,为了保证支付服务等其他重要服务,一些其他不是很重要的服务就都出现了降级,提示拥挤,人多请重试,这就是服务降级,当然不建议提示网络不好用,会被投诉的[捂脸]

服务降级目标

保证核心服务可用;非核心服务弱可用,甚至不可用

• 核心服务:直接和钱沾边,或者间接和钱沾边
  • 比如搜索列表,在去支付的路上
  • 加入购物车,代表要买了
  • 支付,已经准备掏钱了
• 非核心服务:和钱不沾边,或者影响支付
  • 我的订单:已经下完单了,不用看
  • 退货服务:取消是不可能的

服务降级手段

• 拒绝部分请求
  • 拒绝部分老请求
    • 减轻微服务请求处理数量
    • 确保"新"请求正常响应
    • RPC队列方式(请求入队,出队时间处理请求时,检查请求在队列请求时间超过一定时间[比如1秒],直接丢弃)
    • --感觉就是消息队列,在队列中超过1秒,还没被消费,直接丢弃--
  • 优先级请求方式
    • 非核心请求直接丢弃
    • 业务紧密
  • 随机拒绝方式
    • 随机丢弃一定比例的请求
    • 网站一会可用,一会不可用
• 关闭部分业务(业务相关)

第一种拒绝部分老的请求是开启机制,第二种优先级是丢弃策略,可以现在网关直接丢弃不是核心请求的请求,然后通过队列记录写入和处理时间获取,在队列中停留的时间,判断是否超出设置的阈值,如果超出直接丢弃

服务层降级架构层次

• 集中式
  • 网关层
• 自治式
  • 网关层
  • 业务逻辑层
  • 数据访问层

水平分层架构

因为不同的层次的同样设备的处理能力是不一样的,假设网关层能处理200请求,业务逻辑层只能处理100请求,数据访问层,只能处理50请求

集中式:

直接在网关层砍掉150请求才能符合数据访问层的请求能力,并且是中间隔着业务逻辑层的,并不好知道

自治式:

层层降级,最终砍到数据访问层能处理的请求数量,因为每层都是挨着的所以,容易一些

数据层降级

• 更新请求
  • 持久到消息队列
  • 只更新缓存
• 读请求
  • 读缓存
• 数据补齐
  • 消息队列->数据库

新浪微博,在数据流量的高峰期,比如网红发段子,或者一些事件,那么更新的消息数据会写到队列中并写入缓存,其他人拉取的时候,都是读取的缓存,等到流量陷入低峰期时,读取消息队列,并写入到数据库,实现数据补齐

**一般不是用**

服务降级可用策略

自动打开:不依赖人工

演练:保证线上生效

睡觉觉了...