寧夏智能化氣象信息綜合發布系統設計與實現

高國弘 緱曉輝

（1.中國氣象局旱區特色農業氣象災害監測預警與風險管理重點實驗室 寧夏回族自治區銀川市 750002）（2.寧夏氣象防災減災重點實驗室 寧夏回族自治區銀川市 750002)

1 引言

為向公眾、企業、政府等公共氣象服務用戶提供及時、豐富的服務，氣象部門充分利用信息傳播技術，先后建成了聲訊電話、傳真、郵件、網站、短信、大喇叭、電子屏、微博、微信、APP、小程序等多種氣象信息發布平臺。這些平臺各自獨立，造成了一定程度的資源浪費和重復建設。為實現發布平臺間信息共享、集約化發布，全國氣象部門相繼開展了“氣象信息一鍵式發布”技術方法研究。早在2012年鄭立軍等建設了浙江桐廬縣數字電視氣象預警全頻道一鍵式發布系統，2014年楊昱等開展了天津一鍵式氣象服務信息發布技術研究，張亞、王瑩、莫云音、林紅、王新秀等分別在安徽、廣東、海南、上海、遼寧等省市開展了氣象預警信息一鍵式、多渠道發布技術研究。寧夏于2014年建設了農村氣象預報預警信息一鍵式發布平臺，實現了鄉村大喇叭、顯示屏信息統一發布。這些一鍵式發布平臺，大都基于統一的平臺錄入信息并驅動所有接入的發布渠道發布信息的模式建立。

“以信息化驅動氣象現代化，建設智慧氣象”是氣象行業落實國家信息化發展戰略的重要舉措。為充分利用云計算、大數據、物聯網、移動互聯網和機器智能等現代信息技術，推進信息技術與氣象業務的深度融合，寧夏氣象局組織建設了“寧夏智能化綜合氣象業務服務共享管理平臺（Ningxia Intelligent Integrated Meteorological Service Sharing Management Platform,NXIIMSSMP）”。該平臺由基礎數據庫、業務產品庫、服務產品庫3 個數據庫，智能化天氣預報業務系統、智能化氣候業務系統、智能化農業氣象業務系統、智能化氣象信息業務系統、智能化氣象服務系統5個省級業務系統，1 個智能化氣象信息綜合發布系統，以及相應的氣象信息共享與管理系統組成。5 個省級業務系統，近20 個市縣級業務系統，均需利用各種發布渠道向各自的用戶發布信息，這就向屬于NXIIMSSMP 總出口的氣象信息發布系統，提出了多平臺對多發布渠道、多用戶群，自動發布氣象信息的新需求。再者，為充分利用各級氣象部門優勢資源，形成集約化技術合力，天氣預報、氣候預測、農業氣象、氣象信息等業務系統制作的產品大部分不事先指定服務對象，最終由各對外服務部門確定通過何種渠道發送給那些用戶。因此，要實現服務產品發布的智能化，從而實現NXIIMSSMP 系統的全流程智能化，就必須研究服務產品與服務對象、發布渠道的智能化匹配與分發技術。

2 系統功能設計

2.1 網絡拓撲

整個NXIIMSSMP 可以看作是一個分布式氣象服務產品制作與發布體系。依據NXIIMSSMP 總體設計，各省級智能化氣象業務系統與各市縣級綜合氣象服務系統制作的公共服務產品均存入“氣象服務產品庫”，該庫在存入產品時，利用三方消息件，向智能化氣象信息綜合發布系統（下簡稱“綜合發布系統”）推送產品入庫信息，綜合發布系統利用產品入庫信息，提取服務產品，并向各發布渠道轉發。為確保突發事件預警信息發送時效，綜合發布系統還為省級突發事件預警信息發布系統（下簡稱“省突系統”）開通“綠色通道”，即省突系統與綜合發布系統實現直連。因此，綜合發布系統有兩類氣象服務數據來源。以上各系統均處于氣象業務寬帶網（內網）。

短信、聲訊、傳真、郵件、大喇叭、顯示屏、微博、微信、FTP、服務云等需以推送方式接收信息的渠道，設計了Web API 渠道對接接口和發布結果回傳接口，由綜合發布系統調用各渠道信息發布接口，以主動推送方式發布信息，各渠道系統調用綜合發布系統結果回傳接口，實現結果數據的回傳；其他網站、APP、小程序及各行業氣象信息應用系統等需通過互聯網主動獲取信息的渠道，由綜合發布系統將信息推送至位于互聯網的氣象服務云，由服務云以API 接口方式提供各客戶端主動調取信息。因此服務云既是發布渠道之一，也可看作綜合發布系統的組成部分。綜合發布系統還需與“天鏡”省級氣象信息監控系統連接，向天鏡傳輸服務產品發送狀況等監控數據。綜合發布系統與產品制作、產品存儲、天鏡及發布渠道之間的位置關系見圖1。

圖1：智能化氣象信息綜合發布系統在氣象信息體系中所處位置

2.2 功能設計

綜合發布系統由產品管理、服務對象管理、渠道管理、系統管理、系統監控5 大模塊組成，其系統架構見圖2。產品管理模塊首先以兩個數據輸入接口分別與氣象服務產品庫、省突系統互聯。氣象服務產品庫在收到各業務系統存入的服務產品時，即以RabbitMQ 的生產者（Producer）方式向綜合發布系統推送產品，綜合發布系統以消息消費（Consumer）方式接收產品并落地暫存數據庫，同時利用KMP 算法將服務產品關鍵字與服務對象需求關鍵字進行匹配，匹配成功即通過為服務對象設定的發布渠道向該對象發布信息；產品管理模塊設置Web API 接口供省突系統以HTTP 協議訪問傳遞預警信息。服務對象管理模塊向省市縣三級系統操作員提供服務對象（用戶）管理能力，各級操作員可錄入本級收集的用戶，設定用戶所需產品、關注區域、發布單位、接收渠道等關鍵字，供產品管理模塊調取匹配。渠道管理模塊依據各發布渠道系統廠商提供的接口規范，研發不同的接口與之互聯發送信息。系統管理模塊提供系統操作員管理功能并為操作員分配不同的角色，為角色授予不同的權限；該模塊還負責同步服務產品庫中的發布單位、產品類型、地域信息數據到綜合發布系統，供產品管理模塊與服務對象管理模塊建立匹配關系；此外該模塊還負責管理系統“字典”表及其他系統參數設置調整工作。系統監控模塊監測產品接收、用戶匹配、各渠道發送成功率、用戶關注量等數據，同時生成日志或統計報表并通過本系統監控大屏或傳輸給“天鏡”系統展示。

圖2：智能化氣象信息綜合發布系統總體架構

3 關鍵技術

3.1 KMP算法

是一種改進的字符串匹配算法，由D.E.Knuth，J.H.Morris和V.R.Pratt 提出，人稱克努特—莫里斯—普拉特操作（簡稱KMP 算法）。KMP 算法的核心是利用匹配失敗后的信息，盡量減少模式串與主串的匹配次數以達到快速匹配的目的。該算法的用途廣泛，是正則表達式的基礎。本研究采用改進的KMP 模式匹配算法，優化服務產品與服務對象、發布渠道的匹配算法。

3.2 RabbitMQ

MQ 全稱為Message Queue，是一種分布式應用程序的通信方法，它是消費者（Consumer）-生產者（Producer）模型的一個典型的代表，Producer 往消息隊列中不斷寫入消息，而另一端Consumer 則可以讀取或者訂閱隊列中的消息。RabbitMQ 則是MQ 產品的典型代表，是一款基于AMQP（高級消息隊列協議）協議可復用的企業消息系統。業務上，可以實現服務提供者和消費者之間的數據解耦，提供高可用性的消息傳輸機制，在實際生產中應用相當廣泛。因前期已建成的氣象服務數據庫采用RabbitMQ 推送數據，本研究完成了以Consumer 消息消費方式接收數據的接口軟件開發。

3.3 Web API

API 應用程序編程接口（Application Programming Interface）是一些預先定義的函數，這些函數是由某個軟件開放給開發人員使用的，幫助開發者實現某種功能，開發人員無須訪問源碼、無須理解其內部工作機制細節，只需知道如何使用即可。Web API 則是基于HTTP 協議的網頁化API。本研究開發兩個Web API 分別供省突、天鏡系統與綜合發布系統對接；引用微博、微信、短信、大喇叭平臺提供的Web API 接口，向此類渠道發送信息并接收各渠道返回的用戶關注量、成功接收數、設備在線率等管理信息。

3.4 FTP/SFTP

FTP 文件傳輸協議（File Transfer Protocol）。SFTP 為安全文件傳送協議（Secure FTP），可以為傳輸文件提供一種安全的加密方法。SFTP 為SSH（安全外殼協議）的一部分，由于這種傳輸方式使用了加密/解密技術，所以傳輸效率比普通的FTP 要低得多，如果對網絡安全性要求更高時，可使用SFTP 代替FTP。綜合發布系統提供FTP、SFTP及被動、主動FTP 等模式選擇，以連接不同要求的發布渠道。其中大喇叭/顯示屏、傳真、聲訊、云網站等平臺采用FTP或SFTP 傳播文件類型產品，并提供一個專門的FTP 接口供渠道拓展。

3.5 系統運行與開發環境

綜合發布系統采用的服務器配置為至強2.4GHz 雙核CPU、32GB 內存、1TB 硬盤，Windows Server 2012 操作系統、Oracle 11g 數據庫管理系統、Tomcat 7.0 互聯網信息服務器；系統基于B/S 架構開發，開發語言為Java、JavaScript、Html5、CSS3。

4 核心軟件實現

4.1 產品格式標準

各種發布渠道所需的服務產品格式不盡相同，為制作、存儲、轉發等各環節都帶來了困難，因此需要首先設計一個綜合的服務產品標準格式，供NXIIMSSMP 各系統共同遵守，以標準化促進智能化、集約化。所制定格式的標準數據表見表1。

表1：氣象服務產品格式標準數據表

表1是數據交換時的基本字段，NXIIMSSMP 中各系統為了各自操作便利，可增加若干輔助字段。表中產品類型、影響區域、制作單位三個字段數據由氣象服務產品庫設定并管理，其他系統每日定時下載更新，以保持數據的統一。綜合發布系統引用此三個字段作為產品匹配關鍵字。依據發送渠道的不同，表中各字段及文件類型可選擇填寫。

4.2 服務對象管理

在綜合發布系統中建立服務對象管理子系統，用于管理氣象產品數據的接收對象，對象類型包括屬于個人或單位的決策氣象服務用戶、專業氣象服務用戶及面向公眾服務的大喇叭電子屏、微博賬號、微信公眾號、FTP 地址、云網站等三類。該子系統提供省市縣三級服務對象數據增、刪、改管理能力，以及相應的自上而下逐級管理能力，供各級氣象部門存放自己收集的服務對象基本信息、服務產品接收類型、方式、發布單位等信息。子系統的核心庫表——服務對象數據表見表2。

表2：服務對象數據表

發布系統引用其中的關注區域、所需產品、發布單位三個關鍵字段用于與服務產品匹配，引用接收渠道關鍵字段向發布渠道系統推送產品信息。

4.3 產品發送原則

引用表1產品格式標準，根據匹配到的服務對象接收渠道不同，發送內容有所區別，因此制定產品發送原則見表3。

表3：各渠道服務產品發送原則

4.4 產品智能發送

產品與對象智能匹配發送模塊是綜合發布系統的核心。該模塊數據流程見圖3所示。當Consumer 或Web API 接口收到外部系統發來服務產品時整個流程被啟動，隨即用接收到的服務產品相應關鍵字分別與每一個服務對象對應關鍵字一一比較，匹配成功即依照服務對象指定的接收渠道及產品發送原則，通過不同的發布渠道向服務對象（用戶）發送服務產品。

圖3：氣象服務產品智能匹配發送流程

為提高匹配效率，本研究采用改進的KMP 模式匹配算法，優化服務對象與服務產品的匹配算法，同時，將匹配算法線程數設定在1000 條，以提高匹配效率。實測，在發布渠道系統及網絡環境正常情況下，本系統響應時間≤15s。

5 結論

智能化氣象信息綜合發布系統是智能化氣象業務系統的末端，是氣象信息流的總出口，只有實現了氣象信息的智能化發布，方能達成氣象業務系統的全流程智能化。采用本文所述技術方案建成的寧夏智能化氣象信息綜合發布系統，實現了個人（決策、專業）服務對象與公眾對象融合管理，服務產品與發布渠道、服務對象智能化匹配，產品發布全流程監控、留痕與評估，多氣象業務系統對多發布渠道的智能化集約發布。省市縣各級業務人員只需在采集服務對象數據時配置相應的內容，在向氣象服務產品庫存放產品時選擇相應的關鍵字，之后服務產品通過何種發布渠道發送，發給那些服務對象，再無需人工干預，完全由綜合發布系統智能選擇、自動完成，極大地提高了發送時效及工作效率。