再谈服务限流和熔断(6.20)

首先本文谈到的服务限流和熔断，和常规我们说的限流和熔断有区别，具体说明为：

1. 服务限流：取消某个消费方对某个服务的访问授权，只单个消费方受影响

2. 服务熔断：直接对该服务进行下线处理，或将该服务状态设置为不可用，所有消费方受影响

其次，对于服务流控我们需要设置具体要监控哪些指标 ，注意这个指标监控是在单位时间里面的监控指标，即计算在单位时间的累计数据，当触发后即进行流控。具体包括：

1. 运行次数： 单位时间里面的运行次数累计，比如一个消费方大并发调用，可以限流

2. 业务系统异常次数： 即源服务出现异常的次数，也可以考虑异常占比率

3. 系统异常： 即出现系统级异常次数，本身包括Token失效，也包括ESB总线本身故障

4. 报文量： 即单位时间内传输的报文量达到某个值，考虑是输入+输出报文量和的累计

对于运行时长更多是预警，而实际上直接限流和熔断不现实。因此主要的流控指标就是上面这些，基于以上指标本身又有两种操作，一种是限流，一种是整个服务熔断。而实际上可以看到。

1. 限流：运行次数，Token失效，报文量

2. 熔断：业务系统异常，系统ESB本身故障异常

限流熔断解除， 最后，在还需要考虑的就是在实施了限流和熔断后如何解除的问题，在实际实现的时候，对于限流可以在规定时间后自动解除，而对于熔断最好还是人工恢复解除。即比如对CRM系统访问MDM的查询供应商服务进行限流后，在启动限流后的某个时间间隔后，比如2小时后，可以自动进行解除。这个时间间隔可以灵活配置。

以上限流和熔断实现基本可以满足我们大部分的业务需求场景，同时本身又对ESB总线和业务系统实现保护作用，防止出现大并发大数据量的调用出现的影响。当然对于限流也可以人工进行恢复，人工恢复好处是可以跟踪到消费方端是否已经修改了消费方法，当确认修改后再进行重新授权恢复调用。

我们结合本文最前面的图来说明下整个实现过程

前期已有和已经实现的工作有

1. 所有的服务消息调用实例日志数据全部入JMS，再异步写入到数据库。

2. 运行每分钟的定时任务，将实例日志汇总为分钟级的统计表，Group By 消费方ID+服务ID

接着我们来看，需要增加的实现过程

1. 构建一个服务限流熔断实时记录表集合，暂约定为集合A

1.1 在内存中记录，可以不入库

1.2 表应该包括字段为消费方ID，服务ID，开始记录时间，数据量累计，次数累计，异常累计

2. 再增加一个定时任务，每分钟执行一次

2.1 找到最近1分钟配置了限流熔断的服务信息，提出一个服务子集合B

2.2 对集合B进行循环，判断集合B里面的的记录行是否在集合A中能够检索到

2.2.1 如果检索不到，增加一行

2.2.2 如果检索到，判断当前时间-开始记录时间是否大于统计时间间隔

a) 如果小于间隔，则对所有数据进行累加处理

b) 如果大于间隔，则对该行数据进行擦写重新计数，开始记录时间为当前新时间

2.3 对该行处理数据进行判断，是否满足了限流熔断条件？

1.3.1 如果满足限流条件，则对该消费方取消对该服务的授权，记录限流状态和限流开始时间

1.3.2 如果满足熔断条件，直接对该服务进行熔断，标记状态，并记录熔断时间

3. 再增加一个定时任务，可以每1分钟运行一次，进行限流解除操作

3.1 对集合A里面的数据进行循环，找到当前状态为限流或熔断的服务

3.2 判断当前时间-限流开始时间是否大于设置间隔，如果大于并超时，就进行限流恢复

该实现思路存在的问题点

注意该实现思路并非是基于流处理模式的，可以持续监控连续的时间间隔下面是否出现了超过指标阈值的情况，即我们在数据处理的时候也不是持续的去取最近1个时间的汇总数，如果这样处理本身会消耗更多的资源和性能。考虑到实际应用场景，虽然没有实现连续的流监控，但是基本能够满足限流熔断需求。