再谈服务流量控制(9.22)

项目临近上线，因此最近做的最多的事还是服务运行监控和性能分析，也对流量控制做进一步的思考。

首先还是解释下流控的两种场景，即限流和断流。

1. 限流：对于服务请求仍然接收，但是如果你并发量大了就在外面排队，而不是将压力全部传递到ESB。

2. 断流：如果发现大数据，大并发的异常调用则直接进行熔断处理，不允许再进行调用。

具体如何进行限流和断流，一个就是针对消费方系统，一个就是针对具体的服务，当然也可以是消费方+特定服务精确组合进行限流。我们举个例子来说明下这个场景。

比如在你家附近有5个小区，旁边刚好有3个电影院，5个小区的人一般都去这3个电影院看电影。那么当出现看电影的人多拥挤的时候就存在三种做法。其一就是小区A的人都不允许去看电影，3个电影院都不允许；其二是3个影院中的万达影院不允许所有小区去看电影；其三就是小区A的人不允许去万达影院看电影。

而对于限流或断流的处理往往就存在上面的三种情况，需要分别对待。比如仅仅发现是ERP系统消费MDM的查询供应商服务出现大并发，大数据量调用。那么我们只需要对ERP系统+该服务进行限流或熔断处理即可，而不是对整个ERP系统或所有服务都进行禁用。或者当你发现ERP提供的查询OU组织服务出现响应很长，导致性能极低的时候，你可以将查询OU服务进行熔断，不允许所有的消费方进行调用。

究竟采用哪种方式，必须根据实际的服务调用场景，并发和性能分析来综合进行分析和判断。

在前面很多文章里面，我都谈到过，对于ESB服务总线，大并发调用并不可怕，大数据量短耗时也不可怕。真正可怕的是大数据量+长耗时的调用，这种调用会导致ESB总线的JVM内存一直增长而无法释放，最终导致总线的管道破裂，JVM内存溢出。而我们对JVM启动参数的调整更多也是在调整究竟设置多大的堆内存合理，究竟采用哪种垃圾回收机制效率更高。

所以对于限流和断流的触发，并不是简单的根据服务调用并发量，或者服务调用的数据量，响应时间进行就可以了，最好的方法是结合实际的活动线程数，当前的JVM内存使用和增长率来进行。

1. 如果我们发现当前活动线程数一直持续增加，无法释放，那么我们就需要对大并发服务调用限流。

2. 如果发现是JVM内存持续增长而无法释放，那么就需要对大数据量调用进行限流。

这种限流方式往往更加科学合理，也就是说如果仅仅是一次大数据量调用，比如超过20M的消息报文，那么对整体ESB总线的影响并不会太大。但是如果该服务被大并发在调用，那么一定导致线程数增加，JVM持续增长到90%或以上，那么这个时候才需要及时触发限流和熔断机制。

注意，消息报文量和实际的JVM内存耗用量不是等比关系，对于20M的消息报文，往往在JVM内存里面需要耗费掉100M甚至更多的内存，这点必须要引起注意。如果同时有5个这种大数据量并发调用，往往就会导致你JVM内存溢出或管道破裂了。