分布式系统中的降级熔断设计问题面试
作者：Q.E.D
引言
稳定性设计第一篇：在分布式系统下，线上的某一个功能按钮背后会有很多个服务共同完成，这些服务之间有依赖关系，且有一定的顺序调用。那么这些服务如果其中有一个环节出现问题，会带来一些连锁反应。
比如，突如其来的流量，部分服务突然宕机，你能想到的故障都算故障，是不是整个服务都不可用了吗？作为开发者肯定不希望这样的事情发生，那么有哪些解决问题？思路就是尽量给每个服务找一个“备胎” ，这个“备胎”不是集群概念里一个备用机器 ，而是一种备用方案。
1、面试官：
你对你负责的系统做了哪些提高可用性的设计？
问题分析：稳定性设计三把斧：降级、熔断和限流。即使你没用过，也可以完全根据我描述的场景再结合自己的项目编造一个。
答：这个问题很好理解，举个例子：比如外卖订单服务，假设美团外卖订单系统，系统日常QPS 在 1000 左右（这里我拍脑袋假设，实际远高于1000），可能受天气影响或者是否工作日，QPS 会上下浮动，为1000 - 2000之间。
假设线上系统设计时最多能承受2000 QPS，正常会发生的突发情况单量增多都能承受，突然有那么一天，你的竞争对手饿了么宕机了，用户无法使用都蜂拥而至来美团下单，这个时候QPS 变成了 3000，系统扛不住 3000 的QPS怎么办？用户都卡在提交订单的页面，谁也下不了单。那么如何有效解决这个问题？这个时候就要想到“备胎”方案，尝试以下优化思路。
- 流量控制：也就是限流，限流包括单机限流和集群限流，订单系统某一环节加一个开关，好比地铁进站口，人多要排队，保证流量持续进入，而不是撑破服务器大家都无法使用，比如将系统QPS控制在最高2000，后面的 1000 用户告诉他“系统繁忙，请稍后再试”，这样一来无非就是多点几下或者等几分钟，你还能吃上饭。
- 降级备案：比如商品列表查询，默认查询的是 Redis 集群，各种故障赶在一起，Redis 所有集群都挂了不能用了，这个时候怎么办，设计一个备胎 Elasticsearch，查询速度可能没 Redis 快，但好歹备胎还能用。
- 熔断： 这个可以理解成家庭电路中的保险丝，电流有异常后自动开启熔断保护，系统流量也同样原理。
举例： 我对公司内部订单查询系统做的优化，订单查询是运营人员每天都要使用的功能，一定要保证服务可用，还要迅速响应，为了解决这个问题，我使用了ES作为查询主库，如ES故障，系统会自动降级到MySQL查询，完美解决了性能和可用性的问题。
（有了上面这个例子，面试官对我在系统可用性方面的设计能力放心多了。）
Tip： 说了这么多不如直接看看图形界面，限流到底是怎么用的，举个例子，我负责的一个接口，限流参数设置是这样的。
这是限流功能做成页面可视化系统以后，看看红色框备注和提示如何设置限流，是不是so easy，使用开源的 Hystrix 也能解决此类问题。
总结
这一节的内容不多，最重要的是要知道系统稳定性设计还有三把斧：降级、熔断和限流，内容并不难，重要的是你要有这个意识，你能做到让系统全年不故障持续提供服务，领导把这事儿交给你放心，offer不是你的是谁的？
以上就是分布式系统中的降级熔断设计问题面试的详细内容，更多关于分布式系统中的降级熔断设计的资料请关注脚本之家其它相关文章！