基于事件驅動的礦井應急聯(lián)動Web平臺設計

王麗麗

摘? 要： 針對在Web請求處理線程總數(shù)有限的情況下，大量用戶訪問導致多業(yè)務應急聯(lián)動通信Web平臺服務器響應慢、阻塞、數(shù)據(jù)處理能力低等性能瓶頸問題，提出了基于事件驅動架構構建礦井多業(yè)務應急聯(lián)動通信Web平臺的方案，對比分析了同步模式與異步模式、SOA架構與事件驅動架構性能優(yōu)勢，介紹了應急聯(lián)動系統(tǒng)Web平臺異步架構設計。實際應用表明，采用異步架構實現(xiàn)的礦井多業(yè)務應急聯(lián)動系統(tǒng)Web平臺，跨平臺、松耦合便于接入和擴展，數(shù)據(jù)處理能力高，整體響應時間短，且?guī)砹薟eb平臺服務器吞吐能力的提升和性能效率的提高。

關鍵詞： 同步模式;異步模式;事件驅動架構;WEB平臺;吞吐量;應急聯(lián)動

【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? 引言

在我國煤炭行業(yè)當前的礦井信息化建設中，一個成熟的、信息化建設卓有成效的煤礦，一般至少有十幾個甚至幾十個系統(tǒng)，這些系統(tǒng)相互獨立，無法從企業(yè)的角度實現(xiàn)信息共享和統(tǒng)一指揮調度。近年來，雖然各大廠商通過數(shù)據(jù)整合、系統(tǒng)整合，實現(xiàn)了系統(tǒng)的集成，但似乎問題仍沒有解決[1-3]，多套系統(tǒng)被機械地捆綁在一起，大部分只是做到了信息集中，沒做到真正意義上的信息集成和信息融合，效率不高，不確定性多。因此，調度指揮人員需要一個真正綜合的系統(tǒng)，提高信息上傳下達效率，提高調度指揮的時效性，并減輕用戶負擔。礦井多業(yè)務應急聯(lián)動通信系統(tǒng)滿足上述要求，能夠實現(xiàn)對生產(chǎn)企業(yè)各類安全生產(chǎn)信息的有效集成，同時能將各監(jiān)控子系統(tǒng)數(shù)據(jù)進行有機整合，進而實現(xiàn)各接入系統(tǒng)相關聯(lián)業(yè)務之間的聯(lián)動，達到真正意義上的信息融合。

然而，當達到十幾或幾十個一定數(shù)量的各專業(yè)子系統(tǒng)接入礦井多業(yè)務應急聯(lián)動通信系統(tǒng)平臺，系統(tǒng)數(shù)據(jù)量大，接入服務和數(shù)據(jù)處理負載極高，在爭分奪秒的應急聯(lián)動等關鍵時刻，對系統(tǒng)平臺提出了更高的數(shù)據(jù)處理能力和響應速度等性能要求。

一方面為了滿足系統(tǒng)跨平臺性，各子系統(tǒng)業(yè)務松耦合便于接入和擴展等特性，另一方面以提高系統(tǒng)的數(shù)據(jù)處理能力和大量用戶訪問時的響應速度等，本文對比分析同步與異步方式、SOA與事件驅動架構性能優(yōu)勢，在實際應用需求的基礎上，提出了基于異步事件驅動架構實現(xiàn)礦井多業(yè)務應急聯(lián)動通信系統(tǒng)WEB平臺，解決了礦井多業(yè)務應急聯(lián)動系統(tǒng)跨平臺數(shù)據(jù)處理能力、用戶并發(fā)數(shù)和響應速度等性能瓶頸問題，并獲得服務器吞吐能力的提升和性能效率的提高。

1? 同步和異步模式

1.1? 同步模式

普通同步的WEB請求訪問是請求響應模型（即調用方法并等待返回結果），瀏覽器Http請求達到Web服務器，服務器創(chuàng)建一個線程處理，等待處理結束后將結果返回給瀏覽器，如圖1所示：

當處理的過程中需要調用后臺業(yè)務時，請求處理線程會在調用后端處理業(yè)務Call之后等待返回Return，請求處理線程自身處于阻塞狀態(tài)，WEB服務器無法處理其他的任務，如圖2所示，此時頁面的交互等任何操作都會被阻塞，這顯然是不可接受的。

一旦礦井多業(yè)務應急聯(lián)動平臺接入十幾個子系統(tǒng)，后臺處理業(yè)務量大，“長時間處理的服務”調用隨即增多，請求訪問數(shù)量達到一定量級時，在請求處理線程短缺時，同步模式會造成所有的處理線程處于阻塞的狀態(tài)，WEB整體的響應時間延長，新進的請求也就無法處理，極大地影響了系統(tǒng)的并發(fā)數(shù)、服務器的吞吐能力和性能。

最大線程數(shù)決定Web服務可以同時處理的請求數(shù)，每個HTTP請求到達Web服務時，服務器會創(chuàng)建一個線程來處理該請求，Java虛擬機在默認情況下創(chuàng)建新線程時會分配大小為1M的線程棧，增加線程是有成本的，更多的線程會帶來更多的內存消耗和線程上下文切換成本[4-6]。因為請求處理線程總數(shù)量受最大線程數(shù)限制并且有限，所以會給多業(yè)務類系統(tǒng)造成不容忽視的功能和性能缺陷，因此服務器性能的關鍵，是使用異步模式。

1.2? 異步模式

異步不同于同步的請求響應模式，而是一種事件驅動模式。在異步模式下，web服務在等待當前任務返回響應之前，可以繼續(xù)執(zhí)行后續(xù)達到的其他請求或操作，當前執(zhí)行不會阻塞后續(xù)任務，Web異步處理模式，如圖3所示：

請求處理線程對后臺處理業(yè)務調用后直接返回，不等待處理結果，請求處理線程可以繼續(xù)執(zhí)行其他請求，當后臺處理服務器處理完成后鉤起一個回調處理線程來處理調用的結果，回調處理線程跟請求處理線程相互間可以完全無關，由這個回調處理線程向瀏覽器返回結果，異步處理過程，帶來的效率是明顯的。

Request請求對中央處理器線程的損耗直接影響著系統(tǒng)外部接口、IO等吞度能力，單個請求CPU損耗越高，外部系統(tǒng)接口、IO響應速度越慢，系統(tǒng)吞吐能力越低，反之越高[7-8]。當請求處理線程不再阻塞，CPU線程消耗小，WEB服務器處理能力得到了更充分的使用，不但提高了數(shù)據(jù)處理能力，自然也帶來了服務器吞吐能力和性能的提升。礦井多業(yè)務應急聯(lián)動通信系統(tǒng)在面對突發(fā)事件需應急聯(lián)動等緊急情況時，多業(yè)務聯(lián)動平臺服務器的關鍵性能也是系統(tǒng)實時性和安全有效的保障，異步訪問以及平臺的異步架構顯得尤為關鍵和必要。

2? 事件驅動架構

事件驅動架構（Event-Driven Architecture，EDA）是以事件為核心的異步通信的架構模式，主要以生產(chǎn)者和消費者為基礎的，用于創(chuàng)建可伸縮的應用程序。這種模式是自適應的，事件所觸發(fā)的消息可以在松散耦合的組件和服務之間傳遞，相應地改進了響應表面上毫無關聯(lián)和不同的事件的能力，從而快速、恰當?shù)仨憫吞幚磉@些事件，使系統(tǒng)響應更靈敏高效[9-10]，能更好地滿足如跨平臺跨系統(tǒng)的應急聯(lián)動協(xié)同服務等應用。

EDA提供事件產(chǎn)生，路由，消費以及結果回調，是以事件為核心機制的架構模式[11]。在發(fā)布與訂閱模式下，消息發(fā)布者和訂閱者以及消息通道和主題之間交互，如圖4所示，調用者和被調用者只和中間消息隊列耦合，達到服務或組件之間的最大松耦合[12-13]。SOA（service-oriented architecture）面向服務架構中也使用消息系統(tǒng)作為企業(yè)服務總線（Enter prise Service Bus，ESB），然而并非包含有消息系統(tǒng)的架構均可稱為事件驅動架構，請求驅動加消息系統(tǒng)和事件驅動加消息系統(tǒng)存在著本質區(qū)別，前者是一種請求響應模型，而后者重點是在消息消費者，業(yè)務邏輯站在消費者角度完成[14-15]。EDA通過引入異步處理功能來填補SOA架構的不足，兩者的集成稱為事件驅動的面向服務架構（Event- Driven SOA）[16]。依賴并獲益于Event-Driven SOA架構的優(yōu)點構建多業(yè)務類系統(tǒng)，系統(tǒng)的不同服務均由事件驅動，并能夠自動地進行觸發(fā)，達到更高自動化要求。

Event-Driven SOA架構的系統(tǒng)彈性好，適合業(yè)務量持續(xù)增加的多業(yè)務類系統(tǒng)，便于增加事件消費者和生產(chǎn)者，因此利于提高系統(tǒng)吞吐量。Event-Driven SOA架構具有對環(huán)境變化的快速響應能力，整體靈活性高，由于事件組件之間的高度獨立和相互解耦，易于部署，可擴展性高;由于其異步的特性，性能通常比較高，執(zhí)行解耦的、并行的異步操作的能力超過消息隊列出入的成本;礦井多業(yè)務類系統(tǒng)業(yè)務越來越復雜和龐大，接入的系統(tǒng)或第三方系統(tǒng)比較多，要求系統(tǒng)有很強的整合能力及對異構環(huán)境的適應能力，同時也要求系統(tǒng)有很好的可擴展性。因此，Event-Driven SOA 架構可以很好地滿足礦井多業(yè)務系統(tǒng)Web平臺的實際需求。

3? Web平臺架構設計

本文僅針對礦井地面多系統(tǒng)數(shù)據(jù)融合的多業(yè)務應急聯(lián)動通信WEB平臺架構進行研究。根據(jù)礦井多業(yè)務應急聯(lián)動通信系統(tǒng)Web平臺的業(yè)務需求和Event-Driven SOA架構的特點，以Event-Driven SOA為基礎將系統(tǒng)平臺架構分化為細粒度并且重用性高的單個服務和結構層，提高系統(tǒng)的效率和彈性。

3.1? 分層架構

根據(jù)業(yè)務特點，將Web平臺架構的應用層，業(yè)務層，組件層細分為如圖5所示的分層架構。

事件驅動架構的重點在于引擎層，引擎層的核心作用在于將復雜、易變的規(guī)則和業(yè)務決策從業(yè)務流程的邏輯中分離出來，由靈活可變的規(guī)則來描述業(yè)務需求。規(guī)則引擎的關鍵是推理引擎推理過程，匹配規(guī)則庫rules和事實庫facts，將事實、數(shù)據(jù)與產(chǎn)

接受各接入系統(tǒng)的數(shù)據(jù)輸入，依賴規(guī)則庫解釋數(shù)據(jù)和事件之間的業(yè)務規(guī)則，通過分析事件之間的聯(lián)系，利用關聯(lián)、過濾和聚合等技術，得到復雜的復合事件，并根據(jù)復合事件業(yè)務規(guī)則做出業(yè)務決策，實現(xiàn)并完成應急聯(lián)動平臺預案觸發(fā)的決策過程。

規(guī)則庫和事實庫是處于數(shù)據(jù)層的元數(shù)據(jù)、實例數(shù)據(jù)和基礎配置，為引擎層提供規(guī)則推理分析過程的基礎數(shù)據(jù)支撐。

3.2? 消息中間件設計

在JMS體系中，使用消息實現(xiàn)事件驅動架構最簡單和直觀。作為消息運轉的根本，消息中間件（Message-Oriented Middleware，MOM）必須安全、可靠和效率高。本文采用WebSphere MQ Low Latency Messaging（簡稱MQ LLM）消息中間件，來滿足應急聯(lián)動系統(tǒng)的高吞吐量、低延遲的業(yè)務需求。

MQ LLM具有低傳輸延時特性，具備可靠的數(shù)據(jù)交付和流故障轉移能力，以及消息過濾和控制流量速率擁塞等功能，能夠滿足大量數(shù)據(jù)急迫業(yè)務要求的速度傳輸。在MQ LLM中，有RMM（Reliable Multicast Messaging）和RUM（Reliable Unicast Messaging）兩種消息傳輸方式，均需要確定發(fā)送方、接收方，通訊的邏輯通道、物理通道、消息等5個元素[17-18]：

（1）RMM：基于UDP協(xié)議，支持可靠的單播和多播傳輸;

（2）RUM：基于TCP協(xié)議，提供一對一的單播傳輸。

基于Event-Driven SOA的聯(lián)動系統(tǒng)它不是發(fā)送一個消息給安全監(jiān)控系統(tǒng)，拉取它當前的狀態(tài)，而是向事件總線訂閱，當安全監(jiān)控有狀態(tài)報告時，將發(fā)出事件通知聯(lián)動系統(tǒng)。WEB平臺架構中消息中間件與基礎組件的交互，如圖7所示：

在Web平臺中，各接入子系統(tǒng)，如人員定位系統(tǒng)、安全監(jiān)測系統(tǒng)等與消息中間件的消息傳輸采用RMM消息傳輸方式，在發(fā)送方部署Transmitter，在每個接收方部署Receiver，傳輸過程如圖8所示：

音視頻聯(lián)動與消息中間件之間采用RMM消息傳輸方式，RUM基于TCP 需要事先建立握手連接，使用RUM的API實現(xiàn)消息傳輸，如圖9所示：

WEB平臺各子系統(tǒng)之間存在著大量的信息交互，如圖10所示。一個聯(lián)動組報警信息輸入到系統(tǒng)平臺后，經(jīng)由前臺系統(tǒng)，中間服務以及后臺系統(tǒng)，除了系統(tǒng)層面的跨度外，所有的交互和服務組件都需要具備自觸發(fā)能力，主張盡可能少的人工干預。每個子系統(tǒng)內部包括很多服務組件，依據(jù)事件是否可以獨立運行，相應地規(guī)劃事件處理器的粗細粒度，事件處理組件之間的契約的創(chuàng)建、維護和管理。事件均有一個對應的契約，也即傳遞給事件處理器的數(shù)據(jù)值和數(shù)據(jù)格式，本文通過選定XML、JSON等格式建立消息傳遞的契約策略。

3.3? 事件發(fā)布

在Event-Driven SOA中，跨服務完成業(yè)務邏輯的關鍵點是以原子粒度更新數(shù)據(jù)庫和發(fā)布事件，即服務或業(yè)務組件自動更新數(shù)據(jù)庫和發(fā)布事件[19]，系統(tǒng)數(shù)據(jù)的不一致會導致自觸發(fā)機制失效。保證數(shù)據(jù)更新和事件發(fā)布原子化的方法有以下三種：使用本地事務發(fā)布事件、挖掘數(shù)據(jù)庫事務日志和使用事件源[20]。

本文采用使用本地事務發(fā)布事件，其優(yōu)點是數(shù)據(jù)庫均具備本地事務的能力，數(shù)據(jù)被更新時保證事件定能被發(fā)布且實現(xiàn)簡單。

使用本地事務來更新業(yè)務實體和事件列表，流程如圖11所示。

利用數(shù)據(jù)庫本地事務原子化地完成事件發(fā)布，在聯(lián)動系統(tǒng)中，告警信息服務更新區(qū)域ID和告警類型，然后在事件表中插入“啟動告警預案”的待發(fā)布事件。事件發(fā)布線程在事件表中查詢狀態(tài)為未發(fā)布的NEW事件并發(fā)布給消息代理，然后再更新事件表，將該事件標記為已發(fā)布狀態(tài)，如圖12所示。

消息代理通過查詢消息訂閱者列表，并將消息通過JSON格式發(fā)送給所有訂閱者，并執(zhí)行相應的處理。音視頻聯(lián)動后臺從消息代理處獲得已訂閱的“啟動告警預案”事件的消息，觸發(fā)聯(lián)動動作，執(zhí)行某區(qū)域告警預先定義好的聯(lián)動預案，如向該區(qū)域內廣播終端發(fā)送“請速撤離告警區(qū)域”等語音或向區(qū)域內所有攜帶定位卡的人員發(fā)送呼叫信號，以實現(xiàn)告警信息發(fā)布和應急聯(lián)動機制。

3.4? 異步請求訪問

事件驅動架構各邏輯層清晰的角色劃分，分工明確，松耦合等特點使得業(yè)務擴展點相當靈活，很容易實現(xiàn)各子系統(tǒng)業(yè)務的接入和擴展，滿足了礦井多業(yè)務應急聯(lián)動通信系統(tǒng)跨平臺、靈活接入、易于部署和高性能等要求。平臺Web的高用戶并發(fā)數(shù)、低延遲響應等性能要求則通過異步請求實現(xiàn)。本文采用SpringMVC的WebAsyncTask和DeferredResult異步請求接口實現(xiàn)異步請求訪問，并以DeferredResult為例，詳細講解DeferedResult異步處理實現(xiàn)機制，如圖13所示。

DeferedResult處理機制：

客戶端請求服務;

SpringMVC調用控制層Controller，Controller返回一個DeferedResult<>泛型對象;

SpringMVC調用request.startAsync;

DispatcherServlet以及Filters等從容器主線程中結束，暫時還不返回給客戶端，但Response仍然是Open狀態(tài)。此時，容器主線程可以繼續(xù)處理其他的請求，并因此獲得處理能力的提高;

調用業(yè)務組件，在處理異步線程業(yè)務之后，執(zhí)行setResult方法，將實際響應數(shù)據(jù)分配給DeferedResult對象（實際數(shù)據(jù)是對象的成員變量結果，可以是字符串類型、ModelAndView類型等），異步線程會喚醒容器主線程，SpringMVC將請求發(fā)送給主容器線程繼續(xù)處理;

DispatcherServlet再次被調用并且容器主線程會繼續(xù)執(zhí)行getResult方法，獲得Deferred- Result中的結果，最終將其返回給客戶端。

4? 性能試驗

通過JMeter性能壓力測試工具，對基于異步事件驅動架構設計實現(xiàn)的礦井多業(yè)務應急聯(lián)動通信系統(tǒng)Web平臺的吞吐量（TPS）、用戶并發(fā)量和性能進行對比測試和驗證，根據(jù)最終Jmeter結果分析（圖14所示）得出結論，同樣量級用戶請求訪問下異步架構Web平臺服務器的吞吐能力和性能效率有顯著的提高。

經(jīng)工業(yè)性試驗表明，基于該架構的礦井多業(yè)務應急聯(lián)動通信Web平臺各子系統(tǒng)業(yè)務的接入和擴展靈活，松耦合、易于部署，符合煤礦井下安全六大系統(tǒng)“系統(tǒng)可靠、設施完善、管理到位、運轉有效”的要求。

5? 結語

采用了異步事件驅動架構設計實現(xiàn)的礦井多業(yè)務應急聯(lián)動通信WEB平臺架構，并在煤礦部署應用，一方面滿足了各子系統(tǒng)業(yè)務松耦合便于接入、擴展、跨平臺、低延遲等特性，另一方面提高了系統(tǒng)數(shù)據(jù)處理能力、用戶并發(fā)數(shù)、量級用戶訪問響應速度，解決了礦井多業(yè)務應急聯(lián)動通信系統(tǒng)Web平臺服務器性能瓶頸問題，獲得Web服務器吞吐能力的提升和性能效率的提高。經(jīng)實際應用表明，能夠滿足礦井多系統(tǒng)融合及聯(lián)動系統(tǒng)平臺系統(tǒng)架構建設要求。

參考文獻

王金華， 汪有剛， 傅俊皓. 數(shù)字礦山關鍵技術研究與示范[J]. 煤炭學報， 2016， 41（6）： 1323-1331.

陳孝國， 母麗華， 杜紅， 等. 煤礦突發(fā)事件應急救援的群決策方法[J]. 災害學， 2015， （1）： 167-170， 180.

閆兆振. 煤礦安全監(jiān)控多系統(tǒng)融合平臺[J]. 工礦自動化， 2017， 43（2）： 11-14.

盛武， 高明中， 楊力， 等. 煤礦緊急避險體系構建與應急救援模型研究[J]. 中國安全科學學報， 2011， 21（4）： 171-176.

鐵威， 黃志球， 王進. 基于BPEL的RESTful Web服務異步交互及組合研究[J]. 計算機工程與科學， 2013， （4）： 29-36.

李玲勇， 高春鳴， 文華南. Web服務組合執(zhí)行引擎中服務異步調用機制研究[J]. 計算機應用研究， 2010， 27（2）： 558-562.

章蓬陽， 邵帥. Android 異步框架的研究與設計[J]. 軟件， 2016， 37（02）： 150-154

宋健健， 戴鴻君， 于治樓. 一種采用異步事件驅動實現(xiàn)WEB服務器負載均衡的方法[P].中國： CN201611189166.8， 2017-05-10.

曹文彬， 譚新明， 劉備， 等. 基于事件驅動的高性能WebSocket服務器的設計與實現(xiàn)[J]. 計算機應用與軟件， 2018， 35（1）： 21-27， 91.

姚錫凡， 金鴻， 李彬. 事件驅動的面向云制造服務架構及其開源實現(xiàn)[J]. 計算機集成制造系統(tǒng)， 2013， 19（3）： 654-661.

沈杜娟， 李愛華， 蘇延召. 基于事件驅動的國防工程監(jiān)測報警系統(tǒng)設計[J]. 現(xiàn)代電子技術， 2018， 41（19）： 113-116， 120.

別曉峰， 李為民， 張雅艦， 等. 事件驅動的面向服務作戰(zhàn)仿真集成平臺架構[J]. 空軍工程大學學報（自然科學版）， 2013， 14（2）： 37-41.

梁宏濤， 房正華， 楊新艷， 等. 面向本科教學評估的高校數(shù)據(jù)SOA服務模型研究[J]. 軟件， 2016， 37（4）： 22-24.

馬存， 馬躍， 廉東本， 等. 基于SEDA企業(yè)服務總線負載控制[J].計算機系統(tǒng)應用， 2013， （12）：66-69.

何浪， 史維峰， 董建剛. 基于事件驅動的面向服務計算模型[J].計算機工程， 2010， 36（18）： 57-59， 66.

楊曉偉， 文福安. 基于事件驅動的虛擬實驗反饋回路仿真方法[J]. 軟件， 2015， 36（2）： 127-132.

韓彪， 吳眾欣， 欒鐘治， 等.一種適于主-從模式網(wǎng)絡計算的事件驅動架構[J]. 西安交通大學學報， 2010， 44（2）： 39-43.

王貝貝. WebSphere MQ Low Latency Messaging 產(chǎn)品介紹及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的異步全雙工消息總線的實現(xiàn)[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

張鋒. 微服務架構實戰(zhàn)[M]. 北京： 電子工業(yè)出版社， 2018.