高并发整体可用性：一文详解降级、限流和熔断

• 并发线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。

合作方只有那么大的能力，我只能索取这么多！

对下游依赖系统的服务能力，需要有一个精准的判断，对于服务能力弱的下游系统，要适当减少调用，得有点眼力见，对不对。

因为，绝大部分的业务系统都不是单独存在的，会依赖很多其他的系统，这些依赖方的服务能力，就像是木桶短板，限制了当前系统的处理能力。这个时候就需要把下游当做一个整体来考虑。

因此，需要把集群限流和单机限流配合起来使用，特别是下游服务的实例数、服务能力等和当前系统有较大差距的时候，集群限流还是必要的。

一种方案：是通过收集服务节点的请求日志，统计请求量，并通过限流配置，控制节点限流逻辑：

我将其称为后置限流，即收集各个节点的请求量和既定阈值对比，超过则反馈到各个节点，依赖单机限流进行比例限流。

另一种方案：是限流总控服务，根据配置生产token，然后各个节点消费token，正常获取token后才能继续业务：

摘自:Sentinel

我将其称为前置限流，预先确定分配好可用的token，省去了汇总和反馈的处理机制，相比而言，这种控制方式要相对精准和优雅。

合作方虽然能力有限，但态度很好，加班加点的处理；而我们的客户也很友好，同意多等等

一个非常经典的例子，就是第三方支付平台的还款业务，用过的同学应该都有体会，一般都是支付完成之后等一会才会收到销账的通知。

这个时延的底层逻辑是什么呢？

一般的，金融机构的服务接口，因为其数据一致性和系统稳定性的要求，性能方面可能不如互联网公司的系统。

那么，当到了月初月末的还款高峰，如果把支持成功用户的销账请求一股脑的都压给机构，后果可想而知。

但是，对于用户来说，整个流程是可以被拆分的，用户侧只要完成支付操作就可以了。至于最终结果，可以允许延后被通知。

因此，基本上，金融网关在处理机构销账都是异步的，即先将各业务的销账请求落地，然后异步的限速轮询待处理的单据，再和机构交互。

其实，不仅仅是在金融领域，只要我们的业务处理速度存在差异，且流程可以被拆分，即可考虑这种架构思路，来缓解系统压力，保障业务可用性。

事发突然，能力有限，我只能紧着几个重要客户服务！

那么，什么情况需要降级，什么链路可以被降级呢？

当整个业务处于高峰期，或活动脉冲期，当服务的负载很高，逼近了服务承载阈值，即可以考虑服务降级来保障主功能可用。

可以降级的一定是非核心的链路，比如网购场景下的积分抵扣，如果降级积分抵扣链路，其实不影响大部分的支付功能。

那么，在系统中我们一般采用的降级方案有哪些呢？

即从用户操作页面进行操作，直接限制和截断某功能的入口：

从页面入口对积分链路降级

如上图所示，该业务场景下，是否使用积分，是在页面渲染阶段决定并返回给前段进行页面拼接的。

当我们需要对其进行降级时，会通过控制平台进行降级开关切换，系统读到降级开启后，会返回前段积分降级的标识，前端将不再显示积分抵扣入口。即从入口处截断积分链路的执行，达到降级的目的。

使用缓存方式来降级频繁操作的存储

https://blog.csdn.net/di_ko/article/details/118058080

对于秒杀业务这种写多读少的场景，对DB的压力是非常大的，一般的，我们会采用上图所示的缓存架构，用缓存操作代替DB操作，用异步MQ代替同步接口，也属于一种存储的降级行为。

对于非核心信息的读请求禁用

微信的抢红包场景，红包列表的展示属于抢红包的非核心链路，因此，对于列表展示，在业务压力较大的情况下，对头像等信息的读，可以直接禁用。

直接禁止相关写操作的服务请求

总结，一句话概括降级的核心--丢车保帅。以损失部分体验的代价，来换取整个业务链路的稳定性和持续可用。