氣象綜合業務運行監控和管理系統軟件的開發設計研究

陳凱 吳健 程若虎

摘要：為增強省級氣象信息化水平，軟件設計開發實現觀測網絡互聯化，全空間無縫使用，改進現有綜合業務運行項目分散使用管理的現狀。文章全面而簡要介紹了該系統軟件項目的開發情況，主要包括環境配置，結構設計、架構模式、項目功能、數據庫和頁面設計，以及開發實施過程中遵守的準則及標準等等。

關鍵詞：氣象綜合業務;監控管理系統;結構;功能;數據庫

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2019）07-0175-02

0 引言

隨著氣象探測設備類型和數量的不斷增加，氣象裝備的穩定和數據質量的可靠性對現在氣象業務有著非常重大的影響，為及時有效地發現裝備故障和數據質量異常，設計開發一套氣象綜合業務運行監控和管理平臺，實現故障的實時預警有著非常深刻的意義。開展系統軟件的功能開發設計研究工作，要充分滿足業務需求，體現軟件的實用性、先進性、可擴充性、可靠性和可伸縮性十分必要。

1 軟件開發設計的準備工作

針對該系統的目的、要求等情況進行詳細的調查收集，并反復推敲梳理，分析研究在系統中實現目標的可行性，從而明確該系統的設計要求，解決管理者和操作者所要獲取的信息要求。在此基礎上，編寫了較為完整和成熟的《氣象綜合業務運行監控和管理系統》需求方案;并從信息處理的功能需求上提出系統的邏輯模型，為下一階段進行物理方案設計、確定解決問題的相關運算方法做好鋪墊。同時，在開發設計過程中，要充分體現出軟件的實用性、先進性、可擴充性、可伸縮性和可靠性。

在系統軟件開發設計過程中，遵循的原則有：

（1）執行標準原則。在軟件的開發過程中，完全按照《計算機軟件開發規范》（GB8566-88）來進行規范和控制。（2）整體性原則。整合集約現有分散的觀測數據加工處理系統，充分利用現有資源，優化建設規范統一的觀測數據加工處理系統，優化系統管理維護和運行，實現觀測業務現代化與氣象業務信息化深度融合。（3）集約規范原則。按照綜合氣象觀測質量管理體系和質量保證體系的總體要求，制定氣象觀測業務標準規范，推動氣象觀測業務建設標準化、集約化。（4）分散—集中原則。在實現功能的過程中，進行模塊化設計，復雜問題分散解決，在考慮系統整體協調原則下，確保系統實現整體工作的穩定性和可靠性。（5）目標優化原則。對簡單軟件開發設計來說，主要考慮是求最優解;對復雜軟件開發設計來說，主要考慮的是求滿意解。本系統可以理解為是滿意解和最優解的幾何體，這里包括對數據的處理速度、操作是否簡便，數據大小優化等要求。

這里主要遵循的的是幾個主要原則，并非全部原則，實際開發設計中還是用了其他原則，在這里不再詳述。

2 軟件設計的基本要求

2.1 性能要求

瀏覽器支持：支持瀏覽器B/S方式，完全支持IE8、chrome和Safari及以上的，可支持在移動設備上瀏覽;操作系統支持：系統控件支持32位及64位操作系統，服務器端全部使用64位操作系統開發。

系統接口：系統的數據、界面及計算服務具有可供第三方使用的接口，其它系統可使用不同方式調用。

性能要求：實時監視數據的采集周期不超過60秒，計算數據的刷新周期最多為5秒;頁面在局域網條件下加載完成時間小于5秒;界面上顯示的畫面數量、組態圖形數量及動態點數應無限制，且數據刷新率滿足要求。高峰時，服務器CPU占用率少于80%（2顆8核至強CPU），內存占用率小于128G;系統至少滿足最大100并發用戶訪問。

2.2 系統適應性和安全性要求

系統具有優化和再配置能力;支持LDAP單點登錄，確保用戶信息只配置一次，即可全部信息系統共同使用;按照SOA的實施方法論，提供完善的Webservice接口，確保系統架構靈活性。

2.3 系統可靠性要求

系統應具備自動預警和自動數據備份功能，以避免出現影響正常運行的嚴重事件，例如：系統死鎖、資源耗盡、程序崩潰等，能夠提供系統日志，滿足審查系統和事務處理的要求。

3 系統開發設計及實現

主要開發設計過程包括：系統總體結構設計，軟件架構設計、功能設計等。

3.1 軟件開發環境

B/S模式是基于WWW技術對傳統C/S模式進行改進而形成的一種新型處理模式。該模式是以Web為中心，采用TCP/IP、HTTP為傳輸協議，前端采用通用瀏覽器（IE、Netscape、Navigator等）Web 客戶軟件，客戶端可通過Browser（瀏覽器）訪問Web。后端采用Web Server訪問數據庫，將結果返回瀏覽器，多級用戶的操作均可通過瀏覽器進行。前后端連接靠HTTP協議，所有開發都在Server上進行。

在這種結構下，用戶工作界面是通過WWW瀏覽器來實現，極少部分事務邏輯在前端（Browser）實現，但是主要事務邏輯在服務器端（Server）實現，形成所謂三層3-tier結構。相對于C/S結構屬于“胖”客戶端，需要在使用者電腦上安裝相應的操作軟件來說，B/S 結構是屬于一種“瘦”客戶端，大多數或主要的業務邏輯都存在于服務器端，因此，B/S結構（如圖1）的系統不需要安裝客戶端軟件，它運行在客戶端的瀏覽器之上，系統升級或維護時只需更新服務器端軟件即可，這樣就大大簡化了客戶端電腦載荷，減輕了系統維護與升級的成本和工作量，降低了用戶的總體成本。

采用這種結構，其優勢主要體現在，無需專門開發客戶端軟件，系統在維護和升級的同時，不影響客戶端的使用，在保證瀏覽查詢者方便操作的同時，也使系統簡單靈活;可跨平臺操作，任何機器只要裝有ie瀏覽器，均可做為客戶端訪問系統;將服務器劃分為數據服務器和Web服務器兩部分，使數據庫端易于維護和升級（如圖2）。

3.2 軟件構架設計

以基礎設施資源與氣象大數據體系化模式的思路建立一整套機制，面向業務和應用，以服務為導向，建設全流程、可視化的運維監控管理平臺，實現一體化的業務運維管理體系。軟件構架主要包括三個層次：監視信息采集層、監視信息處理層和應用展現層（如圖3）。

（1）監視信息采集層：監控管理平臺實現對基礎設施資源池、網絡、網絡安全及機房和數據全流程等監視信息完整采集。具體有：計算、存儲、網絡等基礎資源以及對運行于基礎資源上的數據庫、中間件等平臺環境的監控;省內高清會商系統，MCU、終端等設備狀態及會議效果等信息的采集;網絡拓撲管理、網絡設備監控、網絡鏈路監控及網絡事件管理;網絡信息安全威脅統計;集成機房溫濕度、配電、空調、消防及門禁、安防等信息;每類氣象數據在生成、傳輸、存儲、服務和應用等各環節的關鍵性能指標狀態。（2）監視信息處理層：對實時監視信息的分析加工統計，生成統計分析報表，將監控信息、分析統計結果、告警及反饋等信息規范化存儲管理，存儲在日志文件、數據庫以及語音庫中，為其他子系統提供數據源。對滾動日志文件、監控數據庫以及臨時數據進行定期清除，并實現備份、歸檔。還將處理通過手機客戶端處理的報警反饋結果，并形成存儲、數據和報表。（3）應用展現層：設計監控信息查詢統計分析與綜合展示功能，用于在省級信息業務平臺展示業務總體狀況。集成應用新技術，增加信息網絡業務值班運維手段，研發電話語音通知系統、移動終端處理反饋系統，根據業務流程和應用需求設計告警策略、參數的配置，實現故障自動定位，以及智能化的處理、反饋，提供短信、電話和移動終端APP推送等多種形式的報警提醒。

3.3 軟件系統子系統設計規范要求

3.3.1 基礎設施資源池監控

充分考慮底層硬件平臺和虛擬化平臺的差異性和接口開放情況，以及資源管理、運維和第三方軟件的接入問題，進行云平臺的松耦合架構設計，將異構虛擬化管理與資源統一調度進行有效隔離，確保各個組件的獨立運行。

系統支持省級資源池基礎設施資源集中監控，實現對計算、存儲、網絡等基礎資源以及對運行于基礎資源上的數據庫、中間件等平臺環境的監控，并應當根據實際本地資源實際情況實現對本地及異構設備的集成對接。

3.3.2 網絡、安全及場地監控

網絡監視應當具備網絡拓撲管理、網絡設備監控、網絡鏈路監控及網絡事件管理功能。

3.3.3 數據全流程監視

以實時資料（臺站數據、接收數據、業務單位數據）為主線，實時監視每類氣象數據在采集（生成）、收集、質控評估、入庫、分發等各環節的關鍵性能指標狀態。包括上行數據傳輸實時監視、下行數據傳輸實時監視、全流程詳情查詢。

3.3.4 告警與管理平臺

應支持監視告警處理規則管理及告警分析處理。

3.4 系統的維護

該系統的運行維護主要體現在糾錯性維護、完善性維護和預防性維護這三個方面。據不完全統計，現在大部分的軟件產品完善性維護沾所有維護工作總量的40%左右，所有在系統設計研究盡量把需求分析詳盡，以減少后勤完善性維護的工作量。

（1）糾錯性維護。系統在測試時不可能完全測試出系統中存在的所有錯誤，當系統運行到一段時間后會暴露出系統內隱藏的錯誤，這是維護改進就很重要。（2）完善性維護。根據用戶在使用過程中不斷提出的新要求，來持續擴充原有的系統功能;用戶在系統使用一段時間后，會對系統有不同程度的改進要求。（3）預防性維護。維護工作要由被動變主動，來延長系統的使用壽命。

4 結語

本文的系統開發設計研究，目的是加強氣象業務的信息化、集約化管理，高效完成安徽全省氣象的日常管理工作，致力于氣象業務的長遠發展，是符合業務發展及信息化規劃綱要的根本精神。目前，該系統開發設計的編制，為軟件開發提供了指導性的方向，同時，也為單位的業務管理提供了經驗。