黃偉，阮惠華，李澤杰，黃宇宸，陳逸智

（廣東省氣象探測數(shù)據(jù)中心，廣東廣州 510640）

隨著氣象現(xiàn)代化要求日益增高［1］，廣東省氣象局于2019年開始建設(shè)新業(yè)務(wù)網(wǎng)，針對原業(yè)務(wù)網(wǎng)的文件處理功能不集中，文件管理與業(yè)務(wù)網(wǎng)頁面顯示耦合度太高的問題［2］，新業(yè)務(wù)網(wǎng)建設(shè)采用開發(fā)文件管理子系統(tǒng)的思路。當(dāng)前，文件類氣象資料的處理多為功能單一的軟件系統(tǒng)，例如對氣象數(shù)據(jù)的全鏈路監(jiān)控［3］、針對CTS文件傳輸?shù)目梢暬O(jiān)控［4］、對觀測類數(shù)據(jù)的調(diào)度傳輸［5］、氣象資料檢索［6］、氣象資料備份［7-8］等等，這些功能單一的系統(tǒng)，無法滿足新業(yè)務(wù)網(wǎng)的需求，且各個(gè)系統(tǒng)之間信息無法共享。綜合式的文件管理方案，有利于業(yè)務(wù)網(wǎng)功能擴(kuò)展以及降低系統(tǒng)耦合度。新一期的業(yè)務(wù)網(wǎng)建設(shè)對數(shù)據(jù)安全提出了更高的要求［9］，獨(dú)立的文件管理系統(tǒng)更有利于安全功能的擴(kuò)展。

廣東省氣象業(yè)務(wù)網(wǎng)文件管理子系統(tǒng)（以下簡稱系統(tǒng)），要求在可能出現(xiàn)的單點(diǎn)故障和維護(hù)狀態(tài)下，保證業(yè)務(wù)能夠不間斷運(yùn)行及保證數(shù)據(jù)的一致性和完整性［10］。同時(shí)系統(tǒng)設(shè)計(jì)采用微服務(wù)架構(gòu)［11-12］，實(shí)現(xiàn)動(dòng)態(tài)可擴(kuò)展性。

1 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

1.1 系統(tǒng)模塊設(shè)計(jì)

系統(tǒng)的基礎(chǔ)功能可分為3個(gè)大模塊：文件調(diào)度模塊、文件搜索模塊和文件監(jiān)控模塊。其中，3個(gè)模塊通過日志相互關(guān)聯(lián)。

1）文件調(diào)度模塊。該模塊實(shí)現(xiàn)了文件的遷移、清理、轉(zhuǎn)換、改名、備份等功能。支持不同協(xié)議、不同節(jié)律、不同字符集的傳輸；系統(tǒng)實(shí)現(xiàn)了多種文件讀取的過濾、文件寫入的后處理、對Office文檔的轉(zhuǎn)換功能。具體功能詳見表1。

表1 調(diào)度模塊功能說明

2）文件搜索模塊。該模塊是基于Solr的搜索引擎實(shí)現(xiàn)。Solr是基于Lucene的全文搜索服務(wù)器，支持中文分詞算法。匹配度根據(jù)文件名命中數(shù)、文件內(nèi)容命中數(shù)、文件時(shí)間不同權(quán)重計(jì)算匹配度，最后根據(jù)匹配相關(guān)的排序顯示。顯示詞條包含文件的文件名、文件實(shí)體地址、源地址、目標(biāo)地址等信息。

3）文件監(jiān)控模塊。該模塊實(shí)現(xiàn)了對數(shù)據(jù)流程的監(jiān)控管理，應(yīng)用數(shù)據(jù)血緣關(guān)系形成數(shù)據(jù)鏈路圖來描述數(shù)據(jù)流程，通過配置每個(gè)節(jié)點(diǎn)的監(jiān)控，實(shí)現(xiàn)整個(gè)數(shù)據(jù)流程的監(jiān)控，每個(gè)監(jiān)控節(jié)點(diǎn)定義了不同告警級別、不同類型（文件、連接、服務(wù)）、不同節(jié)律的監(jiān)控，并通過數(shù)據(jù)接口發(fā)送到值班輔助平臺(tái)。

另外，系統(tǒng)接口服務(wù)模塊支持http的get與post兩種方式請求，為了保證系統(tǒng)數(shù)據(jù)訪問安全，訪問系統(tǒng)接口通常需要3個(gè)步驟：訪問認(rèn)證接口；根據(jù)時(shí)間戳、系統(tǒng)編碼、密碼等信息生成認(rèn)證；獲取認(rèn)證信息后，則數(shù)據(jù)訪問接口附帶認(rèn)證信息，獲取接口數(shù)據(jù)。對于以往開放式的數(shù)據(jù)服務(wù)，數(shù)據(jù)安全性有較大提升。

其他功能包含公共信息的管理，如連接協(xié)議管理、系統(tǒng)監(jiān)控管理、日志的維護(hù)模塊、消息提醒模塊、資料類型相關(guān)子系統(tǒng)的關(guān)聯(lián)配置等。系統(tǒng)功能劃分見圖1。

圖1 功能模塊示意圖

1.2 系統(tǒng)邏輯架構(gòu)設(shè)計(jì)

為了充分滿足系統(tǒng)在高可用、易擴(kuò)展等方面的要求，采用Spring Cloud微服務(wù)架構(gòu)。根據(jù)不同的方法劃分成相應(yīng)的微服務(wù)，各服務(wù)之間彼此獨(dú)立，也可以根據(jù)業(yè)務(wù)需求進(jìn)行服務(wù)調(diào)用。邏輯層級上系統(tǒng)分為3層結(jié)構(gòu)：交互層、服務(wù)層、數(shù)據(jù)層。

系統(tǒng)以Tomcat為web服務(wù)器，Tomcat響應(yīng)用戶請求，訪問微服務(wù)集群；而傳輸產(chǎn)生的日志、搜索的索引等其他相關(guān)的日志，通過Solr日志索引庫存儲(chǔ)。Oracle則提供了基本元數(shù)據(jù)的持久化存儲(chǔ)，例如配置信息等等。通過Redis作為數(shù)據(jù)緩存，減少了數(shù)據(jù)查詢的壓力。系統(tǒng)邏輯架構(gòu)如圖2所示。

圖2 系統(tǒng)邏輯架構(gòu)示意圖

1.3 系統(tǒng)部署實(shí)現(xiàn)

通過測試發(fā)現(xiàn)，系統(tǒng)運(yùn)行壓力主要存在于文件處理服務(wù)的IO壓力以及線程數(shù)量的不足，所以部署多臺(tái)文件處理服務(wù)器和一臺(tái)接口服務(wù)器。因系統(tǒng)用戶數(shù)有限，Oracle、Redis服務(wù)壓力小，部署同一服務(wù)器。Solr提供日志服務(wù)與搜索服務(wù)，單獨(dú)部署一臺(tái)服務(wù)器。消息中間件與其他系統(tǒng)共用現(xiàn)有消息中間件服務(wù)器（圖3）。

圖3 系統(tǒng)物理部署示意圖

2 關(guān)鍵技術(shù)

2.1 基于Quartz的任務(wù)調(diào)度算法

系統(tǒng)的調(diào)度任務(wù)分配是基于Quartz框架完成，核心元素是調(diào)度器scheduler，并由觸發(fā)器trigger和任務(wù)job兩個(gè)元素構(gòu)成。trigger是用于定義調(diào)度時(shí)間的元素，例如定時(shí)執(zhí)行、按日歷執(zhí)行、單次執(zhí)行等；job用于表示被調(diào)度的具體作業(yè)內(nèi)容。概括性的描述，通過輪詢scheduler列表，完成了任務(wù)的調(diào)度，具體如圖4所示。

圖4 任務(wù)調(diào)度算法

2.2 文件同步清單生成算法

文件同步是一項(xiàng)耗費(fèi)IO資源的功能，為防止頻繁的掃描和重復(fù)同步，對哪些文件同步的判斷十分關(guān)鍵。該系統(tǒng)采用的是日志比對的方式，對源目錄掃描文件集A和已同步文件集合B進(jìn)行比對，判斷出是否需要同步，其具體方法是：A和B交集代表已經(jīng)傳輸?shù)娜罩荆苊庠俅蝹鬏?；A補(bǔ)集代表新增的文件，新增的文件清單，發(fā)送到消息隊(duì)列處理；B的補(bǔ)集代表已過期的日志，為了減少日志查詢壓力避免日志累積，可以刪除過期日志，具體同步清單生成如圖5所示。

圖5 同步清單生成數(shù)據(jù)流程圖

2.3 任務(wù)異步執(zhí)行管理

為了避免多個(gè)任務(wù)線程對資源的搶占，本系統(tǒng)由RabbitMQ消息中間件實(shí)現(xiàn)任務(wù)的異步執(zhí)行，對應(yīng)每個(gè)任務(wù)，QuartZ生成任務(wù)調(diào)度器，執(zhí)行調(diào)度清單生成算法，生成的調(diào)度清單打包成JSON消息集發(fā)送到RabbitMQ。當(dāng)隊(duì)列監(jiān)聽線程發(fā)現(xiàn)有消息時(shí)，通過消費(fèi)者獲取消息，解析JSON信息，獲取完整的任務(wù)信息，完成任務(wù)的執(zhí)行（圖6）。

圖6 線程異步流程圖

該機(jī)制有以下幾個(gè)優(yōu)點(diǎn)。

（1）調(diào)度線程不會(huì)受到任務(wù)實(shí)際執(zhí)行情況影響，當(dāng)完成消息寫入時(shí)，調(diào)度器的線程就結(jié)束。

（2）如果執(zhí)行異常，將異常消息寫入日志，任務(wù)json重新寫入隊(duì)列，并附加已傳輸?shù)拇螖?shù)，實(shí)現(xiàn)文件有限次數(shù)的重傳。

（3）執(zhí)行線程設(shè)置了超時(shí)中斷，當(dāng)任務(wù)阻塞時(shí)，線程超時(shí)，中斷線程回收資源，任務(wù)json重新寫入隊(duì)列。

（4）消息中間件作為任務(wù)執(zhí)行的緩存器，只有一個(gè)監(jiān)聽線程，配置有限個(gè)消費(fèi)者，避免了大量任務(wù)同時(shí)執(zhí)行造成的IO壓力。

2.4 字符集轉(zhuǎn)換算法

由于文件管理的數(shù)據(jù)源于不同用戶的文件上傳，系統(tǒng)無法控制用戶上傳的中文文件名字符集，如果不對中文文件名有效的處理，則會(huì)出現(xiàn)文件名亂碼的情況，嚴(yán)重的將會(huì)影響到文件的讀取，字符轉(zhuǎn)換算法的核心是：

（1）正確匹配源文件的字符集讀取文件，此處可以根據(jù)用戶設(shè)定的字符集或者用JCharDet算法識(shí)別，JCharDet是基于統(tǒng)計(jì)概率的識(shí)別方法，通過計(jì)算字符集轉(zhuǎn)換后字符出現(xiàn)的概率，判斷是否亂碼、識(shí)別出字符集。

（2）負(fù)責(zé)轉(zhuǎn)換的服務(wù)器操作系統(tǒng)字符集為最為完備的字符集，編碼范圍至少包含了源與目標(biāo)目錄的字符集，該系統(tǒng)設(shè)定為utf-8，以免在字符集轉(zhuǎn)換的過程中發(fā)生了信息丟失。

（3）將正確讀取的文本以目標(biāo)目錄字符集寫入到目標(biāo)目錄。

3 試運(yùn)行

系統(tǒng)為業(yè)務(wù)網(wǎng)提供了完備的文件處理服務(wù)。隨著新業(yè)務(wù)網(wǎng)建設(shè)周期，不斷的優(yōu)化建設(shè)系統(tǒng)。通過統(tǒng)計(jì)2021年8月到10月的運(yùn)行，日均同步文件數(shù)量144 264個(gè)，總計(jì)大小23 GB、搜索接口訪問231次。在千兆網(wǎng)絡(luò)帶寬、64核CPU、64 g內(nèi)存、ssd存儲(chǔ)的配置條件下，對系統(tǒng)的最大負(fù)載做了測試，分析了系統(tǒng)的文件處理、接口服務(wù)的最大負(fù)載能力，系統(tǒng)運(yùn)行在最大負(fù)載的情況下，仍能夠穩(wěn)定運(yùn)行。通過與原業(yè)務(wù)網(wǎng)分散的文件處理功能對比，系統(tǒng)最大負(fù)載能力如表2所示。

表2 最大負(fù)載性能對比

在管理效率上，通過系統(tǒng)的監(jiān)控模塊實(shí)現(xiàn)自我監(jiān)控，監(jiān)控消息通過服務(wù)接口對接值班輔助理平臺(tái)，納入了值班監(jiān)控；與原系統(tǒng)相比，通過分析值班員人工記錄的日志。對文件故障的發(fā)現(xiàn)時(shí)間減少了約33%；系統(tǒng)的文件接口，增加了信息認(rèn)證，文件的同步，不依賴第三方軟件，有效的提升了安全性；集約的文件處理功能，實(shí)現(xiàn)了原業(yè)務(wù)網(wǎng)3個(gè)系統(tǒng)功能，減少了運(yùn)維的工作量，優(yōu)化了業(yè)務(wù)管理。系統(tǒng)還彌補(bǔ)了原業(yè)務(wù)網(wǎng)系統(tǒng)中中文字符集轉(zhuǎn)換、全文搜索等缺失的功能，解決了業(yè)務(wù)上的需求。