王麗麗

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

關(guān)鍵詞： 同步模式;異步模式;事件驅(qū)動架構(gòu);WEB平臺;吞吐量;應(yīng)急聯(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è)當(dāng)前的礦井信息化建設(shè)中，一個成熟的、信息化建設(shè)卓有成效的煤礦，一般至少有十幾個甚至幾十個系統(tǒng)，這些系統(tǒng)相互獨立，無法從企業(yè)的角度實現(xiàn)信息共享和統(tǒng)一指揮調(diào)度。近年來，雖然各大廠商通過數(shù)據(jù)整合、系統(tǒng)整合，實現(xiàn)了系統(tǒng)的集成，但似乎問題仍沒有解決[1-3]，多套系統(tǒng)被機(jī)械地捆綁在一起，大部分只是做到了信息集中，沒做到真正意義上的信息集成和信息融合，效率不高，不確定性多。因此，調(diào)度指揮人員需要一個真正綜合的系統(tǒng)，提高信息上傳下達(dá)效率，提高調(diào)度指揮的時效性，并減輕用戶負(fù)擔(dān)。礦井多業(yè)務(wù)應(yīng)急聯(lián)動通信系統(tǒng)滿足上述要求，能夠?qū)崿F(xiàn)對生產(chǎn)企業(yè)各類安全生產(chǎn)信息的有效集成，同時能將各監(jiān)控子系統(tǒng)數(shù)據(jù)進(jìn)行有機(jī)整合，進(jìn)而實現(xiàn)各接入系統(tǒng)相關(guān)聯(lián)業(yè)務(wù)之間的聯(lián)動，達(dá)到真正意義上的信息融合。

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

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

1? 同步和異步模式

1.1? 同步模式

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

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

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

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

1.2? 異步模式

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

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

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

2? 事件驅(qū)動架構(gòu)

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

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

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

3? Web平臺架構(gòu)設(shè)計

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

3.1? 分層架構(gòu)

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

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

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

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

3.2? 消息中間件設(shè)計

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

MQ LLM具有低傳輸延時特性，具備可靠的數(shù)據(jù)交付和流故障轉(zhuǎn)移能力，以及消息過濾和控制流量速率擁塞等功能，能夠滿足大量數(shù)據(jù)急迫業(yè)務(wù)要求的速度傳輸。在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)，拉取它當(dāng)前的狀態(tài)，而是向事件總線訂閱，當(dāng)安全監(jiān)控有狀態(tài)報告時，將發(fā)出事件通知聯(lián)動系統(tǒng)。WEB平臺架構(gòu)中消息中間件與基礎(chǔ)組件的交互，如圖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)，中間服務(wù)以及后臺系統(tǒng)，除了系統(tǒng)層面的跨度外，所有的交互和服務(wù)組件都需要具備自觸發(fā)能力，主張盡可能少的人工干預(yù)。每個子系統(tǒng)內(nèi)部包括很多服務(wù)組件，依據(jù)事件是否可以獨立運行，相應(yīng)地規(guī)劃事件處理器的粗細(xì)粒度，事件處理組件之間的契約的創(chuàng)建、維護(hù)和管理。事件均有一個對應(yīng)的契約，也即傳遞給事件處理器的數(shù)據(jù)值和數(shù)據(jù)格式，本文通過選定XML、JSON等格式建立消息傳遞的契約策略。

3.3? 事件發(fā)布

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

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

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

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

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

3.4? 異步請求訪問

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

DeferedResult處理機(jī)制：

客戶端請求服務(wù);

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

SpringMVC調(diào)用request.startAsync;

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

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

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

4? 性能試驗

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

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

5? 結(jié)語

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

參考文獻(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

韓彪， 吳眾欣， 欒鐘治， 等.一種適于主-從模式網(wǎng)絡(luò)計算的事件驅(qū)動架構(gòu)[J]. 西安交通大學(xué)學(xué)報， 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

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