微服务架构中的 熔断和降级

熔断

微服务架构中，如果需要保障可用性，其中一个方式就是 熔断。熔断在微服务架构里面是指 当微服务本身出现问题的时候，它会拒绝新的请求，直到微服务恢复。通过熔断机制可以给服务端恢复的时间，比如 CPU 使用率已经超出负载了，此时服务端触发了熔断，那么新来的请求就会被拒绝，因此，服务端的 CPU 使用率就会在一段时间内降到100%以内。

判定服务的健康状态

判断微服务是否出现了问题，需要根据自己的业务来选择一些指标来代表这个服务器的健康程度，一般可以使用 响应时间、错误率。不管选择什么指标，都要考虑两个因素： 一是阈值如何选择；二是超过阈值之后，要不要持续一段时间才触发熔断。

假设 把响应时间作为指标，如果业务对响应时间的要求是在 1s 以内，那么你的阈值就可以设定在 1s，或者稍高一点，留点容错的余地也可以，原则上阈值应该明显超过正常响应时间。比如经过一段时间的观测之后，发现这个服务的 99 线是 1s，那么你可以考虑将熔断阈值设定为 1.2s。

如果响应时间一旦超过了阈值，也不能立刻就熔断，而是 要求响应时间超过一段时间之后才触发熔断。这主要是出于两个考虑，一个是响应时间可能是偶发性地突然增长；另外一个则是防止抖动。这个“一段时间”很大程度上就依赖个人经验了，如果时间过短，可能会频繁触发熔断，然后又恢复，再熔断，再恢复…… 反过来，如果时间过长，就可能会导致需要触发熔断的时候却迟迟没有触发。你可以根据经验来设定一个值，比如说三十秒或者一分钟。

总结：为了保障微服务的可用性，在核心服务里面可以接入熔断，针对不同的服务，可以设计不同的微服务熔断策略。比如最简单的熔断策略就是根据响应时间来判定，当响应时间超过阈值一段时间之后就会触发熔断；一般会根据业务情况来选择这个阈值，如果产品方要求响应时间是1s，那么可以把阈值设定在1.2s。如果响应时间超过1.2s，并且持续三十秒，就会触发熔断。在触发熔断的情况下，新请求会被拒绝，而已有的请求还是会被继续处理，直到服务恢复正常。

还可以根据缓存策略设计熔断方案，比如某一个接口得并发很高，对缓存的依赖度非常严重，所以当检测到缓存不可用的时候（比如说 Redis 崩溃了），那么就会触发熔断，因为此时如果不熔断的话，高并发的请求会因为 Redis 崩溃而全部落到 MySQL 上，导致压垮 MySQL。
在触发熔断之后，可以额外开启一个线程（例如 Goroutine）持续不断地 ping Redis的服务是否正常，如果 Redis 恢复了，那么就退出熔断状态，新来的请求就不会被拒绝了。
这种方案类似于处理缓存雪崩的问题，参考：《缓存雪崩、缓存击穿、穿透穿透具体指哪些问题？》

服务恢复正常

如果我们判断一个服务响应时间过长，进入了熔断状态，那么一段时间（比如十分钟）过后，已接收的请求已经被处理完了，也就是服务已经恢复正常了，那么就需要退出熔断状态，继续接收新请求。因此在触发熔断之后，就要考虑检测服务是否已经恢复正常。

如果本身熔断是高并发引起的，那么在一分钟后并发依旧很高，这时候你一旦直接恢复正常，然后高并发的流量打过来，服务是不是又会触发熔断？ 这就会出现上面说的“抖动”的情况。

所谓 抖动：就是服务频繁地在正常-熔断两个状态之间切换。引起抖动的原因是多样的，比如说前面提到的一旦超过阈值就进入熔断状态；再比如“一分钟后就认为服务已经恢复正常，继续处理新请求”就容易引发抖动问题。

要解决这个抖动问题，就需要在恢复之后控制住流量。比如说按照 10%、20%、30%……逐步递增，而不是立刻恢复 100% 的流量（需要负载均衡来配合）。在这种逐步放开流量的措施下，依旧有请求因为熔断不会被处理，那么有没有更好的处理方式？

其实，可以让客户端来控制这个流量。就是当服务端触发熔断之后，客户端就直接不再请求这个节点了，而是换一个节点。等到恢复了之后，客户端再逐步对这个节点放开流量。整体思路是利用负载均衡来控制流量，如果一个服务端节点触发了熔断，那么客户端在做负载均衡的时候就可以将这个节点挪出可用列表，后续请求会发给别的节点。在经过一段时间之后，客户端可以尝试发请求给该节点。如果该节点正确处理了，那客户端就可以加大流量，否则客户端就要再一次等待一段时间。

综合运用负载均衡和熔断的方案，重点在于客户端控制流量，并根据服务端节点的状况来操作可用节点列表。参考：《微服务的注册发现和微服务架构下的负载均衡》

万一所有可用节点都触发熔断了，应该怎么办？ 如果因为某些原因数据库出问题，导致某个服务所有的节点都触发了熔断，那么客户端就完全没有可用节点了。针对这个问题，熔断解决不了，负载均衡也解决不了，只能通过监控告警之后人手工介入处理了。

整体流程：

1. 服务端在触发熔断的时候，会返回一个代表熔断的错误。
2. 客户端在收到这个错误之后，就会把这个服务端节点暂时挪出可用节点列表。后续所有的新请求都不会再打到这个触发了熔断的服务端节点上了。
3. 客户端在等待一段时间后，逐步放开流量
4. 如果服务端正常处理了新来的请求，那么客户端就加大流量。
5. 如果服务端再次返回了熔断响应，那么客户端就会再一次将这个节点挪出可用列表。
6. 如此循环，直到服务端完全恢复正常，客户端也正常发送请求到该服务端节点。

降级

降级就是在服务资源不够用的时候，停用一部分边缘业务，这部分被停用的边缘业务可以被理解为“全部熔断了”。

比如在双十一之类的大促高峰，电商平台可能会关闭一些服务（比如退款服务）用来保证订单业务尽可能不受影响（当然营销策略部分不在我们的讨论范围），这就是降级的典型应用，不过它是一种手动的跨服务降级。这种降级的好处有两方面：一方面是腾出了服务器资源，可以给订单服务或者支付服务；另外一方面是减少了对公共组件的压力，比如说减少了对数据库的写入压力。

关于服务降级，主要关心的也是两个方面，其一、如何判定一个服务要不要降级（如何判定服务健康）；其二、降级之后怎么恢复，也是要考虑抖动的问题。熔断是彻底不提供服务，而降级则是尽量提供不分服务。

所以在一些场景下，既可以用熔断，也可以用降级。比如说在响应时间超过阈值之后，可以考虑选择熔断，完全不提供服务；也可以考虑降级，提供一部分服务。

原则上来说，是应该优先考虑使用降级的，然而有些服务是无法降级的，尤其是写服务。例如 你从前端接收数据，然后写到数据库，这种场景是无法降级的。另外，如果你希望系统负载尽快降低，那么熔断要优于降级。

如何降级？基本上可以分成两大类：跨服务降级 和 本服务提供有损服务。

跨服务降级

当服务资源不够的时候可以暂停某些服务，将腾出来的资源给其他更加重要、更加核心的服务使用。（上面提到的大促期间暂停退款服务就是跨服务降级的例子）。这种策略的要点是，必须要确定一个服务比另外一个服务更有业务价值，或者更加重要。

跨服务降级的措施常见的做法有三个：

• 整个服务停掉，例如前面提到的停掉退款服务。
• 停掉服务的部分节点，例如十个节点，停掉其中五个节点，这五个节点被挪作他用。
• 停止访问某些资源。例如日志中心压力很大的时候，发信号给某些不重要的服务，让它们停止上传日志，只在本地保存日志。

跨服务降级可以在大部分合并部署的服务里面使用，一般的原则就是 B、C端合并部署降级 B 端；付费服务和非付费服务降级非付费服务。当然也可以根据自己的业务价值，将这些部署在同一个节点上的服务分成三六九等。而后在触发降级的时候从不重要的服务开始降级，将资源调配给重要服务。

自身服务提供有损服务

例如各大 App 的首页都会有降级的策略。在没有触发降级的时候，App 首页是针对你个人用户画像的个性化推荐。而在触发了降级之后，则可能是使用榜单数据，或者使用一个运营提前配置好的静态页面。这种策略的要点是你得知道你的服务调用者能够接受什么程度的有损。

针对服务本身的一些常见的降级思路：

• 返回默认值，这算是最简单的一种状况。
• 禁用可观测性组件，正常来说在业务里面都充斥了各种各样的埋点。这些埋点本身其实是会带来消耗的，所以在性能达到瓶颈的时候，就可以考虑停用，或者降低采样率。
• 同步转异步，即正常情况下，服务收到请求之后会立刻处理。但是在降级的情况下，服务在收到请求之后只会返回一个代表“已接收”的响应。后续服务会异步地开启线程来处理，或者依赖于定时任务来处理。
• 简化流程，如果你处理一个请求需要很多步骤，后续如果有一些步骤不关键的话，可以考虑不执行，或者异步执行。例如在内容生产平台，一般新内容要被推送到推荐系统里面。那么在降级的情况下你可以不推，而后可以考虑异步推送过去，也可以考虑等系统恢复之后再推送过去。

需要注意的是，在任何的故障处理里面，都要考虑恢复策略会不会引起抖动问题。

也可以考虑使用降级来保护 缓存-数据库 结构，一般来说，基本上都是先从缓存里面读数据，如果缓存里面没有数据，就从数据库中读取。那么在触发降级的情况下，可以考虑只从缓存里面读取，如果缓存里面没有数据，那么就直接返回，而不会再去数据库里读取。 这样可以保证在缓存里面有数据的那部分请求可以得到正常处理，也就是提供了有损服务。如果完全不考虑从数据库里取数据，那么你的性能瓶颈就完全取决于缓存，那么服务能够撑住的 QPS 会非常高。但是，如果缓存不命中的时候要去数据库取数据，那么服务的性能会衰退得非常快，即极少数缓存未命中的请求会占据大部分的系统资源。

具体案例分析

如果你的某个服务是同时提供了读服务和写服务，并且读服务明显比写服务更加重要，那么这时候你就可以考虑降级写服务。

假如说现在有一个针对商家的服务（比如 某团外卖），商家调用这些 API 来录入一些数据，比如他们门店的基本信息，上传一些门店图片等。同时还有一个针对 C 端普通用户的服务，这个服务就是把商家录入的数据展示在商家门店的首页上。所以你可以看到在这个场景下， 读服务 QPS 更高，也更加重要。那么如果这两个服务是一起部署的，在需要降级的时候，就可以考虑将针对商家的写服务停掉，将资源都腾出来给针对 C 端用户的读服务。从资源占用的角度分析，虽然整体来说写服务 QPS 占比很低，但是对于数据库来说，一次写请求对性能的压力要远比一次读请求大。所以暂停了写服务之后，数据库的负载能够减轻不少。

具体解决方案1（ 读写服务中 降级写服务）：接入一个跨服务的降级策略，当发现读服务的响应时间超过了阈值的时候，或者响应时间开始显著上升的时候，就将针对 B 端商家用户的服务临时停掉，腾出来的资源都给 C 端用户使用。对于 B 端用户来说，他们这个阶段是没有办法修改已经录入的数据的，但是这并不是一个特别大的问题。当 C 端接口的响应时间恢复正常之后，会自动恢复 B 端商家接口，商家又可以修改或者录入数据了。

在内容生产平台，作者生产内容，C 端用户查看生产的内容。那么在资源不足的情况下可以考虑停掉内容生产端的服务，只保留 C 端用户查看内容的功能。如果你的用户分成普通用户和 VIP 用户，那么你也可以考虑停掉给普通用户的服务。甚至，如果一个服务既提供给普通用户，也提供给 VIP 用户，你可以考虑将普通用户请求拒绝掉，只服务 VIP 用户。毕竟，VIP用户花钱了！

判断一个服务的业务价值最简单的方法就是判定什么业务带来了多少价值，又或者根据公司的主要营收来源确定服务的业务价值，越是能赚钱的就越重要。

具体解决方案2（快慢路径中 降级慢路径）：在查询商品数据中，先查询缓存，如果缓存有数据，那么就直接返回。如果缓存没有，那么就需要去数据库查询。如果此时系统的并发非常高，那么就采取降级策略，将请求标记为降级请求。降级请求只会查询缓存，而不会查询数据库。如果缓存没有，那就直接返回错误。这样能够有效防止因为少部分请求缓存未命中而占据大量系统资源，导致系统吞吐量下降和响应时间显著升高。

这种思路其实可以在很多微服务里面应用。如果一个服务可以分成快路径和慢路径两种逻辑，那么在降级之前就可以先走快路径，再走慢路径。而触发了降级之后，就只允许走快路径。上面例子中，从缓存里加载数据就是快路径，从数据库里面加载数据就是慢路径。

慢路径还可以是发起服务调用或者复杂计算。比如说一个服务快路径是直接查询缓存，而慢路径可能是发起很多微服务调用，拿到所有响应之后一起计算，算出来一个结果并缓存起来。那么在降级的时候，可以有效提高吞吐量。不过这种吞吐量是有损的，毕竟部分请求如果没有在缓存中找到数据，那么就会直接返回失败响应。