摘? 要：本文的研究目標(biāo)是深入結(jié)合稅務(wù)業(yè)務(wù)，通過引入應(yīng)用性能管理的技術(shù)模式，實時監(jiān)測分析業(yè)務(wù)數(shù)據(jù)，快速找到故障源，形成一套面向稅務(wù)平臺的健康監(jiān)測分析系統(tǒng)。首先通過采集網(wǎng)絡(luò)數(shù)據(jù)流，對碎片化的TCP/IP報文實現(xiàn)業(yè)務(wù)還原;其次對還原的業(yè)務(wù)數(shù)據(jù)進行軌跡跟蹤，實時生成軌跡跟蹤鏈;再次對軌跡跟蹤鏈進行健康指標(biāo)計算，并對計算結(jié)果進行單位時間內(nèi)的統(tǒng)計;最后持久化入庫，為運維管理人員提供系統(tǒng)健康狀況的查詢和展示功能，并對異常故障點及時告警。

關(guān)鍵詞：監(jiān)測分析;業(yè)務(wù)健康;稅務(wù)大數(shù)據(jù);運維監(jiān)控

中圖分類號：TP311.5? ? ? 文獻標(biāo)識碼：A 文章編號：2096-4706（2019）24-0009-06

Abstract：The research objective of this paper is to form a set of health monitoring and analysis system for tax platform by deeply combining tax business，introducing technical mode of business performance management，real-time monitoring and analysis of business data，and rapid positioning of fault sources of the system. Firstly，the network data stream is collected to restore the fragmented TCP/IP packets. Secondly，track the restored business data and generate track tracking chain in real time. The health index of track tracking chain was calculated again and the calculated results were counted in unit time. Finally，persistent warehousing provides query and presentation for operation and maintenance managers.

Keywords：monitoring analysis;business health;tax big data;operation and maintenance monitoring

0? 引? 言

歷經(jīng)了十?dāng)?shù)年的發(fā)展，信息化技術(shù)已經(jīng)深入扎根于稅務(wù)業(yè)務(wù)的活動當(dāng)中，成為稅務(wù)發(fā)展的一項重要推動力;新技術(shù)、新架構(gòu)的不斷運用，解決了日益增長的業(yè)務(wù)需求，相關(guān)稅收應(yīng)用系統(tǒng)的數(shù)量由少至多，程序不斷升級，從單一系統(tǒng)模式逐步發(fā)展到目前以金稅三期工程為主的稅務(wù)平臺的規(guī)?；w系，系統(tǒng)復(fù)雜程度越來越高，這就給系統(tǒng)的運維工作提出了更高的要求。

本文圍繞以金稅三期工程為主的核心稅務(wù)應(yīng)用系統(tǒng)，以APM（Application Performance Management & Monitoring）技術(shù)思路為主導(dǎo)，對系統(tǒng)的運行原理、流程模型和通訊機制進行了研究與分析。利用流式計算結(jié)構(gòu)實現(xiàn)對稅務(wù)平臺海量業(yè)務(wù)數(shù)據(jù)的實時性處理;并通過健康分析模型，對業(yè)務(wù)數(shù)據(jù)流經(jīng)每個業(yè)務(wù)環(huán)節(jié)的性能指標(biāo)進行實時監(jiān)測分析，對業(yè)務(wù)系統(tǒng)整體健康狀況進行評估，對可能導(dǎo)致系統(tǒng)故障的指標(biāo)偏離進行預(yù)警，對在業(yè)務(wù)流程中出現(xiàn)問題的具體環(huán)節(jié)進行精確定位，最后總結(jié)出適合稅務(wù)平臺健康監(jiān)測分析系統(tǒng)的整體技術(shù)方案，完成了稅務(wù)平臺健康檢測分析系統(tǒng)的開發(fā)實現(xiàn)和測試，并在實際環(huán)境中進行了驗證。

1? 國內(nèi)外相關(guān)研究綜述

金稅工程是國家電子政務(wù)“十二金”[1]工程之一，是國家建設(shè)中具有重要戰(zhàn)略地位的信息系統(tǒng)工程，通過搭建統(tǒng)一的納稅服務(wù)平臺，實現(xiàn)了我國稅收數(shù)據(jù)的集中[2]。金稅工程共經(jīng)歷了三個建設(shè)階段，自1994年到2001年分別經(jīng)歷了“金稅一期”和“金稅二期”建設(shè)階段;在2008年9月24日，發(fā)改委正式批準(zhǔn)金稅三期初步設(shè)計方案和中央投資預(yù)算，標(biāo)志“金稅三期”工程正式啟動[3]。

1.1? 稅務(wù)平臺運維發(fā)展現(xiàn)狀和存在的問題

《金稅工程（三期）總體實施方案》中提出了“通過建立一個以省級運維為基礎(chǔ)、總局運維為后盾的規(guī)范化、標(biāo)準(zhǔn)化、制度化的集中管理的運維體系，完成對稅務(wù)信息系統(tǒng)運行狀態(tài)的全面監(jiān)控和運行問題的及時處理，支持應(yīng)用系統(tǒng)的安全、穩(wěn)定、高效、持續(xù)運行”的目標(biāo)[4]。從目前省級稅務(wù)平臺運維建設(shè)情況看，運維服務(wù)是由總局統(tǒng)一指揮要求，各省信息中心具體實施，既保證了運維規(guī)范化，也可以保證各地具備根據(jù)實際情況進行運維的靈活性，并逐步向成熟可靠的運維機制，全面覆蓋運維工作的方向發(fā)展。但是稅務(wù)平臺運維工作的高度復(fù)雜性決定了還有很多不足的地方需要不斷完善，當(dāng)前所有問題中比較突出的問題還是龐大的運維人員隊伍管理和不夠智能化的運維工具平臺帶來的麻煩。

首先稅務(wù)平臺運行的系統(tǒng)非常龐大，涉及的技術(shù)公司眾多，每個運行系統(tǒng)都可能需要安排一家公司的運維團隊駐場工作，這就造成了信息中心的運維管理難度越來越大;其次各運行系統(tǒng)之間的配合協(xié)作越來越密切，出現(xiàn)系統(tǒng)問題后已經(jīng)不能僅僅通過對獨立的系統(tǒng)分析尋找問題，因此需要在各家運維公司之上形成另外的協(xié)調(diào)運維工作團隊，導(dǎo)致稅務(wù)運維團隊的管理復(fù)雜性非常高。

為了解決運維管理高度復(fù)雜的問題，引入智能化的運維工具平臺就顯得尤為重要，總局和各省級稅務(wù)局在這個方面投入力度很大，但是效果并不顯著。一方面受制于技術(shù)創(chuàng)新發(fā)展的因素，當(dāng)前行業(yè)運維管理軟件更多情況下還是需要人為參與的，還不能做到真正智能化;另一方面，也是更為重要的一方面，就是運維管理方面的軟件產(chǎn)品大多數(shù)都是建立在跨行業(yè)、多用途的通用型產(chǎn)品架構(gòu)之上，極少數(shù)會深入到稅務(wù)行業(yè)的實際業(yè)務(wù)情況，去設(shè)計融合稅務(wù)業(yè)務(wù)流程和數(shù)據(jù)模型特征的運維工具產(chǎn)品。

1.2? 傳統(tǒng)監(jiān)控系統(tǒng)在稅務(wù)運維中的應(yīng)用與不足

稅務(wù)平臺主要應(yīng)用的監(jiān)控系統(tǒng)分為基于數(shù)據(jù)網(wǎng)絡(luò)監(jiān)控和基于狀態(tài)監(jiān)控兩種方式[5]。這類傳統(tǒng)的監(jiān)控工具為了全面獲取稅務(wù)平臺在網(wǎng)絡(luò)方面或系統(tǒng)運行方面的情況，需要對于服務(wù)器的硬件資源、性能指數(shù)、運行進程數(shù)量、CPU使用情況等提供持續(xù)與可靠的監(jiān)測統(tǒng)計[6]。傳統(tǒng)監(jiān)控系統(tǒng)是目前各地方稅務(wù)局應(yīng)用最廣泛的運維監(jiān)控方式。例如：國內(nèi)的科來網(wǎng)絡(luò)回溯產(chǎn)品[7]也是稅務(wù)上常見的數(shù)據(jù)網(wǎng)絡(luò)監(jiān)控系統(tǒng)。但是傳統(tǒng)方式監(jiān)控系統(tǒng)具有很多不足：

（1）基于狀態(tài)監(jiān)控對軟硬件平臺資源的定時狀態(tài)采集和監(jiān)控指標(biāo)告警，一方面存在安全端口隱患，另一方面也在一定程度上影響生產(chǎn)性能，而且實施過程手續(xù)流程非常繁雜，最關(guān)鍵的因素是被監(jiān)控的資源設(shè)備無法形成有效的關(guān)聯(lián)分析，無法準(zhǔn)確定位問題。

（2）基于數(shù)據(jù)的網(wǎng)絡(luò)監(jiān)控是通過采集網(wǎng)絡(luò)數(shù)據(jù)、分析網(wǎng)絡(luò)協(xié)議的方式進行網(wǎng)絡(luò)層面的監(jiān)控，雖然具有一定的旁路監(jiān)聽效果，但依然只能在網(wǎng)絡(luò)狀態(tài)層面提供監(jiān)控指標(biāo)分析結(jié)果，還是無法與業(yè)務(wù)實際運行情況產(chǎn)生關(guān)聯(lián)。

因此稅務(wù)運維工作特別需要一款更符合實際需要的運維監(jiān)控工具，能做到旁路監(jiān)聽、連續(xù)可靠數(shù)據(jù)監(jiān)測、業(yè)務(wù)深度融合、實時預(yù)警、故障快速定位的整體解決方案。目前多個省級稅務(wù)局都將稅務(wù)平臺的健康監(jiān)測分析需求納入到了建設(shè)計劃當(dāng)中。

2? 相關(guān)技術(shù)介紹

2.1? APM

APM系統(tǒng)種類繁多，但是其基本工作流程類似：

（1）數(shù)據(jù)采集：通過多種方式采集與應(yīng)用程序相關(guān)的數(shù)據(jù)，這是整個APM系統(tǒng)的基礎(chǔ)。

（2）數(shù)據(jù)收集：將不同采集端采集到的數(shù)據(jù)進行統(tǒng)一整理轉(zhuǎn)發(fā)。

（3）數(shù)據(jù)分析：對一些需要實時分析的數(shù)據(jù)需要收集到之后馬上進行分析，不需要實時分析的則進行持久化存儲。

（4）數(shù)據(jù)存儲：將性能數(shù)據(jù)持久化，以便后續(xù)查詢、定位問題。

（5）數(shù)據(jù)展示：通過各種圖表的形式，展示應(yīng)用運行時的詳細(xì)信息，為定位故障提供極大便利。

數(shù)據(jù)采集常用的抓包分析軟件如tcpdump、Wireshark等，但并沒有提供良好的適合于Java開發(fā)的API接口，因此選擇Pcap4J的Java組件庫實現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)包采集。數(shù)據(jù)收集后統(tǒng)一轉(zhuǎn)發(fā)到Kafka消息服務(wù)中心，由Storm實時計算架構(gòu)進行數(shù)據(jù)分析，最終寫入MySQL存儲統(tǒng)計分析數(shù)據(jù)，同時寫入ElasticSearch存儲實時軌跡數(shù)據(jù)，并通過EChars可視化庫在PC瀏覽器上展示統(tǒng)計分析數(shù)據(jù)。

2.2? Storm流式計算

Stream流式數(shù)據(jù)是由生產(chǎn)環(huán)節(jié)的業(yè)務(wù)產(chǎn)生的有向無界的數(shù)據(jù)流，這些海量的流數(shù)據(jù)，需要實時進行計算處理，由于順序地在一個計算點上是無法做到實時性的，一定會產(chǎn)生數(shù)據(jù)擁堵，處理時間會被無限延長，因此為了達到實時計算的目的，就需要使用流式計算，其特征是在分布式的計算架構(gòu)下，對流數(shù)據(jù)進行分流、聚合、批量、并行的拓?fù)浣Y(jié)構(gòu)計算，達到實時性要求。

如圖1所示，海量流數(shù)據(jù)進入單一計算點后，因為計算節(jié)點的處理性能受到的制約因素很多，就會導(dǎo)致嚴(yán)重的下個環(huán)節(jié)輸出結(jié)果延時的情況。

流式計算是基于分布式流式計算框架，提高對數(shù)據(jù)流的分布式計算性能，如圖2所示，海量流數(shù)據(jù)首先進入計算分解環(huán)節(jié)，在最低延時消耗的狀態(tài)下進行數(shù)據(jù)流分解工作，由多個計算任務(wù)進行并行計算，根據(jù)可接收的延時性能需求，選擇增加的并行計算任務(wù)節(jié)點數(shù)，對最終交付下一個環(huán)節(jié)點的計算結(jié)果進行計算匯聚。

Storm是Twitter內(nèi)部使用開源并被廣泛使用的一套流計算系統(tǒng)，非常適合流式計算架構(gòu)的分布式計算。Storm抽象出數(shù)據(jù)流Stream的概念，一個流由無限的Tuple（元組）序列組成，這些元組會被分布式并行地創(chuàng)建和處理。通過流中元組包含的字段名稱來定義這個流。稅務(wù)平臺實時產(chǎn)生的海量數(shù)據(jù)達到130G/天，通過單一的處理節(jié)點，必然產(chǎn)生阻塞，通過Storm的Topology（拓?fù)洌┚W(wǎng)絡(luò)，把Spouts（噴射）、Bolts（門閂）組成拓?fù)溆嬎憔W(wǎng)絡(luò)，Spouts不斷向下一個環(huán)節(jié)發(fā)送Stream數(shù)據(jù)，經(jīng)過Bolts環(huán)節(jié)后，被分解成多個Task（任務(wù)）完成計算任務(wù)，并發(fā)送至下一個環(huán)節(jié)，或者本身成為匯聚環(huán)節(jié)。Storm結(jié)構(gòu)如圖3所示。

如圖3所示，Storm的兩個Spout訂閱消費Kafka數(shù)據(jù)輸入隊列的兩組流數(shù)據(jù)并不斷向Bolt發(fā)送流數(shù)據(jù)，兩組Bolt并行完成任務(wù)計算后將計算數(shù)據(jù)合并到JoinBolt（聚合門閂），進行聚合處理后再將結(jié)果推送到下一個Bolt做最終任務(wù)處理，最后作為Kafka的發(fā)送者身份，將任務(wù)計算的最終結(jié)果推送到Kafka數(shù)據(jù)輸出隊列上，交給其他訂閱系統(tǒng)消費。

2.3? Kafka消息系統(tǒng)

流式計算建立了健康監(jiān)測分析的基礎(chǔ)架構(gòu)模型，架構(gòu)的關(guān)鍵原理是通過分流與聚合，從而形成有效的計算單元解耦，而每個階段的分流與聚合是通過消息系統(tǒng)的訂閱與消費來實現(xiàn)。因此面對海量流式數(shù)據(jù)的消息化實時轉(zhuǎn)換，就需要搭建足夠強悍的消息系統(tǒng)來支撐，需要滿足幾點能力要求：

（1）集群化能力：可以動態(tài)伸縮地通過計算資源調(diào)整消息的處理能力。

（2）數(shù)據(jù)冗余能力：可分布式冗余消息數(shù)據(jù)，當(dāng)計算環(huán)境處于異常狀態(tài)，或最終數(shù)據(jù)丟失，可以通過消息位移重定位，回溯記憶，保證數(shù)據(jù)計算的可靠性。

（3）多線程消費能力：通過建立多線程消費端，并行接收消息，提高數(shù)據(jù)接收的實時效率。

Kafka是最初由LinkedIn公司開發(fā)，是一個分布式，支持Partition（分區(qū)）、Replica（副本）機制，基于Zoo Keeper協(xié)調(diào)的分布式消息系統(tǒng)。Kafka通過Broker抽象概念表示每個Kafka運行實例。多個Broker可以組成Kafka Cluster（集群），由ZooKeeper進行分布式協(xié)調(diào)，水平提升消息寫入和消費的吞吐量。Kafka通過Partition機制，實現(xiàn)每個Broker的Topic（主題）被切分成多分區(qū)，并分布在Cluster的不同Broker上，當(dāng)數(shù)據(jù)發(fā)送方不斷寫入Topic的同時，消費端可以配置多線程消費機制，同一時間每線程訪問每分區(qū)的形式，最大化提升數(shù)據(jù)的接收速度，保障數(shù)據(jù)流式中轉(zhuǎn)的實時性。Kafka通過Replica機制，每個分區(qū)保存至少兩份數(shù)據(jù)的方式，實現(xiàn)Cluster的高可靠性，至少當(dāng)一個Broker宕機或被移除時，不會造成Cluster數(shù)據(jù)丟失。

Kafka消息通訊示例圖如圖4所示，Kafka形成三個Broker組成Cluster，創(chuàng)建Topic后，每個Broker分配到相同Topic再被切分成三個Partition，同時每個Partition都有一個Replica，就形成了如圖4中每個Topic有兩個Partition：M（主分區(qū)）、S（從分區(qū)）。

KafkaProduce（發(fā)送端）將消息分發(fā)到不同的Partition中的速度會遠遠大于單Thread（線程）KafkaConsumer（消費端）接受數(shù)據(jù)的速度，因此Kafka設(shè)計了需要實現(xiàn)上圖中三個Thread并行訪問三個Partition的機制，此設(shè)計既保障了線程并發(fā)安全性，也滿足了通過提高消費速度保證了數(shù)據(jù)發(fā)送和數(shù)據(jù)消費一致的實時性。

3? 系統(tǒng)總體架構(gòu)

健康度系統(tǒng)項目提供了核心的稅務(wù)平臺健康指標(biāo)監(jiān)測分析能力，輔之基礎(chǔ)設(shè)備平臺的狀態(tài)監(jiān)控和網(wǎng)絡(luò)平臺的日志分析，實現(xiàn)了綜合一體的平臺化運維監(jiān)控?？傮w架構(gòu)為五橫兩縱，如圖5所示。五橫為五層體系，包括：基礎(chǔ)架構(gòu)層、數(shù)據(jù)層、中間層、核心層和展示層（圖中未展示），每個層面羅列了關(guān)鍵性的應(yīng)用和技術(shù)，形成了自底向上的平臺化軟件支撐體系，一方面滿足展示查詢、異常告警、統(tǒng)計分析、數(shù)據(jù)采集、大數(shù)據(jù)及持久化的應(yīng)用和技術(shù)需求，另一方面也滿足了網(wǎng)絡(luò)環(huán)境、虛擬化資源、網(wǎng)絡(luò)通訊和數(shù)據(jù)存儲的基礎(chǔ)設(shè)施需求;兩縱為自上而下貫穿整個系統(tǒng)的稅務(wù)安全體系與稅務(wù)運維管理規(guī)范的兩個保障性要求。

4? 系統(tǒng)設(shè)計

4.1? 系統(tǒng)總體功能

如圖6所示，涉稅業(yè)務(wù)健康度系統(tǒng)項目功能分為六大部分組成，包括：綜合展示、告警預(yù)警、后臺配置、健康監(jiān)測分析、平臺狀態(tài)監(jiān)控及網(wǎng)絡(luò)日志分析。

綜合展示、告警預(yù)警、后臺配置均使用了Spring Cloud的部分微服務(wù)特性，包括：Spring Boot基礎(chǔ)服務(wù)特性、服務(wù)的注冊與發(fā)現(xiàn)特性等。網(wǎng)站部分實現(xiàn)前后端分離（綜合展示、后臺配置），獨立部署。網(wǎng)站基于Spring Boot構(gòu)建，實現(xiàn)統(tǒng)計數(shù)據(jù)、配置數(shù)據(jù)的高效訪問。因為本文研究重點是健康監(jiān)測分析部分，所以包括平臺狀態(tài)監(jiān)控、網(wǎng)絡(luò)日志分析在內(nèi)的這五個部分，就不再進行功能方面的贅述。

本文研究的重點是健康監(jiān)測分析部分（圖6淺色部分），對網(wǎng)絡(luò)采集、清洗還原、軌跡跟蹤、實時分析和持久化的五個下屬子功能做詳細(xì)的功能描述。

（1）網(wǎng)絡(luò)采集：網(wǎng)絡(luò)采集對網(wǎng)卡數(shù)據(jù)流量進行監(jiān)聽與抓取，根據(jù)IP/端口的設(shè)定，采集由不同網(wǎng)區(qū)（DMZ網(wǎng)絡(luò)區(qū)、涉稅網(wǎng)區(qū)、內(nèi)網(wǎng)區(qū)）的核心交換機提供的實時網(wǎng)絡(luò)鏡像數(shù)據(jù)。并為流經(jīng)采集節(jié)點的每個被采集數(shù)據(jù)包打上時序時間戳，作為分析計算的延時性能計算依據(jù)。最終推送至Kafka數(shù)據(jù)隊列中心，供清洗還原程序使用。

（2）清洗還原部分通過從Kafka隊列中心得到網(wǎng)絡(luò)采集部分提供的網(wǎng)絡(luò)TCP/IP原始數(shù)據(jù)包。探針是網(wǎng)絡(luò)包數(shù)據(jù)中業(yè)務(wù)數(shù)據(jù)的關(guān)鍵組件，一方面需要將雜亂無序的數(shù)據(jù)包重新進行拼接成實際傳遞的業(yè)務(wù)數(shù)據(jù)段;另一方面需要對拼接后的業(yè)務(wù)數(shù)據(jù)的請求和響應(yīng)進行碰撞過濾，形成一次完整的數(shù)據(jù)請求響應(yīng)，以達到最接近實際業(yè)務(wù)系統(tǒng)處理數(shù)據(jù)的情況，防止冗余數(shù)據(jù)的干擾。最終推至Storm拓?fù)湎乱浑A段的計算。

（3）軌跡跟蹤部分從Storm上一個環(huán)節(jié)得到請求響應(yīng)配對的業(yè)務(wù)數(shù)據(jù)后，讀取業(yè)務(wù)流程信息，發(fā)現(xiàn)自身將與其他需要軌跡碰撞的節(jié)點進行碰撞組鏈，并繼續(xù)將半組鏈狀態(tài)數(shù)據(jù)繼續(xù)推至Storm下一個組鏈計算環(huán)節(jié)，直至完成最終的業(yè)務(wù)流程軌跡全鏈，并推送給Storm聚合技術(shù)環(huán)節(jié)，進行實時分析統(tǒng)計。

（4）實時分析部分是每個流程聚合的Storm計算環(huán)節(jié)，對聚合來的軌跡跟蹤數(shù)據(jù)，首先進行健康指標(biāo)分析，包括：軌跡成功率分析、流程環(huán)節(jié)延時分析、吞吐量分析、流程環(huán)節(jié)異常率分析，接著對分析的明細(xì)數(shù)據(jù)開始單位時間內(nèi)統(tǒng)計，例如：每秒鐘的吞吐量，每分鐘的流程環(huán)節(jié)平均延時，每小時的業(yè)務(wù)軌跡成功率，每天的環(huán)節(jié)異常率等。最后實時分析完成將原軌跡數(shù)據(jù)和統(tǒng)計數(shù)據(jù)，推送Kafka集群的持久化Topic。

（5）持久化部分通過訂閱Kafka集群的持久化Topic，將分析計算的最終結(jié)果數(shù)據(jù)寫入數(shù)據(jù)庫：1）軌跡數(shù)據(jù)需要按明細(xì)保存，一方面因為每天大約有130G以上的海量軌跡明細(xì)數(shù)據(jù)生成，另一方面運維管理人員可能隨時查詢軌跡信息去驗證異常問題，因此選擇比較適合的ElasticSearch集群進行海量數(shù)據(jù)索引，并且盡可能快地提供查詢結(jié)果;2）統(tǒng)計數(shù)據(jù)按秒級匯總一定數(shù)量的數(shù)據(jù)后，增量更新數(shù)據(jù)庫，不會造成大量數(shù)據(jù)寫入的情況，但是不同流程的不同環(huán)節(jié)會頻繁并發(fā)地更新數(shù)據(jù)庫，因此選擇更為廉價的MySQL單機版數(shù)據(jù)庫比較合適，完全能提供更快的并發(fā)寫入和網(wǎng)頁讀取性能。

4.2? 健康監(jiān)測分析系統(tǒng)設(shè)計

系統(tǒng)總體架構(gòu)的核心需求是稅務(wù)平臺健康監(jiān)測分析，因此本章節(jié)重點對涉稅業(yè)務(wù)健康度項目中需要研究開發(fā)的核心范圍進行更詳細(xì)的技術(shù)設(shè)計與描述。

根據(jù)相關(guān)規(guī)定，系統(tǒng)異常問題在發(fā)生后30分鐘以內(nèi)必須解決，那么系統(tǒng)就需要在更早的時間（5～10分鐘）發(fā)出性能警告，面對每秒百兆的業(yè)務(wù)數(shù)據(jù)吞吐，任何定時抓取數(shù)據(jù)的延時性聯(lián)機分析系統(tǒng)，都無法在此大數(shù)據(jù)流量情況下達到實時性的分析計算要求，無法實現(xiàn)數(shù)據(jù)包重組、軌跡跟蹤與性能延時計算等要求。因此需要建立主動式計算分析模型，在數(shù)據(jù)流動的過程中，建立各個分析場景的多組流計算節(jié)點，不斷將本節(jié)點的計算結(jié)果推送至下一個分析場景的計算節(jié)點，最終在推送入庫之前就完成所有的計算分析結(jié)果。此實時計算過程也稱為流式計算。

流式計算是健康監(jiān)測分析核心的基礎(chǔ)架構(gòu)。流式計算基礎(chǔ)架構(gòu)是為了滿足提升大數(shù)據(jù)實時計算處理能力的架構(gòu)模式，保證數(shù)據(jù)流處理過程中更靈活的算力配置、可擴展的業(yè)務(wù)計算需求以及更優(yōu)的數(shù)據(jù)吞吐量。

如圖7所示，從網(wǎng)絡(luò)數(shù)據(jù)源開始，就像一條蜿蜒的河流流經(jīng)不同的計算站點，經(jīng)過對數(shù)據(jù)水流的過濾處理后繼續(xù)向下一個站點流去，直到最終匯入ElasticSearch的海量存儲中。其中Kafka如同具備吞吐量的水庫，計算站點在每個階段處理“前/后”的水流“出/入”水庫的操作，就為流經(jīng)每個站點的水流的處理上提供了吞吐性能的保證，避免了站點處理能力不足造成的“河流”阻塞。計算站點又分成了網(wǎng)絡(luò)數(shù)據(jù)采集（JNetPcap）、網(wǎng)絡(luò)數(shù)據(jù)清洗（NetProbe）、業(yè)務(wù)數(shù)據(jù)清洗（實時計算）、業(yè)務(wù)增量統(tǒng)計（歷史計算），就像在數(shù)據(jù)河流的不同階段建立的水流處理站，根據(jù)階段不同，對流經(jīng)站點的水流處理分工也不同，并進行著職責(zé)范圍內(nèi)的過濾處理工作。

數(shù)據(jù)流經(jīng)的每個計算站點，采用了分布式計算的系統(tǒng)架構(gòu)，架構(gòu)的特點在于根據(jù)數(shù)據(jù)流業(yè)務(wù)的特征進行分組計算，通過對流式計算任務(wù)的這種分解方式，一方面可以極大提高計算性能，另一方面也極大地提高了Kafka隊列收發(fā)的性能。這就從架構(gòu)機制上保證了計算結(jié)果的實時性。

如圖8所示，計算站點會被分成多個計算進程，進程間不直接通訊，而是形成Fork/Join的分支聚合結(jié)構(gòu)的方式進行通訊，任務(wù)計算在分支上進行，聚合點（Kafka）實現(xiàn)路由轉(zhuǎn)發(fā)。網(wǎng)絡(luò)采集站點的任務(wù)劃分是根據(jù)相關(guān)業(yè)務(wù)的IP/端口群分組設(shè)定，例如外網(wǎng)的稅控開票VPN分組、稅控開票受理分組、內(nèi)網(wǎng)的稅庫銀分組，也就是根據(jù)業(yè)務(wù)和數(shù)據(jù)流量的情況，可以不斷細(xì)化分組，最終到IP端口為原子級別;網(wǎng)絡(luò)探針、實時計算、歷史計算的任務(wù)劃分都是根據(jù)Kafka的Topic作為分組的條件，形成計算分組和Topic一對一的關(guān)系，主題又根據(jù)業(yè)務(wù)分類進行聚合或者新的拆分，同樣計算分組也保持一致的劃分。

5? 結(jié)? 論

隨著分布式應(yīng)用、云計算的不斷深入發(fā)展，業(yè)務(wù)系統(tǒng)的邏輯結(jié)構(gòu)正變得越來越復(fù)雜，目前許多應(yīng)用都是分布式的，應(yīng)用也從早先的一個大程序演變成系列服務(wù)的形式，運行在不同平臺上，這種應(yīng)用的復(fù)雜性和靈活性對發(fā)現(xiàn)定位性能問題提出了更高的挑戰(zhàn)。我們需要一種新的技術(shù)手段，用來關(guān)注哪些問題影響了企業(yè)應(yīng)用的性能和可用性，關(guān)注如何識別這些問題、如何確定它們的重要性以及如何解決這些問題?；诖?，本文根據(jù)APM模型，對“稅務(wù)平臺健康監(jiān)測分析系統(tǒng)的設(shè)計與實現(xiàn)”的主要技術(shù)進行了論述，并完成了部分核心模塊的理論闡述和設(shè)計。

參考文獻：

[1] 中國電子政務(wù)網(wǎng).國家兩網(wǎng)，一站，四庫，十二金工程 [EB/OL].（2018-05-21）.http：//www.e-gov.org.cn./egov/web/article_detail.php？id=166340.

[2] 黃釗.稅收大數(shù)據(jù)時代的金稅三期工程分析 [J].經(jīng)貿(mào)實踐，2018（15）：124-125.

[3] 歐舸，金曉茜.淺談稅收大數(shù)據(jù)時代的金稅三期工程 [J].中國管理信息化，2017，20（1）：136-137.

[4] 肖勝球.金稅三期背景下建立稅務(wù)信息系統(tǒng)運維制度的思考 [J].黑龍江科技信息，2016（26）：94.

[5] 陶海.基于Web技術(shù)的服務(wù)器監(jiān)控報警管理系統(tǒng)的設(shè)計與實現(xiàn) [D].北京：中國地質(zhì)大學(xué)（北京），2012.

[6] 李天嬌.網(wǎng)絡(luò)監(jiān)控告警系統(tǒng)的設(shè)計與實現(xiàn) [D].成都：成都理工大學(xué)，2017.

[7] 科來.科來網(wǎng)絡(luò)回溯分析系統(tǒng)（RAS） [EB/OL].[2019-08-24].http：//www.colasoft.com.cn/products/phras.php.

作者簡介：郭嘉（1989-），男，漢族，山西晉城人，研發(fā)工程師，碩士研究生，研究方向：軟件工程與應(yīng)用。