分布式数据流系统分析论文

摘要：软件总线是管理和组织软件系统构件的平台，是一种有别于硬件总线的软件开发工具。它是保证软件建设过程规范性，系统在运用中具有可靠、适用和扩展性，满足用户和发展的需求。本文对软件总线模块设计方案进行了理论阐述。下面是小编整理的《分布式数据流系统分析论文(精选3篇)》，供大家参考借鉴，希望可以帮助到有需要的朋友。

分布式数据流系统分析论文 篇1：

基于SOA的在线考试网站系统的设计与实现

摘 要 随着现代社会计算机技术飞速的发展，目前网上在线考试系统已经成为一种非常流行的现代化的教育教学管理手段。以前由于技术限制，在考试系统的开发上存在某些这样或那样的局限，总是不尽人意。文章对基于SOA的在线考试网站系统提出了系统的改良、构建思路和实现的基本方法，并且通过使用面向服务的程序设计对整个在线考试进行整合，并在此基础上进行了一些探索。

关键词 在线考试；SOA；服务业务数据流程

高等职业教育近几年发展迅速，前景可观。目前要解决的首要问题是如何使用先进的技术手段和通过完善的考核制度从而减少学生考试作弊机会，并且提高教学评价能力和教学管理水平。无纸化在线考试网站系统的建立可以解决这个问题。

无纸化在线考试网站系统有以下优势：考试方式灵活，时间和地点不受限制；节约了考试成本；考试题库更加智能化；自动组卷功能提高出卷速度；试卷随机生成可以真正实现教考分离；提高判卷的速度和准确率；避免考题重复，减少抄袭现象。

因此，开发一套在线考试系统，对提高学生的学习效果和教师的教学效果具有非常现实的意义。

1 国内外网上考试系统的研究现状

在当今计算机网络技术的声速发展和行业规范化程度的迅速提高的基础上，各种各样从事于考试业务的公司应运而生，相应在此基础上产生很多基于网络的考试系统。但是，由于各种考试系统具有非常强的针对性，每个系统应该具备不同的考试模式。并且在实际运行中存在着诸多问题，因需要考虑到系统的实时性、兼容性、开放性和服务器复用问题。

2 系统分析与设计

2.1 系统运行环境

操作系统：客户端主要考虑采用Windows 2000 或者Professional操作系统。服务器端主要考虑采用Windows 2000 Server。

测试环境：选择采用Windows 2000 Server和Professional操作系统。

2.2 相关技术描述

采用ASP.NET动态服务器端脚本编程技术和HTTP、XML、DOM、XSL、SOAP等跨平台的Web Service技术来实现无纸化在线考试网站的设计。基于XML的Web Service技术可以解决跨平台实现远程过程的透明调用。HTTP协议穿过防火墙非常容易；本地的XML结合XLS技术可以大大降低网络流量，服务机与客户机的协同工作还解决服务器的压力的难题。

2.3 模块设计

以试题库模块为例，试题库维护模块包括：

1）题库结构创建和维护子模块：在该模块教师可以对考试的学科类别和课程体系进行定义与更新。

2）题库内容维护和创建子模块：在该模块教师可以完成题目的修改、添加、删除等更新操作。

3）资源注册与服务描述子模块：在该模块可以在中心服务器注册服务资源URI，并且可以描述所提供的服务。

图1 试题库维护模块用例图

2.4 服务业务数据流程

考试系统服务设计模如图2所示。

图2 考试系统服务业务数据流程

3 系统实现

3.1 系统架构

网站系统是按照三层架构所编写，应用的VS2008自带的AJAX无刷新开发环境，网站安全的实现是通过使用无解密MD5单向加密技术来完成的。

3.2 系统界面

以网站系统的登录页面为例：用户在该界面输入用户编号和密码，网站系统从Usersmr数据表中读取用户编号，根据用户编号查询用户密码。如果密码错误，给出错误提示。如果正确，用自定义方法 CreateCookie（）存储用户编号，用户编号存储到创建的Cookie对象中，并转向用户操作界面。

图3 在线考试登录界面

4 总结与展望

网络给教育带来的是巨大的冲击，为教育现代化提供了相当大的机遇。教育机构计算机网络的建设大大促进了网络考试与教育教学质量评价的有机结合。由于时间的限制和实验环境等条件的局限以及开发经验等方面还存在相当大的不足，有待进一步的完善和改进，主要有以下几个方面：增加多种形式的试题；进一步研究考试网站系统的安全性问题；进一步研究考试的结果反馈影响试题的参数问题；对考试题库的结构进一步优化，提出更合理的设计从而提高组卷的效率和访问的速度。

参考文献

[1]翟洁，等.一个分布式网络考试系统的设计与实现微机发展[J].微机发展，2001（1）.

[2]赵强，张红忠.基于ASP.NET的网站系统安全性设计与实现[J].计算机应用，2008.

[3]罗爱军.一个网上考试系统的设计和实现[D].东南大学，2006.

[4]何卫红.基于SOA的江海职业学院网络教学平台设计与实现[D].扬州大学，2009.

[5]汪赵强.基于SOA的网上考试系统的设计与实现[D].北京邮电大学，2009.

作者：尹蕾

分布式数据流系统分析论文 篇2：

基于软件总线技术的设计方法

摘要：软件总线是管理和组织软件系统构件的平台，是一种有别于硬件总线的软件开发工具。它是保证软件建设过程规范性，系统在运用中具有可靠、适用和扩展性，满足用户和发展的需求。本文对软件总线模块设计方案进行了理论阐述。

关键词：软件总线；构件模块；设计方法

Design Based on Software Bus Technology

Liu Kaiying

(Department of Computer Science,Guiyang University,Guiyang550005,China)

一、软件总线的概念界定

又称软总线，是硬件总线的虚拟和映射。是一组编写多个、多种类型软件功能部件服务的多种计算机语言虚拟的数据传输线。也是计算机操作系统与集成功能部件间或部件之间，数据传输与联系时的虚拟公共通道和接口界面。

I2C总线（Inter IC BUS）是一种接口少和通信效率高的双向两线串行通信的标准，这种标准的优点很多，现在已经被广泛的运用起来。总线可以进行简单的单在多节点通信系统，所以可以防止通信被破坏或是数据被破坏。

如果两个或者更多的主节点同时启动数据传输，总线具有冲突检测和仲裁功能，保证通信正常进行并防止数据破坏。对于没有I2C总线接口的MCU，可以采用两条I/O接口线进行模拟。目前，一些介绍模拟I2C的资料主要讲的是在单主节点系统中进行的通信，这使得模拟I2C总线的应用具有一定的局限性。本文根据总线仲裁的思想，提出一种多主节点通信的思想及实现流程。总线协议规定，各主节点进行通信时都要有起始、结束、发送数据和应答信号。这些信号都是通信过程中的基本单元。总线传送的每1帧数据均是1个字节，每当发送完1个字节后，接收节点就相应给一应答信号。协议规定，在启动总线后的第1个字节的高7位是对从节点的寻址地址，第8位为方向位（“0”表示主节点对从节点的写操作；“1”表示主节点对从节点的读操作），其余的字节为操作数据。图1列出I2C总线上几个基本信号的时序。

图1：I2C总线数据传递时序

二、软件总线模块设计方案

（一）软件总线设计遵循的原则。首先进行系统分析，根据需要处理应用请求，初步确定软构件种类，规划其需要实现的功能。每构件对象完成的逻辑功能不过分繁多，便于软件总线对软构件库的控制，增强软插件板的适用性。用户对数据库的请求通过所选定的软构件实现，将访问权授予软插件，保证了访问数据库的安全性。规划完毕后，制作所选定软构件组成通用的软插件。

（二）软件总线的框架结构。软件总线结构模型中，有一组即插即用的构件集成框架，将构件通过COM或动态链接库等形式加载到总线上后，构件间相互协作，支持网络应用程序间功能共享和信息交互，实现系统的结构分层，主要包括通信功能、调度管理、软总线的管理控制和接口界面四大模块，软件总线的设计需要解决这四个基本要素。

（三）软件总线模块的设计方法。软件总线的设计是虚拟数据传输线能对软构件库中模块的调用、控制和管理，在系统设计前须先对数据库设计。软件总线设计思想的核心是通过软件总线

框架实现：通讯模块的功能、调度管理模块的功能、接口界面模块功能以及软总线管理控制模块，实现各个构件的协同工作，完成数据交换、构件管理和总线管理。

1.通信功能模块的设计。通信功能是软件总线的重点，设计关键是模块间数据传输协议。一般由总线API、接口、管理和服务四部分构成。通常采用C/S模式通信方式，每一进程可做客户也可作服务器，完全由用户决定功能。总线API向用户提供一组函数，用户通过调用，向总线登记、注册、发送和接收消息。反之，用户向总线登记时，API为其分配一个与其它对应的通信接口，进行应用程序载入、删除及查询等操作。

2.调度管理模块设计。调度管理模块是系统通过软件总线，实现对软构件的调用、安装、卸载和完成对软构件库的管理。根据需要处理的数据流使用任务调度器，调用相应构件，将数据流不断地转换为任务流，驱动整个系统连续工作。数据源构件通过中断等方式，形成原始数据流 调用总线接口函数，接受新的数据调度器将数据流转换为任务流交给线程池 任务流在线程池中运行后，转回产生新的数据流，完成数据处理和系统功能任务。

3.接口界面模块设计。系统对软构件库的管理和控制，软构件间通信联络、数据和信息的传送，都需解决软件总线和这些软构件接口。由于构件间的低耦合性以及不同构件其任务存在显著差别。设计时，需用接口定义表示对象相关性，总线及构件可跨越多个接口，将构件规范划分多个接口，而非整个构件规范。

4.软总线的管理控制模块设计。解决系统与软件组装开发平台及构件库间通信和数据交换、传递的合理分配和控制。通常，构件集成是XML数据流的集成机制来实现，重点是构件加载，脚本是构件加载机制设计的核心，通过为脚本注册总线数据接口，实现构件的即插即用。

三、结束语

总之，做好软件总线设计，为用户提供具有良好开放性、透明性、可靠性和通用性的可重用的系统方案，是确保实现其开发的核心环节，将给软件开发带来大规模的变革。目前，国内外已有不少部门展开了对其的研究，随着软件总线标准的制定，使软件开发走上集成化组装之路，促进大批软件工厂和软件组装公司得以产生和发展。

参考文献：

[1]张秋余,袁占亭,张冬冬,任磊.基于分布式软件总线的软构件开发技术的研究[J].兰州理工大学学报,2005,1

[2]张世琨,张文娟,常欣,王立福,杨芙清.基于软件体系结构的可复用构件制作和组装[J].软件学报,2001,9

作者：刘凯英

分布式数据流系统分析论文 篇3：

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

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

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

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-），男，汉族，山西晋城人，研发工程师，硕士研究生，研究方向：软件工程与应用。

作者：郭嘉