氣象信息決策支持系統微服務化改造及設計

◆崔磊 馮宇星 石鋒 趙瑞

氣象信息決策支持系統微服務化改造及設計

◆崔磊1馮宇星1通訊作者石鋒2趙瑞1

（1.國家預警信息發布中心 北京 100081；2.中國氣象局減災司公眾處 北京 100081）

氣象信息決策支持系統是服務于國辦和應急管理部的決策業務系統，系統采用傳統的Web服務架構開發，目前很難滿足面向山洪地質災害防治和應急管理需求的行業服務應用，不能支撐各行業領域定制服務功能，因此需要以“微服務”架構思想對系統進行功能升級改造，實現功能服務管理去中心化，系統部署獨立化，功能實現接口化，能夠靈活應對本地化和行業化需求。“微服務”是一種架構模式，屬于分布式架構系統，具有跨語言、“易部署”等優點，但“微服務”在對傳統系統應用改造中也有許多需要突破的難點。本文在對“微服務”架構技術體系研究的基礎上，結合氣象信息決策支持系統的架構及業務體系，給出了系統微服務化改造的設計方案。

微服務；分布式架構；氣象信息決策支持系統；改造

2016年12月，國家發布《中共中央國務院關于推進防災減災救災體制機制改革的意見》（以下簡稱“《意見》”）文件，《意見》中指出：目前的突出問題是災害信息共享和防災減災救災資源統籌不足；注重災后救助向注重災前預防轉變，從應對單一災種向綜合減災轉變，從減少災害損失向減輕災害風險轉變。因此，2017年在國家預警發布中心領導的指導下，建設國家突發事件預警信息發布系統—氣象信息決策支持系統，為國家應急管理工作提供輔助支持。國家級氣象信息決策支撐系統依托“公有云”資源建設，以預警信息和突發事件為主線，以匯集的各部門數據為基礎，通過分析、挖掘氣象和經濟社會大數據與災害事件間的相關關系，提供基于影響的預報預警信息，并實現可視化應用。

系統自2016年業務化運行以來，在密云火災、貴州山體滑坡、臺風利奇馬等百余次重大突發事件中，為國務院應急辦和應急管理部防災救災業務提供覆蓋災前、災中、災后的輔助決策支持服務，起到了很好的服務和應用效益。預報預警信息是自然資源、交通、電力、能源、森林火險等行業日常生產順利開展的重要參考資料。

目前系統采用傳統的Web服務架構開發，很難滿足面向山洪地質災害防治和應急管理需求的行業服務應用，不能支撐各行業領域定制服務功能，因此迫切需要解決系統可移植性差，需求變動成本高，不支持定制等方面的問題。

本文在研究“微服務”技術架構基礎上，結合氣象信息決策支持系統的業務需求、架構體系，設計了氣象信息決策支持系統微服務化的改造方案，實現決策系統能夠靈活應對本地化和行業化需求，為國家應急決策提供有力支撐。

1 氣象信息決策支持系統現狀

國家級氣象信息決策支撐系統采用傳統的Web服務架構開發，架構自底向上分別建立了數據層、資源層、應用層、接口層和交互層。基于此架構，氣象信息決策支持系統功能、數據不斷豐富，研發了突發事件、氣象產品、熱點預警等各類服務產品。這樣的平臺架構雖然滿足了業務需求，但是在各行業領域服務功能定制開發、“運維”過程中，存在很多問題，主要表現在以下方面：

（1）系統業務架構缺少統一規劃，沒有標準接口，無法通過功能組合的方式快速響應新需求。

（2）部分業務重疊，業務流程相似，存在重復工作，成果復用率低。

（3）功能模塊耦合度高，代碼開發周期長，系統部署耗時，可伸縮性和靈活性差等問題。

因此，為了更好運用國家級氣象信息決策支撐系統現有成果，向各行業領域的氣象信息決策支持擴展服務。迫切要求以“微服務”架構思想對系統進行功能升級改造，實現功能服務管理去中心化，系統部署獨立化，功能實現接口化，能夠靈活應對本地化和行業化需求。

2 “微服務”架構

自2014年始，微服務（Microservice）概念開始火爆，各大技術“峰會”均以“微服務”為主題展開討論。“微服務”架構（Microservices Architecture，MSA）主要依賴領域驅動設計、敏捷方法論、持續交付、虛擬化和基礎設施自動化、DevOps這些內容。“微服務”架構是把小的服務開發成單一應用的形式，運行在自己的進程中，并采用輕量級的機制進行通信，這些服務都圍繞業務能力來構建，通過全自動部署工具來實現“獨立部署”[1-3]。這些服務可以使用不同的編程語言和不同的數據存儲技術，并保持最小化管理。因此，“微服務”架構有以下好處：

（1）每個“微服務”都相對較小：易于開發者理解；IDE反應更快，開發者更高效；Web容器啟動更快，開發者更高效，并提升了部署速度。

（2）每個服務都可以獨立部署，易于頻繁部署新版本的服務。

（3）易于伸縮開發組織結構，提升故障隔離。

（4）每個服務可以單獨開發和部署

3 微服務化改造及設計

通過對“微服務”技術路線的深入研究，對氣象信息決策系統現有的功能模塊進行升級改造，下文按照“微服務”的架構思想，設計了氣象信息決策支持系統微服務化改造方案，并通過以下步驟實現。

3.1 確定改造原則

以“微服務”架構思想對現有的功能模塊進行升級改造，需要遵循以下規則[4-5]：

（1）開發規范：遵循國家預警信息發布中心集約化業務管理辦法和開發規范，項目全部部署于集約化平臺，能夠提供可復用的數據、算法等接口服務。

（2）業務分解原則：按照領域驅動原則和單一職責原則，實現對所有業務的分解。

（3）部署原則：實現獨立部署，每個“微服務”獨立運行在各自的進程中，加快部署速度。

（4）輕量級通信：“微服務”間通信應采用輕量級的通信協議。

3.2 梳理數據服務現狀

通過對氣象信息決策支持系統中的數據業務進行梳理，確定目前系統數據服務包括四大類：預警信息服務、突發事件服務、氣象信息服務和基礎信息服務。預警信息服務包括獲取所有生效預警服務、獲取熱門預警數據排行服務、獲取31省及自治區預警數量排行服務等；突發事件服務包括獲取突發事件詳情數據服務、熱點預警分析服務等；氣象信息服務包括獲取氣溫、降水、雷達圖、云圖、臺風、“落區”數據等服務；基礎信息服務包括獲取船舶數據、交通擁堵數據、POI數據、河流水庫水位數據、城市預報數據等服務。

3.3 確定業務分解方案

將單體架構的應用拆分為“微服務”時，應考慮“微服務”的顆粒度問題。根據“微服務”單一職責原則，結合氣象信息決策支持系統的業務場景及數據服務現狀情況，將系統功能分為四個“微服務”工程，分別為：預警信息服務工程、突發事件工程、氣象信息服務工程和基礎信息服務工程，并對四個“微服務”工程進一步分解為45個“微服務”，并按照國家預警信息發布中心的開發規范，對45個“微服務”進行代碼改造。基于“微服務”架構的技術，氣象信息決策支持系統改造架構如下圖1所示：

圖1 氣象信息決策支持系統微服務化改造架構圖

3.4 “微服務”功能測試

“微服務”架構下，氣象信息決策支持系統拆分成很多個獨立運行的服務，這些微服務間通信采用輕量級的通信協議，采用REST服務進行通信，因此需要定義各種各樣的服務接口[5]。具體來說，在基于Spring Cloud的“微服務”模式中，各個“微服務”會基于Spring MVC的Controller定義多個該微服務需要向外部發布的接口。我們采用Swagger工具進行“微服務”接口測試。Swagger是一款基于YAML、JSON語言的文檔在線生成和代碼自動生成的工具，通過Swagger-UI就可以完成對所有接口的測試。

3.5 獨立部署

采用持續集成的方式進行“微服務”工程部署，持續集成滿足了“微服務”獨立、進程隔離的特點[6]，為“微服務”提供了開發、測試、構建、部署與運維一整套自動化流水線。系統部署時，考慮容災備份，實現生產節點的雙機備份和容災，避免單點故障。

4 結語

在深刻理解“微服務”技術架構的基礎上，本文結合氣象信息決策支持系統的數據流程和業務場景，研究設計了微服務化的升級改造方案，通過確定改造原則、梳理數據流程現狀、確定業務分解方案、功能測試及部署五個步驟，實現對氣象信息決策支持系統的微服務化，從而進一步實現系統功能能夠靈活應對本地化和行業化需求。

[1]Sam Newman. 微服務設計[M].北京：人民郵電出版社，2016：70-85.

[2]王磊.微服務架構與實踐[M].北京：電子工業出版社，2015：112-132.

[3]宋大為，侯婷婷，顧松敏，等.數據挖掘技術在電子商務領域的應用研究[J].科技創新與應用，2016（05）：87.

[4]尹紹捷.移動互聯網技術與電子商務[J].科技創新與應用，2015（30）.

[5]杜尊.基于微服務的互聯網金融平臺設計與實現[D].北京：北京交通大學，2018.

[6]張峰.微服務技術構建大規模web系統的研究[J].科技創新與應用，2017（22）.