蔡 寅 張 明 趙 瑞 尹玉振 李 紅

1）中國地震局地球物理研究所，北京 100081

2）山東省地震局，濟(jì)南 250014

引言

現(xiàn)今，地震預(yù)報仍沒有實(shí)現(xiàn)重大突破，地震預(yù)警系統(tǒng)（Earthquake Early Warning System，EEWS）是世界上公認(rèn)的能夠有效減輕地震災(zāi)害的新技術(shù)手段之一（Xu等，2017；Festa等，2018）。地震預(yù)警信息發(fā)布系統(tǒng)需要在破壞性地震波到達(dá)前，以最小的延遲，通過最便捷的方式，告知用戶最精準(zhǔn)的地震信息，達(dá)到緊急避險和決策應(yīng)對的目的（Gasparini等，2014；Cauzzi等，2016）。作為服務(wù)于民生的“最后一公里”，預(yù)警信息的快速發(fā)布是整個地震預(yù)警系統(tǒng)在社會服務(wù)中的重要體現(xiàn)（蔡寅等，2016）。

自2004年開始，在全國范圍內(nèi)運(yùn)行的地震速報信息共享服務(wù)系統(tǒng)（Earthquake Instant Messenger，EQIM）實(shí)現(xiàn)了省級臺網(wǎng)與國家臺網(wǎng)之間地震速報信息的交換與共享，并以短信的方式快速發(fā)布（楊陳等，2009）。地震預(yù)警系統(tǒng)僅能提供數(shù)秒或數(shù)十秒的預(yù)警時間，若以短信方式發(fā)送預(yù)警信息，一方面短信的固有延遲性已經(jīng)不能滿足公眾對信息時效性的需求，另一方面所有短信用戶接收到的信息是完全一致的。然而，由于用戶所在區(qū)域場地的差異以及距離震中遠(yuǎn)近的不同，致使所受到地震的破壞程度也有所差異，地震預(yù)警系統(tǒng)對于不同位置的用戶所推送的預(yù)警信息也不盡相同。因此，需要考慮其它方式實(shí)現(xiàn)地震預(yù)警信息的快速發(fā)布。

近年來，隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，尤其是移動互聯(lián)網(wǎng)的普及，基于地理位置的信息服務(wù)（Location Based Services，LBS）逐漸成為1種新興的增值業(yè)務(wù)形式，為用戶提供與所在位置有關(guān)的服務(wù)（劉成，2013；Vanjire等，2014）。面向公眾的地震預(yù)警恰恰與用戶所在的位置信息有極大的關(guān)系，如果有效地結(jié)合LBS與GIS（Geographic Information System，地理信息系統(tǒng)）2種技術(shù)，融合地理信息數(shù)據(jù)與用戶位置信息，將能夠?yàn)橛脩籼峁┚W(wǎng)絡(luò)化與個性化的地震預(yù)警信息服務(wù)（趙慶展等，2015）。

本文針對移動互聯(lián)網(wǎng)用戶與桌面用戶，通過分析對比，選擇MQTT協(xié)議與JSON技術(shù)作為服務(wù)端與客戶端的數(shù)據(jù)交互方式，提出1種支持海量并發(fā)式的地震預(yù)警信息推送架構(gòu)，設(shè)計并實(shí)現(xiàn)了一體化地震預(yù)警信息發(fā)布系統(tǒng)。經(jīng)綜合測試，系統(tǒng)能夠?yàn)楦黝惢ヂ?lián)網(wǎng)用戶提供基于位置的地震預(yù)警信息服務(wù)，在破壞性地震波到達(dá)前，為公眾緊急避險爭取了最大限度的自救時間。

1 系統(tǒng)總體架構(gòu)

地震預(yù)警信息發(fā)布系統(tǒng)由服務(wù)端與客戶端2部分組成。服務(wù)端完成地震預(yù)警信息的實(shí)時推送，客戶端獲取預(yù)警信息后進(jìn)行前端展現(xiàn)報警?？蛻舳酥饕嫦蛞苿踊ヂ?lián)網(wǎng)用戶與桌面用戶設(shè)計開發(fā)，因而又細(xì)分為移動端與桌面端，分別選用Android與WebGIS平臺作為開發(fā)環(huán)境。從整體架構(gòu)角度分析，系統(tǒng)為C/S（Client/Server，客戶端/服務(wù)器架構(gòu)）與B/S（Browser/Server，瀏覽器/服務(wù)器架構(gòu)）的混合架構(gòu)。系統(tǒng)借鑒了經(jīng)典的三層架構(gòu)設(shè)計模式，增加了服務(wù)層，實(shí)現(xiàn)邏輯層多類用戶預(yù)警參數(shù)計算與數(shù)據(jù)層多種數(shù)據(jù)源間的服務(wù)封裝與數(shù)據(jù)交互，目的是將數(shù)據(jù)資源與分析展現(xiàn)的完全解耦，為今后接入不同的終端設(shè)備或平臺用戶提供可擴(kuò)展的服務(wù)接口（Mantas等，2015）。系統(tǒng)邏輯架構(gòu)如圖1所示。

圖1 地震預(yù)警信息發(fā)布系統(tǒng)邏輯架構(gòu) Fig.1 The logical architecture of earthquake early warning information rapid release system

數(shù)據(jù)層由內(nèi)部數(shù)據(jù)庫與外部數(shù)據(jù)源組成。其中，內(nèi)部數(shù)據(jù)庫以用戶信息數(shù)據(jù)庫為主體，通過多種定位方式（GPS、Wi-Fi、移動通信網(wǎng)絡(luò)）獲取用戶位置信息，將其與用戶的基礎(chǔ)數(shù)據(jù)、所在位置的場地響應(yīng)數(shù)據(jù)及地理信息數(shù)據(jù)（離線數(shù)據(jù)）進(jìn)行關(guān)聯(lián)，提供給上層進(jìn)行預(yù)警參數(shù)計算及信息展示；外部數(shù)據(jù)源主要由提供發(fā)震時刻、震中位置、極震區(qū)烈度等信息的震源參數(shù)數(shù)據(jù)庫和提供實(shí)時地理信息的在線式地圖數(shù)據(jù)組成。

服務(wù)層負(fù)責(zé)完成數(shù)據(jù)層與邏輯層之間的數(shù)據(jù)交互，通過封裝標(biāo)準(zhǔn)Web Service接口服務(wù)，自動適配各類數(shù)據(jù)源，實(shí)時獲取數(shù)據(jù)層資源，將震源參數(shù)及用戶信息以多線程的方式發(fā)送給邏輯層。對用戶的反饋數(shù)據(jù)或更新的定制信息，服務(wù)層將其保存至數(shù)據(jù)層的用戶信息數(shù)據(jù)庫，作為系統(tǒng)日志進(jìn)行管理。針對混合型邏輯架構(gòu)，融合2種交互技術(shù)，實(shí)現(xiàn)多類終端海量用戶的高并發(fā)信息服務(wù)。

邏輯層以預(yù)警信息消息傳遞模塊為核心，面向各類終端用戶的服務(wù)請求，支持海量用戶的并發(fā)接入操作，通過服務(wù)層將每一報的震源參數(shù)向下保存至數(shù)據(jù)層的用戶信息數(shù)據(jù)庫。同時，將震源參數(shù)以服務(wù)的方式提供給基于位置的預(yù)警參數(shù)計算模塊。計算模塊結(jié)合用戶所在的地理位置和場地響應(yīng)因子，快速估算每個在線用戶的地震預(yù)警信息，向展現(xiàn)層提供需要推送的預(yù)警信息。此外，邏輯層負(fù)責(zé)與服務(wù)層建立持久化連接，確保預(yù)警信息推送的高可用性。

展現(xiàn)層分別面向Android和Web平臺用戶，實(shí)現(xiàn)基于GIS和LBS的地震預(yù)警信息的可視化展現(xiàn)，在客戶端以地震波動態(tài)擴(kuò)散、聲音振動報警以及倒計時提醒等多種方式提示用戶緊急避險。雖然兩大平臺實(shí)現(xiàn)預(yù)警信息發(fā)布的技術(shù)不盡相同，但兩者在信息展現(xiàn)的方式和用戶體驗(yàn)的效果上仍保持一致。

2 數(shù)據(jù)交互方式

一般情況下，地震預(yù)警系統(tǒng)僅能為公眾提供幾十秒甚至幾秒的避險時間，每提前1s接收到地震預(yù)警信息，都將有效減少更多的人員傷亡與經(jīng)濟(jì)損失。這就意味著預(yù)警信息發(fā)布對系統(tǒng)響應(yīng)時間有較高的需求，需要考慮信息從服務(wù)端至客戶端傳輸?shù)母鱾€環(huán)節(jié)中降低時間延時，因此，選擇1種高效的數(shù)據(jù)交互機(jī)制至關(guān)重要。

2.1 與Android端數(shù)據(jù)交互

目前，基于Android移動平臺的主流信息推送方案有3種：C2DM（Cloud to Device Messaging，云端推送）、MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測傳輸協(xié)議）及XMPP（Extensible Messaging and Presence Protocol，可擴(kuò)展通訊和表示協(xié)議）。其中，C2MD是谷歌公司為應(yīng)用開發(fā)者提供的1項(xiàng)服務(wù)，實(shí)現(xiàn)從服務(wù)器向Android應(yīng)用程序發(fā)送數(shù)據(jù)，但信息發(fā)送過程需要綁定谷歌賬號，在國內(nèi)使用具有一定局限性；XMPP協(xié)議技術(shù)成熟，標(biāo)準(zhǔn)化程度高，功能強(qiáng)大，具有較強(qiáng)的可擴(kuò)展性，但其缺點(diǎn)是數(shù)據(jù)負(fù)載過重，導(dǎo)致終端流量及電量消耗過高（關(guān)慶余等，2014）；MQTT協(xié)議1種輕量級的基于代理的發(fā)布、訂閱消息傳輸協(xié)議，目前已成為物聯(lián)網(wǎng)傳輸標(biāo)準(zhǔn)協(xié)議之一，由于其低功耗、數(shù)據(jù)包較?。ü潭▓箢^僅為2字節(jié)）、分布式等特點(diǎn)，MQTT成為實(shí)現(xiàn)移動應(yīng)用的理想選擇，因此，也是地震預(yù)警信息推送的首選解決方案（許金喜等，2015）。

實(shí)現(xiàn)MQTT消息代理的開源項(xiàng)目較多，但在實(shí)際應(yīng)用中表現(xiàn)各異。本文從CUP占用率及數(shù)據(jù)傳輸延時的角度，對比測試了目前主流代理服務(wù)器在支持不同用戶數(shù)量方面的表現(xiàn)。參與測試的代理服務(wù)器包括Apollo 1.7、ActiveMQ 5.10.0、Mosquitto 1.3.5及RabbitMQ 3.4.2。在相同的硬件環(huán)境下（CPU：E8400 3.00GHz，內(nèi)存：4GB），各代理服務(wù)器CPU占用率及數(shù)據(jù)傳輸延時的結(jié)果如圖2、3所示，ActiveMQ因無法支持2000個以上的用戶同時并發(fā)信息，其測試結(jié)果在圖中并未標(biāo)出。

圖2 MQTT服務(wù)器CPU占用率測試結(jié)果 Fig.2 Test result for the CPU occupancy of MQTT servers

圖3 MQTT服務(wù)器響應(yīng)延時測試結(jié)果 Fig.3 Test result for response latency of MQTT servers

測試結(jié)果表明，Mosquitto在資源占用率、數(shù)據(jù)傳輸延時及并發(fā)用戶支持?jǐn)?shù)量等方面的表現(xiàn)均為最優(yōu)。RabbitMQ并發(fā)能力極大地依賴于CPU性能，當(dāng)每秒并發(fā)數(shù)超過8000時，CUP占用率超過70%，出現(xiàn)內(nèi)存溢出現(xiàn)象；當(dāng)Apollo每秒并發(fā)操作超過1萬個時，系統(tǒng)延時快速增長，超過2萬后，系統(tǒng)延時超過1s，不能滿足業(yè)務(wù)需求；盡管CPU占用率較高，但Mosquitto仍然能夠支持6萬個用戶的并發(fā)操作，數(shù)據(jù)延時也小于1s，但超過6萬用戶時，會出現(xiàn)內(nèi)存溢出，其可能的原因是Mosquitto自身單線程的處理方式，6萬用戶為處理上限，這也解釋了雙核CPU使用率始終處于50%水平的現(xiàn)象。

2.2 與Web端數(shù)據(jù)交互

盡管XML（Extensible Markup Language，擴(kuò)展標(biāo)記語言）早已成為業(yè)界公認(rèn)的Web數(shù)據(jù)交換的標(biāo)準(zhǔn)格式，但服務(wù)端和客戶端都需要占用大量資源，消耗大量時間來解析XML文件，導(dǎo)致整體效率較低。與XML不同，JSON（JavaScript Object Notation，JavaScript對象表示法）作為1種輕量級的數(shù)據(jù)交換格式，更加簡單和靈活，對元素的定義也更加精練，占用更小的空間資源，易于機(jī)器的解析和生成。并且，JSON是與編程語言無關(guān)的普通文本文件，不需要編譯和執(zhí)行，這些特性使JSON成為地震預(yù)警信息發(fā)布Web端的首選數(shù)據(jù)交換格式（韓敏等，2010）。以1條預(yù)定義的預(yù)警信息的為例，JSON所用的字節(jié)數(shù)明顯小于XML格式，代碼對比見表1。

表1 XML與JSON格式預(yù)警信息代碼對比 Table1 Code format of early warning information between XML and JSON

相對XML，1條JSON格式的預(yù)警信息即減少了75字節(jié)的數(shù)據(jù)量，當(dāng)用戶量和數(shù)據(jù)量增大后，其優(yōu)勢更加突出。在元素規(guī)模較大的情況下，JSON傳輸所消耗的時間遠(yuǎn)遠(yuǎn)小于XML；隨著測試預(yù)警信息元素數(shù)量的逐漸增加，JSON的傳輸速率沒有明顯變化，而XML出現(xiàn)線性增長的趨勢，如圖4所示。此外，客戶端需要對服務(wù)器端傳來的數(shù)據(jù)進(jìn)行反序列化才能獲取有效的數(shù)據(jù)。XML自身基于文檔對象模型（Document Object Mode，DOM）樹結(jié)構(gòu)，進(jìn)行反序列化時需要考慮父節(jié)點(diǎn)和子節(jié)點(diǎn)的相應(yīng)解析，這為反序列化過程增加了難度（于京等，2012）；而基于JavaScript腳本語言的JSON，自身語法非常簡潔，屏蔽了DOM解析的復(fù)雜度，大大降低了反序列化時的冗余度，反序列化時間也明顯小于XML，如圖5所示。因此，采用JSON作為數(shù)據(jù)交換格式，可以最大限度地降低通訊延遲，有利于提高系統(tǒng)的響應(yīng)速度，保證預(yù)警信息的時效性。

圖4 不同元素數(shù)量的傳輸延時測試結(jié)果 Fig.4 Test result for response latency between XML and JSON

圖5 反序列化耗時測試結(jié)果 Fig.5 Test result for time consuming of anti-serialization between XML and JSON

3 核心邏輯設(shè)計

3.1 服務(wù)端設(shè)計

地震預(yù)警信息服務(wù)端軟件從震源參數(shù)數(shù)據(jù)庫獲取參數(shù)信息（發(fā)震時刻、震中位置、震級、震中區(qū)烈度），根據(jù)不同接收終端的信息傳輸協(xié)議，將參數(shù)信息推送至各類客戶端接收軟件。當(dāng)服務(wù)端獲取來自不同數(shù)據(jù)源的地震預(yù)警信息后，首先進(jìn)行數(shù)據(jù)解析，對需要發(fā)布的信息進(jìn)行編碼轉(zhuǎn)換，形成標(biāo)準(zhǔn)化的預(yù)警信息；其次，根據(jù)不同客戶端的數(shù)據(jù)交互方式，按照MQTT協(xié)議及JSON數(shù)據(jù)格式封裝為地震預(yù)警信息包，分別并發(fā)推送至移動端與Web端。推送完成后，監(jiān)聽客戶端的反饋信息，判斷信息是否推送成功，如推送成功，則創(chuàng)建預(yù)警信息服務(wù)日志，否則重新推送，直至獲得正確的反饋信息。地震預(yù)警信息發(fā)布服務(wù)端的邏輯流程如圖6所示。

3.2 客戶端設(shè)計

地震預(yù)警信息客戶端軟件在接收到預(yù)警信息后，對數(shù)據(jù)進(jìn)行解析計算，形成向用戶展現(xiàn)的圖形要素，在前端進(jìn)行可視化展現(xiàn)。當(dāng)客戶端啟動應(yīng)用服務(wù)后，首先向服務(wù)端發(fā)送服務(wù)請求，訂閱預(yù)警信息包，通過定時發(fā)送心跳包與服務(wù)端保持長連接；同時，獲取客戶端位置信息，根據(jù)定位精度的不同，定位方式優(yōu)先級依次為GPS定位、Wi-Fi定位和移動網(wǎng)絡(luò)定位。當(dāng)客戶端接收到服務(wù)端推送的地震預(yù)警信息后，將結(jié)合客戶端此時的位置信息，分別按公式（1）—（3）計算震中距D、用戶所在位置烈度I和對P波、S波的預(yù)警時間TP、TS，以逐秒動態(tài)的方式在前端進(jìn)行展現(xiàn)，并通過聲音或震動方式進(jìn)行報警，同時向服務(wù)端發(fā)送響應(yīng)包，完成1次預(yù)警信息發(fā)布的完整過程。地震預(yù)警信息發(fā)布客戶端的邏輯流程如圖7所示。

圖6 地震預(yù)警信息發(fā)布服務(wù)端邏輯流程 Fig.6 The logical flow chart of server-side

其中，D為震中距（km）；（α1，β1）為用戶所在位置的經(jīng)緯度坐標(biāo)；（α2，β2）為震中位置的經(jīng)緯度坐標(biāo)；R為地球半徑，設(shè)定為6371km。

其中，I0為震中烈度。

其中，VP、VS分別為P波、S波的傳播速度（km/s）；Tnow為當(dāng)前時間；Teq為發(fā)震時間。

圖7 地震預(yù)警信息發(fā)布客戶端邏輯流程 Fig.7 The logical flow chart of client-side

4 系統(tǒng)實(shí)現(xiàn)與測試

根據(jù)上述系統(tǒng)總體架構(gòu)及核心邏輯設(shè)計，開發(fā)實(shí)現(xiàn)了地震預(yù)警信息發(fā)布系統(tǒng)。根據(jù)各子系統(tǒng)部署所在物理位置及用戶類別的角度，從服務(wù)端、客戶端及綜合管理3方面進(jìn)行功能劃分。服務(wù)端子系統(tǒng)與綜合管理子系統(tǒng)分別包含5個子模塊，客戶端子系統(tǒng)功能模塊較多，共包含25個功能模塊。系統(tǒng)功能模塊樹狀圖見圖8。

圖8 地震預(yù)警信息發(fā)布系統(tǒng)功能模塊樹 Fig.8 The function tree component of the earthquake early warning information rapid release system

為檢驗(yàn)軟件系統(tǒng)是否符合預(yù)期目標(biāo)，在對系統(tǒng)的功能模塊及兼容性測試后，重點(diǎn)對軟件的實(shí)時性及可靠性進(jìn)行測試，確定系統(tǒng)運(yùn)行時服務(wù)端與客戶端的性能表現(xiàn)。測試方式是在虛擬機(jī)的環(huán)境下，部署服務(wù)端軟件，模擬每30s向客戶端推送預(yù)警信息，并發(fā)用戶量為2萬以內(nèi)的隨機(jī)數(shù)，連續(xù)推送24小時，通過響應(yīng)時間（從服務(wù)端發(fā)送預(yù)警信息到客戶端收到預(yù)警信息并展現(xiàn)所需的時間）與信息接收率2方面測試系統(tǒng)的整體性能。針對Android客戶端軟件，增加了耗電量的測試。

4.1 Web端

Web端地震預(yù)警信息發(fā)布軟件整體采用RIA（Rich Internet Application，富客戶端應(yīng)用）模式，通過Java語言完成JSON數(shù)據(jù)包的反序列化處理，對解析后的數(shù)據(jù)，采用HTML5語言實(shí)現(xiàn)WebGIS功能與地震預(yù)警信息的疊加展現(xiàn)。富客戶端應(yīng)用模式不僅降低了系統(tǒng)部署的復(fù)雜度和服務(wù)端的計算壓力，提高了系統(tǒng)整體響應(yīng)速度，同時也實(shí)現(xiàn)了無刷新的動態(tài)展現(xiàn)的預(yù)警信息，給用戶帶來更好的操作體驗(yàn)。

Web端預(yù)警信息發(fā)布軟件能夠?qū)φ鹪葱畔⑦M(jìn)行滾動發(fā)布，標(biāo)注用戶位置（Wi-Fi網(wǎng)絡(luò)定位）與震中位置，計算地震預(yù)警信息，通過動態(tài)的形式展現(xiàn)P、S波擴(kuò)散過程，并以倒計時方式配合聲音報警提示用戶預(yù)警時間，如圖9所示。通過24小時連續(xù)測試，客戶端在Wi-Fi網(wǎng)絡(luò)環(huán)境下的平均響應(yīng)時間為460ms。由于網(wǎng)絡(luò)狀態(tài)相對穩(wěn)定，測試結(jié)果未出現(xiàn)丟包或二次推送的情況，客戶端能夠100%接收到預(yù)警信息。

圖9 WebGIS端預(yù)警信息發(fā)布效果 Fig.9 Actual effect map of the early warning information release in WebGIS

4.2 Android端

Android端地震預(yù)警信息發(fā)布軟件基于Android操作系統(tǒng)原生開發(fā)，采用ViewStub動態(tài)布局顯示技術(shù)完成用戶界面設(shè)計，有效減少了對資源的占用，降低了信息接收的延遲。通過調(diào)用高德開放平臺的地圖數(shù)據(jù)，構(gòu)建地理信息數(shù)據(jù)資源，完成預(yù)警信息、位置信息及地理信息的疊加渲染。用戶可根據(jù)需求定制預(yù)警服務(wù)內(nèi)容，設(shè)置交互模式及信息接收方式，滿足各種場景下對地震預(yù)警信息的需求。

在接收到預(yù)警信息后，移動端預(yù)警信息發(fā)布軟件首先以振動及聲音報警的形式提醒用戶查看信息，同時自動彈出地震預(yù)警基本信息頁面，如圖10（a）所示。用戶可以點(diǎn)擊查看地震波擴(kuò)散的動態(tài)過程，如圖10（b）所示。為統(tǒng)一客戶端軟件的風(fēng)格，在顯示內(nèi)容與展現(xiàn)形式上與Web端基本一致。

為充分反映不同網(wǎng)絡(luò)環(huán)境下的系統(tǒng)響應(yīng)時間，分別選擇Wi-Fi和4G無線網(wǎng)絡(luò)環(huán)境進(jìn)行24小時連續(xù)測試。在Wi-Fi網(wǎng)絡(luò)環(huán)境下，系統(tǒng)的平均響應(yīng)時間為318ms，客戶端能100%接收到預(yù)警信息；在4G網(wǎng)絡(luò)環(huán)境下，由于網(wǎng)絡(luò)波動較大，系統(tǒng)的平均響應(yīng)時間為705ms，查詢系統(tǒng)日志記錄發(fā)現(xiàn)有1.7%的預(yù)警信息通過二次推送完成，一定程度上增加了系統(tǒng)的響應(yīng)時間。

圖10 移動端預(yù)警信息發(fā)布效果 Fig.10 Actual effect map of the early warning information release in Android

最后，采用AccuBattery軟件，測試Android端軟件的耗電量。在空載狀態(tài)下，即Android客戶端程序在后臺運(yùn)行，定時發(fā)送心跳包保持與服務(wù)端的長連接，選取發(fā)送時間間隔為5分鐘，經(jīng)24小時連續(xù)測試，消耗電量為24.08mAh。按照一般手機(jī)電池容量為3000mAh計算，Android端軟件每天的電量消耗占比小于1%，幾乎可以忽略不計。

5 結(jié)論

本文基于互聯(lián)網(wǎng)技術(shù)，面向移動端及桌面端用戶，提出了地震預(yù)警信息發(fā)布系統(tǒng)總體架構(gòu)設(shè)計方案。通過對比分析，選定MQTT協(xié)議及JSON格式作為服務(wù)端與客戶端數(shù)據(jù)交互方式。根據(jù)業(yè)務(wù)需求，結(jié)合GIS及LBS技術(shù)，設(shè)計并實(shí)現(xiàn)了核心邏輯流程與系統(tǒng)功能模塊。最后，通過綜合測試，驗(yàn)證了該系統(tǒng)在實(shí)時性、可靠性等方面的優(yōu)勢。

該地震預(yù)警信息發(fā)布系統(tǒng)具有如下特點(diǎn)：①兼容性，預(yù)警參數(shù)計算與各類數(shù)據(jù)源之間完全解耦，通過協(xié)議自動適配，支持多類預(yù)警數(shù)據(jù)源的接入；②靈活性，系統(tǒng)基于服務(wù)組件架構(gòu)模型開發(fā)，各類用戶可根據(jù)需求最大化的配置、定制系統(tǒng)服務(wù)；③可靠性，利用專有信息傳送機(jī)制，有效降低了系統(tǒng)總體延時，確保預(yù)警信息發(fā)布的時效性和可靠性。面向大規(guī)?；ヂ?lián)網(wǎng)用戶應(yīng)用時，有較高實(shí)時性要求的混合架構(gòu)應(yīng)用系統(tǒng)，具有一定的實(shí)際應(yīng)用價值和參考借鑒意義。

當(dāng)發(fā)生較大地震時，震源區(qū)的通訊設(shè)施可能被損毀，震源區(qū)用戶將無法接收到地震預(yù)警信息，因此，系統(tǒng)仍有改進(jìn)的空間。在接下來的工作中，將增加C/S架構(gòu)下桌面端信息接收軟件，通過在客戶端離線緩存地理信息數(shù)據(jù)，降低系統(tǒng)對互聯(lián)網(wǎng)數(shù)據(jù)的依賴，提升系統(tǒng)的實(shí)時性。同時，進(jìn)一步優(yōu)化系統(tǒng)架構(gòu)，增加廣播、衛(wèi)星等通訊方式，確保在互聯(lián)網(wǎng)中斷的極端情況下，仍能快速發(fā)布預(yù)警信息，增強(qiáng)系統(tǒng)的魯棒性。

致謝：感謝審稿專家對本文提出的修改建議，使系統(tǒng)的架構(gòu)設(shè)計趨于合理，文章的邏輯性更加嚴(yán)密。