一種基于微服務架構的突發(fā)事件預警輔助決策系統(tǒng)的設計與實現(xiàn)

陳石定 劉翔 汪應瓊

摘要 單體式架構應用在突發(fā)事件預警輔助決策系統(tǒng)開發(fā)中不能滿足現(xiàn)實需求，本文引入了微服務架構設計開發(fā)該輔助決策系統(tǒng).通過分析微服務架構在復雜系統(tǒng)中相對于傳統(tǒng)單體式架構的應用優(yōu)勢，設計出一種基于微服務架構的突發(fā)事件預警信息發(fā)布輔助決策系統(tǒng)，該系統(tǒng)選用Spring Cloud微服務框架，并對其進行適當?shù)臄U展，創(chuàng)建了基于該系統(tǒng)設計的注冊中心與網(wǎng)關.系統(tǒng)采用二三維一體化地理信息系統(tǒng)作為展示平臺，通過接入各行業(yè)靜態(tài)、危險源動態(tài)監(jiān)測數(shù)據(jù)，根據(jù)設定的模型進行數(shù)據(jù)融合、處理，輔助進行預警信息生成、發(fā)布及應急處置階段的指揮決策.所設計方案在湖北省突發(fā)事件預警發(fā)布輔助決策系統(tǒng)中得以實際應用，驗證了該類系統(tǒng)使用微服務架構的合理性和有效性.

關鍵詞 微服務架構;突發(fā)事件;預警信息發(fā)布;輔助決策系統(tǒng);三維地理信息系統(tǒng)

中圖分類號 TP319

文獻標志碼 A

0 引言

權威、精準發(fā)布各類預警信息是做好防災減災和應對各種突發(fā)事件的關鍵和有效環(huán)節(jié)[1].目前，我國各省、市依托氣象業(yè)務系統(tǒng)逐步建立了省、市、縣級政府部門統(tǒng)一應用的突發(fā)事件預警信息發(fā)布平臺，作為國家級突發(fā)事件預警發(fā)布平臺的一個分支，承擔突發(fā)事件預警信息的發(fā)布、管理及組織工作.為保證預警信息發(fā)布的精準性、及時性以及決策的科學性，提高所發(fā)布信息的針對性，達到信息精準、受眾靶向的目標，需要有一個科學的輔助決策系統(tǒng)來支持進行突發(fā)事件的信息生成、智能發(fā)布和災害的應對工作.突發(fā)事件預警信息發(fā)布輔助決策系統(tǒng)是針對突發(fā)事件的預警信息發(fā)布工作智能生成預警信息內容，并根據(jù)災害落區(qū)情況，向有需要的人群靶向發(fā)布;同時，它也是根據(jù)災害影響及嚴重程度，按照設定的應急預案進行應對輔助的一個智能化信息平臺.

我國在突發(fā)事件預警輔助決策方面的研究及系統(tǒng)研發(fā)已有一定的基礎及實際案例.陳炳洪等[2]介紹了基于“一張圖”、“一張網(wǎng)”的廣東省突發(fā)事件應急指揮決策輔助系統(tǒng)，系統(tǒng)可以展示各類數(shù)據(jù)，并通過數(shù)據(jù)融合及致災模型，實現(xiàn)了氣象的影響預報模型與風險等級預警.黃成南等[3]研究了基于三維地理信息系統(tǒng)Google Earth的突發(fā)事件預警發(fā)布輔助決策系統(tǒng)，實現(xiàn)了各應急單位行業(yè)數(shù)據(jù)接入和輔助進行預警信息發(fā)布.周潔等[4]提出了將各類數(shù)據(jù)進行融合，通過大數(shù)據(jù)分析技術，為應急決策提供依據(jù).曹蕾[5]對預警系統(tǒng)進行了詳細的研究，搭建了基于G/S模式的突發(fā)事件時空平行演化平臺，對突發(fā)事件中海量、異構的時空數(shù)據(jù)進行分析識別、組織管理、態(tài)勢推演和可視化表達，在突發(fā)事件預警及應急指揮方面可以起到智能支持作用.我國國土、水利、安監(jiān)、海事等行業(yè)也建設了針對本行業(yè)相關災害的決策支持系統(tǒng)，同樣偏重于解決在事件發(fā)生后如何進行數(shù)據(jù)協(xié)同、應急管理.劉峰博等[6]研究了大數(shù)據(jù)技術在軌道交通應急方面的輔助決策應用，通過大數(shù)據(jù)處理技術構建了應急輔助決策系統(tǒng)中的大數(shù)據(jù)處理框架，實現(xiàn)了在軌道交通應急輔助決策方面的應用.

這些研究成果或者系統(tǒng)開發(fā)應用成果對于突發(fā)事件預警、應急指揮決策起到了一定的輔助支持作用.然而，上述成果主要偏重于在突發(fā)事件發(fā)生后如何進行輔助預警信息發(fā)布，或者在事件發(fā)生后對如何進行應急指揮決策提供支持，而對于如何智能生成預警信息內容，并將預警信息精準發(fā)布到相關受眾，同時在應急階段接收受眾的災情現(xiàn)場反饋相結合起來輔助進行災害全流程處置的研究較少.為此，基于業(yè)務需求，本文設計并開發(fā)了突發(fā)事件預警輔助決策系統(tǒng)，實現(xiàn)了預警信息發(fā)布階段通過模型智能生成預警信息，并通過接入的渠道、受眾等信息，實現(xiàn)預警信息靶向發(fā)布，在應急處置階段，根據(jù)事件處置應急預案及現(xiàn)場實際，靶向發(fā)布應急指令.同時，系統(tǒng)通過接收所接入的APP用戶上報的現(xiàn)場詳情，實時了解事件現(xiàn)場的進展，為決策者進行應急處置決策提供輔助.作為一個大型的分布式應用系統(tǒng)，突發(fā)事件預警信息發(fā)布輔助決策系統(tǒng)除了有運行在服務器上的應用外，同時還有運行在移動端的APP應用等.APP與系統(tǒng)通過部署于云端的服務進行數(shù)據(jù)共享，系統(tǒng)功能復雜、模塊眾多，并考慮到后期的功能模塊擴展，因此，在系統(tǒng)設計、開發(fā)部署時采用了當前比較流行的微服務架構，將各模塊進行分解包裝成一個個獨立的服務進行獨立部署，并通過集群進行管理.

1 突發(fā)事件預警信息發(fā)布輔助決策系統(tǒng)設計思想

1.1 系統(tǒng)介紹

突發(fā)事件預警信息發(fā)布輔助決策系統(tǒng)是針對突發(fā)事件的預警信息發(fā)布工作智能生成預警信息內容，并根據(jù)災害落區(qū)情況，向有需要的人群靶向發(fā)布;同時，它也是根據(jù)災害影響及嚴重程度，按照設定的應急預案進行應對輔助的一個智能化信息平臺.系統(tǒng)利用大數(shù)據(jù)和云計算技術來挖掘氣象信息與突發(fā)事件的相關性，構建多災種影響鏈分析模型，按照實況（基礎信息）、風險（預警信息）和事件等場景之間的相關性，建立全過程的氣象應急保障自動化流程，提高突發(fā)事件綜合研判分析與決策支撐能力，促進災害應急輔助決策業(yè)務轉型升級.

湖北省突發(fā)事件預警信息發(fā)布輔助決策系統(tǒng)是一個部署在省級，省、市、縣三級多部門應用的系統(tǒng)，需要接入不同部門所管理的多種類數(shù)據(jù).系統(tǒng)基于“一張圖”，實現(xiàn)了GIS子系統(tǒng)、數(shù)據(jù)管理子系統(tǒng)、綜合監(jiān)控子系統(tǒng)、綜合分析子系統(tǒng)、風險評估子系統(tǒng)、決策聯(lián)動子系統(tǒng)、效益評估子系統(tǒng)、知識庫管理子系統(tǒng)、移動終端決策APP子系統(tǒng)等多個子系統(tǒng)，包括服務器端、客戶端、APP應用等，是一個復雜的分布式應用系統(tǒng)，如圖1所示.

1.2 基于微服務架構的開發(fā)技術

傳統(tǒng)Web軟件系統(tǒng)的典型架構是單體架構，即將應用程序的所有功能打包成一個應用，每個應用是最小的交付和部署單元，應用部署后運行在統(tǒng)一進程中[7].單體架構的應用具有易于測試、部署的優(yōu)點.但是，隨著互聯(lián)網(wǎng)的發(fā)展及企業(yè)應用的擴展，單體架構的應用也表現(xiàn)出代碼包龐雜、難于維護、升級擴展困難等固有的缺陷.微服務架構應運而生.

微服務一詞來源于計算機科學家Fowler[8]的一篇著名的博文，是一種軟件設計風格[8].微服務架構是目前軟件開發(fā)界的一個熱門話題.所謂微服務架構，就是將整個系統(tǒng)分解成互相獨立的功能模塊單元，每個功能模塊單元作為一個獨立的應用提供服務，專注于具體的業(yè)務功能，獨立存儲數(shù)據(jù)，按照業(yè)務功能模塊開發(fā)、測試及部署，系統(tǒng)的各個服務之間通過HTTP API協(xié)議關聯(lián)起來，組成完整的應用系統(tǒng)，服務之間的通信協(xié)議通常采用RESTful API[9].

相對于單體架構應用，基于微服務架構的分布式應用具備以下特點：

1） 復雜度可控.微服務架構通過將龐大復雜的整體應用分解成一組服務，每一個微服務只提供單一的功能，通過定義良好的接口清晰描述服務的邊界，使復雜的功能通過模塊化的方式呈現(xiàn)出來，整體上降低了系統(tǒng)的復雜度[10].微服務架構模式加強了一定程度的模塊化.由于每一個服務體積小、復雜度低，降低了開發(fā)、維護的難度，提高了開發(fā)效率.

2） 靈活可擴展.每一個微服務功能相對比較單一，微服務架構模式使得每個服務可以獨立擴展，進行單獨的功能增減，使得整體變得非常靈活，有效降低風險.

3） 獨立部署.系統(tǒng)的每一個微服務具備獨立的運行進程，所以每個微服務可以獨立部署.使用相同的部署環(huán)境可以實現(xiàn)批量快速部署微服務.

4） 故障隔離.當某一組應用功能發(fā)生故障時，在單一進程的傳統(tǒng)架構下，故障很有可能在進程內擴展，導致整個應用的運行故障.在微服務架構下，故障會被隔離在單個服務中，通過良好的設計，其他服務可通過退化等機制實現(xiàn)應用層面的容錯.

因輔助決策系統(tǒng)首先是一個分布式應用，故在系統(tǒng)設計過程中，需要考慮以下內容：

1）系統(tǒng)包含有多種來源數(shù)據(jù)的集成，且在后期應用的過程中還可能會集成更多種類的數(shù)據(jù);

2）系統(tǒng)集成多個不同的功能單元，接入不同的模型，需要與多個不同的第三方應用進行對接;

3）當出現(xiàn)達到預警模式要求的要素時，系統(tǒng)要能夠超越氣象災害預警常規(guī)處理流程，如審核、簽發(fā)、復核等操作，由系統(tǒng)根據(jù)實時監(jiān)測數(shù)據(jù)自動進行判定，并生成對應的預警信息，進行發(fā)布;

4）系統(tǒng)支持決策指令的實時發(fā)布;

5）系統(tǒng)需要與眾多如移動端APP、微信公眾號、微博等新媒體進行交互;

6）系統(tǒng)需要做到全天候24 h不間斷監(jiān)測、運行等因素.

因此，本系統(tǒng)在設計開發(fā)時需要采用當前比較流行的適用于分布式開發(fā)部署的可擴展軟件架構，以做到快速開發(fā)部署，減少成本、降低風險.根據(jù)采用的平臺，本文選用了目前企業(yè)Web應用開發(fā)中的微服務架構進行系統(tǒng)的設計與開發(fā).

1.3 微服務架構的不足及應對措施

采用微服務架構進行分布式應用系統(tǒng)設計開發(fā)，可以解決單體系統(tǒng)變得龐大之后產(chǎn)生的難以維護等許多問題，但同樣因為功能模塊拆分成微服務，也會引發(fā)許多原本在單體應用中沒有的問題和缺陷.這些問題及缺陷應對措施包括：

1） 服務的邊界問題.在應用微服務架構進行系統(tǒng)分解的過程中，容易出現(xiàn)服務之間的邊界無法很好界定的情況，造成分解后的微服務過大或者過小.單個微服務過大，會出現(xiàn)如同單體架構系統(tǒng)類似的缺陷，單個微服務過小，則導致管理大量服務的難題.因此，在進行系統(tǒng)設計時，需要對系統(tǒng)的功能、模塊進行細致分析，找出最合理的邊界，做到耦合度最小，同時滿足功能需求.

2） 應用的復雜性.分布式應用相對于單體架構應用來說具有固有的復雜性，需要處理RPC或者進程間消息傳遞時的通信機制，特別是當消息傳遞過程中出現(xiàn)速度過慢或者不可用等局部失效的問題時，分布式應用的處理復雜性更高.在基于微服務架構的分布式應用中，只有充分考慮到網(wǎng)絡延遲、容錯、消息序列化、異步、版本控制、負載均衡等[11]對每一個微服務的影響，采取一套完整的策略和機制才能保證各個服務能夠正常運行.

3） 分區(qū)的數(shù)據(jù)庫架構.在基于微服務架構的分布式應用中，一個微服務通常對應一個數(shù)據(jù)庫.在復雜的應用系統(tǒng)中，同時更新多個業(yè)務主題的事務非常普遍，因此在微服務架構應用中，需要同步更新不同服務所使用的不同的數(shù)據(jù)庫，才能夠時刻確保不同的數(shù)據(jù)庫系統(tǒng)中數(shù)據(jù)的一致性.

在系統(tǒng)設計中，有一個CAP原則.根據(jù)CAP原則，在一個較為復雜的分布式系統(tǒng)中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯性）三者需要彼此權衡，不可能同時得到滿足，最多只能保證其中的兩個方面.因此，需要為每個服務調用做不同的權衡，以解決微服務架構應用中的分布式數(shù)據(jù)庫問題.

4） 部署的復雜性.相對于單體式架構應用，基于微服務架構的分布式應用有較多的微服務組成，而且這些微服務均實例化，作為獨立進程運行，這就需要整個應用有較多的配置、部署、監(jiān)控功能，再考慮到系統(tǒng)運行的可靠性及穩(wěn)定性，需要有一定的冗余設計，通常采用集群化的部署方案.這使得系統(tǒng)的部署及維護的復雜性大大提高.

2 基于微服務架構的突發(fā)事件預警輔助決策系統(tǒng)設計

2.1 微服務框架選擇

微服務框架有很多，不同的平臺有不同的適用框架.JAVA平臺比較著名的微服務框架有Dubbo和Spring Cloud框架.經(jīng)過對比及建設實際要求，選擇Spring Cloud作為系統(tǒng)開發(fā)的微服務應用框架.Spring Cloud使用Spring作為容器框架，SpringMVC作為模型控制器框架.相較于其他的微服務框架，Spring是真正的微服務框架，它提供了完整的組件支持，支持跨語言實現(xiàn)，使用簡單方便且有強大的社區(qū)支持，支持自定義組件，是一套完整的分布式系統(tǒng)實現(xiàn)解決方案.

Spring Cloud[11-12]是一個基于Spring Boot的云服務的分布式框架集合，核心功能包括分布式/版本化配置、服務注冊和發(fā)現(xiàn)、路由、服務和服務之間的調用、負載均衡、斷路器、分布式消息傳遞等.它實現(xiàn)了從網(wǎng)關服務到服務發(fā)現(xiàn)，再到熔斷機制等一系列流程，涵蓋了實現(xiàn)分布式系統(tǒng)所需的基礎軟件組件.其組件架構如圖2所示.

Spring Cloud基于Spring Boot，通過在代碼中添加依賴和使用注解功能，使得系統(tǒng)的開發(fā)和部署變得簡單.

2.2 系統(tǒng)微服務設計

根據(jù)系統(tǒng)設計，系統(tǒng)分為基礎公共模塊和業(yè)務處理模塊.基礎公共模塊中包括對引用的各類第三方組件的封裝、系統(tǒng)設計的各類公共組件模塊等;業(yè)務處理模塊包括進行業(yè)務處理所需要的處理、分析、模型等模塊.根據(jù)前述的微服務架構，以及項目建設實際情況，系統(tǒng)將各功能模塊設計為微服務，并將其分為兩類：基礎微服務和業(yè)務定制微服務.基礎微服務提供基礎功能，業(yè)務定制微服務根據(jù)功能設計實現(xiàn)各定制的業(yè)務功能.系統(tǒng)功能模塊分類及相應的微服務設計如表1所示.

各微服務設計成獨立運行的程序，可以部署在不同的服務器上.通過定義良好的服務接口，使用服務所提供的功能.

2.3 系統(tǒng)的微服務總體架構設計

預警信息發(fā)布輔助決策系統(tǒng)由Spring Cloud提供的基本組件和構建的業(yè)務微服務組成.通過使用Zuul組件開發(fā)自己的注冊服務，實現(xiàn)服務注冊，統(tǒng)一提供REST API，使用Ribbon實現(xiàn)負載均衡[13].通過開發(fā)API網(wǎng)關，實現(xiàn)服務注冊中心，并通過Eureka實現(xiàn)服務注冊和服務發(fā)現(xiàn).針對構建的業(yè)務微服務，注冊到開發(fā)的注冊服務中，并通過Eureka實現(xiàn)向外訂閱，提供微服務的具體功能.各微服務對應著獨立的業(yè)務數(shù)據(jù)庫.各庫之間的數(shù)據(jù)有部分冗余.微服務應用架構設計如圖3所示.

2.4 系統(tǒng)實現(xiàn)

2.4.1 動態(tài)信息接入

系統(tǒng)基于GIS地圖，以各圖層疊加的方式展示接入的各行業(yè)數(shù)據(jù)，包括靜態(tài)數(shù)據(jù)、動態(tài)實時監(jiān)測數(shù)據(jù)、歷史數(shù)據(jù)等.靜態(tài)數(shù)據(jù)包括監(jiān)測點、災害風險點、應急資源場所、應急物資存放信息等;動態(tài)數(shù)據(jù)包括氣象部門的監(jiān)測、預報數(shù)據(jù)，水利行業(yè)的水庫、湖泊、河流水文監(jiān)測數(shù)據(jù)，國土行業(yè)的災害點實時監(jiān)測數(shù)據(jù)，海事部門的船舶實時監(jiān)測數(shù)據(jù)，其他部門的視頻監(jiān)控圖像信息等;歷史數(shù)據(jù)主要包括監(jiān)測點（或監(jiān)測區(qū)域）歷史上發(fā)生的災害情況數(shù)據(jù)等.這些數(shù)據(jù)通過數(shù)據(jù)擁有部門提供的接口接入到本系統(tǒng)中，并基于一張圖，根據(jù)決策者需要分類有條件進行展示，同時根據(jù)致災預警模型，對數(shù)據(jù)進行加工、融合處理后得出預測結果，并有針對性地生成各類預警信息.

針對發(fā)布的預警信息，系統(tǒng)實時在圖上的對應區(qū)域進行高亮提醒，并使用相應的預警圖標在預警區(qū)域進行標明，動態(tài)展現(xiàn)預警情況，如圖4所示.

2.4.2 致災預警模型接入

發(fā)布預警信息是一件嚴肅的事情，事關人民群眾生產(chǎn)生活、防災減災，要有科學性、權威性、實時性.預警信息的缺發(fā)、濫發(fā)、錯發(fā)都會導致嚴重的后果，故發(fā)布前需要仔細斟酌發(fā)布的內容、范圍、等級、受眾、時間等因素[3].本系統(tǒng)在發(fā)布流程上設計了多流程節(jié)點進行確認，在預警信息要素的獲取上通過采用相應的科學模型進行計算，輔助生成預警信息內容.系統(tǒng)根據(jù)實際，引入或接入了多種模型，例如：暴雨洪水水淹模型接入.系統(tǒng)采用了目前研究、使用較多的二維水動力演進模型Flood Area[14]，計算指定區(qū)域內淹沒范圍.國內很多研究人員，如文獻[15-17]使用該模型進行了暴雨洪水、淹沒區(qū)域模擬，證明該模型用以界定洪水淹沒范圍并預警洪澇風險的精度較高.

Flood Area模型的計算基于水動力方法，同時考慮當前柵格周圍8個鄰域單元，對鄰域單元的泄入量使用Manning-Stricker公式[14]進行計算：

式中：kst是反映地表粗糙情況對水流影響的系數(shù)，稱之為Stricker系數(shù)，根據(jù)土地利用數(shù)據(jù)轉換得到，系統(tǒng)中將使用到的類型建立表格，通過查表得到;rhy是水力半徑;I為地形（或明渠）的坡度.

水流的淹沒深度為淹沒水位高程與地面高程之間的差值，淹沒過程中的水流方向則由地形的坡向所決定[17].對地面上的任意一點，其坡向表征了該點高程值變化最大的方向，其計算公式[14]為

Flood Area模型有3種基本的淹沒情景：漫頂式、潰口式以及暴雨式.本系統(tǒng)由用戶根據(jù)實際使用場景選擇適合的淹沒情景.

系統(tǒng)獲取指定區(qū)域及周圍臨近各站點的實時降雨量預測預報數(shù)據(jù)及觀測數(shù)據(jù)，采用泰森多邊形面積權重法計算小時面雨量，然后根據(jù)該區(qū)域DEM分布，確定不同的地形類型，采用不同的Flood Area模型計算參數(shù)，分別計算致災雨量、洪水淹沒區(qū)、警戒區(qū)，并將計算結果在GIS地圖上進行三維疊加模擬顯示.同時，系統(tǒng)根據(jù)計算得到的致災雨量數(shù)據(jù)進行判斷并自動進行預警.在雨量達到設定的閾值時，根據(jù)計算所得到的淹沒區(qū)域、警戒區(qū)域信息，提取該區(qū)域內的學校、村莊等各類場所信息及應急資源等要素，獲取各應急責任人、區(qū)域內的各種預警信息發(fā)布渠道等，自動將其作為靶向發(fā)布的受眾，提醒發(fā)布預警信息和應急指令，為防災、減災提前做好應對措施，給決策者或者系統(tǒng)使用者進行決策提供相應的輔助，并根據(jù)預案信息實現(xiàn)決策聯(lián)動.

其他主要接入模型包括污染物擴散模型、城市內澇模型、地質災害預警模型等，均采用微服務架構集合各種外部門數(shù)據(jù)和災害公式模型做上述引用處理疊加呈現(xiàn)在GIS系統(tǒng)中.

2.4.3 發(fā)布渠道接入

輔助決策系統(tǒng)對于各部門、行業(yè)已建的各類發(fā)布渠道，如大喇叭、LED、短信、12121語音外呼、FTP、傳真、微信公眾號、微博、APP等，可以通過接口實現(xiàn)接入，并通過Web Service回調機制實現(xiàn)狀態(tài)監(jiān)測，通過TCP/IP的連接狀態(tài)實現(xiàn)心跳監(jiān)測，并通過表格或圖形化模式直觀顯示各接入渠道管理平臺中所管理的發(fā)布渠道的實時連接狀態(tài).

在輔助決策系統(tǒng)中，如果監(jiān)測的要素中遇到有超限情況，或者有比較緊急的預警信息或通知消息、決策指令，可以通過系統(tǒng)中的模型直接生成預警信號或通知消息，通過靶向發(fā)布方式或者指定受眾發(fā)布的形式進行發(fā)布.若是有影響較大、涉及面較廣的預警信號，需要通過嚴格的發(fā)布流程進行處理，則可直接轉到預警信息發(fā)布界面，通過錄入、審核、簽發(fā)等規(guī)定的發(fā)布流程進行處理.

2.4.4 應急支持輔助

系統(tǒng)設計實現(xiàn)了在突發(fā)事件已經(jīng)發(fā)生情況下的應急輔助支持.系統(tǒng)可以通過決策聯(lián)動、預案指令、靶向發(fā)布等功能或技術，執(zhí)行視頻會商及會商紀要記錄，啟動應急預案進行突發(fā)事件處置，通過靶向發(fā)布技術對預警信息精準發(fā)布，通過APP上報事件處置情況及災害詳情供決策者了解現(xiàn)場現(xiàn)狀等.輔助支持詳情信息可在一張圖上實時疊加展示，如圖5所示.

2.4.5 災害四維復盤

針對已經(jīng)發(fā)生的災害情況，需要做好災害事件發(fā)生過程中各要素過程的詳盡記錄，事后可以進行災害發(fā)生過程、處置過程的復盤查看，為今后同類事件的處置提供借鑒.

災害四維復盤以事件進展的時間先后順序，以二維/三維GIS為基礎畫面，綜合展示各種觀測數(shù)據(jù)、評估分析、聯(lián)動情況，及各關鍵人員的行動軌跡，直觀顯示突發(fā)事件的演變、處置情況.

3 基于微服務架構的系統(tǒng)開發(fā)核心流程處理示例

突發(fā)事件預警輔助決策系統(tǒng)采用IntelliJIDEA開發(fā)平臺，Maven項目管理和綜合工具進行系統(tǒng)構建.

在基于Maven的系統(tǒng)開發(fā)中使用微服務，其流程如圖6所示[14].

3.1 搭建（定義）服務注冊中心

1）使用IntelliJIDEA，創(chuàng)建新應用項目Service-Registry，把該項目作為注冊中心的服務.創(chuàng)建完成后先在配置管理文件，例如以下定義項目配置文件pom.xml，在其中配置必需的依賴：

org.springframework.cloud

spring-cloud-starter-eureka-server

2）實現(xiàn)注冊應用類ServiceRegistryApplication

例如在代碼ServiceRegistryApplication.java文件中類聲明的前面，添加注解，通過@EnableEurekaServer注解啟動一個服務注冊中心，提供給其他應用進行對話.

@EnableEurekaServer

public class ServiceRegistryApplication {

public static void main（String[]args） {

SpringApplication.run（ServiceRegistryApplication.class，args）;

}

}

3）配置訪問路徑及相關參數(shù)

例如定義application.yml配置文件，參數(shù)可如下進行：

#應用（服務名稱）：service-registry

spring：

application：

name：service-registry

# 定義注冊服務運行時提供服務用的端口

server：

#設置該服務注冊中心的端口號，此處設為8761

port：8761

# 定義 Eureka server

eureka：

instance：

# 設置該服務注冊中心的hostname

hostname：localhost

port：${server.port}

client：

#由于該應用是一個服務注冊中心，而不是普通的應用，默認情況下，這個應用會向注冊中心（即本身）注冊它自己，為此需設置為false以禁止這種默認行為.

registerWithEureka：false

#服務注冊中心本身的職責就是維護服務實例，不需要去檢索其他服務.設置為false

fetchRegistry：false

serviceUrl：

defaultZone：

http：∥${eureka.instance.hostname}：${server.port}/eureka/

server：

waitTimeInMsWhenSyncEmpty：0

enable-sel f-preservation：false

其中，server.port=8761，表明通過SpringEureka的訪問地址，可以訪問http：∥localhost：8761以查看注冊的微服務信息.

3.2 微服務注冊

在完成服務注冊中心的搭建后，將其他的服務添加到Eureka的服務治理體系中，作為服務的提供者提供相應的功能服務.下面以user-service微服務為例介紹微服務的創(chuàng)建及注冊流程.

1）創(chuàng)建新應用模塊，例如定義為user-service，并在pom.xml配置對Eureka的依賴.

配置情況如下：

user-service

jar

user-service

org.springframework.cloud

spring-cloud-starter-eureka

org.springframework.boot

spring-boot-starter-web

2）創(chuàng)建微服務啟動類UserServiceApplication，并在該類中實現(xiàn)設計好的相應功能.

@SpringBootApplication

@EnableFeignClients

@MapperScan（"com.user.service.mapper"）

@ServletComponentScan（"com.user.service"）

public class UserServiceApplication extends BaseApplication {

public static void main（String[]args） {

SpringApplication.run（UserServiceApplication.class，args）;

}

}

在主類中通過加上@EnableDiscoveryClient注解，可以激活Eureka中的DiscoveryClient實現(xiàn)，實現(xiàn)對該服務中的相應服務信息的輸出.

3）在application.yml或者application.porperties文件中配置用戶的訪問參數(shù)，通過spring.application.name屬性為該服務進行命名，再通過eureka.client.serviceUrl.defaultZone屬性來指定上一步構建的服務中心的地址.配置情況如下：

spring：

application：

name：user-service

# Define the port where the Widget Foundry server would be running

server：port：8881

# Define the Eureka server that handles service registration.

eureka：

instance：

port：8761

client：

serviceUrl：

defaultZone：http：∥localhost：${eureka.instance.port}/eureka/

通過server.port=8881，服務注冊中心可以發(fā)現(xiàn)該服務，并在服務列表中列出該服務的信息.通過在瀏覽器輸入http：∥localhost：8761，即可打開Eureka信息面板，查看已有注冊的微服務.

3.3 微服務發(fā)現(xiàn)和路由

經(jīng)過注冊后的微服務可以作為服務提供者為服務消費者提供相應服務.該步驟通過服務發(fā)現(xiàn)實現(xiàn).在實際的實現(xiàn)過程中，為有效降低維護路由規(guī)則與服務實例表的難度，解決微服務接口訪問時的前置校驗冗余，通常使用API網(wǎng)關服務，將所有的外部客戶端訪問通過它進行調度和過濾.因此在本系統(tǒng)中，實現(xiàn)了API網(wǎng)關功能.

1）創(chuàng)建API網(wǎng)關服務api-gateway，也在pom.xml配置相關依賴：

API網(wǎng)關服務基于NexflixZuul實現(xiàn).在配置文件中需要引入相應的對spring-cloud-starter-auul的依賴.例如：

org.springframework.cloud

spring-cloud-starter-eureka

org.springframework.cloud

spring-cloud-starter-zuul

com.github.mthizo247

spring-cloud-netflix-zuul-websocket

1.0.0

2）創(chuàng)建應用主類，并使用@EnableZuulProxy注解開啟Zuul的API網(wǎng)關服務功能：

@SpringBootApplication

∥開啟Zuul的API網(wǎng)關服務功能

@EnableZuulProxy

∥該應用是一個Eureka客戶端應用.該注解表明該應用自動具備了發(fā)現(xiàn)服務的能力.

@EnableDiscoveryClient

public class ApiGatewayApplication {

public static void main（String[]args） {

SpringApplication.run（ApiGatewayApplication.class，args）;

}

}

3）在配置文件匯總配置Zuul應用的基礎信息，如應用名稱、服務端口號等.

配置例如：

spring：

aop：

proxyTargetClass：true

application：

name：api-gateway

# 定義API網(wǎng)關服務運行時提供服務的端口

server：

port：5555

# Define the Eureka server that handles service registration

eureka：

instance：

port：8761

client：

serviceUrl：

defaultZone：http：∥localhost：${eureka.instance.port}/eureka/

zuul：

routes：

user-service：/user/**

demo-service：/demo/**

system-service：/system/**

……

add-proxy-headers：true

ribbon：

eureka：

enabled：true

3.4 使用微服務

在API中注冊的微服務可以向整個系統(tǒng)提供該微服務所具備的功能，即實現(xiàn)服務消費.

1）創(chuàng)建一個使用User-service服務的Spring Boot基礎工程uaa-service，在pom.xml中引入相應的依賴.

配置例如：

uaa-service

登錄和鑒權服務

org.springframework.cloud

spring-cloud-starter-eureka

org.springframework.boot

spring-boot-starter-actuator

org.springframework.boot

spring-boot-starter-web

……

2）創(chuàng)建應用的入口類.在入口類的實現(xiàn)文件中通過使用@EnableDiscoveryClient注解讓該應用注冊為Eureka的客戶端應用，以獲得服務發(fā)現(xiàn)能力.

@SpringBootApplication

@MapperScan（"com.uaa.service.mapper"）

∥通過使用@EnableDiscoveryClient注解讓該應用注冊為Eureka的客戶端應用，以獲得服務發(fā)現(xiàn)能力.

@EnableDiscoveryClient

@ServletComponentScan（"com.uaa.service"）

public class UaaServiceApplication extends WebMvcConfigurerAdapter {

public static void main（String[]args） {

SpringApplication.run（UaaServiceApplication.class，args）;

}

}

3）創(chuàng)建Controller類接口并實現(xiàn)接口：

@RestController

public class Controller implements Service {

@ApiOperation（value="得到用戶"，notes="查詢…"）

@RequestMapping（value="/getUser"）

@ResponseBody

public User getUser （）{

User u=ThreadVariable.getUser（）;

return u;

}

}

4）最后，在.properties配置文件中配置Eureka服務注冊中心的位置，同時設置該服務消費者的端口.

經(jīng)過上述步驟，可以通過向http：∥localhost：port/uaa-service發(fā)起GET請求，實現(xiàn)對服務中相關功能的調用.

3.5 系統(tǒng)應用場景案例模擬

本文選取系統(tǒng)中的監(jiān)測數(shù)據(jù)超限時自動發(fā)送通知消息功能和災害四維復盤模塊進行系統(tǒng)的應用模擬.

3.5.1 站點監(jiān)測數(shù)據(jù)超限自動發(fā)送通知消息模擬

系統(tǒng)定時從接入的監(jiān)測站點獲取實時的監(jiān)測數(shù)據(jù)，然后與設定監(jiān)控的站點的閾值進行比對，當是實測值超過閾值引發(fā)告警提示時，系統(tǒng)后臺自動通過設定渠道發(fā)布告警提示信息.發(fā)布的告警提示信息可在發(fā)布管理平臺中查看，如圖7所示.

3.5.2 災害四維復盤模擬

系統(tǒng)假設某一區(qū)域可能會發(fā)生一次災害，根據(jù)業(yè)務處理流程，模擬該次災害發(fā)生前后的數(shù)據(jù)收集融合處理情況、應急處置情況等，事后進行復盤展示，為以后處置該類事件提供參考.

圖8展示了復盤處置過程中的3個顯示界面.首先收集各站點監(jiān)測數(shù)據(jù)、氣象部門的預測預報數(shù)據(jù)，并進行數(shù)據(jù)融合處理，根據(jù)設定的閾值、模型進行判斷處理.當超閾值時，圖8在可能發(fā)生災害區(qū)域進行信息提示，并將可能的災害落區(qū)繪制顯示.

系統(tǒng)根據(jù)落區(qū)情況，統(tǒng)計出該落區(qū)的相關要素，并檢索與該落區(qū)相關的應急處置預案，根據(jù)預案生成相應的處置指令，執(zhí)行靶向發(fā)布操作.同時，系統(tǒng)接收相應的APP用戶上報的災情信息進行顯示.

4 結束語及討論

基于Spring Cloud架構的微服務框架已經(jīng)在湖北省突發(fā)事件預警輔助決策系統(tǒng)中得以應用，系統(tǒng)實現(xiàn)了融合多部門數(shù)據(jù)的災害預警發(fā)布、應急指揮“一張圖”，驗證了微服務架構用于復雜的輔助決策的可行性與實用性，減小了系統(tǒng)各功能模塊間的耦合度，更有利于應用系統(tǒng)的擴充和完善，與采用傳統(tǒng)單體架構應用的開發(fā)過程相比較，降低了開發(fā)的難度，與外省同類系統(tǒng)相比提高了系統(tǒng)運行效率，也更便于發(fā)布渠道等擴展系統(tǒng)的對接.

本系統(tǒng)今后的重點研究方向是，隨著接入更多的實時數(shù)據(jù)，通過開發(fā)新的微服務，以接入更多的預測預警模型，并將大數(shù)據(jù)分析技術更好地應用于各類災害模型，使之不斷完善，同時利用已廣泛建設的視頻監(jiān)控系統(tǒng)，借助成熟的圖像處理技術，使預測、預報更為精確，提升預警信息發(fā)布的及時性和覆蓋面，提高災情現(xiàn)場態(tài)勢監(jiān)測能力，更好地服務于防災減災.

參考文獻References

[1] 鄭國光.加快推進預警信息發(fā)布系統(tǒng)建設 努力實現(xiàn)權威精準快速安全發(fā)布[J].中國應急管理，2016（5）：72-74

ZHENG Guoguang.Accelerating the construction of early warning information release system，strive to achieve authoritative accurate，fast and secure release[J].China Emergency Management，2016（5）：72-74

[2] 陳炳洪，曾沁，張毅，等.廣東省突發(fā)事件應急指揮決策輔助系統(tǒng)的建設[J].廣東氣象，2018，40（1）：39-42

CHEN Binghong，ZENG Qin，ZHANG Yi，et al.Construction of emergency command and decision support system for emergency situations in guangdong province[J].Guangdong Meteorology，2018，40（1）：39-42

[3] 黃成南，王文波，陳妍.肇慶市突發(fā)事件預警信息發(fā)布決策輔助系統(tǒng)的設計與應用[J].廣東氣象，2017，39（1）：61-64

HUANG Chengnan，WANG Wenbo，CHEN Yan.Design and application of decision support system for early warning information release in Zhaoqing city [J].Guangdong Meteorology，2017，39（1）：61-64

[4] 周潔，許麗佳，林倩.面向輔助決策的突發(fā)事件預警信息發(fā)布系統(tǒng)研究：以北京市突發(fā)事件預警信息發(fā)布系統(tǒng)為例[J].科技風，2018（22）：76，86

ZHOU Jie，XU Lijia，LIN Qian.Research on emergency warning information release system for assistant decision-making：taking beijing emergency early warning information release system as an example[J].Technology Wind，2018（22）：76，86

[5] 曹蕾.基于G/S模式的突發(fā)事件時空平行演化方法研究與實現(xiàn)[D].成都：成都理工大學，2013

CAO Lei.The research and implementation of parallel space-time evolution method based on the G/S Model of emergency[D].Chengdu：Chengdu University of Technology，2013

[6] 劉峰博，干葉婷，周峰.大數(shù)據(jù)技術在軌道交通應急輔助決策中的應用設計[J].華東交通大學學報，2016，32（2）：56-62

LIU Fengbo，GAN Yeting，ZHOU Feng.Application design of big data technologies in emergency decision supporting system[J].Journal of East China Jiaotong University，2016，32（2）：56-62

[7] 張晶，王琰潔，黃小鋒，等.一種微服務框架的實現(xiàn)[J].計算機系統(tǒng)應用，2017，26（4）：82-86

ZHANG Jing，WANG Yanjie，HUANG Xiaofeng，et al.Implementationof microservice architecture[J].Computer Systems & Applications，2017，26（4）：82-86

[8] Fowler M.Microservices[DB/OL].（2018-03-25）.https：∥martinfowler.com/articles/microservices.html

[9] 張峰.微服務技術構建大規(guī)模web系統(tǒng)的研究[J].科技創(chuàng)新與應用，2017，22：48-49

ZHANG Feng.Research on building large-scale web system with microservice technology[J].Technology Innovation and Application，2017，22：48-49

[10] 鄭明釗，張建強.基于微服務的大平臺系統(tǒng)架構演進探討[J].軟件，2017，38（12）：165-169

ZHENG Mingzhao，ZHANG Jianqiang.Discussion on the evolution of big platform system architecture based on microservice[J].Computer Engineering & Software，2017，38（12）：165-169

[11] Richardson C.Introduction to microservices [EB/OL].[2019-04-01].https：∥www.nginx.com/blog/introduction-to-microservices

[12] Alberto R.Spring Cloud[EB/OL].[2019-04-01].http：∥spring.io/projects/spring-cloud，2018

[13] 翟永超.Spring Cloud微服務實戰(zhàn)[M].北京：電子工業(yè)出版社，2017

ZHAI Yongchao.Spring Cloud microservices in action [M].Beijing：Publishing House of Electronics Industry，2011

[14] Geomer.Flodarea-arcview extention for calculating flooded areas （user manual version 10.3） [M].Heidelberg，2015

[15] 謝五三，田紅，盧燕宇.基于FloodArea模型的大通河流域暴雨洪澇災害風險評估[J].暴雨災害，2015，34（4）：384-387

XIE Wusan，TIAN Hong，LU Yanyu.Risk evaluation of rainstorm and flood disasters in Datong river basin based on the FloodArea model[J].Torrential Rain and Disasters，2015，34（4）：384-387

[16] 苗茜，謝志清，曾燕，等.基于統(tǒng)計-FloodArea模型的平原水網(wǎng)區(qū)致災臨界雨量研究[J].自然資源學報，2018，33（9）：1563-1574

MIAO Qian，XIE Zhiqing，ZENG Yan，et al.Research of critical rainfalls in wet-net plains based on statistical method and FloodArea[J].Journal of Natural Resources，2018，33（9）：1563-1574

[17] 張磊，王文，文明章，等.基于“FloodArea”模型的山洪災害精細化預警方法研究[J].復旦學報（自然科學版），2015，54（3）：282-287

ZHANG Lei，WANG Wen，WEN Mingzhang，et al.Research on refined early-warning method of mountain flood disaster based on FloodArea[J].Journal of Fudan University（Natural Science），2015，54（3）：282-287