大厂-分布式专栏 19 系统中的降级熔断设计

19系统中的降级熔断设计

青年是学习智慧的时期,中年是付诸实践的时期。—— 卢梭

引言

稳定性设计第一篇:在分布式系统下,线上的某一个功能按钮背后会有很多个服务共同完成,这些服务之间有依赖关系,且有一定的顺序调用。那么这些服务如果其中有一个环节出现问题,会带来一些连锁反应。

比如,突如其来的流量,部分服务突然宕机,你能想到的故障都算故障,是不是整个服务都不可用了吗?作为开发者肯定不希望这样的事情发生,那么有哪些解决问题?思路就是尽量给每个服务找一个“备胎” ,这个“备胎”不是集群概念里一个备用机器 ,而是一种备用方案

1.面试官:你对你负责的系统做了哪些提高可用性的设计?

问题分析:

稳定性设计三把斧:降级、熔断和限流。即使你没用过,也可以完全根据我描述的场景再结合自己的项目编造一个。

我:

这个问题很好理解,举个例子:比如外卖订单服务,假设美团外卖订单系统,系统日常QPS 在 1000 左右(这里我拍脑袋假设,实际远高于1000),可能受天气影响或者是否工作日,QPS 会上下浮动,为1000 – 2000之间。

假设线上系统设计时最多能承受2000 QPS,正常会发生的突发情况单量增多都能承受,突然有那么一天,你的竞争对手饿了么宕机了,用户无法使用都蜂拥而至来美团下单,这个时候QPS 变成了 3000,系统扛不住 3000 的QPS怎么办?用户都卡在提交订单的页面,谁也下不了单。那么如何有效解决这个问题?这个时候就要想到“备胎”方案,尝试以下优化思路。

  1. 流量控制:也就是限流,限流包括单机限流和集群限流,订单系统某一环节加一个开关,好比地铁进站口,人多要排队,保证流量持续进入,而不是撑破服务器大家都无法使用,比如将系统QPS控制在最高2000,后面的 1000 用户告诉他“系统繁忙,请稍后再试”,这样一来无非就是多点几下或者等几分钟,你还能吃上饭。
  2. 降级备案:比如商品列表查询,默认查询的是 Redis 集群,各种故障赶在一起,Redis 所有集群都挂了不能用了,这个时候怎么办,设计一个备胎 Elasticsearch,查询速度可能没 Redis 快,但好歹备胎还能用。
  3. 熔断: 这个可以理解成家庭电路中的保险丝,电流有异常后自动开启熔断保护,系统流量也同样原理。

举例: 我对公司内部订单查询系统做的优化,订单查询是运营人员每天都要使用的功能,一定要保证服务可用,还要迅速响应,为了解决这个问题,我使用了ES作为查询主库,如ES故障,系统会自动降级到MySQL查询,完美解决了性能和可用性的问题。

(有了上面这个例子,面试官对我在系统可用性方面的设计能力放心多了。)

Tip: 说了这么多不如直接看看图形界面,限流到底是怎么用的,举个例子,我负责的一个接口,限流参数设置是这样的。

这是限流功能做成页面可视化系统以后,看看红色框备注和提示如何设置限流,是不是so easy,使用开源的 Hystrix 也能解决此类问题。

总结

这一节的内容不多,最重要的是要知道系统稳定性设计还有三把斧:降级、熔断和限流,内容并不难,重要的是你要有这个意识,你能做到让系统全年不故障持续提供服务,领导把这事儿交给你放心,offer不是你的是谁的?

更多关于限流、降级、重试的设计与使用,推荐张开涛的《亿级流量网站架构核心技术》。

参考资料

https://github.com/Netflix/Hystrix/wiki

https://github.com/resilience4j/resilience4j

https://github.com/alibaba/Sentinel

正文完