基于C/B/S的气象辅助决策系统设计与实现

邱忠洋　吴晶璐　刘文伟　陈宏波

摘要：综合分析了当前市级气象预报业务与气象服务工作的特点及存在的问题，针对预报产品制作过程中辅助决策参考资料来源不一、发布渠道多样、业务制作平台多变、预警信息传输滞后等问题，提出了C/B/S气象灾害预警辅助决策系统的解决方案。首先采用多线程C/S数据处理和B/S数据展示的混合模式对辅助决策数据源和具体的预报业务制作进行分析和分类。在系统的总体框架设计过程中，采用Oracle数据库存储服务、WebGIS技术、Leaflet.js插件、Mybatis框架。详细阐述了系统各项技术设计方案，并给出了混合模式下的具体设计方法。实际运行效果表明，该模式极大地提高了系统实时性、灵活性，预报业务服务的效率也得到了提高。

关键词：预警预报;辅助决策;C/B/S;WebGIS;leaflet;Mybatis框架

中图分类号：TP399;P45         文献标识码：A

文章编号：0439-8114（2020）05-0129-09

Abstract： Comprehensive analysis and summary of the current city-level forecasting business and meteorological service work characteristics and existing problems. In the process of forecasting product production， the problems of different sources of reference materials， various distribution channels， changeable business platform， and delay of early warning information transmission are discussed. A solution based on C/B/S meteorological disaster warning decision support system is proposed. First， it analyzes and classifies the auxiliary decision data source and the concrete forecast business production， and formulate mixed mode that use the multi thread C/S data processing and the B/S data display. In the overall framework of the system， the Oracle database storage service， the WebGIS technology， leaflet plugin， the Mybatis framework of the background service are used. The article elaborates on the technical design schemes of the system and gives the specific design method under the mixed mode. The actual operation results show that the model greatly improves the real-time and flexibility of the system， and the efficiency of forecasting business services has also been improved.

Key words： warning and forecasting; auxiliary decision-making; C/B/S; WebGIS; leaflet; Mybatis framework

2016年底中国气象局发布了《关于发展智慧气象的若干思考》一文，文章高度重视并关注“智慧气象”的战略研究，阐述了智慧气象的内涵和特征，提出了发展智慧气象的三大战略——气象大数据战略、互联网气象战略和气象平台战略，初步确立了2020年的发展目标和重点任务[1]。

结合当前业务现状，在中国气象系统，面向社会大众服务的基础大多集中在市、县级。市县级所需承担的工作除了气象预报的发布，还包括气象预警、气象服务产品、网络建设及维护等相关工作。随着气象服务的深入开展，服务范围逐渐扩大，预警预报及服务质量要求也越来越高[2]。作为市级气象部门，如何解决因社会发展带来的一系列问题，成了当务之急。研究提出建立预警辅助决策系统，旨在将气象多种监测平台集约化、多种制作渠道集中化、多种发布手段归一化，让预报制作智能化。以解放人力、方便业务为宗旨，建立健全的管理机制，契合预报业务流程，使业务规范化、制度化，增加可控性和可管理性，提高业务管理水平。这也响应了中国气象局智慧气象的战略号召。本系统在气象信息化标准体系框架内，围绕市级综合气象业务，强化具有地方特色的气候异常、灾害性天气、服务平台数据的监测预警，建设系統融合、功能突出、数据标准的综合辅助决策平台，实现一站式的数据采集、传输、存储、分析和展示，一键式的检验、发布和回执，满足观测、预报、服务等各项业务服务使用需求。有效促进业务一体化、功能集约化、岗位多责化的市级综合气象业务，全面实现气象业务现代化。

1  关键要点

1.1  系统业务架构设计

系统业务架构主要分为5个模块：数据集成子系统、监控子系统、资料库数据采集子系统、信息发布子系统、业务应用子系统[3]。数据集成子系统为数据资源采集库提供数据资源，数据采集库产生的产品库同时为业务应用展示平台及数据监控平台提供数据资源。业务应用子系统通过调用产品库资源利用天气分析工具做出预报决策，最终的预报结论通过多种渠道一键式发布至各大平台。流程见图1。

1.1.1  数据层  该模块主要任务在于统一数据源，将零散的数据资源整合到同一个平台，目前集中处理的数据源包括CIMISS、CMACAST、省局数据库、自建数据库及外部共享数据库等。

1.1.2  服务层  该模块主要是对来源多、种类繁杂的气象数据进行自动采集、处理、分批入库并提供相应的数据服务。采集的数据除了本地气象探测资料外，还包括雷达、卫星云图、闪电定位等多种类型数据。

1.1.3  监控子系统  主要对系统本身、要素数据超出阈值的情况及预警信号发布情况起到监控提醒的作用。

1.1.4  逻辑分析层  将实况、短临、数值预报、预报产品及相关统计信息集中展示，为决策提供辅助。预警提醒方面主要是对观测超阈值、预报不符逻辑、区域预警及组合策略预警进行自动监测提醒，最后由预报员做出相应的判断，发布预警或相关气象服务信息。

1.1.5  数据推送层  逻辑层分析出的预报信息将由管理员进行审核，签发后可将预报产品信息一键式推送至短信、微博、FTP、传真、网站、大喇叭、显示屏等。

1.2  气象数据

1.2.1  气象数据的特点  气象数据种类繁多，对数据的实时性要求高。按照类型可以分为常规和非常规观测资料。比如基本站资料（温度、湿度、气压、风速、风向）等属于常规天气资料，非常规特殊天气资料包括加密自动站、探空、雷达、风廓线雷达、卫星等。气象资料具有连续性，时序性极强，对于这些数据的采集都是按照时间顺序进行存储、计算、统计、整理和保存的。同时气象资料还具有一定的规律性，表现在资料的周期性强，无论是多年长系列，还是年内、季节内、月内等系列，都有一定的周期性[4]。该系统的建设需要容纳这些气象数据大、繁杂的特性，并为预报业务提供所要参考的各项数据资料，这也给数据处理系统研发带来了一定的难度。

1.2.2  辅助决策系统数据库  Oracle数据库，一个面向Internet计算的、支持关系对象型的、分布式的数据库产品，是一个高度集成的互联网应用平台，为企业数据存储提交高性能的数据管理系统[5，6]。

为统一对各种气象数据进行处理，提出基于Oracle建立辅助决策气象数据库。建立辅助决策数据库的目的有两个，一是存储，二是共享。数据库处理的对象包含多种气象数据，传统基本自动站的数据、加密站数据、卫星云图数据、雷达图数据、环保数据、阈值及预计数据。还包括业务相关的留痕管理数据、气象数据多种发布手段及受众群组数据等。这些数据内部之间存在着一定的联系。因此在对数据库设计时，需尽量让数据具备完整性和可拓展性，并且在数据结构的设计上需标准化，气象数据格式的标准化有利于数据的处理。部分结构如图2所示。

1.3  相关技术

1.3.1  Multi-Thread下的数据流  辅助决策系统在实施多种数据气象解析入库过程中，发现以单线程的形式实现数据处理有很多硬伤。一是单线程效率低下，单线程必须要将上一个任务处理完毕，才能开启下一个任务。而用线程同步机制，消息可以通过主线程的提醒调用，再通过线程互斥机制，合理分配资源，保证资源使用的惟一性[7，8]。二是数据处理不及时，气象数据种类繁多，业务中拥有海量的数据，单线程模式无法以最快的速度将气象数据分析展示在业务人员桌面上。比如有自动站报文、卫星雷达图片、模式产品数据、外界数据源等。基于上述的一系列原因，提出使用Multi-Thread方式处理数据，这样既可以将多类别的气象数据同步处理，又可以充分发挥服务器的CPU资源效率。同时为了提高软件的研发效率以及便于后期维护和扩展。在软件研发过程中，将系统的数据流划分为4个模块，包括数据源模块、数据处理模块、数据服务模块以及数据应用模块（图3），多线程的应用也植入其中。

1）数据源模块。该模块将多种气象要素数据源集中管理，统一到服务器上，以備处理。种类较多，包括基础信息、自动站数据、雷达数据、云图数据、预报数据等。

2）数据处理模块。该模块主要是将数据源模块集中的数据进行接收、整理、分类、预处理、质量控制及筛选，最后将无效数据剔除，有效数据入库。其每个流程处理过程都经过封装，耦合度低。在数据处理过程中，对海量数据进行研究，使用数据挖掘算法研究数据的相关性对数据进行多元化融合。

3）数据服务模块。该模块主要是为各种数据应用提供接口服务。实质是从数据库提取数据，为定制化的需求提供API支撑。为保障数据的安全性，设计了接口注册白名单，经过实际注册并通过验证的用户才可以使用该服务。

4）数据应用模块。该模块主要考虑对数据的展示，展示流程从数据的API接口获取开始，经过数据处理、解析，最后展示。从应用角度出发，系统设计的应用层面考虑到了数据的高度共享性，不仅可以为该系统应用提供数据服务，还可以为其他应用包括APP、Wetchat、局官网和其他业务网站提供服务。

目前系统基本完成了前期数据流模块研发的各项工作，并能够实现数据调用演示。但是如何对海量气象数据进行深度挖掘，以提高短时临近数据的准确性和稳定性，还有待进一步研究。

1.3.2  WebGIS及Arcgis server服务器  WebGIS，简而言之就是在Web上提供的GIS服务，被称之为网络地理信息系统，是传统GIS在网络上的延伸和发展，具备了传统GIS的检索、查询、制图输出、编辑等基本功能[9]。围绕着开放式服务、互动式操作、分布式计算、三维信息可视化等主题，WebGIS技术功能在未来将会进一步强化。结合系统的业务需求和WebGIS的功能，划分为以下6个方面。

1）具备空间发布能力。系统可以利用GIS技术通过Map方式图形化展示空间数据，技术人员可以及时获取气象信息做出决策。

2）地理信息检索游览功能。通过切图的方式将所需市县地图作为底图，除了地图缩放，还可以通过人机交互对地理空间属性数据库进行检索。

3）地图制作功能。操作人员可以通过Web輸入所需制图参数，服务器会将空间制图参数处理完毕后返回到Web。

4）数据更新能力。可以通过前段Web页面与后台服务器数据进行交互，包括对空间或属性数据的编辑修改。

5）空间决策分析。可以通过模型算法对实时数据进行计算分析，给出预测结论，并反馈给用户。

6）数据资源共享性能。将空间数据展示在浏览器上，可以不受时间地点显示访问数据。

Arcgis server，网络地理信息服务平台，用于构建WebGIS应用的软件开发平台。作为分布式系统可以在不同的环境下协同完成GIS工作，与系统选择B/S展示模式相匹配。同时Server具备与空间相关的定位、分析、处理的GIS技术及当前互联共享两大功能。在系统研发过程中，系统采用二次开发的方式集成使用Arcgis server，因此可以得到来自Server在GIS功能上的支持，控制图层隐藏和显示，地图的漫游缩放，框选查询，空间数据编辑查询、空间分析坐标转换、地图下载图层管理、高级GIS分析路径绘制等。基于上述优势，平台选择WebGIS结合Arcgis server作为地理信息互动展示研发的技术（图4）。

1.3.3  C/B/S混合模式WebGIS结构  混合使用WebGIS结构，一方面从C/S结构来讲，GIS任务被分给客户端和服务器，应用资源被合理分配。这种结构属于典型的胖瘦服务器模式，将数据交互、逻辑、计算、任务反馈集中在客户端，而服务器只需提供数据即可，任务较轻。第二方面则是从B/S结构来讲，将重心从客户端转向了浏览器，包括数据库服务器、客户浏览器、应用服务器（图5）。这种方式依赖服务器对大部分的业务逻辑进行处理，并通过TCP/IP进行消息之间的传递，前段的逻辑处理及展示则是通过Script、Plug-in插件实现。该系统结合C/S和B/S在WebGIS处理上的优势，制定系统所需的GIS服务策略。①GIS数据的处理使用C/S形式，全部放在后台服务器端，定时定期操作，避免浪费资源和时间。②GIS数据的展示以B/S形式放在浏览器端，直接从后台数据库提取数据演示，减轻前端的负载。

1.3.4  C/B/S 软件设计模式  根据对系统整体架构的分析，数据的处理和展示采用2种框架设计模式混合使用，即C/B/S模式，结合使用了C/S和B/S这两种模式[10]。

数据的处理采用了C/S模式（Client/Server）。在局域网内，对数据的保护较强，安全性能高。这种软件通过客户端、服务器、数据库三级模式，将多种气象数据的接收定位在服务器上，而业务逻辑的处理包括采集、解析、质控、入库放在客户端。这种开发方式合理分配了Client端和Server端的任务，降低系统的通讯开销。该模式下系统开发的灵活性、安全性、可拓展性能得到了保障，系统维护也比较方便。服务器与数据库进行交互，通过网间通信与客户端就可以进行互动。

数据的展示采用了B/S模式（Browser/Server），该模式用户页面通过浏览器实现，基于应用层http协议提供Web服务。辅助决策平台对数据的访问可以通过Post/Get方式向服务器发送请求，服务器则是通过API接口的方式响应请求、提供服务、反馈数据。这种模式可拓展性极强，通过增加网页即可添加服务器功能。同样是Browser、Web Server、db Server三层架构，业务逻辑同样被放置在服务器端，但这种http协议下的Request请求能够实现数据的全方位共享，不仅适用于辅助决策平台，还可以为其他业务平台提供接口共享支撑（图6）。

1.3.5  Mybaitis框架提供API服务  辅助决策系统对数据的调用和访问都有一定的要求，一是数据的精准度，二是调用数据的效率，三是能够满足多并发的数据获取条件。这样的后台数据处理要求急需一个具备简易存储过程、高级映射、通用SQL及高并发的持久性框架来满足。经过研究系统最终选择了Mybatis框架，除了能够满足上述功能外，通过XML和注解配置数据库原生信息，将接口和Java对象映射成数据库中的记录，满足基本数据调用需求，该模式可以让开发者把更多的精力放在业务SQL的编辑上，节省一定的开发成本。Mybatis功能框架主要分为三层[11]。

1）API接口层。负责为外部应用提供API接口服务，通过这些API可对数据库进行操作。向接口层发送带参数的Request请求，数据处理层将接收参数并完成数据处理。

2）数据处理层。负责将接收到的SQL及参数进行解析、执行、映射处理及反馈结果。返回的结果可以自行设定。它主要的目的是根据调用的请求完成一次数据库操作。

3）基础支撑层。负责基础功能支撑，包括数据库链接配置、映射管理、事务管理、配置加载和缓存处理。为上层数据处理提供最基础的支撑。

考虑到系统未来使用的可扩展性、高效性、兼容性、通用性，选择Mybatis作为系统开发的ORM框架。框架结构见图7。

1.3.6  WebGIS引入Leaflet.js插件技术  建立辅助决策系统，其目的是方便业务员在预警、预报、业务产品制作过程中能够实时查询到所要参考的气象资料。预报员做出决策的数据依据是当前气象部门的地面观测数据。如何直观、高效的展示这些数据成为系统设计的关键一环。

系统采用了基于Leaflet插件的WebGIS技术。Leaflet.js 解决了传统WebGIS矢量数据在浏览器中展示缺乏统一以及响应慢框架重的问题。Leaflet.js适用于移动端交互地图主要的开源JavaScript库，拥有大部门开发者所需的地图功能轻量级库。服务拥有数百个第三方插件扩展地图功能，基本能够满足该系统的开发研究。地图由官方机构提供，经过自ArcGIS编辑器切出所需要的地图底图，地图服务器采用ArcGIS server提供在线服务。GIS的应用不断普及，就该系统而言，结合Leaflet和WebGIS能够很好的满足气象要素直观高效演示的要求。

1.3.7  开发语言及相关环境  系统选择了J2EE开发环境，J2EE体系架构将表示逻辑、业务逻辑与数据逻辑相分离，使系统的并行操作、网络计算能力提高，系统的整体性能得以优化。

开发语言方面平台选择采用基于J2EE规范的Java语言，支持JDK1.6版本以上，后台采用流行的Spring Boot、Shrio、Redis数据缓存和Mybatis架构分层体系结构，前端采用Html5、Bootstrap、Jquery、Vue等页面制作技术和规范，构建安全、稳定、高效、简单实用的中心客户端应用[12]。

网络通信及数据传输方面采用http协议技术，数据传输采用加密方式，保障信息的安全通信。

与其他系统的对接采用安全规范的接口技术，数据格式采用JSON和XML，基于安全规范的制定统一控制接口，重要数据实现加密，支持异构系统、目录、FTP站点等手动或自动获取数据。

2  软件框架设计

2.1  混合模式下软件平台的设计

结合系统采用的框架模式特点及实际业务需求分析，系统主要有两大功能：①满足对气象数据的采集、分类、解析、挖掘、存储;②通过发布对数据的调用指令操作数据库，实现以API白名单服务方式抓取数据，安全、高效、共享性能高。优化整个气象系统数据传输的方式[13]。

2.1.1  C/S模式通信设计  系统中气象信息可以分为规则数据报和临时数据报信息。其中规则数据报文的周期是固定的，可以定时定量处理，而临时数据报的产生比较随机，需要特殊处理。

基于数据处理的稳定性，系统采用C/S架构模式处理数据。考虑数据处理并发量大的问题，系统选择了多线程模式。在C/S架构下采用了多线程的操作方式，将繁杂多样的气象数据解析融合入库归纳到各自的线程中。主要包括如下几类：①主线程。主要工作是启动程序，对报文预处理、设定定时器并启动读写线程等;②读写线程，在该线程中对文件进行数据文件读取、文件整理、文件分类、文件标注;③解析线程，将对分类后的报文数据截取字段，提取要素值，接着进行质量控制、数据分类、数据解析及数据融合;④入库线程，将分类的报文分级提取，执行操作，存储到数据库中，最后以日志的方式保存。所有操作完成之后将结果向主线程反馈。

经过长时间的数据积累，数据库模型逐渐完善，为接下来的数据访问提供了数据基础。流程如图8所示。

2.1.2  B/S模式通信設计  为满足业务员随时随地查询和浏览气象灾害数据。系统在展示端采用了B/S模式。

系统以Web形式存在，浏览器在打开时就已经对系统页面和相关接口进行了初始化。用户即远程客户端可以在UI上发送请求，查询所需参考的气象数据[14]。①初始化连接数据库，若连接不上则继续发送请求，请求三次反馈结果;②接口认证，访问数据时自带访问API的Key，拉取数据;③请求发送及反馈，前端访问通过线程页面发送请求，模式POST/GET。后台接收到请求后，立即调用Mybatis下的API查询数据库，反馈给前端;④前端的展示，后台传递的数据将经过解析与前端控件绑定，最后呈现给用户。在数据的请求反馈方面，可启动数据处理线程，将数据反馈给页面，也可以直接通过http协议与接口沟通，发送请求返回数据。第二种方式可以服务该系统以外的远程客户端应用。

B/S模式下的系统设计业务拓展简单，通过添加网页即可添加服务器功能，数据以接口的方式存在，其共享性能强大。

2.2  系统运行

系统在研发过程中，引入了当前较为成熟的Multi-thread技术、WebGIS技术、数据库技术等，这些技术的应用可以解决系统实施中的基本问题。但对插件式Leflet和混合架构设计技术的使用让系统的数据处理性能和GIS展示性能变得更加实用，响应速度变快。研究在辅助决策平台的研发工作中将各种技术融合取得了不错的进展。系统已形成原型，系统采用了Java语言、JavaScript技术、WebGIS技术及Mybatis框架提供API服务同步编程。同时结合Oracle数据库来存储数据。该系统兼容性能较好，可以部署在Windows或Linux服务器上。

实际运行效果表明该系统性能良好。如何进一步优化对海量气象数据处理以及挖掘数据中隐藏的规则，还需进一步研究和探索。系统展示如图9、图10所示。

3  小结

随着科技的发展和进步，信息传输速度需求加快、群众需求不断提高，老旧气象业务平台基本无法满足现代化气象业务发展需要，而省级平台研发也无法兼顾各市局本地化的需求。因此新平台的建设迫在眉睫。依托省局一体化平台提供的数据资源，结合CIMISS库，根据本市地方化业务需要出发，建立常州气象灾害预警辅助决策系统平台，简化值班人员工作环节，提高服务效果和预警效率，促进服务创新，使气象服务工作形成一种可持续发展的长效机制。系统提出一体化业务制作、一键式信息发布，集约化数据监测等理念，结合J2EE平台架构，多线程数据处理、WebGIS前端服务、Mybatis后台服务、Oracle分布式数据存储，跨平台部署，并能够支持第三方Leflet插件整合接入。最大效能地发挥了互联网技术在气象服务中的作用。

系统当前处于应用阶段，还有很多不足和需要改进的地方。后期除了解决系统本身的问题以外，还会花更多的时间和精力对海量气象数据进行深度挖掘，将人工智能机器学习带到气象领域，剖析累计多年的海量气象数据背后的规律和秘密。

参考文献：

[1] 郭树军，张洪广，周  勇.关于发展智慧气象的若干思考[J].气象知识，2018（2）：19-21.

[2] 孙石阳，邱宗旭，刘东华，等.智能专业气象信息融合与服务系统建设初步研究[A].第27届中国气象学会年会雷电防护科学与技术发展分会场论文集[C].北京：中国气象学会，2010.