面向大規(guī)模集群的網(wǎng)元自動巡檢系統(tǒng)設(shè)計與實現(xiàn)

朱云杰

（中博信息技術(shù)研究院有限公司，江蘇 南京 210012）

0 引言

網(wǎng)元巡檢是電信操作維護部門的一項重要工作，也是保證網(wǎng)元正常運行的必要手段。網(wǎng)元巡檢的基本過程為：連接登錄網(wǎng)元，向網(wǎng)元發(fā)送若干巡檢指令，網(wǎng)元接收指令后返回相應的指令執(zhí)行報告，最后分析返回的報告是否存在異常。

由于網(wǎng)元類型多、數(shù)量多，且檢查項目多，因此人們開發(fā)了相關(guān)的網(wǎng)元自動巡檢系統(tǒng)，以代替人工完成繁重的巡檢任務。隨著5G 技術(shù)的快速發(fā)展，現(xiàn)有網(wǎng)元巡檢系統(tǒng)暴露出一些突出問題，主要包括：新接入網(wǎng)元周期較長，新型網(wǎng)元接入時需要對現(xiàn)有系統(tǒng)進行二次開發(fā)，然后重新進行版本升級，無法做到快速支撐、快速響應；現(xiàn)有系統(tǒng)框架在數(shù)據(jù)采集與數(shù)據(jù)應用上采用緊耦合方式，數(shù)據(jù)采集能力不易開放給其他應用，數(shù)據(jù)采集需求存在大量重復開發(fā)且開發(fā)周期較長等問題；采集任務缺乏優(yōu)先級控制，重點任務得不到保障，由于數(shù)據(jù)采集缺乏統(tǒng)一規(guī)劃，同一網(wǎng)元上可能對接多種采集機與采集接口，存在大量重復采集、資源搶占、采集數(shù)據(jù)無法及時同步等問題，尤其對于重點采集任務無法第一時間執(zhí)行；采集數(shù)據(jù)丟失，由于采集過程缺乏有效的監(jiān)控預警，沒有審計監(jiān)控日志，因此采集數(shù)據(jù)的完整性、準確性無法得到保障。

本文設(shè)計與實現(xiàn)的系統(tǒng)采用微服務技術(shù)架構(gòu)構(gòu)建統(tǒng)一的網(wǎng)元數(shù)據(jù)采集平臺，實現(xiàn)網(wǎng)元自動巡檢作業(yè)調(diào)度執(zhí)行，采集平臺可同時開放給其他系統(tǒng)應用，從而能較好地解決上述問題。

目前江蘇電信公司已由不同廠家建設(shè)了若干網(wǎng)元巡檢系統(tǒng)，如交換網(wǎng)元例行測試系統(tǒng)［1］。本文采用先進的集群技術(shù)，對原有網(wǎng)元巡檢系統(tǒng)進行的改進與優(yōu)化如下：

（1）基于高可用、可伸縮微服務架構(gòu)設(shè)計，較原有系統(tǒng)的Monolith 單體架構(gòu)具有更強的服務能力［2-4］。隨著巡檢網(wǎng)元數(shù)量的不斷增加，只須增加服務結(jié)點即可，而原有系統(tǒng)則需要更換性能更好的服務器。

（2）業(yè)務邏輯做到完全解耦，將業(yè)務邏輯內(nèi)聚性高的業(yè)務置于單個微服務中（采用Spring Boot［5-6］開發(fā)），使得新增與修改業(yè)務邏輯變得更為方便。例如：原有交換網(wǎng)元例行測試系統(tǒng)［1］的網(wǎng)元數(shù)據(jù)采集接口具有數(shù)據(jù)采集、報告解析與異常分析功能，每次開發(fā)新的網(wǎng)元接口時，報告解析與異常分析都需要重新寫一遍，可重用性差。

（3）建設(shè)統(tǒng)一的網(wǎng)元數(shù)據(jù)采集平臺，采用分布式內(nèi)存數(shù)據(jù)庫Redis［7-9］對各個應用系統(tǒng)的數(shù)據(jù)采集任務進行統(tǒng)一調(diào)度，實現(xiàn)采集任務的限流與優(yōu)先級調(diào)度。例如：IMS 網(wǎng)元數(shù)據(jù)采集需使用數(shù)據(jù)總線，但該總線除交換網(wǎng)元例行測試系統(tǒng)使用外，其他廠家的巡檢系統(tǒng)也會使用，因此經(jīng)常會出現(xiàn)總線擁堵的情況。

（4）采用采集數(shù)據(jù)緩存方法，某些巡檢任務在一定時間間隔內(nèi)變化微小，可將采集的數(shù)據(jù)存放于共享內(nèi)存數(shù)據(jù)庫并設(shè)置存放時長，在此時間內(nèi)若再有該采集任務，則用緩存內(nèi)采集的數(shù)據(jù)作為本次采集任務的結(jié)果數(shù)據(jù)，從而減少網(wǎng)元上數(shù)據(jù)采集產(chǎn)生的負荷。

（5）采用集群技術(shù)部署邏輯服務，使系統(tǒng)更加穩(wěn)定、可靠。對原有系統(tǒng)采用主程序+看門狗程序進行加固，當某個邏輯服務發(fā)生故障時，不影響系統(tǒng)正常運行。

（6）采用開源的XXL-JOB 任務調(diào)度平臺［10］進行開發(fā)，能夠?qū)ρ矙z任務執(zhí)行情況進行有效監(jiān)控，通過查看日志跟蹤錯誤。

1 系統(tǒng)整體架構(gòu)設(shè)計

網(wǎng)元自動巡檢系統(tǒng)整體分為3 部分：巡檢任務調(diào)度執(zhí)行系統(tǒng)、統(tǒng)一網(wǎng)元數(shù)據(jù)采集平臺和網(wǎng)元。統(tǒng)一網(wǎng)元數(shù)據(jù)采集平臺采用SpringCloud 微服務框架實現(xiàn)，也主要包括3 部分：數(shù)據(jù)采集任務路由服務、網(wǎng)元數(shù)據(jù)采集任務網(wǎng)關(guān)和網(wǎng)元數(shù)據(jù)采集服務，該平臺可作為通用服務開放給其他系統(tǒng)使用。系統(tǒng)整體架構(gòu)如圖1 所示。

1.1 巡檢任務調(diào)度執(zhí)行

采用開源的分布式任務調(diào)度平臺XXL-JOB 作為基礎(chǔ)架構(gòu)進行開發(fā)，主要分為3 個模塊：網(wǎng)元巡檢任務調(diào)度控制中心模塊、巡檢任務執(zhí)行器模塊和采集報告告警分析模塊。各模塊完全解耦，以提高系統(tǒng)整體的穩(wěn)定性和擴展性。

Fig.1 Overall system architecture圖1 系統(tǒng)整體架構(gòu)

調(diào)度中心采用中心式設(shè)計，執(zhí)行器支持集群部署，通過在注冊中心周期性地自動注冊執(zhí)行任務，調(diào)度中心會自動發(fā)現(xiàn)執(zhí)行器，并使用Cron 策略調(diào)度執(zhí)行。

1.1.1 調(diào)度控制中心

調(diào)度中心進行任務調(diào)度時，會解析不同任務參數(shù)發(fā)起遠程調(diào)用，以調(diào)用各自的遠程執(zhí)行器服務。這種調(diào)用模型類似RPC 調(diào)用，調(diào)度中心提供調(diào)用代理功能，而執(zhí)行器提供遠程服務功能。調(diào)度中心自身并不承擔業(yè)務邏輯，只負責發(fā)起調(diào)度請求，將任務抽象成分散的JobHandler，交由執(zhí)行器統(tǒng)一管理。執(zhí)行器專注于任務執(zhí)行等操作，負責接收調(diào)度請求并執(zhí)行對應JobHandler 中的業(yè)務邏輯。

為了實現(xiàn)網(wǎng)元自動巡檢，控制中心設(shè)計以下功能模塊完成巡檢任務的配置、調(diào)度與監(jiān)控。

（1）網(wǎng)元接口管理。對網(wǎng)元連接進行管理，包括：網(wǎng)元ID、網(wǎng)元名稱、網(wǎng)元類型、網(wǎng)元組ID、接口IP、賬號口令、接口版本、網(wǎng)元限流及網(wǎng)元組限流，網(wǎng)元限流小于等于網(wǎng)元組限流。

網(wǎng)元組是指多個網(wǎng)元使用同一個接口，例如：登錄專業(yè)網(wǎng)管，從該網(wǎng)管上發(fā)送巡檢采集數(shù)據(jù)指令，此時接口IP使用網(wǎng)管IP，若該網(wǎng)管上管理了數(shù)十個網(wǎng)元，為避免同一時刻因巡檢采集數(shù)據(jù)在該網(wǎng)管上建立了數(shù)十個連接，而影響網(wǎng)管正常運行，必須配置網(wǎng)元組限流。在網(wǎng)元類型中定義一個特殊的“虛網(wǎng)元”作為網(wǎng)元組，“虛網(wǎng)元”作為網(wǎng)元組的父網(wǎng)元，并不生成巡檢任務。當網(wǎng)元組中只有一個實體網(wǎng)元，此時網(wǎng)元ID 等于網(wǎng)元組ID，且網(wǎng)元限流等于網(wǎng)元組限流；當網(wǎng)元組中有多個實體網(wǎng)元，此時網(wǎng)元ID 不等于網(wǎng)元組ID，且網(wǎng)元限流小于等于網(wǎng)元組限流。

接口版本指定使用哪一個網(wǎng)元數(shù)據(jù)采集微服務，當網(wǎng)元的接口升級后，重新開發(fā)一個數(shù)據(jù)采集微服務并部署到統(tǒng)一的網(wǎng)元數(shù)據(jù)采集平臺，此時修改接口版本后即可實現(xiàn)動態(tài)、平滑地升級網(wǎng)元接口。

（2）作業(yè)項配置。在網(wǎng)元類型上配置作業(yè)項，作業(yè)項配置內(nèi)容包括執(zhí)行指令、作業(yè)項執(zhí)行結(jié)果緩存時長與指令邏輯模板。一個網(wǎng)元類型配置有一個或多個作業(yè)項，一個作業(yè)項配置有一個或多個指令。如華為軟交換（HWSS）配置的巡檢作業(yè)項有5 個：檢查媒體網(wǎng)關(guān)設(shè)備狀態(tài)、檢查MTP目的信令點狀態(tài)、處理器負荷檢查、檢查SCCP 目的信令點狀態(tài)、檢查M3UA 路由狀態(tài)。檢查MTP 目的信令點狀態(tài)配置的執(zhí)行命令有2 個：“LST N7DSP：；”和“DSP N7DSP：DPX=$D1$；”。

作業(yè)項執(zhí)行結(jié)果緩存時長配置：某些作業(yè)項檢查結(jié)果在短時間內(nèi)不會出現(xiàn)較大變化，若此時再有采集任務，則用緩存內(nèi)上次的采集報告作為本次采集結(jié)果。其優(yōu)點是減少頻繁地連接網(wǎng)元，減輕網(wǎng)元運行壓力。

作業(yè)項執(zhí)行超時時長配置：防止因執(zhí)行巡檢作業(yè)項時網(wǎng)元繁忙導致作業(yè)項執(zhí)行超時，影響網(wǎng)元正常運行。

指令邏輯模板配置：邏輯模板分為數(shù)據(jù)邏輯與告警邏輯，數(shù)據(jù)邏輯用于作業(yè)項中某條指令參數(shù)依賴于上條指令執(zhí)行結(jié)果。如華為軟交換（HWSS）的“檢查MTP 目的信令點狀態(tài)”作業(yè)項，第一條指令“LST N7DSP：；”列出所有目的信令點，第二條指令“DSP N7DSP：DPX=$D1$；”為指令模板，其中的參數(shù)$D1$通過執(zhí)行數(shù)據(jù)邏輯得到所有目的信令點具體值，并實例化為多條可執(zhí)行指令。告警邏輯用于分析指令執(zhí)行返回報告中是否存在異常。

（3）執(zhí)行器JobHandler 管理。具體包括：執(zhí)行器名稱（AppName）、說明、任務網(wǎng)關(guān)、發(fā)布者、發(fā)布時間。執(zhí)行器集群的唯一標識為AppName，執(zhí)行器會周期性地以AppName為對象進行自動注冊，供任務調(diào)度時使用。配置任務網(wǎng)關(guān)用于指明該執(zhí)行器任務所使用的任務網(wǎng)關(guān)。

（4）任務調(diào)度管理。針對某一網(wǎng)元類型，將與巡檢任務周期相同的若干作業(yè)項制定為一個巡檢任務。配置項有：任務ID、執(zhí)行器、任務執(zhí)行計劃、網(wǎng)元類型、網(wǎng)元列表、作業(yè)項列表、并發(fā)巡檢數(shù)、任務等級、租戶與任務描述。

執(zhí)行器是該任務執(zhí)行的載體，任務執(zhí)行計劃采用Cron表達式，調(diào)度中心根據(jù)該Cron 表達式周期性地啟動執(zhí)行器，并將參數(shù)任務ID 傳遞給執(zhí)行器。

（5）調(diào)度監(jiān)控。監(jiān)控巡檢任務調(diào)度執(zhí)行狀態(tài)，包括：任務ID、任務名稱、執(zhí)行器名稱、調(diào)度時間、啟動時間、調(diào)度結(jié)果（成功或失敗）、執(zhí)行狀態(tài)（運行中或結(jié)束）。

調(diào)度結(jié)果若失敗，能查看調(diào)度失敗的具體原因。對正在執(zhí)行的任務可人工操作中斷或暫停，暫停后可重新啟動。

（6）網(wǎng)元巡檢報告，查看巡檢作業(yè)項執(zhí)行情況，包括：任務ID、任務名稱、執(zhí)行器名稱、網(wǎng)元名稱、網(wǎng)元類型、作業(yè)項名稱、巡檢時間、巡檢結(jié)果（正常或告警）、報告詳情。

1.1.2 任務執(zhí)行器

執(zhí)行器實際上是一個內(nèi)嵌的服務，每個執(zhí)行器都有機器集群的唯一標識ID、服務IP 與端口。執(zhí)行器啟動后，通過心跳進行執(zhí)行器注冊，調(diào)度中心收到心跳實現(xiàn)自動任務發(fā)現(xiàn)。執(zhí)行器任務是一個Spring 的Bean 類實例，在Spring容器中進行維護，在這個類中實現(xiàn)任務邏輯。

執(zhí)行器的任務類通過注解定義唯一的任務ID，查詢業(yè)務數(shù)據(jù)庫得到具體巡檢任務，包括：任務ID、任務優(yōu)先級、網(wǎng)元類型、網(wǎng)元列表、作業(yè)項列表、任務網(wǎng)關(guān)URL、巡檢網(wǎng)元并發(fā)數(shù)以及每個作業(yè)項對應的指令列表與指令邏輯。

任務被調(diào)度啟動時根據(jù)巡檢網(wǎng)元并發(fā)數(shù)N 啟動N 個線程，線程執(zhí)行步驟如下：①查詢網(wǎng)元列表，若網(wǎng)元列表空則線程結(jié)束，否則從網(wǎng)元列表中取出1 個網(wǎng)元，并將該網(wǎng)元從網(wǎng)元列表中移出；②依次從作業(yè)項列表中取出一個作業(yè)項以及該作業(yè)項對應的執(zhí)行指令序列和指令邏輯；③生成系統(tǒng)唯一的巡檢作業(yè)序列號，發(fā)送巡檢任務參數(shù)（JSON 格式）到統(tǒng)一網(wǎng)元數(shù)據(jù)采集平臺中的巡檢任務路由服務；④接收巡檢返回報告時，通過消息中間件MQ 發(fā)送消息給報告告警分析模塊；⑤當該網(wǎng)元所有作業(yè)項執(zhí)行完畢后，重復第一步。

待N 個線程全部運行結(jié)束，執(zhí)行器完成對某一網(wǎng)元類型的巡檢任務。

1.1.3 巡檢報告告警邏輯分析

報告邏輯分析模塊作為消息中間件MQ 的消息消費者，接收來自任務執(zhí)行器發(fā)送的作業(yè)項，并執(zhí)行返回報告分析請求。根據(jù)執(zhí)行指令配置的告警分析邏輯模板對該指令執(zhí)行報告進行分析，分析結(jié)果連同指令、原始報告、作業(yè)項信息、網(wǎng)元信息、任務信息一起存入業(yè)務數(shù)據(jù)庫。

1.2 統(tǒng)一網(wǎng)元數(shù)據(jù)采集平臺

平臺接收來自上層應用系統(tǒng)的網(wǎng)元數(shù)據(jù)采集請求，請求參數(shù)包括：任務流水號、任務ID、任務優(yōu)先級、作業(yè)項ID、網(wǎng)元ID、網(wǎng)元組ID、網(wǎng)元限流、網(wǎng)元組限流、緩存時長、采集超時時間、指令列表、指令分析邏輯、任務網(wǎng)關(guān)服務名、采集服務名。采集任務完成后，平臺返回任務流水號、任務ID、作業(yè)項ID、網(wǎng)元ID、指令、指令邏輯、指令執(zhí)行報告與采集時間。

1.2.1 巡檢任務路由服務

該服務直接接收來自巡檢任務調(diào)度中心任務執(zhí)行器發(fā)送的巡檢任務請求，從請求參數(shù)中解析出任務網(wǎng)關(guān)服務名，調(diào)用對應的服務網(wǎng)關(guān)并轉(zhuǎn)發(fā)請求參數(shù)，同步等待返回采集數(shù)據(jù)。

根據(jù)網(wǎng)元數(shù)量，采集平臺部署了多個該任務網(wǎng)關(guān)服務名的微服務，因此路由服務還具有負載均衡功能。負載均衡 采 用Netflix 提 供 的 框 架Feign，F(xiàn)eign 整 合 了Ribbon 與Hystrix。Feign 是一個聲明式的Web Service 客戶端，完全代理HTTP 請求，通過編寫簡單的接口和插入注解，即可定義好HTTP 請求的參數(shù)、格式、地址等信息，使用極其方便。

1.2.2 任務網(wǎng)關(guān)

任務網(wǎng)關(guān)是采集平臺的核心模塊，任務網(wǎng)關(guān)微服務名按網(wǎng)元類型命名，具有同一服務名的任務網(wǎng)關(guān)通常有多個，以負載均衡方式接收來自路由服務的巡檢任務請求。主要實現(xiàn)以下功能：①采集任務分發(fā)功能。根據(jù)巡檢任務請求參數(shù)中的采集服務名，將采集任務分發(fā)到相應的采集服務；②采集任務優(yōu)先級控制。優(yōu)先分發(fā)優(yōu)先級高的采集任務；③限流功能。用于解決以往因采集任務頻繁導致的資源搶占等問題，限流內(nèi)容包括：單個網(wǎng)元限流和網(wǎng)元組限流；④采集數(shù)據(jù)緩存功能。將采集的數(shù)據(jù)按照請求參數(shù)中的緩存時長保存在采集平臺中，若在緩存時長內(nèi)有同樣的采集任務，則使用緩存內(nèi)采集的數(shù)據(jù)，以減輕網(wǎng)元壓力。

1.2.3 采集服務

接收來自任務網(wǎng)關(guān)的采集任務請求，一個采集任務包括若干條有順序的指令以及指令數(shù)據(jù)邏輯。根據(jù)請求參數(shù)中的網(wǎng)元連接參數(shù)，連接并登錄網(wǎng)元，按順序發(fā)送采集指令，獲取返回報告。若指令配置有數(shù)據(jù)邏輯，則調(diào)用采集平臺中的報告邏輯分析服務，得到報告中的關(guān)鍵數(shù)據(jù)作為后續(xù)指令參數(shù)。所有指令執(zhí)行完畢后斷開網(wǎng)元連接，將指令及指令報告返回給任務網(wǎng)關(guān)。

1.3 網(wǎng)元

網(wǎng)元層中的網(wǎng)元按照專業(yè)可劃分為數(shù)據(jù)專業(yè)、傳輸專業(yè)、交換專業(yè)、無線專業(yè)等。按照類型可劃分為：PSTN、

NGN、MSCE、MGW、LSTP、AG、TG、HLR、MGCF、PCSCF、HSTP、OLT、BAS、ONU、SDH、MSAP、RRU、BSC 等。

2 關(guān)鍵模塊設(shè)計實現(xiàn)

2.1 任務網(wǎng)關(guān)設(shè)計

任務網(wǎng)關(guān)基于Spring Boot 設(shè)計，分布式內(nèi)存數(shù)據(jù)庫Redis 為任務網(wǎng)關(guān)集群所使用，并在任務網(wǎng)關(guān)進程內(nèi)存上開辟作業(yè)項執(zhí)行排隊區(qū)和作業(yè)項執(zhí)行報告區(qū)，作業(yè)調(diào)度模塊根據(jù)作業(yè)優(yōu)先級、限流、超時參數(shù)對作業(yè)項進行調(diào)度，作業(yè)執(zhí)行模塊對調(diào)度成功的作業(yè)項調(diào)用對應采集服務，取得作業(yè)項執(zhí)行報告。任務網(wǎng)關(guān)結(jié)構(gòu)設(shè)計如圖2 所示。

Fig.2 Task gateway software module structure圖2 任務網(wǎng)關(guān)軟件模塊結(jié)構(gòu)

任務網(wǎng)關(guān)接收來自任務路由的作業(yè)項請求，進行任務限流與優(yōu)先級調(diào)度后，分發(fā)給相應的采集服務并接收返回報告。

2.1.1 任務網(wǎng)關(guān)服務控制器

采用注解@RequestMapping 將任務路由HTTP 請求映射到REST 控制器的作業(yè)項執(zhí)行方法上，該方法處理過程如下：

（1）解析執(zhí)行的作業(yè)項參數(shù)（緩存時長）確定是否緩存采集報告。若緩存時長大于零，則從Redis 中獲取；若超時獲取不到或緩存時長等于零，則將作業(yè)項放入作業(yè)項執(zhí)行排隊區(qū)。

（2）等待作業(yè)項調(diào)度結(jié)果，定時查詢作業(yè)項執(zhí)行區(qū)，若超過作業(yè)執(zhí)行超時時間，則返回結(jié)果失敗。獲取到作業(yè)后，根據(jù)作業(yè)項參數(shù)中的采集服務名，將作業(yè)項轉(zhuǎn)發(fā)到對應的采集服務。

（3）等待采集結(jié)果，若采集成功且緩存時長大于零，則將采集報告存放到Redis 中，最后返回作業(yè)項執(zhí)行結(jié)果。

2.1.2 任務網(wǎng)關(guān)內(nèi)存緩存區(qū)

在任務網(wǎng)關(guān)進程內(nèi)部創(chuàng)建作業(yè)項緩存區(qū)作為進程內(nèi)部線程共享，因此在緩存區(qū)上必須加互斥鎖進行訪問。作業(yè)項緩存區(qū)分為作業(yè)項執(zhí)行排隊等待區(qū)和作業(yè)項執(zhí)行報告區(qū)。

作業(yè)項執(zhí)行排隊等待區(qū)采用隊列方式，隊列中的每一項按照網(wǎng)元組ID 進行區(qū)分，并存放對應該網(wǎng)元組ID 內(nèi)所有網(wǎng)元的作業(yè)項。在隊列上實現(xiàn)放入與取出作業(yè)項兩項操作。

每次放入一個作業(yè)項，根據(jù)該作業(yè)項的網(wǎng)元組ID 掃描排隊等待區(qū)，若隊列中存在該網(wǎng)元組ID，則將作業(yè)項放入隊列中的對應項；若不存在，則在隊列中創(chuàng)建新項。

從排隊等待區(qū)中取出作業(yè)項的調(diào)度策略如下：掃描排隊等待區(qū)，刪除等待超時的作業(yè)項，同一網(wǎng)元上作業(yè)項優(yōu)先級高的先執(zhí)行，相同優(yōu)先級的作業(yè)項則等待時間長的先執(zhí)行。通過網(wǎng)元組ID 檢索正在執(zhí)行作業(yè)項列表，統(tǒng)計所在網(wǎng)元組正在執(zhí)行的網(wǎng)元數(shù)量。對比所在網(wǎng)元組限流，只有在未超出設(shè)定的網(wǎng)元組限流時，方可取出并執(zhí)行該網(wǎng)元的作業(yè)項。

作業(yè)項執(zhí)行結(jié)果報告區(qū)同樣實現(xiàn)放入和取出結(jié)果報告兩個操作，作業(yè)項調(diào)度成功執(zhí)行后放入執(zhí)行結(jié)果報告，并采用任務網(wǎng)關(guān)服務控制器取出執(zhí)行結(jié)果報告。

2.1.3 分布式內(nèi)存設(shè)計

分布式內(nèi)存數(shù)據(jù)庫采用Redis，其是一個高性能的Key Value 數(shù)據(jù)庫，被任務網(wǎng)關(guān)集群共享，支持多種類型的數(shù)據(jù)結(jié)構(gòu)，可實現(xiàn)數(shù)據(jù)緩存。

基于Spring 與Redis 的RedisTemplate 工具類實現(xiàn)列表List 上的以下操作：獲取list 緩存長度、通過索引獲取list 中的值、將list 放入緩存、根據(jù)索引修改list 中的某條數(shù)據(jù)，以及從list 中移除某條數(shù)據(jù)。采用網(wǎng)元組ID 為每個list 創(chuàng)建唯一的Key，list 中存放對應網(wǎng)元組中的網(wǎng)元作業(yè)項。

集群上多個任務網(wǎng)關(guān)存在同時操作共享內(nèi)存中l(wèi)ist 的情況，同樣采用Redis 的RedisTemplate 工具類實現(xiàn)分布式全局鎖類，提供獲取鎖和釋放鎖兩種方法。采用網(wǎng)元組ID為每個list 創(chuàng)建唯一鎖名稱，當要操作該列表時，先要獲取該列表的鎖，獲取成功方可進行操作，操作結(jié)束則釋放該鎖。

共享內(nèi)存上定義了兩種類型的列表：正在執(zhí)行作業(yè)項列表和作業(yè)項執(zhí)行結(jié)果列表，以網(wǎng)元組ID 作為列表鍵值。正在執(zhí)行作業(yè)項列表的作用是實現(xiàn)集群上的網(wǎng)元組限流，通過加入與移出作業(yè)項兩個操作實現(xiàn)。

加入正在執(zhí)行作業(yè)項列表的過程如下：①根據(jù)加入的作業(yè)項網(wǎng)元組ID 獲取需要操作的列表鎖；②獲取列表長度，即為正在執(zhí)行的網(wǎng)元組流量，若大于等于作業(yè)項網(wǎng)元組限流值，則加入失敗；③計算列表中與加入作業(yè)項中與網(wǎng)元ID 相同的作業(yè)項個數(shù)，即為網(wǎng)元流量，若大于等于作業(yè)項網(wǎng)元限流值，則加入失敗；④加入作業(yè)項時設(shè)置緩存時長等于作業(yè)項執(zhí)行超時時長，釋放列表上的鎖。

正在執(zhí)行作業(yè)項列表中的數(shù)據(jù)刪除有兩種方式，一種是Redis 自動按照緩存時長進行刪除，另一種是調(diào)用移出方法。

作業(yè)項執(zhí)行結(jié)果緩存區(qū)數(shù)據(jù)以列表方式存放，并設(shè)置存放時長閾值，當緩存數(shù)據(jù)存放時間超過該閾值，Redis 則自動清除。列表上實現(xiàn)加入與獲取兩種操作，操作前取得對應列表的鎖，操作結(jié)束后釋放。操作前根據(jù)作業(yè)項ID、網(wǎng)元ID 搜索列表中已存在的執(zhí)行結(jié)果，若搜索到則將緩存中的數(shù)據(jù)作為當前作業(yè)項執(zhí)行結(jié)果，否則再次執(zhí)行作業(yè)項并加入新的作業(yè)項執(zhí)行結(jié)果到緩存區(qū)。

2.1.4 作業(yè)項調(diào)度執(zhí)行

作業(yè)項調(diào)度執(zhí)行模塊作為獨立線程在任務網(wǎng)關(guān)啟動時創(chuàng)建并運行，執(zhí)行過程如圖3 所示。

Fig.3 Task item scheduling execution process圖3 作業(yè)項調(diào)度執(zhí)行流程

由圖3 可見，調(diào)度流程主要分為3 步：

步驟1：按照作業(yè)優(yōu)先級、作業(yè)項等待執(zhí)行先后順序以及在單個任務網(wǎng)關(guān)內(nèi)的限流，初步獲取可執(zhí)行的作業(yè)項，同時刪除等待超時的作業(yè)項。

步驟2：將獲取到的初步可執(zhí)行作業(yè)項加入分布式共享內(nèi)存作業(yè)項列表執(zhí)行過程中，完成在任務網(wǎng)關(guān)集群上的限流，此時將有部分作業(yè)項加入失敗。對于被成功加入的作業(yè)項，由作業(yè)執(zhí)行模塊調(diào)用對應的采集服務并取回采集結(jié)果報告。

步驟3：將調(diào)度執(zhí)行失敗的作業(yè)項重新加入作業(yè)項執(zhí)行排隊等待區(qū)，等待再次被調(diào)度執(zhí)行或超時刪除。

2.2 報告邏輯分析

網(wǎng)元巡檢數(shù)據(jù)采集報告是具有特定格式的文本型數(shù)據(jù)，并且各廠家不同網(wǎng)元類型的報告格式千差萬別。通常使用文本處理語言（如：Awk、Perl）進行處理，本文采用自己的專利方法：基于邏輯模板的文本邏輯分析［11］，其優(yōu)點是不再需要編寫復雜的文本分析腳本，只需通過簡單的邏輯模板進行配置即可，從而調(diào)整分析邏輯或部署新的分析邏輯，更加靈活、快捷。

該專利方法的思想是：將文本數(shù)據(jù)格式化為行列式數(shù)據(jù)，創(chuàng)建數(shù)據(jù)庫內(nèi)存表存放格式化后的文本數(shù)據(jù)，在此數(shù)據(jù)庫表上編寫SQL。分析邏輯分為告警分析邏輯和數(shù)據(jù)分析邏輯，告警分析邏輯用于查看文本中是否存在某些關(guān)鍵數(shù)據(jù)，而數(shù)據(jù)分析邏輯用于獲取文本中的若干數(shù)據(jù)，獲取的數(shù)據(jù)作為作業(yè)項指令參數(shù)。

現(xiàn)以華為軟交換“檢查M3UA 路由狀態(tài)”作業(yè)項為例進行說明，作業(yè)項配置兩條指令：“LST M3RT：；”和“DSP M3RT：DEX=$D1$，LSX=$D2$；”，參數(shù)“目的實體索引（DEX）”和“鏈路集索引（LSX）”由第一條指令執(zhí)行報告通過數(shù)據(jù)邏輯分析得到，第二條指令應該是指令模板，參數(shù)值使用通配符，由該指令模板生成若干條可執(zhí)行指令。報告的格式化：以換行符獲取每一行，以空格獲取行內(nèi)字段。字段名為：F1，F(xiàn)2，F(xiàn)3…

第一條指令的返回報告如下：

+++ GL-SoftX 2020-10-10 16：24：56

O&M #1911562

%%LST M3RT：；%%

RETCODE = 0 操作成功

M3UA 路由信息

------------

路由名稱 目的實體索引 鏈路集索引 路由優(yōu)先級 主/從歸屬標志

NJ-YFXJ-MS01-M 20 0 0 從歸屬

NJ-YFXJ-MS01-M-1 20 1 0 從歸屬

……

（結(jié)果個數(shù)= 30）

--- END

在這條指令上配置數(shù)據(jù)邏輯，獲取“目的實體索引”和“鏈路集索引”。邏輯表達式“select F2，F(xiàn)3 from mytable where IsNumber（F2）and IsNumber（F3）IsNumber（F4）”的含義是：獲取字段2、3、4 為數(shù)字所有行中字段2 和字段3 的數(shù)據(jù)，其中“IsNumber”是數(shù)據(jù)庫中自定義的函數(shù)，采用正值表達式判斷函數(shù)的參數(shù)是否為數(shù)字。

第二條指令的返回報告如下：

+++ GL-SoftX 2020-10-10 16：55：39

O&M #1912218

%%DSP M3RT：DEX=20，LSX=0；%%

RETCODE = 44650 由于軟交換工作處于去激活模式，且所操作的對象為從歸屬，所以該對象未安裝，操作不能進行

--- END

指令參數(shù)：DEX=20，LSX=0，由第一條指令通過數(shù)據(jù)邏輯分析得到。報告配置告警邏輯分析表達式為“select *from mytable where F1=‘RETCODE’and F3＜＞‘0’”，含 義為：查詢RETCODE 不等于零的行，若存在則報告異常。

3 結(jié)語

針對現(xiàn)有網(wǎng)元巡檢系統(tǒng)運行過程中暴露出的問題，由于多個系統(tǒng)使用了如數(shù)據(jù)總線之類的公共資源，對原有系統(tǒng)進行改造顯然無法解決該問題。本文借助微服務架構(gòu)與分布式共享內(nèi)存數(shù)據(jù)庫設(shè)計統(tǒng)一的網(wǎng)元數(shù)據(jù)采集平臺，對多個系統(tǒng)使用的公共資源進行統(tǒng)一調(diào)配，解決了諸如任務量限流等問題。該方式既保證了存量系統(tǒng)可繼續(xù)使用，從而避免重復建設(shè)，節(jié)省投資，又新建了基于集群技術(shù)的網(wǎng)元自動巡檢調(diào)度系統(tǒng)，可為新建的5G 網(wǎng)元巡檢服務。