04｜降级：为什么每次大促的时候总是要把退款之类的服务停掉？
前置知识
降级与熔断
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了微服务架构下的降级功能，强调了降级作为构建高可用微服务架构的重要措施。文章首先介绍了降级的基本概念和前置知识，包括降级与熔断的关系，以及降级的好处和原则。随后详细讨论了降级的实践方法，包括跨服务降级和本服务提供有损服务两大类，以及具体的降级策略和措施。此外，还提供了面试准备方面的建议和策略。最后，强调了降级作为构建高可用微服务架构的重要措施，并提供了两个方案作为参考。整体而言，本文深入浅出地介绍了降级在微服务架构中的重要性和实践方法，对于想要了解微服务架构下降级功能的读者具有很高的参考价值。
《后端工程师的高阶面经》，新⼈⾸单¥59
全部留言(10)
- 最新
- 精选
我好像一点都不像程序员端午节到了。饭馆突然出现了大量客人。 但是店里位置有限。都坐满了呀。而且短时间内不会有空位，赶紧关门暂停接待新客户（熔断） 陆续有客人离开了，但是外面等位的客人还是太多了，没办法把所有人都安排位置，让大家先排队吧，有位置就让安排排前面的客人坐下（限流）。 有些热门的菜做起来太慢了。后面的客人如果要点这些菜，就跟他们说这些菜卖完了，吃吃非热门的菜吧（降级） 可以降级的例子： 1、订单表数据太大了，把历史数据归档（比如每年归一次档），然后限制大家只能查近一年的订单，如果要查看更久之前的，要先提申请 只能熔断的例子： 1、服务依赖的数据库无法正常使用，导致很多上游服务处理各种阻塞，此时要果断熔断，直接让服务返回错误，避免上游服务大量的积压业务消息，或有大量的未释放的资源，导致上游服务不健康作者回复: 赞！我感觉这两个例子也蛮符合我说的规律，读请求一般比较好降级，写请求类的，就不太好降级。 历史数据之前我也搞过一个类似的，倒不是说要主动申请，而是历史订单，跑过去大数据平台上搜索，然后异步通知用户后面来看结果。
2023-06-25归属地：广东8
心平气和这个降级是写在业务代码里面的吗？还是在哪里有配置的地方。作者回复: 一般来说，是中间件和业务都要配合的，尤其是跟业务密切相关的怎么降级。 一般来说，中间件，比如说微服务框架的 middleware filter 之类的会帮助你判断是不是要降级。要降级的话就会把这个请求标记为降级请求，你在业务逻辑里面要根据这个标记来执行降级逻辑。本身这个分发机制也可以做得非常通用，但是正常业务逻辑、降级业务逻辑，这个必然是你写的。 也有一些通用的降级逻辑，比如说触发降级就返回默认值，那么你就可以在配置文件里面配置好默认值。 如果你有兴趣，你可以针对你现在的框架来研发一些通用的降级机制——比如说我提到的返回默认值，在面试的时候也可以是一个不错的亮点。
2023-06-26归属地：广东5
3.0的A7一 1、写多个数据源是什么意思？同一份数据写到多个数据库吗？还是说有多个业务的数据来源？ 2、如果是同一份数据写到多给数据库。降级的目的是腾出部分资源给核心系统使用。如果写服务写的多个数据源，应该考虑多个数据源所在的数据库节点压力的释放是否能给核心系统带来减负，如果可以，就可以降级为只写一个数据源。 3、如果是多个业务的数据来源。那可以按照这些写业务进一步按照重要度进行排序， 二 用小饭馆举例子 1 熔断就好比，我直接关门了 降级是你来我接待，但是你点的鱼香肉丝我只能给你方便面或者馒头作者回复: 非常对！这里指的是多个业务的数据库。写多个数据源的场景，一般的降级做法就是，正常就直接同步写，降级就只写最重要的，然后其他都是走异步，甚至直接不写其它数据源，依赖于后续的数据修复工具来修复数据。
2023-06-23归属地：内蒙古4
penbox1. 在前面讲了一个读写服务降级写服务的例子，你觉得写服务内部可以考虑降级吗？比如我的写服务是写多个数据源，可以降级为只写一个数据源吗？ 如果写服务内部还能根据重要程度拆分的话，内部也可以考虑降级。 比如对商家的大部分接口都停用了，但是保留修改商品价格和商品下架的接口，如果发生了 BUG 价之类的事故，商家还有机会即时止损。 对于写多个数据源的情况，在不影响业务的前提下，可以先写部分数据源，然后通过课程里面讲到的异步等手段，再来写其它数据源。 2. 这节课还解释了一下熔断和降级的联系和区别，你是如何看待这两者的关系？可以举一些可以降级或只能熔断服务的例子吗？ 熔断和限流都是提高系统可用性的措施。限流是通过主动降低服务质量，来保证系统核心功能能正常运行。熔断是通过停止服务，来避免出现连锁故障。 比如第三方短信平台挂了，本地的短信服务可以直接熔断，拒绝所有发短信的请求；也可以尝试降级，在第三方恢复前都返回一个明确的错误码，告诉用户不能发短信的原因，避免用户不断重试。 如果是订单的数据库挂了，用户的订单数据没法写入数据库，那么订单服务就只能进行熔断，在订单数据库恢复前，订单服务没法提供任何服务。作者回复: 赞！ 1. 写多个数据源，就是看业务，业务能接受就可以降级。 2. 在短信降级那里，要是不着急，还可以直接转为异步，后续自己再把短信发出去。
2023-07-03归属地：四川1
peter请教老师两个问题： Q1：一个网站的降级，是网站中某一个节点或服务控制吗？或者是每个服务自行控制？ Q2：服务降级后的恢复，也是等待一段时间而且这个时间通常也是经验值吗？作者回复: 1. 你说的两种形态都有。一种是服务自身控制，这种只能做到本服务内降级；但是跨服务降级，是需要有一个控制中心的。比如说，如果你们是自研的网关，就可以考虑让网关来协调不同服务之间的降级。 2. 等待一段时间确实是经验值。经验值比较难以确定，那么就可以考虑经验值 + 试探恢复策略，接近于熔断里面的那种做法。就是最开始是等待一段时间，但是这个等待时间可以非常短。之后就可以放一两个请求，不执行降级逻辑，看看能不能拿到正常响应，能就加大流量。不能就继续睡一段时间。如果你觉得一两个请求拿不到相应（也拿不到降级相应），那么可以考虑说每一秒发一个请求，试探一下看看有没有恢复。
2023-06-23归属地：北京1- 梦倚栏杆熔断: 我不行了，不要找我 降级: 集中有限资源干重要的事，不太重要的事情就要想办法解决了，什么静态页面，缓存，异步，等等
作者回复: 赞！
2023-12-03归属地：北京 - Geek_6806321.理论上来讲上可以的，例如同时写入MySQL和ElasticSearch，可以降级为只同步写入MySQL；从架构层面来讲，写入多个数据源不应该耦合在一起；2.熔断更关注的是服务的健康状态，在高并发的场景下避免服务崩溃；降级则是从请求流程的角度来考虑，然后提供更高的并发度；对超过应用处理能力的请求，只能进行熔断。
作者回复: 1. 是的，总的来说还是看业务。并且极力避免。 2. 嘿嘿，还可以转异步。转异步这种也要看业务，转异步究竟算熔断还是算降级，我个人偏向算降级。
2023-10-11归属地：浙江 
小晨"不过这种跨服务降级都是只能降级处在同一个节点的不同服务。而如果服务本身就分布在不同节点上的话，是比较难设计这种降级方案的。比如说大促时关闭退款服务这种，就需要人手工介入。" 就算时在同一个节点上，我们要降级(停掉)一个服务，也是需要人工介入的吧？作者回复: 这个要看你的服务是怎么定义的。如果你的服务是指不同的接口，比如说 user_service 和 user_detail_service 都是同一个进程，那么你就不需要人手动介入。 如果你说你同一个节点，buyer_service 和 seller_service 分别监听不同的端口，那么多半就是人手动介入了。 这其实是源自“服务”这个词汇语义不确定。
2023-07-08归属地：江苏
gevin写多个数据源降级为写一个数据源的场景，要细化为2个子场景分别分析：1. 多个数据源同步写 2. 多个数据源异步写 1. 多个数据源同步写 这种情况，说明数据很重要，且对数据的一致性要求较高，首先要评估这种情况是否要优先考虑熔断。如果要保证可用性，不熔断，那么优先考虑同步写一个数据源，其他的改为异步，还不行再考虑逐步停掉一些服务。无论哪种方式的降级，都要事先想清楚保证数据一致性的方案再做降级，对万一发生数据不一致留有预案 2. 多个数据源异步写 还可以继续拆子场景：（1）同步写一个数据源，其他数据源异步；（2）全部数据源都是异步写 对于子场景（1），其他数据源本来就是异步的，只要保证同步的数据源写即可，异步的都降级掉没有问题，如果同步写的服务要关停了，那就可以考虑熔断了 对于子场景（2），说明数据的重要程度和一致性不高，降级为异步写一个数据源没有问题作者回复: 分析很对！本质上就是你能接受什么样的一致性的问题。是强一致性还是最终一致性？最终一致性的最终，究竟是多久？ 这里，如果你出去面试的话，这部分最好要有实际案例支撑，所以平时可以在业务里面找找可以降级的东西。
2023-06-26归属地：浙江
Johar限流是目的，熔断和降级是限流后的两种处理方法。 思考题： 1.可以考虑写降级，特别是一些量大不重要的写数据，例如：埋点数据 2.降级：内部观测性数据，比如，埋点数据，服务的观测性数据，内部人员考核数据。作者回复: 很不错的观点。 我个人觉得，可用性是目的，限流是手段，被限流请求可以被熔断或者降级。 不过确实这三个概念意思接近。
2023-06-25归属地：重庆
