税务平台的健康监测分析系统设计与实现

摘  要：本文的研究目标是深入结合税务业务，通过引入应用性能管理的技术模式，实时监测分析业务数据，快速找到故障源，形成一套面向税务平台的健康监测分析系统。首先通过采集网络数据流，对碎片化的TCP/IP报文实现业务还原;其次对还原的业务数据进行轨迹跟踪，实时生成轨迹跟踪链;再次对轨迹跟踪链进行健康指标计算，并对计算结果进行单位时间内的统计;最后持久化入库，为运维管理人员提供系统健康状况的查询和展示功能，并对异常故障点及时告警。

关键词：监测分析;业务健康;税务大数据;运维监控

中图分类号：TP311.5      文献标识码：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  引  言

历经了十数年的发展，信息化技术已经深入扎根于税务业务的活动当中，成为税务发展的一项重要推动力;新技术、新架构的不断运用，解决了日益增长的业务需求，相关税收应用系统的数量由少至多，程序不断升级，从单一系统模式逐步发展到目前以金税三期工程为主的税务平台的规模化体系，系统复杂程度越来越高，这就给系统的运维工作提出了更高的要求。

本文围绕以金税三期工程为主的核心税务应用系统，以APM（Application Performance Management & Monitoring）技术思路为主导，对系统的运行原理、流程模型和通讯机制进行了研究与分析。利用流式计算结构实现对税务平台海量业务数据的实时性处理;并通过健康分析模型，对业务数据流经每个业务环节的性能指标进行实时监测分析，对业务系统整体健康状况进行评估，对可能导致系统故障的指标偏离进行预警，对在业务流程中出现问题的具体环节进行精确定位，最后总结出适合税务平台健康监测分析系统的整体技术方案，完成了税务平台健康检测分析系统的开发实现和测试，并在实际环境中进行了验证。

1  国内外相关研究综述

金税工程是国家电子政务“十二金”[1]工程之一，是国家建设中具有重要战略地位的信息系统工程，通过搭建统一的纳税服务平台，实现了我国税收数据的集中[2]。金税工程共经历了三个建设阶段，自1994年到2001年分别经历了“金税一期”和“金税二期”建设阶段;在2008年9月24日，发改委正式批准金税三期初步设计方案和中央投资预算，标志“金税三期”工程正式启动[3]。

1.1  税务平台运维发展现状和存在的问题

《金税工程（三期）总体实施方案》中提出了“通过建立一个以省级运维为基础、总局运维为后盾的规范化、标准化、制度化的集中管理的运维体系，完成对税务信息系统运行状态的全面监控和运行问题的及时处理，支持应用系统的安全、稳定、高效、持续运行”的目标[4]。从目前省级税务平台运维建设情况看，运维服务是由总局统一指挥要求，各省信息中心具体实施，既保证了运维规范化，也可以保证各地具备根据实际情况进行运维的灵活性，并逐步向成熟可靠的运维机制，全面覆盖运维工作的方向发展。但是税务平台运维工作的高度复杂性决定了还有很多不足的地方需要不断完善，当前所有问题中比较突出的问题还是庞大的运维人员队伍管理和不够智能化的运维工具平台带来的麻烦。

首先税务平台运行的系统非常庞大，涉及的技术公司众多，每个运行系统都可能需要安排一家公司的运维团队驻场工作，这就造成了信息中心的运维管理难度越来越大;其次各运行系统之间的配合协作越来越密切，出现系统问题后已经不能仅仅通过对独立的系统分析寻找问题，因此需要在各家运维公司之上形成另外的协调运维工作团队，导致税务运维团队的管理复杂性非常高。

为了解决运维管理高度复杂的问题，引入智能化的运维工具平台就显得尤为重要，总局和各省级税务局在这个方面投入力度很大，但是效果并不显著。一方面受制于技术创新发展的因素，当前行业运维管理软件更多情况下还是需要人为参与的，还不能做到真正智能化;另一方面，也是更为重要的一方面，就是运维管理方面的軟件产品大多数都是建立在跨行业、多用途的通用型产品架构之上，极少数会深入到税务行业的实际业务情况，去设计融合税务业务流程和数据模型特征的运维工具产品。

1.2  传统监控系统在税务运维中的应用与不足

税务平台主要应用的监控系统分为基于数据网络监控和基于状态监控两种方式[5]。这类传统的监控工具为了全面获取税务平台在网络方面或系统运行方面的情况，需要对于服务器的硬件资源、性能指数、运行进程数量、CPU使用情况等提供持续与可靠的监测统计[6]。传统监控系统是目前各地方税务局应用最广泛的运维监控方式。例如：国内的科来网络回溯产品[7]也是税务上常见的数据网络监控系统。但是传统方式监控系统具有很多不足：

（1）基于状态监控对软硬件平台资源的定时状态采集和监控指标告警，一方面存在安全端口隐患，另一方面也在一定程度上影响生产性能，而且实施过程手续流程非常繁杂，最关键的因素是被监控的资源设备无法形成有效的关联分析，无法准确定位问题。

（2）基于数据的网络监控是通过采集网络数据、分析网络协议的方式进行网络层面的监控，虽然具有一定的旁路监听效果，但依然只能在网络状态层面提供监控指标分析结果，还是无法与业务实际运行情况产生关联。

因此税务运维工作特别需要一款更符合实际需要的运维监控工具，能做到旁路监听、连续可靠数据监测、业务深度融合、实时预警、故障快速定位的整体解决方案。目前多个省级税务局都将税务平台的健康监测分析需求纳入到了建设计划当中。

2  相关技术介绍

2.1  APM

APM系统种类繁多，但是其基本工作流程类似：

（1）数据采集：通过多种方式采集与应用程序相关的数据，这是整个APM系统的基础。

（2）数据收集：将不同采集端采集到的数据进行统一整理转发。

（3）数据分析：对一些需要实时分析的数据需要收集到之后马上进行分析，不需要实时分析的则进行持久化存储。

（4）数据存储：将性能数据持久化，以便后续查询、定位问题。

（5）数据展示：通过各种图表的形式，展示应用运行时的详细信息，为定位故障提供极大便利。

数据采集常用的抓包分析软件如tcpdump、Wireshark等，但并没有提供良好的适合于Java开发的API接口，因此选择Pcap4J的Java组件库实现网络数据包采集。数据收集后统一转发到Kafka消息服务中心，由Storm实时计算架构进行数据分析，最终写入MySQL存储统计分析数据，同时写入ElasticSearch存储实时轨迹数据，并通过EChars可视化库在PC浏览器上展示统计分析数据。

2.2  Storm流式计算

Stream流式数据是由生产环节的业务产生的有向无界的数据流，这些海量的流数据，需要实时进行计算处理，由于顺序地在一个计算点上是无法做到实时性的，一定会产生数据拥堵，处理时间会被无限延长，因此为了达到实时计算的目的，就需要使用流式计算，其特征是在分布式的计算架构下，对流数据进行分流、聚合、批量、并行的拓扑结构计算，达到实时性要求。

如图1所示，海量流数据进入单一计算点后，因为计算节点的处理性能受到的制约因素很多，就会导致严重的下个环节输出结果延时的情况。

流式计算是基于分布式流式计算框架，提高对数据流的分布式计算性能，如图2所示，海量流数据首先进入计算分解环节，在最低延时消耗的状态下进行数据流分解工作，由多个计算任务进行并行计算，根据可接收的延时性能需求，选择增加的并行计算任务节点数，对最终交付下一个环节点的计算结果进行计算汇聚。

Storm是Twitter内部使用开源并被广泛使用的一套流计算系统，非常适合流式计算架构的分布式计算。Storm抽象出数据流Stream的概念，一个流由无限的Tuple（元组）序列组成，这些元组会被分布式并行地创建和处理。通过流中元组包含的字段名称来定义这个流。税务平台实时产生的海量数据达到130G/天，通过单一的处理节点，必然产生阻塞，通过Storm的Topology（拓扑）网络，把Spouts（喷射）、Bolts（门闩）组成拓扑计算网络，Spouts不断向下一个环节发送Stream数据，经过Bolts环节后，被分解成多个Task（任务）完成计算任务，并发送至下一个环节，或者本身成为汇聚环节。Storm结构如图3所示。

如图3所示，Storm的两个Spout订阅消费Kafka数据输入队列的两组流数据并不断向Bolt发送流数据，两组Bolt并行完成任务计算后将计算数据合并到JoinBolt（聚合门闩），进行聚合处理后再将结果推送到下一个Bolt做最终任务处理，最后作为Kafka的发送者身份，将任务计算的最终结果推送到Kafka数据输出队列上，交给其他订阅系统消费。

2.3  Kafka消息系统

流式计算建立了健康监测分析的基础架构模型，架构的关键原理是通过分流与聚合，从而形成有效的计算单元解耦，而每个阶段的分流与聚合是通过消息系统的订阅与消费来实现。因此面对海量流式数据的消息化实时转换，就需要搭建足够强悍的消息系统来支撑，需要满足几点能力要求：

（1）集群化能力：可以动态伸缩地通过计算资源调整消息的处理能力。

（2）数据冗余能力：可分布式冗余消息数据，当计算环境处于异常状态，或最终数据丢失，可以通过消息位移重定位，回溯记忆，保证数据计算的可靠性。

（3）多线程消费能力：通过建立多线程消费端，并行接收消息，提高数据接收的实时效率。

Kafka是最初由LinkedIn公司开发，是一个分布式，支持Partition（分区）、Replica（副本）机制，基于Zoo Keeper协调的分布式消息系统。Kafka通过Broker抽象概念表示每个Kafka运行实例。多个Broker可以组成Kafka Cluster（集群），由ZooKeeper进行分布式协调，水平提升消息写入和消费的吞吐量。Kafka通过Partition机制，实现每个Broker的Topic（主题）被切分成多分区，并分布在Cluster的不同Broker上，当数据发送方不断写入Topic的同时，消费端可以配置多线程消费机制，同一时间每线程访问每分区的形式，最大化提升数据的接收速度，保障数据流式中转的实时性。Kafka通過Replica机制，每个分区保存至少两份数据的方式，实现Cluster的高可靠性，至少当一个Broker宕机或被移除时，不会造成Cluster数据丢失。

Kafka消息通讯示例图如图4所示，Kafka形成三个Broker组成Cluster，创建Topic后，每个Broker分配到相同Topic再被切分成三个Partition，同时每个Partition都有一个Replica，就形成了如图4中每个Topic有两个Partition：M（主分区）、S（从分区）。

KafkaProduce（发送端）将消息分发到不同的Partition中的速度会远远大于单Thread（线程）KafkaConsumer（消费端）接受数据的速度，因此Kafka设计了需要实现上图中三个Thread并行访问三个Partition的机制，此设计既保障了线程并发安全性，也满足了通过提高消费速度保证了数据发送和数据消费一致的实时性。

3  系统总体架构

健康度系统项目提供了核心的税务平台健康指标监测分析能力，辅之基础设备平台的状态监控和网络平台的日志分析，实现了综合一体的平台化运维监控。总体架构为五横两纵，如图5所示。五横为五层体系，包括：基础架构层、数据层、中间层、核心层和展示层（图中未展示），每个层面罗列了关键性的应用和技术，形成了自底向上的平台化软件支撑体系，一方面满足展示查询、异常告警、统计分析、数据采集、大数据及持久化的应用和技术需求，另一方面也满足了网络环境、虚拟化资源、网络通讯和数据存储的基础设施需求;两纵为自上而下贯穿整个系统的税务安全体系与税务运维管理规范的两个保障性要求。

4  系统设计

4.1  系统总体功能

如图6所示，涉税业务健康度系统项目功能分为六大部分组成，包括：综合展示、告警预警、后台配置、健康监测分析、平台状态监控及网络日志分析。

综合展示、告警预警、后台配置均使用了Spring Cloud的部分微服务特性，包括：Spring Boot基础服务特性、服务的注册与发现特性等。网站部分实现前后端分离（综合展示、后台配置），独立部署。网站基于Spring Boot构建，实现统计数据、配置数据的高效访问。因为本文研究重点是健康监测分析部分，所以包括平台状态监控、网络日志分析在内的这五个部分，就不再进行功能方面的赘述。

本文研究的重点是健康监测分析部分（图6浅色部分），对网络采集、清洗还原、轨迹跟踪、实时分析和持久化的五个下属子功能做详细的功能描述。

（1）网络采集：网络采集对网卡数据流量进行监听与抓取，根据IP/端口的设定，采集由不同网区（DMZ网络区、涉税网区、内网区）的核心交换机提供的实时网络镜像数据。并为流经采集节点的每个被采集数据包打上时序时间戳，作为分析计算的延时性能计算依据。最终推送至Kafka数据队列中心，供清洗还原程序使用。

（2）清洗还原部分通过从Kafka队列中心得到网络采集部分提供的网络TCP/IP原始数据包。探针是网络包数据中业务数据的关键组件，一方面需要将杂乱无序的数据包重新进行拼接成实际传递的业务数据段;另一方面需要对拼接后的业务数据的请求和响应进行碰撞过滤，形成一次完整的数据请求响应，以达到最接近实际业务系统处理数据的情况，防止冗余数据的干扰。最终推至Storm拓扑下一阶段的计算。

（3）轨迹跟踪部分从Storm上一个环节得到请求响应配对的业务数据后，读取业务流程信息，发现自身将与其他需要轨迹碰撞的节点进行碰撞组链，并继续将半组链状态数据继续推至Storm下一个组链计算环节，直至完成最终的业务流程轨迹全链，并推送给Storm聚合技术环节，进行实时分析统计。

（4）实时分析部分是每个流程聚合的Storm计算环节，对聚合来的轨迹跟踪数据，首先进行健康指标分析，包括：轨迹成功率分析、流程环节延时分析、吞吐量分析、流程环节异常率分析，接着对分析的明细数据开始单位时间内统计，例如：每秒钟的吞吐量，每分钟的流程环节平均延时，每小时的业务轨迹成功率，每天的环节异常率等。最后实时分析完成将原轨迹数据和统计数据，推送Kafka集群的持久化Topic。

（5）持久化部分通过订阅Kafka集群的持久化Topic，将分析计算的最终结果数据写入数据库：1）轨迹数据需要按明细保存，一方面因为每天大约有130G以上的海量轨迹明细数据生成，另一方面运维管理人员可能随时查询轨迹信息去验证异常问题，因此选择比较适合的ElasticSearch集群进行海量数据索引，并且尽可能快地提供查询结果;2）统计数据按秒级汇总一定数量的数据后，增量更新数据库，不会造成大量数据写入的情况，但是不同流程的不同环节会频繁并发地更新数据库，因此选择更为廉价的MySQL单机版数据库比较合适，完全能提供更快的并发写入和网页读取性能。

4.2  健康监测分析系统设计

系统总体架构的核心需求是税务平台健康监测分析，因此本章节重点对涉税业务健康度项目中需要研究开发的核心范围进行更详细的技术设计与描述。

根据相关规定，系统异常问题在发生后30分钟以内必须解决，那么系统就需要在更早的时间（5～10分钟）发出性能警告，面对每秒百兆的业务数据吞吐，任何定时抓取数据的延时性联机分析系统，都无法在此大数据流量情况下达到实时性的分析计算要求，无法实现数據包重组、轨迹跟踪与性能延时计算等要求。因此需要建立主动式计算分析模型，在数据流动的过程中，建立各个分析场景的多组流计算节点，不断将本节点的计算结果推送至下一个分析场景的计算节点，最终在推送入库之前就完成所有的计算分析结果。此实时计算过程也称为流式计算。

流式计算是健康监测分析核心的基础架构。流式计算基础架构是为了满足提升大数据实时计算处理能力的架构模式，保证数据流处理过程中更灵活的算力配置、可扩展的业务计算需求以及更优的数据吞吐量。

如图7所示，从网络数据源开始，就像一条蜿蜒的河流流经不同的计算站点，经过对数据水流的过滤处理后继续向下一个站点流去，直到最终汇入ElasticSearch的海量存储中。其中Kafka如同具备吞吐量的水库，计算站点在每个阶段处理“前/后”的水流“出/入”水库的操作，就为流经每个站点的水流的处理上提供了吞吐性能的保证，避免了站点处理能力不足造成的“河流”阻塞。计算站点又分成了网络数据采集（JNetPcap）、网络数据清洗（NetProbe）、业务数据清洗（实时计算）、业务增量统计（历史计算），就像在数据河流的不同阶段建立的水流处理站，根据阶段不同，对流经站点的水流处理分工也不同，并进行着职责范围内的过滤处理工作。

数据流经的每个计算站点，采用了分布式计算的系统架构，架构的特点在于根据数据流业务的特征进行分组计算，通过对流式计算任务的这种分解方式，一方面可以极大提高计算性能，另一方面也极大地提高了Kafka队列收发的性能。这就从架构机制上保证了计算结果的实时性。

如图8所示，计算站点会被分成多个计算进程，进程间不直接通讯，而是形成Fork/Join的分支聚合结构的方式进行通讯，任务计算在分支上进行，聚合点（Kafka）实现路由转发。网络采集站点的任务划分是根据相关业务的IP/端口群分组设定，例如外网的税控开票VPN分组、税控开票受理分组、内网的税库银分组，也就是根据业务和数据流量的情况，可以不断细化分组，最终到IP端口为原子级别;网络探针、实时计算、历史计算的任务划分都是根据Kafka的Topic作为分组的条件，形成计算分组和Topic一对一的关系，主题又根据业务分类进行聚合或者新的拆分，同样计算分组也保持一致的划分。

5  结  论

随着分布式应用、云计算的不断深入发展，业务系统的逻辑结构正变得越来越复杂，目前许多应用都是分布式的，应用也从早先的一个大程序演变成系列服务的形式，运行在不同平台上，这种应用的复杂性和灵活性对发现定位性能问题提出了更高的挑战。我们需要一种新的技术手段，用来关注哪些问题影响了企业应用的性能和可用性，关注如何识别这些问题、如何确定它们的重要性以及如何解决这些问题。基于此，本文根据APM模型，对“税务平台健康监测分析系统的设计与实现”的主要技术进行了论述，并完成了部分核心模块的理论阐述和设计。

参考文献：

[1] 中国电子政务网.国家两网，一站，四库，十二金工程 [EB/OL].（2018-05-21）.http：//www.e-gov.org.cn./egov/web/article_detail.php？id=166340.

[2] 黄钊.税收大数据时代的金税三期工程分析 [J].经贸实践，2018（15）：124-125.

[3] 欧舸，金晓茜.浅谈税收大数据时代的金税三期工程 [J].中国管理信息化，2017，20（1）：136-137.

[4] 肖胜球.金税三期背景下建立税务信息系统运维制度的思考 [J].黑龙江科技信息，2016（26）：94.

[5] 陶海.基于Web技术的服務器监控报警管理系统的设计与实现 [D].北京：中国地质大学（北京），2012.

[6] 李天娇.网络监控告警系统的设计与实现 [D].成都：成都理工大学，2017.

[7] 科来.科来网络回溯分析系统（RAS） [EB/OL].[2019-08-24].http：//www.colasoft.com.cn/products/phras.php.

作者简介：郭嘉（1989-），男，汉族，山西晋城人，研发工程师，硕士研究生，研究方向：软件工程与应用。