再谈服务监控预警和流控(3.4)

今年对于服务监控部分一个重要改进就是服务流量控制，即在服务监控预警的基础上，基于既定的监控预警指标触发的自动化流量控制。流量控制的核心目的还是充分保证ESB服务总线本身的可靠性和稳定性，其中既包括了限流也包括了断流。

1.限流的作用是对大并发过来的访问请求进行排队，主要是控制并发线程数

2.断流则是直接对服务进行拒绝访问，可以是整个服务停用，也可以是对单个服务取消访问授权

动态准实时流控计算和触发

在我们进行流控的时候，最好的方式就是做到不断的对最近单位时间里面的运行数据进行统计，超过了我们预设的阈值就触发相应的流控。注意我们计算可以每5-10秒就动态计算一次，但是实际我们仍然是计算从当前时间点开始超前推移的一个时间周期，比如1分钟或5分钟的统计数据量。

在实现的时候，注意我们的动态统计数据应该是在应用服务器的缓存里面，当请求来后应该是动态的更新缓存数据，缓存数据应该是最近一个单位时间的统计数据，可以是总量，也可以是平均值。

也就是说我们这个数据是不断的滚动计算的。既然是滚动计算，那么 除了一个触发流控的阈值外，还需要设计一个流控解除恢复的的阈值 。通过这两个值我们来动态控制流控策略的使用。

举例来说明下：以某一个服务单位时间，最近5分钟，最大的数据流量要小于100M，解除阈值为30M，动态计算时间为每30秒计算一次。具体处理逻辑如下。

1. 到30秒间隔，对最近5分钟的数据流量进行计算。

  1.1 如果当前流控策略生效状态，则判断数据流量是否>30M

a. 如果判断为真，则继续保持流控

b. 如果判断为假，则解除流控

  1.2 如果当前流控未生效，且数据流量>100M

a. 如果判断为真，则对流控策略进行生效

b. 如果判断为假，则不做任何处理

注意对于具体的流控策略，即可以是对服务访问进行限流，也可以是直接断流。其中断流既可以对单个消费端系统进行断流，也可以对所有服务消费方进行断流。

按实际的业务场景来分析，一个服务如果有50个消费方访问，很可能就是其中1到2个服务消费方出现大并发服务调用导致了整体平台或服务出现异常或响应缓慢。因此最好就是要做到对特定的服务消费方发起流控。而不是对整个服务进行断流。

服务流控需要保持计算的实时性，同时又不能对服务正常运行造成太多的性能影响和损耗。因此在整个流控模块设计的时候，需要将所有计算结果数据全部放在内存里面，而且对内存不断的进行刷新。这个是流控设计最难实现的一个点。

定时时间间隔进行流控计算，定期解除

另外一种实现思路，不进行实时计算，我们仍然用我们分钟级的统计结果数据进行流控。因为分钟级的统计数据中间表，现在服务运行监控预警本身就在生产。基于这个数据我们就不需要每次都对服务请求进行统计。只需要将分钟级别的统计数据存入到缓存中即可。

我们来举个例子，比如一个系统登录，一天最大重试次数就是三次，你如果三次都输入错误，或者对账号进行锁定，或者你只有明天才有资格重试。对于流控一样道理，我们虽然是分钟级流控计算，但是我们的解除策略就难以做到动态和实时。

在这种场景下， 流控解除我们可以预设一个固定值，超过后即自动解除 。比如流控只要触发，那么就需要10分钟后才自动解除。从流控开始的10分钟你都无法访问服务。到了10分钟后流控策略自动解除，又开始新的计算过程。这个是和我前面讲的第一张动态实时流控最关键的一个差别点。