首页 » 漏洞 » 利用ESB和EDA结合解决服务高并发下性能(8.2)

利用ESB和EDA结合解决服务高并发下性能(8.2)

 

利用ESB和EDA结合解决服务高并发下性能(8.2)

前段时间和一个客户交流,客户反馈了一个很有意思的场景,他们在系统集成过程中发现,处于外网的系统A调用非常频繁,外网系统A通过Webservice方式消费内网系统B提供的服务,由于是同步服务,在并发量非常大的时候经常会出现阻塞、调用失败甚至应用服务器崩溃的情况。

后来客户在系统B中加入了消息中间件JMS,虽然出现了明显的改善,但还是因为并发次数太高,内网B系统处理的速度赶不上A系统调用增加的次数,JMS队列数持续据高不下,B系统处理性能受到影响,从而导致整个业务操作越来越慢,最后不得不通过暂停服务、重启队列来恢复系统。

说到这里,突然联想到很久之前在广州坐地铁的场景,当时在珠江新城站下班时发现在地铁闸机前有几个保安拿着对讲机在指挥排队,可能因为从来没有在人流量如此大的站坐过地铁,只是觉得只有在进入地铁车厢时会要排队,所以觉得有些新奇。在排队过程中发现,每次闸机前的保安都会通过对讲机了解下地铁下的人流情况,确认好后再放行一部分。到了地铁下面发现虽然还是要排队,但是不会觉得很拥挤,出入车厢井然有序,效率很高,也不会由于拥挤影响地铁在站头的等待时间。

从表面上看,以上两个事情可能毫无关联,但细想下其实两个场景都是在排队,一个排队的是人,一个排队的是数据。因此对于客户反馈的集成场景我们应用到地铁乘车,如果在闸机前不再设置一个队列,并且不通过对讲机来实时了解地铁下的排列情况,是不是在人流量非常大的时候就会造成地铁下通道的大量拥挤,形成阻塞,给车厢的进出效率带来很大影响。

理解了以上这些,那么客户的问题亦可迎刃而解,即我们可以通过SOA套件中的ESB内置消息中间件再来设置一层队列,而实时对讲的机制可以通过SOA套件的EDA事件驱动来完成。整个处理过程经上述优化后如下:

假如A系统有1000个并发,那么传递到ESB的消息队列时也同样是1000个并发,但是ESB转发给B的消息队列是根据B系统本身的处理能力来设置的,我们暂且将B系统的最大处理队列数定为100,可再接收处理数为60,那么ESB转发给B系统消息队列在100个并发请求之后便不再转发,在B系统处理到还剩下60个并发数时再次进行转发。那么ESB如何知道B系统目前正在排队的并发数呢?很显然可以通过EDA的事件来完成B系统队列的监控,当B队列>100时触发该事件,ESB队列停止发送请求到B,当B队列<60时触发该事件,ESB队列继续发送请求到B。通过这样的设计,可以避免B系统队列的大量并发积累导致的处理效率低下,也可转嫁部分压力到ESB,实现应用间的解耦。 (注意类似ESB总线流量控制中的入口限流和出口限流)

关于EDA:事件驱动框架(EDA)里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件,事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时,事件管理把这个事件转送给相应的事件消费者。

---------------------------------------------------------------------------------------------------------

备注:深圳市远行科技股份有限公司是一家专业从事SOA和ESB规划咨询,建设实施的高新技术软件企业,2016年在新三板挂牌上市。曾经成功建设和实施了中国移动集团,中国联通集团,江西移动,山东移动,贵州移动,TCL集团,唐人神,华星光电,中油中泰多个大型ESB项目。

详细情况请参考远行科技SOA宣传子网站

http://soa.vispractice.com:82/chanzhi/

原文链接:利用ESB和EDA结合解决服务高并发下性能(8.2),转载请注明来源!

0