羅桂林 張勇 李偉 任亞飛 公安部第一研究所

引言

機(jī)場安檢系統(tǒng)包括機(jī)場柜臺式分層管理系統(tǒng)、機(jī)場主帶式分層管理系統(tǒng)、機(jī)場信息管理系統(tǒng)、貨運(yùn)機(jī)場分層管理信息系統(tǒng)，它們都不是孤立運(yùn)營的，與機(jī)場很多系統(tǒng)都有接口。與安檢系統(tǒng)進(jìn)行對外接口的系統(tǒng)包括安檢信息管理系統(tǒng)、離港系統(tǒng)、行李處理系統(tǒng)和公安系統(tǒng)等外部系統(tǒng)[1]。隨著技術(shù)的升級和時間的推移，不同外部系統(tǒng)采用接口技術(shù)方式也不盡相同，安檢系統(tǒng)對外接口方式包括Socket、MQ、Web Services、RESTful等接口模式[1,2]。不同外部系統(tǒng)多種接口模式給安檢系統(tǒng)的開發(fā)和維護(hù)也帶來了復(fù)雜性。如圖1所示，通過基于MEF的安檢外部系統(tǒng)接口平臺（以下簡稱“安檢接口平臺”）實(shí)現(xiàn)了安檢系統(tǒng)與外部系統(tǒng)的多種接口技術(shù)形態(tài)的接口功能，解決了外部系統(tǒng)接口的開發(fā)和維護(hù)問題[2]。安檢接口平臺自從2018年在廣州白云國際機(jī)場T2航站樓首次使用以來，到目前為止全國已有近45家機(jī)場部署使用。

一、問題的提出

安檢接口平臺，在安檢系統(tǒng)正常運(yùn)行中起著關(guān)鍵作用，是機(jī)場整個安檢流程的重要銜接環(huán)境[1]，如果出現(xiàn)了不可用情況，或發(fā)生了故障，將會影響安檢業(yè)務(wù)，甚至?xí)苯訉?dǎo)致機(jī)場安檢業(yè)務(wù)中斷。

傳統(tǒng)的運(yùn)行管理維護(hù)模式是根據(jù)部署的外部系統(tǒng)接口制定巡檢表，由運(yùn)管人員定期進(jìn)行人工巡檢。2020年，某機(jī)場運(yùn)管人員在凌晨4:30完成了對機(jī)房通訊服務(wù)器的巡檢，然而主通訊服務(wù)器4:45發(fā)生宕機(jī)故障，接口切換到備用通訊服務(wù)器上運(yùn)行，隨后備用服務(wù)器CPU負(fù)載逐步攀升到100%，導(dǎo)致接口處理數(shù)據(jù)積壓，影響機(jī)場旅客登機(jī)，致使航班延誤。人工巡檢雖然緩解了故障和問題的滯后，但也不可避免地引入不可靠、不及時、運(yùn)管人員水平與責(zé)任心參差不齊等諸多不利因素[3-5]。

設(shè)計與實(shí)現(xiàn)監(jiān)控系統(tǒng)的目的在于在故障發(fā)生萌芽階段，或者影響范圍很小的時候，將故障通過微信、短信等方式告知運(yùn)管人員，最小化地減少故障可能造成的損失，保障安檢接口平臺可靠平穩(wěn)運(yùn)行，以此保障機(jī)場業(yè)務(wù)系統(tǒng)運(yùn)行，以減輕運(yùn)管人員的工作負(fù)壓。

設(shè)計與實(shí)現(xiàn)監(jiān)控系統(tǒng)的主要問題在于如何實(shí)現(xiàn)與具體外部系統(tǒng)和具體接口方式無關(guān)的監(jiān)控系統(tǒng)，具體來說，如何采集與具體外部系統(tǒng)和具體接口方式無關(guān)的監(jiān)控指標(biāo)相關(guān)數(shù)據(jù)。

二、關(guān)鍵技術(shù)

微軟可拓展MEF框架，為解決接口平臺與具體接口方式之間的直接依賴、涉及監(jiān)控系統(tǒng)功能提供了技術(shù)方案。

MEF是用于創(chuàng)建輕量、可擴(kuò)展應(yīng)用程序的庫，是.NET 4.0的組成部分。MEF不僅讓應(yīng)用程序在無需配置的前提下發(fā)現(xiàn)和擴(kuò)展協(xié)定組件，還可以讓開發(fā)人員得以輕松地封裝代碼并避免脆弱的緊密依賴性。MEF核心概念如下[2,5]：

（1）Export（導(dǎo)出）組件、模塊、服務(wù)、插件，它向容器中的其它部件提供的功能和服務(wù)等；

（2）Import（導(dǎo)入）是組件、服務(wù)、插件等接入系統(tǒng)的窗口，MEF支持若干導(dǎo)入類型，其中包括動態(tài)導(dǎo)入、延遲導(dǎo)入、必備導(dǎo)入和可選導(dǎo)入。

Contract（協(xié)定）是Export和Import的一種約定，只有Contract相匹配的Import和Export部件才能組裝成功。

三、研究與設(shè)計

（一）安檢接口平臺

圖2為安檢接口平臺設(shè)計原理圖，其中，虛線框內(nèi)為本文設(shè)計與實(shí)現(xiàn)的監(jiān)控系統(tǒng)功能。針對安檢各子系統(tǒng)與外部系統(tǒng)之間處理的消息遵循一定消息規(guī)范以及處理消息邏輯也基本相同的特點(diǎn)，安檢接口平臺規(guī)范了各子系統(tǒng)消息處理流程。針對安檢各子系統(tǒng)與外部系統(tǒng)存在不同的接口方式，不同接口方式是由不同接口訪問器實(shí)現(xiàn)，安檢接口平臺則是參照MEF導(dǎo)出、導(dǎo)入和協(xié)定等概念設(shè)計并實(shí)現(xiàn)了基于.NET 2.0輕量級MEF框架（EasyMEF）的接口訪問器動態(tài)裝載器，用于動態(tài)加載訪問外部系統(tǒng)的對象模型庫、接口訪問器、消息處理器和消息解析器。這樣徹底避免接口平臺與外部系統(tǒng)的直接依賴，實(shí)現(xiàn)了不同接口方式的接口訪問器“即插即用”[2]。

在安檢接口平臺中，實(shí)現(xiàn)監(jiān)控系統(tǒng)的解決方案在于接口訪問器記錄接口接收報文數(shù)、發(fā)送報文數(shù)、接收隊列報文數(shù)、發(fā)送隊列報文數(shù)，并通過屬性字段開放給安檢接口平臺。安檢接口平臺定期采集這些數(shù)據(jù)，并以結(jié)構(gòu)化的數(shù)據(jù)形式寫入日志文件中，供監(jiān)控數(shù)據(jù)采集模塊提取使用。

（二）監(jiān)控內(nèi)容

監(jiān)控對象是通訊服務(wù)器和安檢接口平臺軟件，監(jiān)控內(nèi)容包括性能監(jiān)控和業(yè)務(wù)監(jiān)控，具體如下：

（1）通訊服務(wù)器基礎(chǔ)設(shè)施性能監(jiān)控指標(biāo)：CPU占用率、內(nèi)存占用率、磁盤讀寫速度、網(wǎng)卡收發(fā)速度；

（2）安檢接口平臺軟件性能監(jiān)控指標(biāo)：每分鐘接收報文數(shù)、每分鐘發(fā)送報文數(shù)和每分鐘處理接收報文數(shù)；

隨著市場環(huán)境的變化和營銷實(shí)踐的迅速發(fā)展，營銷理念和方式也在發(fā)生著變化。20世紀(jì)70年代以后，以菲利浦·科特勒為代表的學(xué)者更多地將文化與營銷結(jié)合起來，認(rèn)為營銷活動是一種社會現(xiàn)象。文化因素因成為市場營銷和戰(zhàn)略管理中十分重要的領(lǐng)域而被重視。文化營銷作為一種營銷方式，被廣泛運(yùn)用于營銷實(shí)踐中。

（3）安檢接口平臺軟件業(yè)務(wù)監(jiān)控指標(biāo)：接口工作狀態(tài)、接收隊列深度、發(fā)送隊列深度。

（三）監(jiān)控系統(tǒng)架構(gòu)與功能設(shè)計

圖3為監(jiān)控系統(tǒng)架構(gòu)與功能設(shè)計圖。一般地，計算機(jī)監(jiān)控系統(tǒng)包括數(shù)據(jù)采集、預(yù)處理分析與監(jiān)控展示三個方面的功能[6]。

1.數(shù)據(jù)采集功能模塊

數(shù)據(jù)采集功能模塊采集的數(shù)據(jù)包括通訊服務(wù)器基礎(chǔ)設(shè)施的性能數(shù)據(jù)、安檢接口平臺軟件性能數(shù)據(jù)以及安檢接口平臺軟件業(yè)務(wù)監(jiān)控數(shù)據(jù)：

（1）通訊服務(wù)器基礎(chǔ)設(shè)施的性能數(shù)據(jù)采集：通訊服務(wù)器上安裝Cscollect采集模塊，每隔1分鐘采集服務(wù)器的CPU 占用率、內(nèi)存占用率、磁盤讀寫速度、網(wǎng)卡收發(fā)速度、線程數(shù)量以及進(jìn)程數(shù)量等信息，并寫入Cscollect influxdb時序數(shù)據(jù)庫；

（2）安檢接口平臺性能數(shù)據(jù)采集：通訊服務(wù)器上安裝Fmbcounter接口日志分析模塊，提取每分鐘接收報文數(shù)、每分鐘發(fā)送報文數(shù)和每分鐘處理接收報文數(shù)，并寫入Fmb influxdb時序數(shù)據(jù)庫；

（3）安檢接口平臺業(yè)務(wù)數(shù)據(jù)采集：采集隊列深度和發(fā)送隊列深度，并寫入Fmb influxdb時序數(shù)據(jù)庫。

2.監(jiān)控預(yù)處理分析功能模塊

3.監(jiān)控展示功能模塊

（1）監(jiān)控服務(wù)器安裝Grafana模塊，用于展示Cscollect和Fmbcounter采集的數(shù)據(jù)，通過監(jiān)控面板可實(shí)時查看通訊服務(wù)器CPU、內(nèi)存、接口性能指標(biāo)趨勢；

（2）對于CSServices分析模塊提取的異常信息，一方面，通過調(diào)用短信貓SDK推送報警信息，實(shí)現(xiàn)手機(jī)短信通知報警信息；另一方面，通過調(diào)用WebApi訪問微信接口推送報警信息，實(shí)現(xiàn)微信服務(wù)號通知報警信息。

四、應(yīng)用案例

在某機(jī)場安檢信息管理系統(tǒng)項(xiàng)目中，通訊服務(wù)器CS1部署安檢接口平臺離港系統(tǒng)接口模塊和Cscollect數(shù)據(jù)采集模塊。圖4是Cscollect模塊采集的CPU指標(biāo)原始數(shù)據(jù)。Cscollect模塊每分鐘采集一次性能數(shù)據(jù)，并寫入Cscollect數(shù)據(jù)庫。

如圖5所示，Grafana面板展示CS1 CPU負(fù)載率面板。CS1紅色橢圓框的時間序列大致為11:52，11:52之前，CS1上運(yùn)行接口程序，CPU占用率正常。11:52操作系統(tǒng)因故障重啟，操作系統(tǒng)重啟后，由于系統(tǒng)未登錄運(yùn)行接口模塊。后臺CSService模塊通過分析11:52之前的負(fù)載趨勢和11:52之后的負(fù)載趨勢比對，可形成告警信息，通過微信服務(wù)號、短信通知相關(guān)運(yùn)管人員，如圖6所示。

在某機(jī)場智能安檢通道項(xiàng)目中，在CS1、CS2服務(wù)器上采用負(fù)載均衡方式部署了統(tǒng)一接口平臺離港系統(tǒng)接口模塊。如圖7所示，為該機(jī)場安檢接口平臺監(jiān)控分析面板。

圖7（a）、（c）為CS1和CS2離港系統(tǒng)接口內(nèi)存隊列深度（從離港接收的報文，放入內(nèi)存隊列，等待處理的報文數(shù)）趨勢圖，從圖7（a）示意圖中可以看出內(nèi)存隊列最大深度為418個報文，該數(shù)值表示某分鐘內(nèi)接口瞬時等待處理的報文數(shù)。以此圖觀察接口內(nèi)存待處理報文數(shù)，如果最大深度大于50，一直增長且沒有下降的趨勢，則需要重點(diǎn)關(guān)注接口運(yùn)行狀況。

圖7（b）、（d）為CS1和CS2離港系統(tǒng)接口模塊每分鐘接收離港報文和處理離港報文比對趨勢圖，從圖7（d）示意圖中可得知接口每分鐘平均處理27個旅客報文，最大可處理423個報文。通過此圖接口處理報文速度等同于接口接收報文。

圖7（e）示意分別為CS1和CS2心跳接口5分鐘統(tǒng)計圖。按照接口協(xié)議規(guī)范要求，接口每隔30秒發(fā)送心跳報文?？梢缘弥奶涌诿?分鐘平均向離港系統(tǒng)發(fā)送10個心跳報文，以此圖觀察接口是否存活，是否正常工作。

圖7（f）為離港系統(tǒng)接口接收報文統(tǒng)計圖，通過此圖可以觀察接口接收報文數(shù)量的增長趨勢。

如圖8所示，為該機(jī)場離港系統(tǒng)接口報文內(nèi)存駐留時間趨勢圖。內(nèi)存駐留時間計算訪問為：接口完成處理時間T1-接口接收時間T0。接口上線穩(wěn)定運(yùn)行后，接口平均處理時間為1018ms，而最大處理時間為1770ms，均未超過3000ms，符合業(yè)務(wù)功能設(shè)計。

五、結(jié)語

安檢接口平臺的監(jiān)控系統(tǒng)，旨在改變傳統(tǒng)人工巡檢模式的運(yùn)行維護(hù)管理模式，不僅可以提升運(yùn)管人員維護(hù)的質(zhì)量，還能讓運(yùn)管人員清楚地看見安檢接口平臺運(yùn)行情況、發(fā)展趨勢和可能的故障隱患，實(shí)現(xiàn)事前監(jiān)管、事后管理。未來，可作為安檢接口平臺的附加功能推廣，一段時期內(nèi)必然有生存和發(fā)展空間。