一種基于微服務架構的突發事件預警輔助決策系統的設計與實現
2019-05-30 23:31:00陳石定劉翔汪應瓊
南京信息工程大學學報 2019年5期
陳石定 劉翔 汪應瓊
摘要 單體式架構應用在突發事件預警輔助決策系統開發中不能滿足現實需求，本文引入了微服務架構設計開發該輔助決策系統.通過分析微服務架構在復雜系統中相對于傳統單體式架構的應用優勢，設計出一種基于微服務架構的突發事件預警信息發布輔助決策系統，該系統選用Spring Cloud微服務框架，并對其進行適當的擴展，創建了基于該系統設計的注冊中心與網關.系統采用二三維一體化地理信息系統作為展示平臺，通過接入各行業靜態、危險源動態監測數據，根據設定的模型進行數據融合、處理，輔助進行預警信息生成、發布及應急處置階段的指揮決策.所設計方案在湖北省突發事件預警發布輔助決策系統中得以實際應用，驗證了該類系統使用微服務架構的合理性和有效性.
關鍵詞 微服務架構;突發事件;預警信息發布;輔助決策系統;三維地理信息系統
中圖分類號 TP319
文獻標志碼 A
0 引言
權威、精準發布各類預警信息是做好防災減災和應對各種突發事件的關鍵和有效環節[1].目前，我國各省、市依托氣象業務系統逐步建立了省、市、縣級政府部門統一應用的突發事件預警信息發布平臺，作為國家級突發事件預警發布平臺的一個分支，承擔突發事件預警信息的發布、管理及組織工作.為保證預警信息發布的精準性、及時性以及決策的科學性，提高所發布信息的針對性，達到信息精準、受眾靶向的目標，需要有一個科學的輔助決策系統來支持進行突發事件的信息生成、智能發布和災害的應對工作.突發事件預警信息發布輔助決策系統是針對突發事件的預警信息發布工作智能生成預警信息內容，并根據災害落區情況，向有需要的人群靶向發布;同時，它也是根據災害影響及嚴重程度，按照設定的應急預案進行應對輔助的一個智能化信息平臺.
我國在突發事件預警輔助決策方面的研究及系統研發已有一定的基礎及實際案例.陳炳洪等[2]介紹了基于“一張圖”、“一張網”的廣東省突發事件應急指揮決策輔助系統，系統可以展示各類數據，并通過數據融合及致災模型，實現了氣象的影響預報模型與風險等級預警.黃成南等[3]研究了基于三維地理信息系統Google Earth的突發事件預警發布輔助決策系統，實現了各應急單位行業數據接入和輔助進行預警信息發布.周潔等[4]提出了將各類數據進行融合，通過大數據分析技術，為應急決策提供依據.曹蕾[5]對預警系統進行了詳細的研究，搭建了基于G/S模式的突發事件時空平行演化平臺，對突發事件中海量、異構的時空數據進行分析識別、組織管理、態勢推演和可視化表達，在突發事件預警及應急指揮方面可以起到智能支持作用.我國國土、水利、安監、海事等行業也建設了針對本行業相關災害的決策支持系統，同樣偏重于解決在事件發生后如何進行數據協同、應急管理.劉峰博等[6]研究了大數據技術在軌道交通應急方面的輔助決策應用，通過大數據處理技術構建了應急輔助決策系統中的大數據處理框架，實現了在軌道交通應急輔助決策方面的應用.
這些研究成果或者系統開發應用成果對于突發事件預警、應急指揮決策起到了一定的輔助支持作用.然而，上述成果主要偏重于在突發事件發生后如何進行輔助預警信息發布，或者在事件發生后對如何進行應急指揮決策提供支持，而對于如何智能生成預警信息內容，并將預警信息精準發布到相關受眾，同時在應急階段接收受眾的災情現場反饋相結合起來輔助進行災害全流程處置的研究較少.為此，基于業務需求，本文設計并開發了突發事件預警輔助決策系統，實現了預警信息發布階段通過模型智能生成預警信息，并通過接入的渠道、受眾等信息，實現預警信息靶向發布，在應急處置階段，根據事件處置應急預案及現場實際，靶向發布應急指令.同時，系統通過接收所接入的APP用戶上報的現場詳情，實時了解事件現場的進展，為決策者進行應急處置決策提供輔助.作為一個大型的分布式應用系統，突發事件預警信息發布輔助決策系統除了有運行在服務器上的應用外，同時還有運行在移動端的APP應用等.APP與系統通過部署于云端的服務進行數據共享，系統功能復雜、模塊眾多，并考慮到后期的功能模塊擴展，因此，在系統設計、開發部署時采用了當前比較流行的微服務架構，將各模塊進行分解包裝成一個個獨立的服務進行獨立部署，并通過集群進行管理.
1 突發事件預警信息發布輔助決策系統設計思想
1.1 系統介紹
突發事件預警信息發布輔助決策系統是針對突發事件的預警信息發布工作智能生成預警信息內容，并根據災害落區情況，向有需要的人群靶向發布;同時，它也是根據災害影響及嚴重程度，按照設定的應急預案進行應對輔助的一個智能化信息平臺.系統利用大數據和云計算技術來挖掘氣象信息與突發事件的相關性，構建多災種影響鏈分析模型，按照實況（基礎信息）、風險（預警信息）和事件等場景之間的相關性，建立全過程的氣象應急保障自動化流程，提高突發事件綜合研判分析與決策支撐能力，促進災害應急輔助決策業務轉型升級.
湖北省突發事件預警信息發布輔助決策系統是一個部署在省級，省、市、縣三級多部門應用的系統，需要接入不同部門所管理的多種類數據.系統基于“一張圖”，實現了GIS子系統、數據管理子系統、綜合監控子系統、綜合分析子系統、風險評估子系統、決策聯動子系統、效益評估子系統、知識庫管理子系統、移動終端決策APP子系統等多個子系統，包括服務器端、客戶端、APP應用等，是一個復雜的分布式應用系統，如圖1所示.
1.2 基于微服務架構的開發技術
傳統Web軟件系統的典型架構是單體架構，即將應用程序的所有功能打包成一個應用，每個應用是最小的交付和部署單元，應用部署后運行在統一進程中[7].單體架構的應用具有易于測試、部署的優點.但是，隨著互聯網的發展及企業應用的擴展，單體架構的應用也表現出代碼包龐雜、難于維護、升級擴展困難等固有的缺陷.微服務架構應運而生.
微服務一詞來源于計算機科學家Fowler[8]的一篇著名的博文，是一種軟件設計風格[8].微服務架構是目前軟件開發界的一個熱門話題.所謂微服務架構，就是將整個系統分解成互相獨立的功能模塊單元，每個功能模塊單元作為一個獨立的應用提供服務，專注于具體的業務功能，獨立存儲數據，按照業務功能模塊開發、測試及部署，系統的各個服務之間通過HTTP API協議關聯起來，組成完整的應用系統，服務之間的通信協議通常采用RESTful API[9].
相對于單體架構應用，基于微服務架構的分布式應用具備以下特點：
1） 復雜度可控.微服務架構通過將龐大復雜的整體應用分解成一組服務，每一個微服務只提供單一的功能，通過定義良好的接口清晰描述服務的邊界，使復雜的功能通過模塊化的方式呈現出來，整體上降低了系統的復雜度[10].微服務架構模式加強了一定程度的模塊化.由于每一個服務體積小、復雜度低，降低了開發、維護的難度，提高了開發效率.
2） 靈活可擴展.每一個微服務功能相對比較單一，微服務架構模式使得每個服務可以獨立擴展，進行單獨的功能增減，使得整體變得非常靈活，有效降低風險.
3） 獨立部署.系統的每一個微服務具備獨立的運行進程，所以每個微服務可以獨立部署.使用相同的部署環境可以實現批量快速部署微服務.
4） 故障隔離.當某一組應用功能發生故障時，在單一進程的傳統架構下，故障很有可能在進程內擴展，導致整個應用的運行故障.在微服務架構下，故障會被隔離在單個服務中，通過良好的設計，其他服務可通過退化等機制實現應用層面的容錯.
因輔助決策系統首先是一個分布式應用，故在系統設計過程中，需要考慮以下內容：
1）系統包含有多種來源數據的集成，且在后期應用的過程中還可能會集成更多種類的數據;
2）系統集成多個不同的功能單元，接入不同的模型，需要與多個不同的第三方應用進行對接;
3）當出現達到預警模式要求的要素時，系統要能夠超越氣象災害預警常規處理流程，如審核、簽發、復核等操作，由系統根據實時監測數據自動進行判定，并生成對應的預警信息，進行發布;
4）系統支持決策指令的實時發布;
5）系統需要與眾多如移動端APP、微信公眾號、微博等新媒體進行交互;
6）系統需要做到全天候24 h不間斷監測、運行等因素.
因此，本系統在設計開發時需要采用當前比較流行的適用于分布式開發部署的可擴展軟件架構，以做到快速開發部署，減少成本、降低風險.根據采用的平臺，本文選用了目前企業Web應用開發中的微服務架構進行系統的設計與開發.
1.3 微服務架構的不足及應對措施
采用微服務架構進行分布式應用系統設計開發，可以解決單體系統變得龐大之后產生的難以維護等許多問題，但同樣因為功能模塊拆分成微服務，也會引發許多原本在單體應用中沒有的問題和缺陷.這些問題及缺陷應對措施包括：
1） 服務的邊界問題.在應用微服務架構進行系統分解的過程中，容易出現服務之間的邊界無法很好界定的情況，造成分解后的微服務過大或者過小.單個微服務過大，會出現如同單體架構系統類似的缺陷，單個微服務過小，則導致管理大量服務的難題.因此，在進行系統設計時，需要對系統的功能、模塊進行細致分析，找出最合理的邊界，做到耦合度最小，同時滿足功能需求.
2） 應用的復雜性.分布式應用相對于單體架構應用來說具有固有的復雜性，需要處理RPC或者進程間消息傳遞時的通信機制，特別是當消息傳遞過程中出現速度過慢或者不可用等局部失效的問題時，分布式應用的處理復雜性更高.在基于微服務架構的分布式應用中，只有充分考慮到網絡延遲、容錯、消息序列化、異步、版本控制、負載均衡等[11]對每一個微服務的影響，采取一套完整的策略和機制才能保證各個服務能夠正常運行.
3） 分區的數據庫架構.在基于微服務架構的分布式應用中，一個微服務通常對應一個數據庫.在復雜的應用系統中，同時更新多個業務主題的事務非常普遍，因此在微服務架構應用中，需要同步更新不同服務所使用的不同的數據庫，才能夠時刻確保不同的數據庫系統中數據的一致性.
在系統設計中，有一個CAP原則.根據CAP原則，在一個較為復雜的分布式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性）三者需要彼此權衡，不可能同時得到滿足，最多只能保證其中的兩個方面.因此，需要為每個服務調用做不同的權衡，以解決微服務架構應用中的分布式數據庫問題.
4） 部署的復雜性.相對于單體式架構應用，基于微服務架構的分布式應用有較多的微服務組成，而且這些微服務均實例化，作為獨立進程運行，這就需要整個應用有較多的配置、部署、監控功能，再考慮到系統運行的可靠性及穩定性，需要有一定的冗余設計，通常采用集群化的部署方案.這使得系統的部署及維護的復雜性大大提高.
2 基于微服務架構的突發事件預警輔助決策系統設計
2.1 微服務框架選擇
微服務框架有很多，不同的平臺有不同的適用框架.JAVA平臺比較著名的微服務框架有Dubbo和Spring Cloud框架.經過對比及建設實際要求，選擇Spring Cloud作為系統開發的微服務應用框架.Spring Cloud使用Spring作為容器框架，SpringMVC作為模型控制器框架.相較于其他的微服務框架，Spring是真正的微服務框架，它提供了完整的組件支持，支持跨語言實現，使用簡單方便且有強大的社區支持，支持自定義組件，是一套完整的分布式系統實現解決方案.
Spring Cloud[11-12]是一個基于Spring Boot的云服務的分布式框架集合，核心功能包括分布式/版本化配置、服務注冊和發現、路由、服務和服務之間的調用、負載均衡、斷路器、分布式消息傳遞等.它實現了從網關服務到服務發現，再到熔斷機制等一系列流程，涵蓋了實現分布式系統所需的基礎軟件組件.其組件架構如圖2所示.
Spring Cloud基于Spring Boot，通過在代碼中添加依賴和使用注解功能，使得系統的開發和部署變得簡單.
2.2 系統微服務設計
根據系統設計，系統分為基礎公共模塊和業務處理模塊.基礎公共模塊中包括對引用的各類第三方組件的封裝、系統設計的各類公共組件模塊等;業務處理模塊包括進行業務處理所需要的處理、分析、模型等模塊.根據前述的微服務架構，以及項目建設實際情況，系統將各功能模塊設計為微服務，并將其分為兩類：基礎微服務和業務定制微服務.基礎微服務提供基礎功能，業務定制微服務根據功能設計實現各定制的業務功能.系統功能模塊分類及相應的微服務設計如表1所示.
各微服務設計成獨立運行的程序，可以部署在不同的服務器上.通過定義良好的服務接口，使用服務所提供的功能.
2.3 系統的微服務總體架構設計
預警信息發布輔助決策系統由Spring Cloud提供的基本組件和構建的業務微服務組成.通過使用Zuul組件開發自己的注冊服務，實現服務注冊，統一提供REST API，使用Ribbon實現負載均衡[13].通過開發API網關，實現服務注冊中心，并通過Eureka實現服務注冊和服務發現.針對構建的業務微服務，注冊到開發的注冊服務中，并通過Eureka實現向外訂閱，提供微服務的具體功能.各微服務對應著獨立的業務數據庫.各庫之間的數據有部分冗余.微服務應用架構設計如圖3所示.
2.4 系統實現
2.4.1 動態信息接入
系統基于GIS地圖，以各圖層疊加的方式展示接入的各行業數據，包括靜態數據、動態實時監測數據、歷史數據等.靜態數據包括監測點、災害風險點、應急資源場所、應急物資存放信息等;動態數據包括氣象部門的監測、預報數據，水利行業的水庫、湖泊、河流水文監測數據，國土行業的災害點實時監測數據，海事部門的船舶實時監測數據，其他部門的視頻監控圖像信息等;歷史數據主要包括監測點（或監測區域）歷史上發生的災害情況數據等.這些數據通過數據擁有部門提供的接口接入到本系統中，并基于一張圖，根據決策者需要分類有條件進行展示，同時根據致災預警模型，對數據進行加工、融合處理后得出預測結果，并有針對性地生成各類預警信息.
針對發布的預警信息，系統實時在圖上的對應區域進行高亮提醒，并使用相應的預警圖標在預警區域進行標明，動態展現預警情況，如圖4所示.
2.4.2 致災預警模型接入
發布預警信息是一件嚴肅的事情，事關人民群眾生產生活、防災減災，要有科學性、權威性、實時性.預警信息的缺發、濫發、錯發都會導致嚴重的后果，故發布前需要仔細斟酌發布的內容、范圍、等級、受眾、時間等因素[3].本系統在發布流程上設計了多流程節點進行確認，在預警信息要素的獲取上通過采用相應的科學模型進行計算，輔助生成預警信息內容.系統根據實際，引入或接入了多種模型，例如：暴雨洪水水淹模型接入.系統采用了目前研究、使用較多的二維水動力演進模型Flood Area[14]，計算指定區域內淹沒范圍.國內很多研究人員，如文獻[15-17]使用該模型進行了暴雨洪水、淹沒區域模擬，證明該模型用以界定洪水淹沒范圍并預警洪澇風險的精度較高.
Flood Area模型的計算基于水動力方法，同時考慮當前柵格周圍8個鄰域單元，對鄰域單元的泄入量使用Manning-Stricker公式[14]進行計算：
式中：kst是反映地表粗糙情況對水流影響的系數，稱之為Stricker系數，根據土地利用數據轉換得到，系統中將使用到的類型建立表格，通過查表得到;rhy是水力半徑;I為地形（或明渠）的坡度.
水流的淹沒深度為淹沒水位高程與地面高程之間的差值，淹沒過程中的水流方向則由地形的坡向所決定[17].對地面上的任意一點，其坡向表征了該點高程值變化最大的方向，其計算公式[14]為
Flood Area模型有3種基本的淹沒情景：漫頂式、潰口式以及暴雨式.本系統由用戶根據實際使用場景選擇適合的淹沒情景.
系統獲取指定區域及周圍臨近各站點的實時降雨量預測預報數據及觀測數據，采用泰森多邊形面積權重法計算小時面雨量，然后根據該區域DEM分布，確定不同的地形類型，采用不同的Flood Area模型計算參數，分別計算致災雨量、洪水淹沒區、警戒區，并將計算結果在GIS地圖上進行三維疊加模擬顯示.同時，系統根據計算得到的致災雨量數據進行判斷并自動進行預警.在雨量達到設定的閾值時，根據計算所得到的淹沒區域、警戒區域信息，提取該區域內的學校、村莊等各類場所信息及應急資源等要素，獲取各應急責任人、區域內的各種預警信息發布渠道等，自動將其作為靶向發布的受眾，提醒發布預警信息和應急指令，為防災、減災提前做好應對措施，給決策者或者系統使用者進行決策提供相應的輔助，并根據預案信息實現決策聯動.
其他主要接入模型包括污染物擴散模型、城市內澇模型、地質災害預警模型等，均采用微服務架構集合各種外部門數據和災害公式模型做上述引用處理疊加呈現在GIS系統中.
2.4.3 發布渠道接入
輔助決策系統對于各部門、行業已建的各類發布渠道，如大喇叭、LED、短信、12121語音外呼、FTP、傳真、微信公眾號、微博、APP等，可以通過接口實現接入，并通過Web Service回調機制實現狀態監測，通過TCP/IP的連接狀態實現心跳監測，并通過表格或圖形化模式直觀顯示各接入渠道管理平臺中所管理的發布渠道的實時連接狀態.
在輔助決策系統中，如果監測的要素中遇到有超限情況，或者有比較緊急的預警信息或通知消息、決策指令，可以通過系統中的模型直接生成預警信號或通知消息，通過靶向發布方式或者指定受眾發布的形式進行發布.若是有影響較大、涉及面較廣的預警信號，需要通過嚴格的發布流程進行處理，則可直接轉到預警信息發布界面，通過錄入、審核、簽發等規定的發布流程進行處理.
2.4.4 應急支持輔助
系統設計實現了在突發事件已經發生情況下的應急輔助支持.系統可以通過決策聯動、預案指令、靶向發布等功能或技術，執行視頻會商及會商紀要記錄，啟動應急預案進行突發事件處置，通過靶向發布技術對預警信息精準發布，通過APP上報事件處置情況及災害詳情供決策者了解現場現狀等.輔助支持詳情信息可在一張圖上實時疊加展示，如圖5所示.
2.4.5 災害四維復盤
針對已經發生的災害情況，需要做好災害事件發生過程中各要素過程的詳盡記錄，事后可以進行災害發生過程、處置過程的復盤查看，為今后同類事件的處置提供借鑒.
災害四維復盤以事件進展的時間先后順序，以二維/三維GIS為基礎畫面，綜合展示各種觀測數據、評估分析、聯動情況，及各關鍵人員的行動軌跡，直觀顯示突發事件的演變、處置情況.
3 基于微服務架構的系統開發核心流程處理示例
突發事件預警輔助決策系統采用IntelliJIDEA開發平臺，Maven項目管理和綜合工具進行系統構建.
在基于Maven的系統開發中使用微服務，其流程如圖6所示[14].
3.1 搭建（定義）服務注冊中心
1）使用IntelliJIDEA，創建新應用項目Service-Registry，把該項目作為注冊中心的服務.創建完成后先在配置管理文件，例如以下定義項目配置文件pom.xml，在其中配置必需的依賴：
2）實現注冊應用類ServiceRegistryApplication
例如在代碼ServiceRegistryApplication.java文件中類聲明的前面，添加注解，通過@EnableEurekaServer注解啟動一個服務注冊中心，提供給其他應用進行對話.
@EnableEurekaServer
public class ServiceRegistryApplication {
public static void main（String[]args） {
SpringApplication.run（ServiceRegistryApplication.class，args）;
}
}
3）配置訪問路徑及相關參數
例如定義application.yml配置文件，參數可如下進行：
#應用（服務名稱）：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微服務為例介紹微服務的創建及注冊流程.
1）創建新應用模塊，例如定義為user-service，并在pom.xml配置對Eureka的依賴.
配置情況如下：
2）創建微服務啟動類UserServiceApplication，并在該類中實現設計好的相應功能.
@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實現，實現對該服務中的相應服務信息的輸出.
3）在application.yml或者application.porperties文件中配置用戶的訪問參數，通過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，服務注冊中心可以發現該服務，并在服務列表中列出該服務的信息.通過在瀏覽器輸入http：∥localhost：8761，即可打開Eureka信息面板，查看已有注冊的微服務.
3.3 微服務發現和路由
經過注冊后的微服務可以作為服務提供者為服務消費者提供相應服務.該步驟通過服務發現實現.在實際的實現過程中，為有效降低維護路由規則與服務實例表的難度，解決微服務接口訪問時的前置校驗冗余，通常使用API網關服務，將所有的外部客戶端訪問通過它進行調度和過濾.因此在本系統中，實現了API網關功能.
1）創建API網關服務api-gateway，也在pom.xml配置相關依賴：
API網關服務基于NexflixZuul實現.在配置文件中需要引入相應的對spring-cloud-starter-auul的依賴.例如：
2）創建應用主類，并使用@EnableZuulProxy注解開啟Zuul的API網關服務功能：
@SpringBootApplication
∥開啟Zuul的API網關服務功能
@EnableZuulProxy
∥該應用是一個Eureka客戶端應用.該注解表明該應用自動具備了發現服務的能力.
@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網關服務運行時提供服務的端口
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中注冊的微服務可以向整個系統提供該微服務所具備的功能，即實現服務消費.
1）創建一個使用User-service服務的Spring Boot基礎工程uaa-service，在pom.xml中引入相應的依賴.
配置例如：
……
2）創建應用的入口類.在入口類的實現文件中通過使用@EnableDiscoveryClient注解讓該應用注冊為Eureka的客戶端應用，以獲得服務發現能力.
@SpringBootApplication
@MapperScan（"com.uaa.service.mapper"）
∥通過使用@EnableDiscoveryClient注解讓該應用注冊為Eureka的客戶端應用，以獲得服務發現能力.
@EnableDiscoveryClient
@ServletComponentScan（"com.uaa.service"）
public class UaaServiceApplication extends WebMvcConfigurerAdapter {
public static void main（String[]args） {
SpringApplication.run（UaaServiceApplication.class，args）;
}
}
3）創建Controller類接口并實現接口：
@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服務注冊中心的位置，同時設置該服務消費者的端口.
經過上述步驟，可以通過向http：∥localhost：port/uaa-service發起GET請求，實現對服務中相關功能的調用.
3.5 系統應用場景案例模擬
本文選取系統中的監測數據超限時自動發送通知消息功能和災害四維復盤模塊進行系統的應用模擬.
3.5.1 站點監測數據超限自動發送通知消息模擬
系統定時從接入的監測站點獲取實時的監測數據，然后與設定監控的站點的閾值進行比對，當是實測值超過閾值引發告警提示時，系統后臺自動通過設定渠道發布告警提示信息.發布的告警提示信息可在發布管理平臺中查看，如圖7所示.
3.5.2 災害四維復盤模擬
系統假設某一區域可能會發生一次災害，根據業務處理流程，模擬該次災害發生前后的數據收集融合處理情況、應急處置情況等，事后進行復盤展示，為以后處置該類事件提供參考.
圖8展示了復盤處置過程中的3個顯示界面.首先收集各站點監測數據、氣象部門的預測預報數據，并進行數據融合處理，根據設定的閾值、模型進行判斷處理.當超閾值時，圖8在可能發生災害區域進行信息提示，并將可能的災害落區繪制顯示.
系統根據落區情況，統計出該落區的相關要素，并檢索與該落區相關的應急處置預案，根據預案生成相應的處置指令，執行靶向發布操作.同時，系統接收相應的APP用戶上報的災情信息進行顯示.
4 結束語及討論
基于Spring Cloud架構的微服務框架已經在湖北省突發事件預警輔助決策系統中得以應用，系統實現了融合多部門數據的災害預警發布、應急指揮“一張圖”，驗證了微服務架構用于復雜的輔助決策的可行性與實用性，減小了系統各功能模塊間的耦合度，更有利于應用系統的擴充和完善，與采用傳統單體架構應用的開發過程相比較，降低了開發的難度，與外省同類系統相比提高了系統運行效率，也更便于發布渠道等擴展系統的對接.
本系統今后的重點研究方向是，隨著接入更多的實時數據，通過開發新的微服務，以接入更多的預測預警模型，并將大數據分析技術更好地應用于各類災害模型，使之不斷完善，同時利用已廣泛建設的視頻監控系統，借助成熟的圖像處理技術，使預測、預報更為精確，提升預警信息發布的及時性和覆蓋面，提高災情現場態勢監測能力，更好地服務于防災減災.
參考文獻References
[1] 鄭國光.加快推進預警信息發布系統建設 努力實現權威精準快速安全發布[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] 陳炳洪，曾沁，張毅，等.廣東省突發事件應急指揮決策輔助系統的建設[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] 黃成南，王文波，陳妍.肇慶市突發事件預警信息發布決策輔助系統的設計與應用[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] 周潔，許麗佳，林倩.面向輔助決策的突發事件預警信息發布系統研究：以北京市突發事件預警信息發布系統為例[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模式的突發事件時空平行演化方法研究與實現[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] 劉峰博，干葉婷，周峰.大數據技術在軌道交通應急輔助決策中的應用設計[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] 張晶，王琰潔，黃小鋒，等.一種微服務框架的實現[J].計算機系統應用，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] 張峰.微服務技術構建大規模web系統的研究[J].科技創新與應用，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] 鄭明釗，張建強.基于微服務的大平臺系統架構演進探討[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微服務實戰[M].北京：電子工業出版社，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] 苗茜，謝志清，曾燕，等.基于統計-FloodArea模型的平原水網區致災臨界雨量研究[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
