微服务下DRC非结构化数据注册引擎设计

黄安琪，杨文晖+，苗 放

(1.成都理工大学 计算机与网络安全学院，四川 成都 610059；
2.成都大学 大数据研究院，四川 成都 610106)

随着国家大数据战略的推进，政府与企业的应用系统的数量与规模呈现指数型增长，导致数据体量不断增大[1]。在海量、多源、异构、实时、动态等比较复杂的情况下，传统的软件体系在面对数据统一管理、系统间数据共享、数据安全等问题时无法从根本上解决问题[2]。必须从数据本身的角度出发，通过数据自身所带的元数据信息来管理数据。

面向数据的体系结构(data oriented architecture，DOA)，定义具体介绍请参见文献[3]。数据注册中心(DRC)是面向数据体系架构中的核心组件，主要的功能就是对数据的注册信息进行存储与管理，DRC建立数据的实时注册机制，提取数据元数据信息，将上层应用与底层数据资源池进行连接，从而为应用提供数据支撑[4]。数据资源统一注册是实现数据资源统一调度和共享应用的有效途径，是分散存储的多源、异构、异地数据和资源目录间的纽带。

数据按类型分为非结构化、结构化、实时数据等，非结构化数据是数据资源池中重要的组成部分，非结构化数据的注册是面向数据的体系结构(DOA)至关重要的一环。目前，针对于非结构化数据的注册方式还存在一些问题。文献[5]分析非结构化数据的注册属性，提出一种通用的数据注册标准，但是数据注册标准主要是针对农业数据，同时对注册方式并未作进一步阐述。文献[6]提出了全自动注册方案，自动提取文件的元数据信息，但是非结构化数据类型是视频与音频时，无法提取自动获取注册信息。文献[7]对非结构化数据的属性进行了分析，对其注册方式进行了研究，提出数据注册工具方式，实现了自动实时注册，将注册信息写入DRC中，但是没有考虑可拓展性、可维护性，仍然采用单体应用架构，由于非结构化数据呈现海量、多源的特征，采用单体应用架构的数据注册工具将所有功能集成在内部，通过部署在数据源进行注册，一旦数据注册工具出现意外而宕机，会导致数据注册无法进行，且排查异常原因困难。同时受数据源服务器性能制约，面对海量文件时，进行负载扩展十分困难，因此无法应对大规模的非结构化数据注册。

微服务架构可以将一个大型的单个应用系统拆分为数个甚至数十个的微服务，可扩展单个组件而不是整个应用程序堆栈，从而实现快速部署与可拓展性、可维护性。文献[8]详细阐述了微服务架构的概念与应用场景。文献[9]验证了微服务技术的可行性。文献[10]对微服务架构和其它的软件结构进行分析和对比。

本文基于DOA的数据注册中心(DRC)与微服务，结合现有的研究成果，设计出一种针对非结构化数据的注册引擎。通过部署非结构化数据注册引擎，对其功能进行测试，得到数据注册的相关数据，同时分析实验数据，验证了该注册引擎的功能，提出了下一步的优化方向。

1.1 非结构化数据注册引擎的系统结构

面向数据的体系架构(DOA)针对海量的多源异构数据提出了数据注册的理念，通过采集数据注册信息，并对注册信息进行管理，从而高效率地管理复杂数据。非结构化数据注册引擎是DRC数据注册中心的主要功能模块，是部署在数据源机器与云服务器上对非结构化数据实现自动实时注册和未来智能注册的基本工作单元。

微服务架构，定义参见文献[11]。将非结构化数据注册引擎由传统的单体应用架构转换为微服务架构来进行设计，具有复杂度可控、维护难度低、系统稳定性高等特点。

根据注册引擎需求分析结果，基于微服务架构的层次化设计理念与服务拆分思想，注册引擎总体设计采用分层式结构，分为注册信息采集单元、注册信息汇集单元、注册信息注册单元、支撑单元，其中采集单元部署在数据源，汇集单元、支持单元与注册单元部署在云服务器上。其系统结构如图1所示。

图1 非结构化数据注册引擎的系统结构

1.2 注册信息采集单元

注册信息采集单元主要功能是根据非结构化数据统一注册标准，对不同类型、不同大小、不同操作系统的文件的注册信息进行自动采集，内置监听模块可实时感知到文件的变化。可通过数据架构中DRC数据注册中心配置注册微引擎，填写数据源相关参数，通过支撑单元来启动任务进行高效率自动化注册信息采集与实现监听。

1.3 注册信息汇集单元

注册信息汇集单元主要具有以下的两个功能：通过分布式消息队列Kafka，将采集单元按照注册标准采集到的非结构化数据注册信息传输到Kafka服务器集群，实现注册信息的实时传输；
在Kafka服务器集群中来汇集从不同数据源采集到的非结构化数据注册信息，实现多源、海量的非结构化数据注册信息汇聚。

1.4 注册信息注册单元

注册信息注册单元主要功能是按照注册策略，从注册信息汇集单元中提取非结构化数据注册信息，并写入DRC数据注册库中。同时注册单元支持灵活定义注册策略，支持在不同应用场景下的数据采集与注册业务。在写入数据注册库之前，通过去重算法对注册信息进行检查，保障注册信息的完善性、可靠性，实现零重复注册。

1.5 支撑单元

支撑单元接收注册任务请求，支持按负载均衡模式指派采集单元、注册单元等模块来执行注册任务，并生成任务调度日志，跟踪任务执行情况。支撑单元内部集成了微服务中的核心功能模块，包括注册引擎服务注册、数据注册任务调度与负载均衡、功能单元心跳与异常检测等。支撑单元与其它功能单元组成了完整的微服务体系，实现了各大功能单元的松耦合，采用声明式RPC实现支撑单元与各功能单元之间的服务调用，通过负载机制来保证注册引擎工作的稳定性与高效性。

2.1 非结构化数据统一注册标准

非结构化数据注册标准是非结构化数据主要内容的描述信息，以经典的都柏林元数据集为基础。涉及的主要注册内容项包括数据本身相关属性信息、数据权属信息、数据安全信息、使用约束等等。统一数据注册标准后，对接入系统数据的标准要求降低，数据适配性提高。

非结构化数据统一注册标准基于上述共性元素，结合个性化特点，并根据DOA进行设计[12]，非结构化数据注册标准管理中需要的基本信息项获取情况和具体内容见表1。

表1 非结构化数据统一注册标准

2.2 微服务注册与发现

数据注册引擎采用微服务架构进行系统设计，为了保证引擎内部微服务间能够相互访问并且具有松耦合度，采用服务注册与发现机制来实现。服务注册中心是注册与发现中最重要的一部分，目前常见的微服务注册发现方案有两种，一种是基于SpringCloud的Eureka来实现，另一种是采用Apache Dubbo与Zookeeper。

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP，而Eureka则是AP。结合DOA相关理念与非结构化数据注册的实际使用场景，注册引擎对一致性的要求要高于可用性，要确保数据注册信息与数据源实时同步与紧耦合关系。故选择Apache Dubbo与Zookeeper方案。

应用该方案，注册信息采集单元和注册单元微服务在启动后，自行将微服务的IP地址等服务本身自带的信息主动发送到服务注册中心上进行注册，服务消费者可以通过支撑单元能够查询注册中心的注册记录，使用负载均衡机制进行任务调度并进行异常与心跳检测。整体实现流程如图2所示。

图2 基于Apache Dubbo与Zookeeper的注册发现实现流程

Apache Dubbo内置dubbo-admin微服务监控管理组件，将DRC数据注册引擎各单元微服务全部部署启动后，通过监控管理组件的可视化界面查看并监控注册引擎各微服务单元运行情况，可视化界面如图3所示。

图3 Dubbo-Admin查看服务注册状态

2.3 注册信息采集

通过部署注册引擎采集单元到数据源机器或前置机上，需要按照非结构化数据统一注册标准来采集文件的注册信息，注册信息的采集利用Apache Tika技术。

Tika可从一千多种不同的文件类型(例如PPT、XLS和PDF)中检测并提取元数据，具有低内存占用、快速处理、灵活元数据、语言检测等优点，同时支持嵌入多种编程语言，能够提取各种操作系统的文件。使用Tika提取文件元数据信息的核心代码表示为：

代码1：使用Apache Tika提取文件注册信息

输入：非结构化数据存放路径

输出：非结构化数据注册信息

(1) ContentHandler handler = new BodyContentHandler (512*1024*1024);

(2) File file = new File(fileAddress);

(3) Metadata metadata = new Metadata();

(4) metadata.set(Metadata.CONTENT_ENCODING, "utf-8");

(5) metadata.set(Metadata.RESOURCE_NAME_KEY, file.getName());

(6) ParseContext content = new ParseContext();

4)敷设时应特别注意对分支器及终端连接器的保护，先用封口袋把尾纤和终端连接器封起来再进行穿槽盒、进屏柜等工作。

(7) Parser parser = new AutoDetectParser();

(8) InputStream stream = null;

(9) try {

(10) stream = new FileInputStream(file);

(11) parser.parse(stream, handler, metadata, content);

(12) stream.close();}

(13) catch (Exception e){

(14) e.printStackTrace();}

(15) return metadata;

2.4 注册信息汇集与提取

通过注册信息采集单元采集到的非结构化数据注册信息需要通过消息中间件传输给数据注册单元，由于部署数据采集单元的数据源较多，并且部署的地点分散，因此需要消息中间件支持分布式消息传输、高并发吞吐量、弹性扩展、可恢复性、可靠传输等特性[13]。目前，应用比较广泛的主流消息中间件的对比见表2。

表2 消息中间件对比

结合非结构化数据注册引擎中各单元之间进行注册信息传输与协调对于消息中间件的要求，以及上述几种主流的消息中间件的对比，选择了Kafka作为注册信息汇集与传输的消息中间件。Kafka是为分布式而生，具有高吞吐量、持久化数据存储、分布式系统易于扩展、消息延迟低等特性，同时具备负载均衡与弹性部署的特点，使用Kafka

能够满足数据采集单元注册信息汇集的需求。

由于非结构化数据需要采集和监听的数据项异常庞大，注册信息数据采集单元会从不同的地点高频的采集海量的注册信息，在传输和汇集时会用到大量的网络带宽与存储空间，因此将Kafka集群部署在云服务器上，满足非结构化注册信息的高效传输与汇集的需求。在注册信息汇集单元中，云服务器上的Kafka集群同时安装分布式应用程序协调服务ZooKeeper，使用Zookeeper来实现动态的集群扩展[14]，不需要更改注册引擎采集单元与注册单元的配置，同时可在集群服务器之间形成高可用服务，当集群中一部分组件失效时，不会影响到整个系统。另外，为了区分非结构化数据注册信息与监听信息，在Kafka集群内，建立不同的Topic分区来传输信息，避免注册单元在提取数据时产生混乱，同时支持负载均衡，保证集群内部各节点的数据均衡[15]。

2.5 零重复注册

在注册信息采集单元采集文件注册信息时，可能会发生采集服务突然宕机，或任务调度时配置了重复的采集任务等一系列会导致重复注册的问题。为了避免出现重复注册而导致DRC数据注册库中不断出现冗余数据，通过梳理可能导致重复注册的场景，设计了一种针对非结构化数据注册的去重算法，实现零重复注册。

算法设计思路采用双步骤模式。新建去重表，存储非结构化数据的MD5码与存储路径，采集单元的IP地址。在采集注册信息时，首先执行步骤一，查询去重表，判断文件全路径与采集单元IP是否在表中存在。若存在，说明该文件曾被注册，需对比文件MD5码来确定该文件是否进行内容修改；
若不存在，则执行步骤二，查询该文件MD5码是否存在，进行进一步判断是否注册。去重算法具体实现流程如图4所示。

图4 去重算法流程

2.6 数据注册实时监听

数据架构的核心部件是数据注册中心(data register center，DRC)，要求对数据进行“天生注册”或“原生注册”。一切数据天生注册包括数据源本地注册与系统产生的新数据的注册。在实际的业务系统中，数据源的文件是动态变化的，比如新增文件、删除文件、修改文件内容、重命名文件等情况。数据注册中间库中存储的注册信息与数据源应该是紧耦合关系，一旦数据源发生变化，注册引擎能实时监听到变化，进行动态更新。实时监听整体流程如图5所示。

图5 实时监听流程

2.6.1 Hook机制

非结构化数据注册引擎是建立在事件驱动的机制上，本质上就是注册信息的采集和注册都是通过消息的传递来实现的。Hook(钩子)是一种特殊的消息处理机制，Hook机制实时获取文件操作，例如复制、另存为等文件操作[16]。遵循DOA数据架构理论中的“天生注册”的理念，及一切数据都要注册。非结构化数据注册引擎利用Hook机制，在注册信息采集单元内部集成Hook实时监听函数，通过将采集单元远程部署到各数据源，实时监听数据源特定事件的发生，比如文件删除、修改内容等。

2.6.2 监听技术

实时监听是保证DRC注册中心与数据源紧耦合关系不可或缺的一环，目前，最常见的文件监听技术有两种，分别为Java WatchService API与Apache Commons IO Monitor。

对两种监听技术进行功能比较，在事件驱动处理方面，WatchService API由操作系统触发的文件系统更改事件驱动。此方法可避免应用程序重复轮询文件系统以查找更改，另一方面，Apache Commons IO Monitor库通过调用File类的listFiles方法以可配置的睡眠间隔轮询文件系统位置。这种方法浪费了CPU周期，尤其是在没有文件发生变化的情况下。在回调方法方面，WatchService API不提供回调方法，相反，它提供了两种类型的轮询方法来检查是否有新的更改事件可用于处理，例如poll(带有超时参数)和take之类的阻塞方法或者像poll这样的非阻塞方法(没有超时参数)，相反，Apache Commons IO库在FileAlte-rationListener接口上提供了回调方法，当检测到文件系统位置或目录发生更改时，将调用这些方法。

由于WatchService API是基于操作系统底层文件系统事件驱动触发，相比Commons IO重复轮询方式，效率更高，消耗计算机资源更少。故选择WatchService API技术来实现实时监听。

3.1 实验环境

实验环境采用集群形式搭建，利用构建的分布式集群和单个节点对非结构化数据注册引擎的采集效率、注册效率、稳定性等功能进行综合测评。

注册测试通过部署9节点的测试集群，在unstruct-01与unstruct-02节点上部署DRC数据注册中心相关组件与服务。在unstruct-03、unstruct-04、unstruct-05节点上部署注册信息汇集单元中的Kafka消息中间件与Zookeeper分布式协调服务。unstruct-06、unstruct-07节点作为数据源服务器，并在节点上部署中注册信息采集单元微服务。在unstruct-08节点上部署注册信息注册单元微服务。在unstruct-09节点上部署支撑单元微服务，作为任务调度中心。集群及各节点的硬件配置与部署基本信息见表3、表4。

表3 计算机硬件配置

表4 节点部署基本信息

3.2 数据准备

为了有效测试非结构化数据注册引擎，需要准备大量的不同类型文件，本文的文件通过网上收集和代码生成两种方式获取，网站来源有成都理工大学研究生院官网、成都大学研究生院官网、知网等，代码生成DOCX、PPT、XLS、MP3、MP4、PDF等类型测试文件，总计两万余个文件。测试文件详情如图6所示。

图6 测试文件详情

3.3 测试及结果分析

本次测试内容包括：对数据注册引擎的采集注册功能进行测试；
对数据注册引擎的性能进行测试；
对数据注册引擎的负载扩展性进行测试。

3.3.1 注册功能测试

在DRC数据注册中心中配置数据注册任务，选取注册的文件夹与需要采集注册的文件类型，如图7所示。该测试文件夹中共有2022个文件，选取全部类型进行采集注册。

图7 注册任务配置

点击保存后，会将注册任务参数传递到注册引擎支撑单元中进行采集任务调度，通过负载均衡指派采集单元进行非结构化数据的注册信息采集。采集完毕后会将符合注册标准的注册信息传输到汇集单元。汇集单元Kafka集群中变化如图8、图9所示。

图8 Kakfa集群初始状态

图9 Kakfa集群采集完毕后状态

当采集单元将注册信息传输到汇集单元Kafka消息队列后，注册单元微服务会监听指定Topic的偏移量变化，发现变化后，支撑单元会指派注册单元去拉取注册信息，拉取后的Kafka集群状态如图10所示。

图10 Kakfa集群注册完毕后状态

注册单元对注册信息运行去重算法进行检查，通过检查后的注册信息写入DRC数据注册库。DRC数据注册库中注册信息展示如图11所示。

图11 非结构化数据注册信息表部分展示

3.3.2 注册性能测试

本文从横向与纵向两个方面对非结构化数据注册引擎进行性能测试，采用控制变量法，测试相同操作系统下不同文件数的采集阶段耗时、总注册耗时，注册成功率，以及在不同操作系统下的文件平均注册耗时；
测试对比了相同文件类型，不同文件大小的注册效率；
测试对比了不同文件类型，相同文件大小的注册效率。

表5显示的是相同操作系统下不同文件数的采集阶段耗时、注册阶段耗时。

表5 不同文件数量注册效率

由表5可以看出，随着注册文件数量的增加，每个文件的注册平均耗费时间会逐渐减少。当文件数量达到汇集单元与注册单元的节点处理瓶颈时，文件的注册平均耗费时间将基本保持不变。在汇集单元与注册单元的微服务数量保持不变的情况下，本次实验环境注册的文件数量峰值在12 000个文件。

表6展示的是不同文件数量的注册成功率。

表6 不同文件数量注册成功率

由表6可知，当注册文件数量在12 000个以内，注册成功率都维持在100%。当注册文件数量超过12 000个时，会出现注册失败的情况。部署单个注册单元微服务在面对大量的注册信息处理时会出现异常，导致注册信息写入DRC数据注册库失败。

图12、图13显示的分别是非结构化数据注册引擎在面对不同操作系统的文件平均注册耗时。

图12 Windows操作系统下文件平均注册耗时

图13 Linux操作系统下文件平均注册耗时

由图12、图13中可以看出注册引擎支撑不同操作系统下的文件注册。在相同的文件数量情况下，Linux操作系统的文件平均注册耗时低于Windows操作系统。

表7展示的是在Windows操作系统下，相同文件类型，不同文件大小的注册效率。这里选取最常用的Word类型进行测试。

表7 文件类型为Word的不同文件大小的注册效率

由表7可知，在操作系统和文件类型相同的情况下，文件大小对于文件注册耗时没有影响。

表8展示的是在Windows操作系统下，不同文件类型，相同文件大小的注册效率。这里选取最常见的Word、PDF、Excel、PPT这4种类型进行测试，文件大小都选取10 MB。

表8 不同文件类型的文件注册效率

由表8可知，在操作系统和文件大小的情况下，4种常见的文件类型的注册耗时都在32.2 ms左右，PPT类型的文件注册耗时会比其它3种类型略大。

3.3.3 负载扩展性测试

基于以上的测试结果，单个注册信息注册单元在文件数量超过12 000个时，达到了性能瓶颈。为了更进一步测试非结构化数据注册引擎的性能，在当前的实验平台下，讨论文件数量保持不变且超过单个注册单元处理极限的情况下，通过改变注册单元的部署个数，测试注册性能的影响。实验结果如图14所示。

图14 不同注册单元个数的文件平均注册耗时

如图14所示，随着注册单元微服务部署个数的增加，文件的平均注册耗时在逐渐减少，当节点个数达到4个及以上时，文件的平均注册耗时将基本保持不变。说明在注册文件数量一定时，可以测出最佳的注册单元微服务部署个数，来达到非结构化数据注册引擎的性能峰值。

本文结合微服务与面向数据的体系架构的相关思想和技术，同时分析非结构化数据的特点，设计出一种非结构化数据注册引擎，提出一种针对非结构化数据的统一注册标准和注册方法，并利用以上的设计方案搭建了实验平台。

基于实验结果和分析，本文所设计的非结构化数据注册引擎能够按照非结构化数据统一注册标准对分布式数据源进行采集注册与实时监听，针对不同的操作系统与不同的文件类型也能实现自动注册。注册引擎与DRC数据注册中心交互状态稳定，满足数据注册的高效性、可靠性，同时通过对非结构化数据注册的性能测试，可知注册引擎在性能上能达到用户性能需求，为DRC数据注册中心的非结构化数据注册信息管理和应用奠定坚实的基础，为更深一步的理论和实践研究提供支持。但在面对海量非结构化数据注册时，注册效率会发生明显的降低，所以今后的改进与优化还可在两方面进行，一方面是改进注册引擎支撑单元任务调度时使用的负载均衡算法；
另一方面是优化注册引擎采集单元的采集模块，提高注册信息采集效率。

猜你喜欢 监听数据源结构化 英国风真无线监听耳机新贵 Cambridge Audio(剑桥)Melomania Touch家庭影院技术(2021年3期)2021-05-21改进的非结构化对等网络动态搜索算法军民两用技术与产品(2021年2期)2021-04-13深度学习的单元结构化教学实践与思考云南教育·小学教师(2021年12期)2021-03-23千元监听风格Hi-Fi箱新选择 Summer audio A-401家庭影院技术(2020年6期)2020-07-27结构化面试方法在研究生复试中的应用计算机教育(2020年5期)2020-07-24左顾右盼 瞻前顾后 融会贯通——基于数学结构化的深度学习福建基础教育研究(2020年3期)2020-05-28一种多源数据融合过程中的实体关联性计算方法中国人民公安大学学报（自然科学版）(2020年1期)2020-05-15利用属性集相关性与源误差的多真值发现方法研究小型微型计算机系统(2019年3期)2019-03-13Web 大数据系统数据源选择*计算机与生活(2018年3期)2018-03-12网络监听的防范措施电子制作(2017年20期)2017-04-26

推荐访问:微服 结构化 引擎