0 引言

各种重大自然灾害往往可能造成大量的人员伤亡和巨大的经济损失，地震灾情信息的收集需要投入大量的人力、物力、财力，以获取第一手动态灾情信息，从而为灾后应急救援提供方案。目前，国内有关防灾减灾方面的统计数据尚不完善，灾难现场通常会面临复杂且高度动态的实时信息变化，以及政府、时间、社会和受害者之间的连锁反应。然而，现有的灾情收集方式仍存在不足，针对灾前灾情难以预估、灾后灾情获取缓慢且碎片化、灾情评估误差较大、决策支持不到位、灾情服务缺位等科学问题，本文通过开放式接口在最短的时间内对数字、文本、语音、图片及视频等灾情数据信息进行采集，可实现灾情数据全生命周期的动态管理，有利于相关部门组织快速有效的应急救援。

为了对公众涉灾信息数据进行统一处理并进行合理规划，本文设计多源异构灾情数据综合管理(MSHD)系统，该系统基于虚拟化管理技术，设计分布式计算和存储架构，实现灾情数据全生命周期的动态管理，为灾情影响范围、空间分布等决策支撑系统提供数据支持。为适应众多异源、异质、异构的数据请求，同时便于后期系统添加新模块，提出基于微服务架构的系统设计，并开发高效、智能、可控率高的数据管理平台，升级灾情指挥现场管理模式，完成智慧灾情系统的优化升级。

1 MSHD系统微服务架构设计 1.1 单体结构应用缺陷

目前，很多项目均基于传统单体式应用(刘劭，2018)，如图 1所示。例如，由Spring Boot(王永和等，2016)或由Maven自动生成项目开发，这些项目一般是以业务逻辑层为中心的六边形结构模式，同时提供数据库连接接口、管理消息的组件以及支持UI访问的Web模块适配器等。虽然其均以模块设计为出发点，但最终仍然被打包成单体式结构，当单体模块结构达到瓶颈期后，通常会将其复制成多个单体式应用，这样便构成一个“集群”，这些集群能够提供相同的服务，每个服务器为该集群节点，后期仍可通过增加节点解决负载问题，并由负载均衡服务器均匀分配每一个节点负载。MSHD系统在进行原型开发过程中曾采用单体的架构，这种单式应用会随着后期不断开发而变得越来越庞大且复杂，开发难度随之增大。无论后期增加多少个节点，集群效果均无法明显提升，随着应用的增大，启动将会随之减慢，从而导致敏捷性开发无法完成。而通过微服务(崔灿等，2021)架构的改进，加速了敏捷开发模式(Balalaie et al，2016)的推广和分布式系统的开发。

1.2 微服务结构应用的优势

微服务是一种架构模式，由Martin Fowler与James Lewis共同提出(开金宇，2016)。其提倡将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合、为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互协作(通常为基于HTTP协议的Restful API)(赵军等，2019)。每个服务均围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

微服务架构模式的思路不再是开发一个大的单体式应用(范峻彤，2018)，而是将其分解为小的互相连接的微服务应用(图 2)。一个微服务完成一个特定功能，每个单体式应用独立部署、维护以及扩展，每个子系统均可在WEB容器中独立运行，每个应用均为低耦合，从而使系统具有强大的扩展能力(徐康明，2018)，并且各模块之间可通过提供Restful API进行相互调用，减少对其他模块的影响(唐志涛等，2017)。

对于单体应用软件，虽然从逻辑层面上划分成多层，但是在运行层次上只有一个进程在运行程序。而微服务架构是将单体应用拆分成多个小的服务(王磊，2016)，每个服务能够独立开发、更新和部署，同时服务之间能够通过轻量级的协议进行协作。轻量级协议是指跟语言无关、平台无关的协议，例如Restful协议。每一个服务均能够被独立部署到类生产环境、生产环境或者其他定义的环境。

1.3 MSHD系统微服务架构

MSHD系统采用敏捷的开发模式(韩万江等，2017)，因此设计时应考虑易于变更、易于维护、易于技术更迭的架构模式。在整个系统设计的过程中，遵循以下设计原则(Bonér，2016)：

(1) 高内聚，低耦合。在对系统中的模块进行功能设计时，应保证模块内部的代码之间联系较强，并均与模块功能有关，同时模块之间数据和代码的联系尽量小。

(2) 框架整洁。根据项目需求选择合适的框架，并基于框架的架构对系统的架构进行设计。

(3) 架构与业务解耦。

(4) 基于业务驱动。每次迭代中，首先对新增的需求进行分析，根据需求编写测试用例，通过TDD(韩万江等，2019)的方式来管理项目的开发。

(5) 使用契约接口的逻辑服务。

(6) 复用性。组件复用是软件系统设计中必须遵守的原则，对可重用的组件进行统一包装，包括系统级的应用组件和应用级的服务组件。

(7) 安全可靠。选择安全可靠的软硬件运行平台，并在系统设计和实现过程中关注系统的安全控制和执行效率，提供相应的安全防护功能，保证系统具有较高的安全性和可靠性；安全性方面，需考虑系统的安全、数据管理的安全、网络安全；保证用户权限、数据安全和系统的稳定性。

(8) 单一职责。在面向对象设计部分采取单一职责原则，其核心思想为，一个类最好只做一件事。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因，从而最终提高系统的可修改性和可维护性(宋海云，2018)。

根据上述原则，采用微服务体系结构设计系统(罗贵木，2017)，将数据采集、数据编码、数据管理、数据输出等子模块按功能相似性精细划分，每一个子模块对特定资源进行对应操作。从开发角度来看，每一个模块均可交给不同的团队进行开发，可以根据团队开发习惯利用不同的模式进行开发，最后只需保证能提供API服务实现通信即可。该方案不仅使开发效率得到提升，且解决了后期维护和添加新模块时技术选型等一系列问题(图 3)。从部署角度来看，每个微服务均为独立部署，减小了部署时对其他模块的影响(孙秀玲，2018)。

2 MSHD系统模块设计

MSHD系统依据高内聚、低耦合、单一职责、复用性等设计原则，采用自上而下进行模块设计(洪华军等，2018)，系统的模块设计如图 4所示。

2.1 用户管理

用户管理模块主要用于对用户信息进行管理，包括用户权限管理，用户注册，用户登录，用户登出，用户注销以及用户信息修改。MSHD系统有数据操作员、系统管理员2种用户角色，根据其身份及作用的不同，通过用户名和密码验证用户身份，对不同权限用户提供不同的可访问的用户界面。

2.2 数据输入

MSHD系统为异源数据提供相应的输入接口，以便接入数据。这些数据包括业务报送数据、泛在感知数据、舆情感知数据和承载体基础数据等。数据涵盖了多种数据类型及多种格式数据文件，包括文本数据、多媒体数据。数据文件包括xml文件、json文件、csv文件、MySQL数据库、txt文件等，以便对数据输入提供接口支持和数据管理服务。

2.3 数据编码

针对公众涉灾信息异源、异质、异构数据的特点，提供一套完备的通用数据编码格式，即一体化编码。所谓的一体化编码就是将多种不同类型、不同数据格式的数据信息，按照既定的编码规则进行统一编码，不仅有利于信息系统的高效数据检索、业务操作和结果输出，还有利于数据的一致性维护，降低系统的运行成本。在编码过程中，需要注意编码的一致性、完整性、易用性，以便对多源灾情数据进行统一格式化管理。

2.4 数据管理

数据管理人员通过灾情数据管理模块对实时读取的灾情数据进行管理，包括灾情数据基本查询管理、灾情统计分析、运用GIS服务(丁晶晶等，2017)进行可视化等。

2.5 数据输出

数据管理人员收到灾情数据请求后，对请求进行处理，之后将所需灾情数据的编码及详细描述发送到指定的FTP文件服务器上。

2.6 数据备份

数据备份是基于数据生命周期的动态管理，需要定期将数据进行动态备份。依据数据的时效性进行数据存储，若当前时刻为t，设置合适的时间窗口T，则对(t-T+1)~t内的数据进行存储，并且随着时间的延续，实现新数据存储及旧数据淘汰，淘汰的数据存储在备份数据库。

3 MSHD系统实现

MSHD系统架构基于微服务的分布式技术，采用服务器集群、水平业务划分、应用分解等方式来解决系统性能问题和复杂业务问题(Aderaldo et al，2017)。系统总体架构如图 5所示，该系统根据资源及其功能模块，在业务层运用了8个微服务，微服务底层使用MyBatis作为数据持久化框架，运用开源数据库MySQL进行数据存储，并以FTP Server作为文件数据输入与输出的媒介。同时，将微服务分别在Eureka中心进行服务注册。考虑到系统的性能，本架构应用Redis非关系数据库，运用RabbitMQ消息中间件为系统提供可靠的消息传输。项目中每个子模块均包含能独立运行和部署的基础模块。

(1) 服务注册与发现(Erl，2017)。MSHD系统的所有微服务(包括服务提供者和服务消费者)均加入Eureka服务注册中心，这样服务间的调用变得简单，只需要使用注册在Eureka的应用名称便可进行服务的调用，如图 6所示。同时服务提供者在启动后，周期性(默认30s)向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间(默认90s)未收到客户端的心跳，则认为服务宕机，并注销该实例。系统在业务层运行了6个微服务，分别为用户管理、数据输入、一体化编码、数据管理、数据输出以及数据备份，然后运用基于Rest风格的API实现微服务之间的协调调用。

(2) Nginx反向代理和Zuul网关。Nginx反向代理服务器主要是为Zuul网关服务器集群提供一个负载均衡的功能，Zuul是Spring Cloud全家桶中的微服务API网关，所有从设备或网站提出的请求均会经过Zuul到达后端的微服务应用程序。作为一个边界性质的网关服务器，Zuul提供了动态路由、监控、弹性负载和安全功能，如图 7所示。MSHD系统首先将Zuul网关服务器注册到Eureka服务中心，则客户端可以根据微服务的“注册服务名称/其他路由信息”的方式实现数据输入、数据输出等微服务的调用。

(3) 缓存数据库。当项目中存在一些经常访问且不轻易修改的数据时，为了提高系统的性能，缓存数据库的应用就显得尤为必要。Redis数据库是可以支持每秒十几万次的读/写操作的key-value数据库，其性能远超数据库，并且还支持集群、分布式、主从同步等配置，支持一定的事务能力，保证了高并发的场景下数据的安全和一致性。本系统将用户信息、行政区划代码等数据存入Redis数据库。

(4) 存储数据库。MySQL作为当下最稳定的关系型数据库之一，在Web开发项目下广为使用。在本研究中，灾情数据本身就是一个大数据源，如人员伤亡、房屋破坏、生命线灾情等，系统需要不断地对其进行数据存储和修改，为确保数据的稳定性和事务的一致性，本文采用MySQL作为灾情数据存储库，同时将MongoDB数据库作为舆情感知的数据存储数据库。

(5) 消息中间件。在现实生活中，当地震发生时，相关单位的灾情数据报送工作会愈加频繁，并发量在短时间内会很大，这就会造成微服务的宕机或者数据库出现故障，消息中间件则可通过在网络环境中为应用系统提供同步或异步、可靠的消息传输来改善上述情况。本文运用Spring Cloud全家桶中的RabbitMQ作为消息队列协议的消息中间件，当用户需要获取灾情数据或者上报灾情数据时，会将请求信息写入消息队列中，并向用户反馈信息(Sill，2016)。

(6) 持久层设计。MyBatis作为一款持久层框架，支持自定义SQL、存储过程以及高级映射，其免除了几乎所有的JDBC代码以及设置参数和获取结果集的工作。MyBatis可以通过简单的XML或注解来配置，将接口和Java的POJOs映射成数据库中的记录。本系统运用MyBatis作为每个微服务的数据持久化框架。

(7) FTP文件服务器。本研究基于多源灾情数据，多源是指业务报送数据、泛在感知数据、舆情感知数据和承载体基础数据等，这些数据格式并不一致，如xml、json等文件格式。本系统采用FTP文件服务器的方式，将这些来源整理成不同的目录，用户将文件上传至FTP，系统通过FTP服务器读取并处理灾情数据。

(8) 用户界面。Web端主要运用Bootstrap前端框架实现。Bootstrap是目前最受欢迎的前端框架，其基于HTML、CSS、JAVASCRIPT，简洁灵活，使得Web开发更加快捷。同时，本研究运用前后端分离的开发思想，应用Jquery中的ajax()方法，通过HTTP请求加载远程数据。

(9) 部署。Docker容器(Stubbs et al，2015)具有提升开发效率、隔离应用、便于整合服务器以及快速部署等优点。本研究采用Docker容器部署技术，通过为每个微服务编写DockerFile文件构建镜像，由镜像创建应用容器。

本研究的灾情管理系统微服务集群结果如图 8所示，通过将每个功能模块组成独立的微服务应用程序，不需要像单体应用那样做任何细微的修改均需要将整个应用程序重新构建、重新部署，而只需对所属的微服务进行部署、局部修改，有利于持续集成和持续交付，提高了系统的灵活性；与单体应用不同，以微服务构建的灾情系统易于搭建微服务集群，如在本系统中，灾情信息存储微服务及一体化编码微服务使用频繁，相应地在不同主机或者不同端口按需搭建了微服务集群(Kakivaya et al，2018)，从而提高了系统的扩展性；同时，本系统采用消息队列对应用进行限流削峰，并加入了缓存数据库，为系统的高并发提供了解决方法。

4 MSHD系统原型展示

多源异构灾情数据综合管理系统平台如图 9所示。多源社会灾情数据通过接口输入到多源灾情数据管理服务系统平台，进行一体化编码；然后将编码后的数据输入虚拟化管理系统。数据来源包括业务报送数据、泛在感知数据、舆情感知数据和承载体基础数据等，将来可以扩展更多数据来源。该系统依据数据的时效性进行数据存储，并随着时间的延续，实现新数据存储、旧数据淘汰；最后，当外界发出数据请求时，从管理系统中获取目标数据，并通过接口发送给请求方，实现灾情数据统一管理和高效合理利用。

4.1 灾情数据获取

MSHD系统通过开放式接口对多源异构灾情数据进行实时读取并统一编码入库，图 10展示了MSHD系统针对业务报送数据、泛在感知数据、舆情感知数据和承载体基础数据等数据来源的数据接口读取设置，并可根据需要设置读取时间间隔；图 11展示了数据管理的周期；图 12和图 13展示了通过接口读取震情和灾情数据并编码入库的结果(其中ID列展示的是数据编码结果)。

4.2 灾情数据速报

MSHD系统对编码入库的震情和灾情数据通过地理信息系统、各种图表等形式进行展示，图 14展示了实时震情，图 15展示了关于人员伤亡的灾情统计情况，图 16展示了次生灾情统计情况，图 17展示了房屋灾情统计情况。

4.3 灾情数据管理

MSHD系统实现灾情数据全生命周期的动态管理，图 18展示了对灾情数据的管理，图 19展示了灾情数据的备份设置。

4.4 灾情智能预测

MSHD系统可对舆情、电力、电信、交通等信息感知并预测灾害损失，给出相关的舆情热力图以及对地震烈度(张方浩等，2016)的智能预测结果，图 20展示了舆情热力图，图 21展示了根据舆情预测的震情烈度。

4.5 灾情数据输出

MSHD系统可以根据对灾情数据的请求，将相应灾情数据输出给请求方，图 22展示了灾情数据发送请求，图 23展示了灾情数据发送处理。

5 结语

本文结合灾情数据管理存在的问题，提出一种基于微服务架构的多源异构灾情综合管理系统，并介绍了系统各模块组成和运用的技术。多源异构灾情数据服务管理系统可以将多源社会灾情数据通过接口输入到系统平台，经过一体化编码后再将数据输入到虚拟化管理系统，实现了灾情数据接口输入、灾情数据一体化编码入库、灾情数据的全周期性管理、多源感知灾情智能预报和数据请求输出管理等功能。目前MSHD系统已进入测试阶段，该系统架构在开发层面弥补了单体式应用的不足，使运行更加稳定，但其仍存在诸如Http请求耗时问题、微服务的多服务部署复杂性等问题，这将成为下一步研究的方向。同时，考虑到系统处理的是海量多源异构灾情数据，MySQL作为数据库可能无法应对数据持续增长带来的稳定性和数据可靠性等挑战，容易成为整个系统的瓶颈，今后将考虑MongoDB等作为主要数据库，以满足该业务场景的需要。