基于事件驱动的矿井应急联动Web平台设计

王丽丽

摘  要： 针对在Web请求处理线程总数有限的情况下，大量用户访问导致多业务应急联动通信Web平台服务器响应慢、阻塞、数据处理能力低等性能瓶颈问题，提出了基于事件驱动架构构建矿井多业务应急联动通信Web平台的方案，对比分析了同步模式与异步模式、SOA架构与事件驱动架构性能优势，介绍了应急联动系统Web平台异步架构设计。实际应用表明，采用异步架构实现的矿井多业务应急联动系统Web平台，跨平台、松耦合便于接入和扩展，数据处理能力高，整体响应时间短，且带来了Web平台服务器吞吐能力的提升和性能效率的提高。

关键词： 同步模式;异步模式;事件驱动架构;WEB平台;吞吐量;应急联动

【Abstract】： In order to solve the problem that a large number of user accesses cause performance bottlenecks such as slow response， blocking， and low data processing capability of the multi-service linkage platform Web server when the number of user requests processing threads is limited， the scheme for constructing a mine multi-service emergency linkage communication system web platform based on asynchronous method is proposed. This paper compares and analyzes the performance advantages of synchronous and asynchronous methods， and introduces the design and implementation of the Web platform architecture of emergency linkage system. The practical application shows that the mine multi-service emergency linkage system Web platform realized by asynchronous method is easy to access and expand across platforms and loosely coupled， with high data processing capability， short overall response time， and improved web server throughput and performance efficiency.

【Key words】： Synchronous mode; Asynchronous mode; Event driven architecture; Web platform; Throughput; Emergency linkage

0  引言

在我国煤炭行业当前的矿井信息化建设中，一个成熟的、信息化建设卓有成效的煤矿，一般至少有十几个甚至几十个系统，这些系统相互独立，无法从企业的角度实现信息共享和统一指挥调度。近年来，虽然各大厂商通过数据整合、系统整合，实现了系统的集成，但似乎问题仍没有解决[1-3]，多套系统被机械地捆绑在一起，大部分只是做到了信息集中，没做到真正意义上的信息集成和信息融合，效率不高，不確定性多。因此，调度指挥人员需要一个真正综合的系统，提高信息上传下达效率，提高调度指挥的时效性，并减轻用户负担。矿井多业务应急联动通信系统满足上述要求，能够实现对生产企业各类安全生产信息的有效集成，同时能将各监控子系统数据进行有机整合，进而实现各接入系统相关联业务之间的联动，达到真正意义上的信息融合。

然而，当达到十几或几十个一定数量的各专业子系统接入矿井多业务应急联动通信系统平台，系统数据量大，接入服务和数据处理负载极高，在争分夺秒的应急联动等关键时刻，对系统平台提出了更高的数据处理能力和响应速度等性能要求。

一方面为了满足系统跨平台性，各子系统业务松耦合便于接入和扩展等特性，另一方面以提高系统的数据处理能力和大量用户访问时的响应速度等，本文对比分析同步与异步方式、SOA与事件驱动架构性能优势，在实际应用需求的基础上，提出了基于异步事件驱动架构实现矿井多业务应急联动通信系统WEB平台，解决了矿井多业务应急联动系统跨平台数据处理能力、用户并发数和响应速度等性能瓶颈问题，并获得服务器吞吐能力的提升和性能效率的提高。

1  同步和异步模式

1.1  同步模式

普通同步的WEB请求访问是请求响应模型（即调用方法并等待返回结果），浏览器Http请求达到Web服务器，服务器创建一个线程处理，等待处理结束后将结果返回给浏览器，如图1所示：

当处理的过程中需要调用后台业务时，请求处理线程会在调用后端处理业务Call之后等待返回Return，请求处理线程自身处于阻塞状态，WEB服务器无法处理其他的任务，如图2所示，此时页面的交互等任何操作都会被阻塞，这显然是不可接受的。

一旦矿井多业务应急联动平台接入十几个子系统，后台处理业务量大，“长时间处理的服务”调用随即增多，请求访问数量达到一定量级时，在请求处理线程短缺时，同步模式会造成所有的处理线程处于阻塞的状态，WEB整体的响应时间延长，新进的请求也就无法处理，极大地影响了系统的并发数、服务器的吞吐能力和性能。

最大线程数决定Web服务可以同时处理的请求数，每个HTTP请求到达Web服务时，服务器会创建一个线程来处理该请求，Java虚拟机在默认情况下创建新线程时会分配大小为1M的线程栈，增加线程是有成本的，更多的线程会带来更多的内存消耗和线程上下文切换成本[4-6]。因为请求处理线程总数量受最大线程数限制并且有限，所以会给多业务类系统造成不容忽视的功能和性能缺陷，因此服务器性能的关键，是使用异步模式。

1.2  异步模式

异步不同于同步的请求响应模式，而是一种事件驱动模式。在异步模式下，web服务在等待当前任务返回响应之前，可以继续执行后续达到的其他请求或操作，当前执行不会阻塞后续任务，Web异步处理模式，如图3所示：

请求处理线程对后台处理业务调用后直接返回，不等待处理结果，请求处理线程可以继续执行其他请求，当后台处理服务器处理完成后钩起一个回调处理线程来处理调用的结果，回调处理线程跟请求处理线程相互间可以完全无关，由这个回调处理线程向浏览器返回结果，异步处理过程，带来的效率是明显的。

Request请求对中央处理器线程的损耗直接影响着系统外部接口、IO等吞度能力，单个请求CPU损耗越高，外部系统接口、IO响应速度越慢，系统吞吐能力越低，反之越高[7-8]。当请求处理线程不再阻塞，CPU线程消耗小，WEB服务器处理能力得到了更充分的使用，不但提高了数据处理能力，自然也带来了服务器吞吐能力和性能的提升。矿井多业务应急联动通信系统在面对突发事件需应急联动等紧急情况时，多业务联动平台服务器的关键性能也是系统实时性和安全有效的保障，异步访问以及平台的异步架构显得尤为关键和必要。

2  事件驱动架构

事件驱动架构（Event-Driven Architecture，EDA）是以事件为核心的异步通信的架构模式，主要以生产者和消费者为基础的，用于创建可伸缩的应用程序。这种模式是自适应的，事件所触发的消息可以在松散耦合的组件和服务之间传递，相应地改进了响应表面上毫无关联和不同的事件的能力，从而快速、恰当地响应和处理这些事件，使系统响应更灵敏高效[9-10]，能更好地满足如跨平台跨系统的应急联动协同服务等应用。

EDA提供事件产生，路由，消费以及结果回调，是以事件为核心机制的架构模式[11]。在发布与订阅模式下，消息发布者和订阅者以及消息通道和主题之间交互，如图4所示，调用者和被调用者只和中间消息队列耦合，达到服务或组件之间的最大松耦合[12-13]。SOA（service-oriented architecture）面向服务架构中也使用消息系统作为企业服务总线（Enter prise Service Bus，ESB），然而并非包含有消息系统的架构均可称为事件驱动架构，请求驱动加消息系统和事件驱动加消息系统存在着本质区别，前者是一种请求响应模型，而后者重点是在消息消费者，业务逻辑站在消费者角度完成[14-15]。EDA通过引入异步处理功能来填补SOA架构的不足，两者的集成称为事件驱动的面向服务架构（Event- Driven SOA）[16]。依赖并获益于Event-Driven SOA架构的优点构建多业务类系统，系统的不同服务均由事件驱动，并能够自动地进行触发，达到更高自动化要求。

Event-Driven SOA架构的系统弹性好，适合业务量持续增加的多业务类系统，便于增加事件消费者和生产者，因此利于提高系统吞吐量。Event-Driven SOA架构具有对环境变化的快速响应能力，整体灵活性高，由于事件组件之间的高度独立和相互解耦，易于部署，可扩展性高;由于其异步的特性，性能通常比较高，执行解耦的、并行的异步操作的能力超过消息队列出入的成本;矿井多业务类系统业务越来越复杂和庞大，接入的系统或第三方系统比较多，要求系统有很强的整合能力及对异构环境的适应能力，同时也要求系统有很好的可扩展性。因此，Event-Driven SOA 架构可以很好地满足矿井多业务系统Web平台的实际需求。

3  Web平台架构设计

本文仅针对矿井地面多系统数据融合的多业务应急联动通信WEB平台架构进行研究。根据矿井多业务应急联动通信系统Web平台的业务需求和Event-Driven SOA架构的特点，以Event-Driven SOA为基础将系统平台架构分化为细粒度并且重用性高的单个服务和结构层，提高系统的效率和弹性。

3.1  分层架构

根据业务特点，将Web平台架构的应用层，业务层，组件层细分为如图5所示的分层架构。

事件驱动架构的重点在于引擎层，引擎层的核心作用在于将复杂、易变的规则和业务决策从业务流程的逻辑中分离出来，由灵活可变的规则来描述业务需求。规则引擎的关键是推理引擎推理过程，匹配规则库rules和事实库facts，将事实、数据与产

接受各接入系统的数据输入，依赖规则库解释数据和事件之间的业务规则，通过分析事件之间的联系，利用关联、过滤和聚合等技术，得到复杂的复合事件，并根据复合事件业务规则做出业务决策，实现并完成应急联动平台预案触发的决策过程。

规则库和事实库是处于数据层的元数据、实例数据和基础配置，为引擎层提供规则推理分析过程的基础数据支撑。

3.2  消息中间件设计

在JMS体系中，使用消息实现事件驱动架构最简单和直观。作为消息运转的根本，消息中间件（Message-Oriented Middleware，MOM）必须安全、可靠和效率高。本文采用WebSphere MQ Low Latency Messaging（簡称MQ LLM）消息中间件，来满足应急联动系统的高吞吐量、低延迟的业务需求。

MQ LLM具有低传输延时特性，具备可靠的数据交付和流故障转移能力，以及消息过滤和控制流量速率拥塞等功能，能够满足大量数据急迫业务要求的速度传输。在MQ LLM中，有RMM（Reliable Multicast Messaging）和RUM（Reliable Unicast Messaging）两种消息传输方式，均需要确定发送方、接收方，通讯的逻辑通道、物理通道、消息等5个元素[17-18]：

（1）RMM：基于UDP协议，支持可靠的单播和多播传输;

（2）RUM：基于TCP协议，提供一对一的单播传输。

基于Event-Driven SOA的联动系统它不是发送一个消息给安全监控系统，拉取它当前的状态，而是向事件总线订阅，当安全监控有状态报告时，将发出事件通知联动系统。WEB平台架构中消息中间件与基础组件的交互，如图7所示：

在Web平台中，各接入子系统，如人员定位系统、安全监测系统等与消息中间件的消息传输采用RMM消息传输方式，在发送方部署Transmitter，在每个接收方部署Receiver，传输过程如图8所示：

音视频联动与消息中间件之间采用RMM消息传输方式，RUM基于TCP 需要事先建立握手连接，使用RUM的API实现消息传输，如图9所示：

WEB平台各子系统之间存在着大量的信息交互，如图10所示。一个联动组报警信息输入到系统平台后，经由前台系统，中间服务以及后台系统，除了系统层面的跨度外，所有的交互和服务组件都需要具备自触发能力，主张尽可能少的人工干预。每个子系统内部包括很多服务组件，依据事件是否可以独立运行，相应地规划事件处理器的粗细粒度，事件处理组件之间的契约的创建、维护和管理。事件均有一个对应的契约，也即传递给事件处理器的数据值和数据格式，本文通过选定XML、JSON等格式建立消息传递的契约策略。

3.3  事件发布

在Event-Driven SOA中，跨服务完成业务逻辑的关键点是以原子粒度更新数据库和发布事件，即服务或业务组件自动更新数据库和发布事件[19]，系统数据的不一致会导致自触发机制失效。保证数据更新和事件发布原子化的方法有以下三种：使用本地事务发布事件、挖掘数据库事务日志和使用事件源[20]。

本文采用使用本地事务发布事件，其优点是数据库均具备本地事务的能力，数据被更新时保证事件定能被发布且实现简单。

使用本地事务来更新业务实体和事件列表，流程如图11所示。

利用数据库本地事务原子化地完成事件发布，在联动系统中，告警信息服务更新区域ID和告警类型，然后在事件表中插入“启动告警预案”的待发布事件。事件发布线程在事件表中查询状态为未发布的NEW事件并发布给消息代理，然后再更新事件表，将该事件标记为已发布状态，如图12所示。

消息代理通过查询消息订阅者列表，并将消息通过JSON格式发送给所有订阅者，并执行相应的处理。音视频联动后台从消息代理处获得已订阅的“启动告警预案”事件的消息，触发联动动作，执行某区域告警预先定义好的联动预案，如向该区域内广播终端发送“请速撤离告警区域”等语音或向区域内所有携带定位卡的人员发送呼叫信号，以实现告警信息发布和应急联动机制。

3.4  异步请求访问

事件驱动架构各逻辑层清晰的角色划分，分工明确，松耦合等特点使得业务扩展点相当灵活，很容易实现各子系统业务的接入和扩展，满足了矿井多业务应急联动通信系统跨平台、灵活接入、易于部署和高性能等要求。平台Web的高用户并发数、低延迟响应等性能要求则通过异步请求实现。本文采用SpringMVC的WebAsyncTask和DeferredResult异步请求接口实现异步请求访问，并以DeferredResult为例，详细讲解DeferedResult异步处理实现机制，如图13所示。

DeferedResult处理机制：

客户端请求服务;

SpringMVC调用控制层Controller，Controller返回一个DeferedResult<>泛型对象;

SpringMVC调用request.startAsync;

DispatcherServlet以及Filters等从容器主线程中结束，暂时还不返回给客户端，但Response仍然是Open状态。此时，容器主线程可以继续处理其他的请求，并因此获得处理能力的提高;

調用业务组件，在处理异步线程业务之后，执行setResult方法，将实际响应数据分配给DeferedResult对象（实际数据是对象的成员变量结果，可以是字符串类型、ModelAndView类型等），异步线程会唤醒容器主线程，SpringMVC将请求发送给主容器线程继续处理;

DispatcherServlet再次被调用并且容器主线程会继续执行getResult方法，获得Deferred- Result中的结果，最终将其返回给客户端。

4  性能试验

通过JMeter性能压力测试工具，对基于异步事件驱动架构设计实现的矿井多业务应急联动通信系统Web平台的吞吐量（TPS）、用户并发量和性能进行对比测试和验证，根据最终Jmeter结果分析（图14所示）得出结论，同样量级用户请求访问下异步架构Web平台服务器的吞吐能力和性能效率有显著的提高。

经工业性试验表明，基于该架构的矿井多业务应急联动通信Web平台各子系统业务的接入和扩展灵活，松耦合、易于部署，符合煤矿井下安全六大系统“系统可靠、设施完善、管理到位、运转有效”的要求。

5  结语

采用了异步事件驱动架构设计实现的矿井多业务应急联动通信WEB平台架构，并在煤矿部署应用，一方面满足了各子系统业务松耦合便于接入、扩展、跨平台、低延迟等特性，另一方面提高了系统数据处理能力、用户并发数、量级用户访问响应速度，解决了矿井多业务应急联动通信系统Web平台服务器性能瓶颈问题，获得Web服务器吞吐能力的提升和性能效率的提高。经实际应用表明，能够满足矿井多系统融合及联动系统平台系统架构建设要求。

参考文献

王金华， 汪有刚， 傅俊皓. 数字矿山关键技术研究与示范[J]. 煤炭学报， 2016， 41（6）： 1323-1331.

陈孝国， 母丽华， 杜红， 等. 煤矿突发事件应急救援的群决策方法[J]. 灾害学， 2015， （1）： 167-170， 180.

闫兆振. 煤矿安全监控多系统融合平台[J]. 工矿自动化， 2017， 43（2）： 11-14.

盛武， 高明中， 杨力， 等. 煤矿紧急避险体系构建与应急救援模型研究[J]. 中国安全科学学报， 2011， 21（4）： 171-176.

铁威， 黄志球， 王进. 基于BPEL的RESTful Web服务异步交互及组合研究[J]. 计算机工程与科学， 2013， （4）： 29-36.

李玲勇， 高春鸣， 文华南. Web服务组合执行引擎中服务异步调用机制研究[J]. 计算机应用研究， 2010， 27（2）： 558-562.

章蓬阳， 邵帅. Android 异步框架的研究与设计[J]. 软件， 2016， 37（02）： 150-154

宋健健， 戴鸿君， 于治楼. 一种采用异步事件驱动实现WEB服务器负载均衡的方法[P].中国： CN201611189166.8， 2017-05-10.

曹文彬， 谭新明， 刘备， 等. 基于事件驱动的高性能WebSocket服务器的设计与实现[J]. 计算机应用与软件， 2018， 35（1）： 21-27， 91.

姚锡凡， 金鸿， 李彬. 事件驱动的面向云制造服务架构及其开源实现[J]. 计算机集成制造系统， 2013， 19（3）： 654-661.

沈杜娟， 李爱华， 苏延召. 基于事件驱动的国防工程监测报警系统设计[J]. 现代电子技术， 2018， 41（19）： 113-116， 120.

别晓峰， 李为民， 张雅舰， 等. 事件驱动的面向服务作战仿真集成平台架构[J]. 空军工程大学学报（自然科学版）， 2013， 14（2）： 37-41.

梁宏涛， 房正华， 杨新艳， 等. 面向本科教学评估的高校数据SOA服务模型研究[J]. 软件， 2016， 37（4）： 22-24.

马存， 马跃， 廉东本， 等. 基于SEDA企业服务总线负载控制[J].计算机系统应用， 2013， （12）：66-69.

何浪， 史维峰， 董建刚. 基于事件驱动的面向服务计算模型[J].计算机工程， 2010， 36（18）： 57-59， 66.

杨晓伟， 文福安. 基于事件驱动的虚拟实验反馈回路仿真方法[J]. 软件， 2015， 36（2）： 127-132.

韩彪， 吴众欣， 栾钟治， 等.一种适于主-从模式网络计算的事件驱动架构[J]. 西安交通大学学报， 2010， 44（2）： 39-43.

王贝贝. WebSphere MQ Low Latency Messaging 产品介绍及API使用[EB/OL]. IBM 中国. （2010-07-08）[2018-11-1]. https：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1007_wangbb_mqllm/1007_wangbb_mqllm.html

魚朝伟， 詹舒波. 基于RabbitMQ的异步全双工消息总线的实现[J]. 软件， 2016， 37（02）： 139-146

Mark Richards. Software Architecture Patterns[EB/OL]. OReilly Media， Inc. （2017-6-22）[2018-11-1]. https：//www.oreilly.com/ programming/free/files/software-architecture-patterns.pdf

张锋. 微服务架构实战[M]. 北京： 电子工业出版社， 2018.