我该不该将控制流指令写入通用结构组件中？

简单来说就是：规则+资源最终通过计算后触发限流熔断行为。

03-对计算逻辑的关键说明

在前面我们把规则和资源讲清楚后，再来看下具体的计算逻辑思路。

对于计算逻辑，我们可以将计算过程分解为多个独立的计算单元，然后多个计算单元的组合最终形成了完整的计算和处理逻辑。

大家可以看下，对于Sentinel限流熔断产品中的Slot概念正是可以理解为我们前面谈到的计算单元。Sentinel将各个Slot的能力最终组合在一起完成了一次完整的限流熔断逻辑处理。

对于计算逻辑，我们还是要回归到具体的规则配置。

比如，我们配置完成的规则呈现方式可能如下：

• 对于用户查询API接口，在5分钟内调用次数大于1万次即整体熔断
• 对于CRM系统消费产品查询接口，在10分钟内如果平均时长大于30秒则拒绝CRM访问
• 对于订单更新API接口，如果失败率超过1%则全部熔断

从上面的描述我们看了单位时间的概念，即当我们去触发限流熔断行为的时候，我们不希望是一次偶然的调用并发或异常就马上触发，而是希望是我们观察的一个单位时间段，如果持续发生某种异常行为才触发。

这个单位时间可以是5分钟，也是是10分钟，乃至1个小时。

也就是说我们最终统计的是单位时间的最终汇总统计数据。也就是说对于服务运行实例数据我们需要进行实时采集，采集完成后在基于资源粒度进行分类汇总，形成汇总数据。

那么如何汇总?

如果希望是统计1个小时，难道我们要在内存里面一直存储一个小时的实例数据，达到了1个小时的单位时间后再进行汇总处理?这个显然是不合适的。


 

即我们对资源本身的颗粒度进一步细化，从最细粒度到最粗粒度可以分为：

• 最细粒度：API消费方+API服务+API提供方
• 熔断层：API服务+API提供方
• 熔断范围：API提供方(对API服务提供方所有服务进行熔断)

以上三种粒度才是我们实际进行资源控制的时候需要考虑的内容。

为啥考虑这个问题，搞清楚了资源管控的颗粒度，我们一个方面是要在规则配置的时候支持多种层次的配置，一个方面就是我们实际实时数据计算的时候需要进行颗粒度的考虑。

02-对规则的关键说明

要实现限流熔断，简单来就是三个方面的内容，一个就是资源，一个是就是规则，一个就是通过计算汇总处理过程。计算过程最终就是来判断在某一个时间点当前的实际数据是否已经满足了规则触发的要求，如果满足要求就触发规则进行限流熔断。

对于规则，首先要考虑维度定义，而维度本身就是API接口服务运行实例的汇总统计数据，那么这些场景的维度包括了：

• API服务运行时长
• API服务单位时间的运行次数
• API服务运行数据量

而这三个基础维度本身又会进一步产生其它扩展维度，比如我们常说的最大数据量，评价数据量，运行失败次数，运行成功率，运行最大耗时等。

而对于具体的规则，我们希望最简单处理，即：

某一个指标 大于 或小于 我们预定的某一个阈值，就算规则满足。

其次就是可以定义复合规则。复合规则也简单处理为规则的与或处理，即：

规则1和规则2同时满足，就算整体规则满足

而对于规则本身的作用范围，我在前面已经讲到，即资源本身的不同粒度。规则可以最细化的作用到某一个特定的消费方调用的某一个特定服务，也可以是作用到某个服务所有消费方。



 

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!