◆崔磊 冯宇星 石锋 赵瑞
气象信息决策支持系统微服务化改造及设计
◆崔磊1冯宇星1通讯作者石锋2赵瑞1
(1.国家预警信息发布中心 北京 100081;2.中国气象局减灾司公众处 北京 100081)
气象信息决策支持系统是服务于国办和应急管理部的决策业务系统,系统采用传统的Web服务架构开发,目前很难满足面向山洪地质灾害防治和应急管理需求的行业服务应用,不能支撑各行业领域定制服务功能,因此需要以“微服务”架构思想对系统进行功能升级改造,实现功能服务管理去中心化,系统部署独立化,功能实现接口化,能够灵活应对本地化和行业化需求。“微服务”是一种架构模式,属于分布式架构系统,具有跨语言、“易部署”等优点,但“微服务”在对传统系统应用改造中也有许多需要突破的难点。本文在对“微服务”架构技术体系研究的基础上,结合气象信息决策支持系统的架构及业务体系,给出了系统微服务化改造的设计方案。
微服务;分布式架构;气象信息决策支持系统;改造
2016年12月,国家发布《中共中央国务院关于推进防灾减灾救灾体制机制改革的意见》(以下简称“《意见》”)文件,《意见》中指出:目前的突出问题是灾害信息共享和防灾减灾救灾资源统筹不足;注重灾后救助向注重灾前预防转变,从应对单一灾种向综合减灾转变,从减少灾害损失向减轻灾害风险转变。因此,2017年在国家预警发布中心领导的指导下,建设国家突发事件预警信息发布系统—气象信息决策支持系统,为国家应急管理工作提供辅助支持。国家级气象信息决策支撑系统依托“公有云”资源建设,以预警信息和突发事件为主线,以汇集的各部门数据为基础,通过分析、挖掘气象和经济社会大数据与灾害事件间的相关关系,提供基于影响的预报预警信息,并实现可视化应用。
系统自2016年业务化运行以来,在密云火灾、贵州山体滑坡、台风利奇马等百余次重大突发事件中,为国务院应急办和应急管理部防灾救灾业务提供覆盖灾前、灾中、灾后的辅助决策支持服务,起到了很好的服务和应用效益。预报预警信息是自然资源、交通、电力、能源、森林火险等行业日常生产顺利开展的重要参考资料。
目前系统采用传统的Web服务架构开发,很难满足面向山洪地质灾害防治和应急管理需求的行业服务应用,不能支撑各行业领域定制服务功能,因此迫切需要解决系统可移植性差,需求变动成本高,不支持定制等方面的问题。
本文在研究“微服务”技术架构基础上,结合气象信息决策支持系统的业务需求、架构体系,设计了气象信息决策支持系统微服务化的改造方案,实现决策系统能够灵活应对本地化和行业化需求,为国家应急决策提供有力支撑。
国家级气象信息决策支撑系统采用传统的Web服务架构开发,架构自底向上分别建立了数据层、资源层、应用层、接口层和交互层。基于此架构,气象信息决策支持系统功能、数据不断丰富,研发了突发事件、气象产品、热点预警等各类服务产品。这样的平台架构虽然满足了业务需求,但是在各行业领域服务功能定制开发、“运维”过程中,存在很多问题,主要表现在以下方面:
(1)系统业务架构缺少统一规划,没有标准接口,无法通过功能组合的方式快速响应新需求。
(2)部分业务重叠,业务流程相似,存在重复工作,成果复用率低。
(3)功能模块耦合度高,代码开发周期长,系统部署耗时,可伸缩性和灵活性差等问题。
因此,为了更好运用国家级气象信息决策支撑系统现有成果,向各行业领域的气象信息决策支持扩展服务。迫切要求以“微服务”架构思想对系统进行功能升级改造,实现功能服务管理去中心化,系统部署独立化,功能实现接口化,能够灵活应对本地化和行业化需求。
自2014年始,微服务(Microservice)概念开始火爆,各大技术“峰会”均以“微服务”为主题展开讨论。“微服务”架构(Microservices Architecture,MSA)主要依赖领域驱动设计、敏捷方法论、持续交付、虚拟化和基础设施自动化、DevOps这些内容。“微服务”架构是把小的服务开发成单一应用的形式,运行在自己的进程中,并采用轻量级的机制进行通信,这些服务都围绕业务能力来构建,通过全自动部署工具来实现“独立部署”[1-3]。这些服务可以使用不同的编程语言和不同的数据存储技术,并保持最小化管理。因此,“微服务”架构有以下好处:
(1)每个“微服务”都相对较小:易于开发者理解;IDE反应更快,开发者更高效;Web容器启动更快,开发者更高效,并提升了部署速度。
(2)每个服务都可以独立部署,易于频繁部署新版本的服务。
(3)易于伸缩开发组织结构,提升故障隔离。
(4)每个服务可以单独开发和部署
通过对“微服务”技术路线的深入研究,对气象信息决策系统现有的功能模块进行升级改造,下文按照“微服务”的架构思想,设计了气象信息决策支持系统微服务化改造方案,并通过以下步骤实现。
以“微服务”架构思想对现有的功能模块进行升级改造,需要遵循以下规则[4-5]:
(1)开发规范:遵循国家预警信息发布中心集约化业务管理办法和开发规范,项目全部部署于集约化平台,能够提供可复用的数据、算法等接口服务。
(2)业务分解原则:按照领域驱动原则和单一职责原则,实现对所有业务的分解。
(3)部署原则:实现独立部署,每个“微服务”独立运行在各自的进程中,加快部署速度。
(4)轻量级通信:“微服务”间通信应采用轻量级的通信协议。
通过对气象信息决策支持系统中的数据业务进行梳理,确定目前系统数据服务包括四大类:预警信息服务、突发事件服务、气象信息服务和基础信息服务。预警信息服务包括获取所有生效预警服务、获取热门预警数据排行服务、获取31省及自治区预警数量排行服务等;突发事件服务包括获取突发事件详情数据服务、热点预警分析服务等;气象信息服务包括获取气温、降水、雷达图、云图、台风、“落区”数据等服务;基础信息服务包括获取船舶数据、交通拥堵数据、POI数据、河流水库水位数据、城市预报数据等服务。
将单体架构的应用拆分为“微服务”时,应考虑“微服务”的颗粒度问题。根据“微服务”单一职责原则,结合气象信息决策支持系统的业务场景及数据服务现状情况,将系统功能分为四个“微服务”工程,分别为:预警信息服务工程、突发事件工程、气象信息服务工程和基础信息服务工程,并对四个“微服务”工程进一步分解为45个“微服务”,并按照国家预警信息发布中心的开发规范,对45个“微服务”进行代码改造。基于“微服务”架构的技术,气象信息决策支持系统改造架构如下图1所示:
图1 气象信息决策支持系统微服务化改造架构图
“微服务”架构下,气象信息决策支持系统拆分成很多个独立运行的服务,这些微服务间通信采用轻量级的通信协议,采用REST服务进行通信,因此需要定义各种各样的服务接口[5]。具体来说,在基于Spring Cloud的“微服务”模式中,各个“微服务”会基于Spring MVC的Controller定义多个该微服务需要向外部发布的接口。我们采用Swagger工具进行“微服务”接口测试。Swagger是一款基于YAML、JSON语言的文档在线生成和代码自动生成的工具,通过Swagger-UI就可以完成对所有接口的测试。
采用持续集成的方式进行“微服务”工程部署,持续集成满足了“微服务”独立、进程隔离的特点[6],为“微服务”提供了开发、测试、构建、部署与运维一整套自动化流水线。系统部署时,考虑容灾备份,实现生产节点的双机备份和容灾,避免单点故障。
在深刻理解“微服务”技术架构的基础上,本文结合气象信息决策支持系统的数据流程和业务场景,研究设计了微服务化的升级改造方案,通过确定改造原则、梳理数据流程现状、确定业务分解方案、功能测试及部署五个步骤,实现对气象信息决策支持系统的微服务化,从而进一步实现系统功能能够灵活应对本地化和行业化需求。
[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).