分布式系统中的降级熔断设计问题面试

引言

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

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

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不是你的是谁的？