β

再谈服务流量控制(9.22)

Harries Blog™ 92 阅读

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

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

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内存溢出或管道破裂了。

原文

http ://blog.sina.com.cn/s/blog_493a84550102xut7.html

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。 PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处: Harries Blog™ » 再谈服务流量控制(9.22)

作者:Harries Blog™
追心中的海,逐世界的梦
原文地址:再谈服务流量控制(9.22), 感谢原作者分享。