通过API网关实现微服务管控-限流，熔断和降级( 四 ) _微服务

由于每个服务本身的并发量不一样，出现峰值的时候也不一样，同时API网关本身承载了多个服务实际更多需要的是控制整个API网关本身的性能负荷，确保网关运行的稳定性。

微服务架构体系下，对于微服务框架内本身也有熔断降级处理措施和机制，那么在这种场景下API网关的限流熔断首先要考虑为了自身的高可靠性运行需求。

如果我们对每个服务都进行配置，往往并不能很理想地达到限流熔断的目的。基于项目实际的实践情况来看，要么是这个值配置的太小，导致对本身可以通过的服务请求进行了熔断和拒绝；要么是这个值配置的太大，API网关本身已经内存溢出也没有触发熔断规则。
那么究竟是什么会影响到API网关的稳定性？
这个一方面是大量的服务访问请求连接长时间保持不释放，导致线程池被消耗完；一方面是出现大报文的消息调用，导致JVM持续增长而无法回收。这两种才是导致API网关出现宕机，重启或不可用的关键因素。
简单来说即首先设置一个统一的JVM阈值和线程池当前线程数阈值即可。
然后规则中心对两个值进行持续的心跳监控，当发现阈值超过的时候，快速地找到对应的接口服务和服务请求方，并执行限流或熔断操作，必要的时候还可以直接kill掉当前线程。如果上述方法还不能恢复的话，还需要对集群中超过阈值的节点强制进行节点重启操作，以防止集群进行故障漂移，导致正常节点也出现问题。
其次，整个服务性能下降也可能出现在月结或年结的时候，这个时候监控中心并不会发现有明显突发的大并发调用或大报文调用，而是所有接口服务访问量都线性在增长。这个时候一方面可以自动触发资源弹性扩容操作，另外一个方面就是可以实施服务降级策略，将SLA等级低的服务进行限流或者直接熔断以释放资源。
API网关限流熔断整体逻辑对于整个限流熔断的处理逻辑流程，我们可以简化为下图：

文章插图

对于该图，实际可以看到，如果按 Slot计算逻辑单元划分的思路可以分为：

基于配置的规则将服务运行实例按资源颗粒度匹配要求存到实例数据暂存区
进行第一次汇总计算
将汇总数据推入到滑动时间窗口数组
基于规则配置进行二次汇总计算
对限流熔断是否触发进行判断和处理

我们再将上面的思路做一个简单的描述。
比如我们当前在限流熔断规则配置中配置了三条独立的规则，不同的资源颗粒度。

规则1：对于CRM消费getCustomer接口进行限流，10分钟调用>1万即拒绝
规则2：对于getProductinfo接口流控，5分钟错误>1%则整体熔断
规则3：对于ERP系统提供所有服务，1分钟平均时长>30秒则整体熔断

如果是以上三条独立的限流熔断规则，则我们需要配置三个不同的临时数据存储区和三个独立的滑动时间窗口区。
在朝10秒临时数据暂存区推送临时数据的时候可能会造成冗余，但是在限流规则本身不带来配置的情况下该方案反而是最优方案。毕竟在实际应用场景中，我们往往是在发现了明细的性能异常或问题的时候才会配置限流熔断规则。
比如，CRM系统调用getCustomer API接口。
当获取到这次实例数据的时候，我们将其推送到第一个缓存集合，如果该接口本身也是ERP系统提供的接口，那么我们会同时将该数据推送一份到ERP系统缓存集合。
对于缓存数据集，我们每10秒就做一次汇总处理。并将汇总完成的结果数据形成一条记录推送到对应的滑动时间窗口区。在推送完成后将该数据集数据全部清空或进行资源释放。
基于滑动窗口数据的二次数据处理
对于滑动窗口中的二次数据处理，我们可以在每次数据推送完成后就计算一次滑动窗口数据，比如5分钟规则，我们就获取窗口中最近5分钟的数据进行二次汇总，并判断二次汇总后的数据是否满足了相应的触发条件。
如果满足条件，就进行限流熔断处理。
对于这部分内容的详细说明，可以参考我前面发布的文章：