劉魁 舒紅平 何文春 羅飛 曹亮

（1 成都信息工程大學(xué)，成都 610225；2 國家氣象信息中心，北京 100081；3 中國氣象局-成都信息工程大學(xué)氣象軟件工程聯(lián)合研究中心，北京 100081）

0　引言

隨著科技創(chuàng)新不斷地推動知識經(jīng)濟的高速發(fā)展，數(shù)據(jù)用于計算成為新一輪經(jīng)濟的重要驅(qū)動力，氣象行業(yè)擁有海量的氣象信息資源，國家大數(shù)據(jù)發(fā)展戰(zhàn)略，已將氣象部門列入釋放數(shù)字紅利推動供給側(cè)改革的重要行業(yè)?；ヂ?lián)網(wǎng)資源整合、微服務(wù)個性化服務(wù)等技術(shù)發(fā)展，使氣象智能服務(wù)軟件成為了聯(lián)接氣象資源和領(lǐng)域服務(wù)的重要技術(shù)途徑之一。面向交通、旅游、健康衛(wèi)生等領(lǐng)域氣象微服務(wù)應(yīng)用的差異化、精準化服務(wù)需求的增長，氣象智能服務(wù)軟件對推動眾創(chuàng)平臺建設(shè)、智慧業(yè)態(tài)形成具有重要現(xiàn)實意義。

釋放海量的氣象數(shù)據(jù)資源以及加工氣象數(shù)據(jù)的算法庫，是推動領(lǐng)域知識經(jīng)濟生產(chǎn)力的重要工程實踐基礎(chǔ)。目前，這一工程實踐面臨著五方面的挑戰(zhàn)：1）互聯(lián)網(wǎng)、氣象、行業(yè)分屬多個學(xué)科，跨專業(yè)跨領(lǐng)域的復(fù)合型人才缺乏；2）傳統(tǒng)的氣象服務(wù)難以滿足不同行業(yè)面跨地域、跨時間的精細化服務(wù)需求；3）各行業(yè)的數(shù)據(jù)資源相對分散，數(shù)據(jù)安全性要求相對較高，缺乏跨行業(yè)的數(shù)據(jù)通道，跨行業(yè)數(shù)據(jù)整合難；4）不同行業(yè)業(yè)務(wù)系統(tǒng)的技術(shù)路線呈現(xiàn)多樣化和封閉化的特點，難以做到技術(shù)層面的整合；5）各行業(yè)應(yīng)用需求變化快，現(xiàn)有技術(shù)難以做到對業(yè)務(wù)的變更進行快速的響應(yīng)。針對上述問題，借助“互聯(lián)網(wǎng)+”模式，設(shè)計滿足業(yè)務(wù)領(lǐng)域需求的氣象微服務(wù)開發(fā)及運行框架，提供氣象業(yè)務(wù)構(gòu)件開發(fā)規(guī)范，指導(dǎo)氣象業(yè)務(wù)構(gòu)件設(shè)計和應(yīng)用，提供構(gòu)件交易、構(gòu)件運行、構(gòu)件監(jiān)控等業(yè)務(wù)保障功能，滿足氣象智能軟件開發(fā)、領(lǐng)域知識、領(lǐng)域軟件工程、領(lǐng)域數(shù)據(jù)分析算法的需求，面向創(chuàng)新驅(qū)動、大眾創(chuàng)業(yè)等提供資源開發(fā)環(huán)境，推進智慧城市、智慧民生等智能服務(wù)生態(tài)建設(shè)發(fā)展積極作用。

1　基于領(lǐng)域知識的微服務(wù)

1.1　氣象領(lǐng)域知識構(gòu)件化

從文本和詞義兩個層次，是提取氣象領(lǐng)域知識的主要途徑。將業(yè)務(wù)領(lǐng)域內(nèi)的潛規(guī)則，應(yīng)用本體論方法表示成領(lǐng)域知識，構(gòu)成領(lǐng)域規(guī)則庫，對領(lǐng)域規(guī)則采用圖形化表示，采用SWRL描述規(guī)則知識的內(nèi)、外部表示，建立領(lǐng)域知識的直觀顯示，并提供適當(dāng)有效的推理機制。軟件構(gòu)件是指語意完整、語法正確、具有一定集成度并可以重復(fù)使用的軟件組成單元[1-3]。構(gòu)件可以分為基礎(chǔ)構(gòu)件、系統(tǒng)構(gòu)件、業(yè)務(wù)構(gòu)件和應(yīng)用構(gòu)件。面向微服務(wù)主要提供氣象業(yè)務(wù)構(gòu)件和氣象應(yīng)用構(gòu)件。開發(fā)這些構(gòu)件時，可將領(lǐng)域知識中的規(guī)則和推理機制封閉在構(gòu)件中，對相應(yīng)的氣象數(shù)據(jù)進行業(yè)務(wù)自動處理。

1.2　微服務(wù)開發(fā)環(huán)境

隨著智慧氣象對跨領(lǐng)域知識深度應(yīng)用的要求不斷提高，氣象部門軟件開發(fā)面向跨行業(yè)跨部門的情形日益增多，與以往氣象信息化軟件不同，氣象智能服務(wù)軟件呈現(xiàn)出大平臺、微開發(fā)的特征。微服務(wù)是將大型傳統(tǒng)軟件分為較小的、可獨立運行的服務(wù)模塊。這些微服務(wù)模塊可采用不同編程語言實現(xiàn)，微服務(wù)接口采用消息隊列相互耦合，各微服務(wù)模塊具有高度的可移植、可替換性，以保證性能和可擴展性。

微開發(fā)以微服務(wù)的構(gòu)件為核心。這些構(gòu)件是領(lǐng)域知識的抽象，采用構(gòu)件化、服務(wù)化的方式進行了封裝。這些構(gòu)件包括面向氣象數(shù)據(jù)解碼、氣象數(shù)據(jù)深加工、氣象數(shù)據(jù)再分析等，提供氣象預(yù)報、氣象預(yù)測、氣象數(shù)據(jù)抽取、氣象產(chǎn)品顯示、生成、分發(fā)等領(lǐng)域知識。將軟件工程技術(shù)與構(gòu)件開發(fā)工具進行結(jié)合，形成的一整套集軟件工程方法論、構(gòu)件開發(fā)方法論和構(gòu)件裝配方法論等理論知識與開發(fā)環(huán)境、調(diào)試環(huán)境和運行環(huán)境等構(gòu)件全生命周期管理工具于一體的微服務(wù)平臺[4-5]。

微服務(wù)運行環(huán)境（圖1）基于Docker容器運行，Docker是一種開源的容器引擎，使服務(wù)構(gòu)件以及依賴資源，打包發(fā)布到一個可移植的容器中，便于應(yīng)用的部署和擴展。微服務(wù)、微開發(fā)和微容器相輔相成，基于Docker 封裝的應(yīng)用可以輕松運行在云計算平臺上。相對于傳統(tǒng)的單塊架構(gòu)，基于容器技術(shù)的微服務(wù)架構(gòu)與業(yè)務(wù)的深度融合[6-8]，有助于打通海量信息資源與個性化服務(wù)。

圖1　微服務(wù)運行環(huán)境Fig. 1 Microservice runtime environment

1.3　微服務(wù)構(gòu)件開發(fā)模式

面向“互聯(lián)網(wǎng)+氣象+服務(wù)行業(yè)”的氣象服務(wù)生態(tài)建設(shè)，針對氣象行業(yè)外知識服務(wù)開發(fā)者，缺乏氣象領(lǐng)域知識，但熟悉用戶跨行業(yè)業(yè)務(wù)需求的特征，構(gòu)建基于氣象服務(wù)構(gòu)件的“2+1”模式，即：兩種開發(fā)模式+一個服務(wù)構(gòu)件庫。

1.3.1基于代碼的開發(fā)模式

面向具有一定計算機編程基礎(chǔ)的眾創(chuàng)應(yīng)用開發(fā)人員，提供多種語言開發(fā)構(gòu)件的環(huán)境。支持符合氣象標(biāo)準的構(gòu)件打包規(guī)范，實現(xiàn)與運行平臺構(gòu)件的接口匹配，系統(tǒng)提供打包模塊上傳功能，經(jīng)自動審核滿足規(guī)模的構(gòu)件可立即入構(gòu)件庫。這些入庫認證的構(gòu)件可基于微服務(wù)架構(gòu)運行，基于主流的技術(shù)協(xié)議進行數(shù)據(jù)交互。客戶端構(gòu)件開發(fā)語言主要包括HTML5、JavaScript、CSS3等；服務(wù)端的開發(fā)語言主要包括Java、C/C++、Python等。

1.3.2基于可視化的開發(fā)模式

面向?qū)τ嬎銠C編程有困難但熟知業(yè)務(wù)的眾創(chuàng)信息服務(wù)人員，提供可視化的開發(fā)工具?；谄脚_提供的構(gòu)件庫，支持無需編寫代碼即可完成構(gòu)件和應(yīng)用的開發(fā)工作。以Web圖形化開發(fā)方式進行界面、邏輯、數(shù)據(jù)的可視化的業(yè)務(wù)編排，提供編譯、部署工具支持，與構(gòu)件交易商城接口建立關(guān)聯(lián)，支持一鍵發(fā)布微服務(wù)應(yīng)用。

1.3.3服務(wù)構(gòu)件庫

基于SOA架構(gòu)思想，提供針對構(gòu)件的分類管理庫，簡稱構(gòu)件庫。構(gòu)件庫中包含眾多氣象領(lǐng)域通用、可定制的已封裝成熟算法的構(gòu)件。支持構(gòu)件庫分類管理，包括基礎(chǔ)類、數(shù)據(jù)類、接口類、傳輸類、分析類、顯示類、交互類、網(wǎng)關(guān)類不同粒度構(gòu)件。

2　基于微服務(wù)的眾創(chuàng)平臺

廣東氣象應(yīng)用眾創(chuàng)平臺以成熟的JavaEE體系為支撐，采用JSF、Seam、Tuscany等技術(shù)框架進行底層搭建，以微服務(wù)架構(gòu)為核心，基于Docker容器技術(shù)，支持包括Restful、WebService、RMI、JMS在內(nèi)的多種數(shù)據(jù)交互技術(shù)，并結(jié)合基于Web端的可視化編輯器進行構(gòu)件的裝配、調(diào)試和部署，實現(xiàn)了氣象業(yè)務(wù)構(gòu)件的標(biāo)準化、模塊化、配置化、圖形化裝配，為氣象業(yè)務(wù)構(gòu)件的開發(fā)、部署、交易、應(yīng)用配置、運行等關(guān)鍵環(huán)節(jié)提供了一整套的核心技術(shù)的支撐。

2.1　平臺基礎(chǔ)架構(gòu)

眾創(chuàng)平臺以眾創(chuàng)為出發(fā)點，圍繞眾創(chuàng)運行平臺、眾創(chuàng)構(gòu)件商城、眾創(chuàng)開發(fā)平臺、眾創(chuàng)運營平臺以及眾創(chuàng)大數(shù)據(jù)等核心要素，以實現(xiàn)眾聯(lián)、眾享、眾籌、眾贏的眾創(chuàng)愿景為目標(biāo)[9]?；诜?wù)構(gòu)件核心思想，從構(gòu)件標(biāo)準規(guī)范、構(gòu)件上傳機制、構(gòu)件加載機制、構(gòu)件交易商城、構(gòu)件可視化裝配、構(gòu)件動態(tài)配置和構(gòu)件運營狀態(tài)監(jiān)控等方面入手，具體如下：

1）服務(wù)構(gòu)件標(biāo)準規(guī)范。主要包括服務(wù)構(gòu)件定義、服務(wù)構(gòu)件開發(fā)、服務(wù)構(gòu)件運行和服務(wù)構(gòu)件運維等方面，圍繞構(gòu)件的全生命周期進行規(guī)范的定制，為服務(wù)構(gòu)件的開發(fā)提供指導(dǎo)思想和實現(xiàn)路徑。

2）服務(wù)構(gòu)件上傳機制。主要提供上傳的功能界面，包括服務(wù)構(gòu)件的打包、上傳、部署等功能并提供上傳之后的構(gòu)件隔離驗證與人工審批的環(huán)節(jié)。為眾創(chuàng)人員提供方便快捷的構(gòu)件提交途徑。

3）服務(wù)構(gòu)件加載機制。針對在服務(wù)器不停機的情況使得新上傳的構(gòu)件能夠正常使用，系統(tǒng)提供服務(wù)構(gòu)件的動態(tài)加載、動態(tài)釋放、構(gòu)件功能組合疊加以及構(gòu)件的自動更新等功能，做到構(gòu)件的按需加載，自動釋放等功能。

4）服務(wù)構(gòu)件交易商城。通過預(yù)留交易接口，使得平臺與銀行的支付接口以及第三方支付交易平臺進行對接變得容易。另外平臺還提供的服務(wù)構(gòu)件商城模塊，實現(xiàn)一整套針對服務(wù)構(gòu)件的在線交易功能。

5）服務(wù)構(gòu)件可視化裝配。為了降低眾創(chuàng)開發(fā)人員在編寫服務(wù)構(gòu)件時的工作量，提高編程效率，平臺提供一個針對服務(wù)構(gòu)件的可視化裝配工具，包括自動編譯、自動打包、自動部署、自動測試等主要功能。

6）服務(wù)構(gòu)件動態(tài)配置。服務(wù)構(gòu)件動態(tài)配置主要基于在線的可視化編輯器為中心，集成了包括界面動態(tài)配置、服務(wù)構(gòu)件在線配置、個性化配置工具、代碼在線查看工具等功能模塊，為多種構(gòu)件的靈活配置提供基礎(chǔ)支撐環(huán)境。

7）構(gòu)件運營狀態(tài)監(jiān)控。主要圍繞構(gòu)件的交易、裝配、運行等環(huán)節(jié)，基于在線的查詢報表及圖表工具，實現(xiàn)構(gòu)件全生命周期的狀態(tài)信息圖形化方式展示。

2.2　安全評估機制

眾創(chuàng)平臺面向社會開放，保證眾創(chuàng)人員上傳的代碼安全性和可靠性是關(guān)鍵、為了避免有人上傳包括嚴重BUG的構(gòu)件甚至惡意上傳病毒構(gòu)件，平臺提供了一整套代碼評估體系，對所有測試過程的問題進行匯總和收集，并可以形成Word形式的綜合評估報告。評估主要包括以下三個步驟：

1）代碼自動走查。上傳的構(gòu)件由平臺程序進行自動走查，依據(jù)平臺定義的規(guī)范進行代碼審查，一旦發(fā)現(xiàn)不符合要求的代碼記錄下來，根據(jù)設(shè)定的規(guī)則自動選擇“直接打回”或“人工審查”等處理手段。

2）人工代碼審查。在自動走查的基礎(chǔ)之上，將發(fā)現(xiàn)的問題由人工核查和確認。

3）云安全測試。當(dāng)自動走查和人工審查都通過之后，系統(tǒng)自動將構(gòu)件進行云安全測試，利用隔離的環(huán)境對代碼進行運行測試，在此時發(fā)現(xiàn)問題，只影響隔離環(huán)境，不會對正式環(huán)境造成破壞。

2.3　系統(tǒng)權(quán)限管理

權(quán)限及安全是眾創(chuàng)平臺應(yīng)當(dāng)解決的最基本的問題之一，基于平臺開發(fā)的業(yè)務(wù)系統(tǒng)由平臺底層統(tǒng)一保障。平臺主要提供針對多種權(quán)限的授予、回收的操作進行統(tǒng)一管理。具體包括以下三種權(quán)限：

1）功能權(quán)限。功能權(quán)限主要是針對用戶和角色進行功能模塊的權(quán)限控制，未被授權(quán)的人或角色無法看到并訪問功能模塊。

2）界面權(quán)限。界面權(quán)限主要是針對界面組件的權(quán)限管理。同一個系統(tǒng)頁面，顯示出來的界面組件會根據(jù)權(quán)限的不同而有所不同。

3）數(shù)據(jù)權(quán)限。數(shù)據(jù)權(quán)限是平臺提供的對數(shù)據(jù)的權(quán)限進行的控制，未授權(quán)的數(shù)據(jù)不能被訪問。

2.4　監(jiān)控管理可視化

運行監(jiān)控是眾創(chuàng)平臺的關(guān)鍵一環(huán)，該平臺提供包括餅狀圖、柱狀圖、拆線圖在內(nèi)的多種監(jiān)控數(shù)據(jù)展現(xiàn)形式，包括“近七天交易額”、“各月份商品交易額”、“各商品購買率”等數(shù)據(jù)信息。監(jiān)控平臺還提供PC、手機、平板等提供多種終端展現(xiàn)形式。對于關(guān)鍵信息提供包括郵件、短信、微信在內(nèi)的多種消息模式。

3　氣象眾創(chuàng)微服務(wù)應(yīng)用

氣象災(zāi)害具有很強的地域特殊性，以廣東省處于沿海地帶，常年多以臺風(fēng)和暴雨氣象災(zāi)害為主?；诒妱?chuàng)平臺提供的基礎(chǔ)運行環(huán)境，可從氣象災(zāi)害的預(yù)防、監(jiān)測、預(yù)報、預(yù)警、應(yīng)急處置方面，建立數(shù)據(jù)共享服務(wù)，將部分實時資料分發(fā)到氣象應(yīng)用眾創(chuàng)商城，經(jīng)過后續(xù)加工處理、儲存，提供共享服務(wù)，使得氣象專業(yè)人員可從氣象應(yīng)用眾創(chuàng)商城上下載相關(guān)應(yīng)用構(gòu)件和數(shù)據(jù)構(gòu)件，進行氣象檢測、預(yù)報等分析。

眾創(chuàng)平臺中包含了大量的氣象業(yè)務(wù)構(gòu)件，因篇幅所限，本文主要以其中一個常用構(gòu)件“實況填圖”進行平臺應(yīng)用的案例說明?！皩崨r填圖”功能一般是業(yè)務(wù)人員在需要了解區(qū)域溫度、降水和瞬時風(fēng)等數(shù)據(jù)時進行使用，其主要包括參數(shù)控制窗口、業(yè)務(wù)構(gòu)件裝配及結(jié)果數(shù)據(jù)展示三個部分。

3.1　參數(shù)控制窗口

業(yè)務(wù)人員在構(gòu)件運行時可基于“實況觀測控制窗口”模塊對對構(gòu)件的屬性進行設(shè)置，主要包括：要素、類型、地區(qū)等控制項，需要使用日期框、多選框及按鈕等基礎(chǔ)構(gòu)件，界面如圖2所示。

以“要素”選擇為例，構(gòu)件針對不同的要素設(shè)置了閾值策略，要素的觀測在不同的區(qū)間時，以不同的顏色進行顯示，例如當(dāng)溫度大于 35度和小于 5度時，溫度值在 WebGIS上將會以紅色數(shù)字顯示，其他區(qū)間的溫度值以深灰色顯示。當(dāng)要素的顯示顏色為非第一個缺省顏色時，則改站點所在地區(qū)要引起預(yù)報員的重視。

圖2　實況觀測控制窗口Fig. 2 Control window for real observation

除了界面之外，還需要使用頁面邏輯流構(gòu)件將配置數(shù)據(jù)進行打包，結(jié)合事件接口、數(shù)據(jù)獲取、數(shù)據(jù)加密等構(gòu)件裝配后，采用Rest接口將加密打包的數(shù)據(jù)發(fā)送到“實況觀測”微服務(wù)。整個功能通過眾創(chuàng)平臺的構(gòu)件封裝方法封裝成XHT格式的構(gòu)件描述文件，該功能中既包括界面構(gòu)件的裝配信息，又包含了界面功能流程的描述。

3.2　業(yè)務(wù)構(gòu)件裝配

微服務(wù)邏輯需要解決數(shù)據(jù)后臺計算的問題，當(dāng)需要對某時段進行溫度距平計算時，可采用數(shù)值預(yù)報中的“物理量計算”構(gòu)件。構(gòu)件需要內(nèi)置 3h、 6h、24h、溫度距平等簡易算法，則每一個算法會封裝成一個構(gòu)件。在構(gòu)件中配置模式、起報時間、物理量名和對應(yīng)的高度層，例如GRAPES模式2015-11-30 20時起報的3h溫差，則在數(shù)值預(yù)報產(chǎn)品中需要有計算服務(wù)對該功能進行支撐。

面對上述需求，“實況觀測”微服務(wù)以SOA架構(gòu)為基礎(chǔ)，采用結(jié)構(gòu)化組裝的方式對“實況觀測”的業(yè)務(wù)邏輯進行結(jié)構(gòu)化的裝配，再結(jié)合業(yè)務(wù)邏輯流的面向接口的編排，最終形成一個完整的服務(wù)構(gòu)件，并將該服務(wù)構(gòu)件的接口暴露為以Rest為接口的微服務(wù)，供前臺的“實況觀測控制窗口”發(fā)送的微服務(wù)請求進行調(diào)用。服務(wù)的配置界面如圖3所示。

圖3　實況觀測微服務(wù)裝配及發(fā)布Fig. 3 Micro service assembly and release for real observation

3.3　結(jié)果數(shù)據(jù)展示

配置構(gòu)件后，可在WebGIS地圖上站點所在經(jīng)緯度繪制站點實時的溫度、降水和瞬時風(fēng)等觀測數(shù)據(jù)；實況填圖提供時間、要素、字體、居中、站點信息和統(tǒng)計填圖等控制。為了便于對不同模式產(chǎn)品進行疊加對比分析，通過產(chǎn)品顯示控制窗口進行控制（圖4）。同時在WebGIS地圖上繪制11時減去08時的溫差場，如圖5所示。

圖4　數(shù)值預(yù)報產(chǎn)品模式選擇Fig. 4 Mode selection of numerical weather prediction products

圖5　數(shù)值預(yù)報產(chǎn)品結(jié)果展示Fig. 5 Display of numerical weather prediction products

4　結(jié)束語

氣象眾創(chuàng)服務(wù)是“大眾創(chuàng)業(yè)，萬眾創(chuàng)新”的重要形式之一，構(gòu)造開放開源的眾創(chuàng)型業(yè)務(wù)發(fā)展平臺是對未來氣象服務(wù)社會化、商業(yè)化服務(wù)的一種嘗試，該平臺在阿里云提供的容器上運行穩(wěn)定，對氣象數(shù)據(jù)處理能力進行了業(yè)務(wù)化封閉，建立微服務(wù)驅(qū)動的多種服務(wù)產(chǎn)品快速開發(fā)的環(huán)境，也提供了領(lǐng)域知識與業(yè)務(wù)應(yīng)用之間的知識產(chǎn)權(quán)交易渠道，對進一步開放氣象服務(wù)市場，加強領(lǐng)域氣象服務(wù)精細化提供了一種實現(xiàn)途徑。

[1]趙夫增, 丁雪偉. 基于互聯(lián)網(wǎng)平臺的大眾協(xié)作創(chuàng)新研究. 中國軟科學(xué), 2009(5): 63-72.

[2]劉志迎, 陳青祥, 徐毅. 眾創(chuàng)的概念模型及其理論解析. 科學(xué)學(xué)與科學(xué)技術(shù)管理, 2015(2): 52-61.

[3]孫雪, 任樹懷. 基于知識創(chuàng)造的眾創(chuàng)空間構(gòu)建. 合作經(jīng)濟與科技,2016(2): 104-108.

[4]郭棟, 王偉, 曾國蓀. 一種基于微服務(wù)架構(gòu)的新型云件PaaS平臺.信息網(wǎng)絡(luò)安全, 2015(11): 15-20.

[5]Cowan R, David P A, Foray D. The explicit economics of knowledge codi fication and tacitness. Industrial and Corporate Change, 2000,9(2): 211-253.

[6]李貞昊. 微服務(wù)架構(gòu)的發(fā)展與影響分析. 信息系統(tǒng)工程, 2017(1):154-155.

[7]孫海洪. 微服務(wù)架構(gòu)和容器技術(shù)應(yīng)用. 金融電子化, 2016(5):63-64.

[8]孫盛婷, 朱奕健. 基于運營商能力開放的能力編排及微服務(wù)架構(gòu)研究. 工業(yè)和信息化教育, 2016(3): 52-57.

[9]Boudreau K J, Lakhani K R. Using the crowd as an innovation partner. Harvard Business Review, 2013, 91(4): 61-69.