黃安琪，楊文暉+，苗 放

(1.成都理工大學(xué) 計算機(jī)與網(wǎng)絡(luò)安全學(xué)院，四川 成都 610059；2.成都大學(xué) 大數(shù)據(jù)研究院，四川 成都 610106)

0 引 言

隨著國家大數(shù)據(jù)戰(zhàn)略的推進(jìn)，政府與企業(yè)的應(yīng)用系統(tǒng)的數(shù)量與規(guī)模呈現(xiàn)指數(shù)型增長，導(dǎo)致數(shù)據(jù)體量不斷增大[1]。在海量、多源、異構(gòu)、實時、動態(tài)等比較復(fù)雜的情況下，傳統(tǒng)的軟件體系在面對數(shù)據(jù)統(tǒng)一管理、系統(tǒng)間數(shù)據(jù)共享、數(shù)據(jù)安全等問題時無法從根本上解決問題[2]。必須從數(shù)據(jù)本身的角度出發(fā)，通過數(shù)據(jù)自身所帶的元數(shù)據(jù)信息來管理數(shù)據(jù)。

面向數(shù)據(jù)的體系結(jié)構(gòu)(data oriented architecture，DOA)，定義具體介紹請參見文獻(xiàn)[3]。數(shù)據(jù)注冊中心(DRC)是面向數(shù)據(jù)體系架構(gòu)中的核心組件，主要的功能就是對數(shù)據(jù)的注冊信息進(jìn)行存儲與管理，DRC建立數(shù)據(jù)的實時注冊機(jī)制，提取數(shù)據(jù)元數(shù)據(jù)信息，將上層應(yīng)用與底層數(shù)據(jù)資源池進(jìn)行連接，從而為應(yīng)用提供數(shù)據(jù)支撐[4]。數(shù)據(jù)資源統(tǒng)一注冊是實現(xiàn)數(shù)據(jù)資源統(tǒng)一調(diào)度和共享應(yīng)用的有效途徑，是分散存儲的多源、異構(gòu)、異地數(shù)據(jù)和資源目錄間的紐帶。

數(shù)據(jù)按類型分為非結(jié)構(gòu)化、結(jié)構(gòu)化、實時數(shù)據(jù)等，非結(jié)構(gòu)化數(shù)據(jù)是數(shù)據(jù)資源池中重要的組成部分，非結(jié)構(gòu)化數(shù)據(jù)的注冊是面向數(shù)據(jù)的體系結(jié)構(gòu)(DOA)至關(guān)重要的一環(huán)。目前，針對于非結(jié)構(gòu)化數(shù)據(jù)的注冊方式還存在一些問題。文獻(xiàn)[5]分析非結(jié)構(gòu)化數(shù)據(jù)的注冊屬性，提出一種通用的數(shù)據(jù)注冊標(biāo)準(zhǔn)，但是數(shù)據(jù)注冊標(biāo)準(zhǔn)主要是針對農(nóng)業(yè)數(shù)據(jù)，同時對注冊方式并未作進(jìn)一步闡述。文獻(xiàn)[6]提出了全自動注冊方案，自動提取文件的元數(shù)據(jù)信息，但是非結(jié)構(gòu)化數(shù)據(jù)類型是視頻與音頻時，無法提取自動獲取注冊信息。文獻(xiàn)[7]對非結(jié)構(gòu)化數(shù)據(jù)的屬性進(jìn)行了分析，對其注冊方式進(jìn)行了研究，提出數(shù)據(jù)注冊工具方式，實現(xiàn)了自動實時注冊，將注冊信息寫入DRC中，但是沒有考慮可拓展性、可維護(hù)性，仍然采用單體應(yīng)用架構(gòu)，由于非結(jié)構(gòu)化數(shù)據(jù)呈現(xiàn)海量、多源的特征，采用單體應(yīng)用架構(gòu)的數(shù)據(jù)注冊工具將所有功能集成在內(nèi)部，通過部署在數(shù)據(jù)源進(jìn)行注冊，一旦數(shù)據(jù)注冊工具出現(xiàn)意外而宕機(jī)，會導(dǎo)致數(shù)據(jù)注冊無法進(jìn)行，且排查異常原因困難。同時受數(shù)據(jù)源服務(wù)器性能制約，面對海量文件時，進(jìn)行負(fù)載擴(kuò)展十分困難，因此無法應(yīng)對大規(guī)模的非結(jié)構(gòu)化數(shù)據(jù)注冊。

微服務(wù)架構(gòu)可以將一個大型的單個應(yīng)用系統(tǒng)拆分為數(shù)個甚至數(shù)十個的微服務(wù)，可擴(kuò)展單個組件而不是整個應(yīng)用程序堆棧，從而實現(xiàn)快速部署與可拓展性、可維護(hù)性。文獻(xiàn)[8]詳細(xì)闡述了微服務(wù)架構(gòu)的概念與應(yīng)用場景。文獻(xiàn)[9]驗證了微服務(wù)技術(shù)的可行性。文獻(xiàn)[10]對微服務(wù)架構(gòu)和其它的軟件結(jié)構(gòu)進(jìn)行分析和對比。

本文基于DOA的數(shù)據(jù)注冊中心(DRC)與微服務(wù)，結(jié)合現(xiàn)有的研究成果，設(shè)計出一種針對非結(jié)構(gòu)化數(shù)據(jù)的注冊引擎。通過部署非結(jié)構(gòu)化數(shù)據(jù)注冊引擎，對其功能進(jìn)行測試，得到數(shù)據(jù)注冊的相關(guān)數(shù)據(jù)，同時分析實驗數(shù)據(jù)，驗證了該注冊引擎的功能，提出了下一步的優(yōu)化方向。

1 非結(jié)構(gòu)化數(shù)據(jù)注冊引擎

1.1 非結(jié)構(gòu)化數(shù)據(jù)注冊引擎的系統(tǒng)結(jié)構(gòu)

面向數(shù)據(jù)的體系架構(gòu)(DOA)針對海量的多源異構(gòu)數(shù)據(jù)提出了數(shù)據(jù)注冊的理念，通過采集數(shù)據(jù)注冊信息，并對注冊信息進(jìn)行管理，從而高效率地管理復(fù)雜數(shù)據(jù)。非結(jié)構(gòu)化數(shù)據(jù)注冊引擎是DRC數(shù)據(jù)注冊中心的主要功能模塊，是部署在數(shù)據(jù)源機(jī)器與云服務(wù)器上對非結(jié)構(gòu)化數(shù)據(jù)實現(xiàn)自動實時注冊和未來智能注冊的基本工作單元。

微服務(wù)架構(gòu)，定義參見文獻(xiàn)[11]。將非結(jié)構(gòu)化數(shù)據(jù)注冊引擎由傳統(tǒng)的單體應(yīng)用架構(gòu)轉(zhuǎn)換為微服務(wù)架構(gòu)來進(jìn)行設(shè)計，具有復(fù)雜度可控、維護(hù)難度低、系統(tǒng)穩(wěn)定性高等特點。

根據(jù)注冊引擎需求分析結(jié)果，基于微服務(wù)架構(gòu)的層次化設(shè)計理念與服務(wù)拆分思想，注冊引擎總體設(shè)計采用分層式結(jié)構(gòu)，分為注冊信息采集單元、注冊信息匯集單元、注冊信息注冊單元、支撐單元，其中采集單元部署在數(shù)據(jù)源，匯集單元、支持單元與注冊單元部署在云服務(wù)器上。其系統(tǒng)結(jié)構(gòu)如圖1所示。

圖1 非結(jié)構(gòu)化數(shù)據(jù)注冊引擎的系統(tǒng)結(jié)構(gòu)

1.2 注冊信息采集單元

注冊信息采集單元主要功能是根據(jù)非結(jié)構(gòu)化數(shù)據(jù)統(tǒng)一注冊標(biāo)準(zhǔn)，對不同類型、不同大小、不同操作系統(tǒng)的文件的注冊信息進(jìn)行自動采集，內(nèi)置監(jiān)聽模塊可實時感知到文件的變化?？赏ㄟ^數(shù)據(jù)架構(gòu)中DRC數(shù)據(jù)注冊中心配置注冊微引擎，填寫數(shù)據(jù)源相關(guān)參數(shù)，通過支撐單元來啟動任務(wù)進(jìn)行高效率自動化注冊信息采集與實現(xiàn)監(jiān)聽。

1.3 注冊信息匯集單元

注冊信息匯集單元主要具有以下的兩個功能：通過分布式消息隊列Kafka，將采集單元按照注冊標(biāo)準(zhǔn)采集到的非結(jié)構(gòu)化數(shù)據(jù)注冊信息傳輸?shù)終afka服務(wù)器集群，實現(xiàn)注冊信息的實時傳輸；在Kafka服務(wù)器集群中來匯集從不同數(shù)據(jù)源采集到的非結(jié)構(gòu)化數(shù)據(jù)注冊信息，實現(xiàn)多源、海量的非結(jié)構(gòu)化數(shù)據(jù)注冊信息匯聚。

1.4 注冊信息注冊單元

注冊信息注冊單元主要功能是按照注冊策略，從注冊信息匯集單元中提取非結(jié)構(gòu)化數(shù)據(jù)注冊信息，并寫入DRC數(shù)據(jù)注冊庫中。同時注冊單元支持靈活定義注冊策略，支持在不同應(yīng)用場景下的數(shù)據(jù)采集與注冊業(yè)務(wù)。在寫入數(shù)據(jù)注冊庫之前，通過去重算法對注冊信息進(jìn)行檢查，保障注冊信息的完善性、可靠性，實現(xiàn)零重復(fù)注冊。

1.5 支撐單元

支撐單元接收注冊任務(wù)請求，支持按負(fù)載均衡模式指派采集單元、注冊單元等模塊來執(zhí)行注冊任務(wù)，并生成任務(wù)調(diào)度日志，跟蹤任務(wù)執(zhí)行情況。支撐單元內(nèi)部集成了微服務(wù)中的核心功能模塊，包括注冊引擎服務(wù)注冊、數(shù)據(jù)注冊任務(wù)調(diào)度與負(fù)載均衡、功能單元心跳與異常檢測等。支撐單元與其它功能單元組成了完整的微服務(wù)體系，實現(xiàn)了各大功能單元的松耦合，采用聲明式RPC實現(xiàn)支撐單元與各功能單元之間的服務(wù)調(diào)用，通過負(fù)載機(jī)制來保證注冊引擎工作的穩(wěn)定性與高效性。

2 關(guān)鍵技術(shù)

2.1 非結(jié)構(gòu)化數(shù)據(jù)統(tǒng)一注冊標(biāo)準(zhǔn)

非結(jié)構(gòu)化數(shù)據(jù)注冊標(biāo)準(zhǔn)是非結(jié)構(gòu)化數(shù)據(jù)主要內(nèi)容的描述信息，以經(jīng)典的都柏林元數(shù)據(jù)集為基礎(chǔ)。涉及的主要注冊內(nèi)容項包括數(shù)據(jù)本身相關(guān)屬性信息、數(shù)據(jù)權(quán)屬信息、數(shù)據(jù)安全信息、使用約束等等。統(tǒng)一數(shù)據(jù)注冊標(biāo)準(zhǔn)后，對接入系統(tǒng)數(shù)據(jù)的標(biāo)準(zhǔn)要求降低，數(shù)據(jù)適配性提高。

非結(jié)構(gòu)化數(shù)據(jù)統(tǒng)一注冊標(biāo)準(zhǔn)基于上述共性元素，結(jié)合個性化特點，并根據(jù)DOA進(jìn)行設(shè)計[12]，非結(jié)構(gòu)化數(shù)據(jù)注冊標(biāo)準(zhǔn)管理中需要的基本信息項獲取情況和具體內(nèi)容見表1。

表1 非結(jié)構(gòu)化數(shù)據(jù)統(tǒng)一注冊標(biāo)準(zhǔn)

2.2 微服務(wù)注冊與發(fā)現(xiàn)

數(shù)據(jù)注冊引擎采用微服務(wù)架構(gòu)進(jìn)行系統(tǒng)設(shè)計，為了保證引擎內(nèi)部微服務(wù)間能夠相互訪問并且具有松耦合度，采用服務(wù)注冊與發(fā)現(xiàn)機(jī)制來實現(xiàn)。服務(wù)注冊中心是注冊與發(fā)現(xiàn)中最重要的一部分，目前常見的微服務(wù)注冊發(fā)現(xiàn)方案有兩種，一種是基于SpringCloud的Eureka來實現(xiàn)，另一種是采用Apache Dubbo與Zookeeper。

著名的CAP理論指出，一個分布式系統(tǒng)不可能同時滿足C(一致性)、A(可用性)和P(分區(qū)容錯性)。由于分區(qū)容錯性在是分布式系統(tǒng)中必須要保證的，因此我們只能在A和C之間進(jìn)行權(quán)衡。在此Zookeeper保證的是CP，而Eureka則是AP。結(jié)合DOA相關(guān)理念與非結(jié)構(gòu)化數(shù)據(jù)注冊的實際使用場景，注冊引擎對一致性的要求要高于可用性，要確保數(shù)據(jù)注冊信息與數(shù)據(jù)源實時同步與緊耦合關(guān)系。故選擇Apache Dubbo與Zookeeper方案。

應(yīng)用該方案，注冊信息采集單元和注冊單元微服務(wù)在啟動后，自行將微服務(wù)的IP地址等服務(wù)本身自帶的信息主動發(fā)送到服務(wù)注冊中心上進(jìn)行注冊，服務(wù)消費者可以通過支撐單元能夠查詢注冊中心的注冊記錄，使用負(fù)載均衡機(jī)制進(jìn)行任務(wù)調(diào)度并進(jìn)行異常與心跳檢測。整體實現(xiàn)流程如圖2所示。

圖2 基于Apache Dubbo與Zookeeper的注冊發(fā)現(xiàn)實現(xiàn)流程

Apache Dubbo內(nèi)置dubbo-admin微服務(wù)監(jiān)控管理組件，將DRC數(shù)據(jù)注冊引擎各單元微服務(wù)全部部署啟動后，通過監(jiān)控管理組件的可視化界面查看并監(jiān)控注冊引擎各微服務(wù)單元運行情況，可視化界面如圖3所示。

圖3 Dubbo-Admin查看服務(wù)注冊狀態(tài)

2.3 注冊信息采集

通過部署注冊引擎采集單元到數(shù)據(jù)源機(jī)器或前置機(jī)上，需要按照非結(jié)構(gòu)化數(shù)據(jù)統(tǒng)一注冊標(biāo)準(zhǔn)來采集文件的注冊信息，注冊信息的采集利用Apache Tika技術(shù)。

Tika可從一千多種不同的文件類型(例如PPT、XLS和PDF)中檢測并提取元數(shù)據(jù)，具有低內(nèi)存占用、快速處理、靈活元數(shù)據(jù)、語言檢測等優(yōu)點，同時支持嵌入多種編程語言，能夠提取各種操作系統(tǒng)的文件。使用Tika提取文件元數(shù)據(jù)信息的核心代碼表示為：

代碼1：使用Apache Tika提取文件注冊信息

輸入：非結(jié)構(gòu)化數(shù)據(jù)存放路徑

輸出：非結(jié)構(gòu)化數(shù)據(jù)注冊信息

(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)敷設(shè)時應(yīng)特別注意對分支器及終端連接器的保護(hù)，先用封口袋把尾纖和終端連接器封起來再進(jìn)行穿槽盒、進(jìn)屏柜等工作。

(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 注冊信息匯集與提取

通過注冊信息采集單元采集到的非結(jié)構(gòu)化數(shù)據(jù)注冊信息需要通過消息中間件傳輸給數(shù)據(jù)注冊單元，由于部署數(shù)據(jù)采集單元的數(shù)據(jù)源較多，并且部署的地點分散，因此需要消息中間件支持分布式消息傳輸、高并發(fā)吞吐量、彈性擴(kuò)展、可恢復(fù)性、可靠傳輸?shù)忍匦訹13]。目前，應(yīng)用比較廣泛的主流消息中間件的對比見表2。

表2 消息中間件對比

結(jié)合非結(jié)構(gòu)化數(shù)據(jù)注冊引擎中各單元之間進(jìn)行注冊信息傳輸與協(xié)調(diào)對于消息中間件的要求，以及上述幾種主流的消息中間件的對比，選擇了Kafka作為注冊信息匯集與傳輸?shù)南⒅虚g件。Kafka是為分布式而生，具有高吞吐量、持久化數(shù)據(jù)存儲、分布式系統(tǒng)易于擴(kuò)展、消息延遲低等特性，同時具備負(fù)載均衡與彈性部署的特點，使用Kafka

能夠滿足數(shù)據(jù)采集單元注冊信息匯集的需求。

由于非結(jié)構(gòu)化數(shù)據(jù)需要采集和監(jiān)聽的數(shù)據(jù)項異常龐大，注冊信息數(shù)據(jù)采集單元會從不同的地點高頻的采集海量的注冊信息，在傳輸和匯集時會用到大量的網(wǎng)絡(luò)帶寬與存儲空間，因此將Kafka集群部署在云服務(wù)器上，滿足非結(jié)構(gòu)化注冊信息的高效傳輸與匯集的需求。在注冊信息匯集單元中，云服務(wù)器上的Kafka集群同時安裝分布式應(yīng)用程序協(xié)調(diào)服務(wù)ZooKeeper，使用Zookeeper來實現(xiàn)動態(tài)的集群擴(kuò)展[14]，不需要更改注冊引擎采集單元與注冊單元的配置，同時可在集群服務(wù)器之間形成高可用服務(wù)，當(dāng)集群中一部分組件失效時，不會影響到整個系統(tǒng)。另外，為了區(qū)分非結(jié)構(gòu)化數(shù)據(jù)注冊信息與監(jiān)聽信息，在Kafka集群內(nèi)，建立不同的Topic分區(qū)來傳輸信息，避免注冊單元在提取數(shù)據(jù)時產(chǎn)生混亂，同時支持負(fù)載均衡，保證集群內(nèi)部各節(jié)點的數(shù)據(jù)均衡[15]。

2.5 零重復(fù)注冊

在注冊信息采集單元采集文件注冊信息時，可能會發(fā)生采集服務(wù)突然宕機(jī)，或任務(wù)調(diào)度時配置了重復(fù)的采集任務(wù)等一系列會導(dǎo)致重復(fù)注冊的問題。為了避免出現(xiàn)重復(fù)注冊而導(dǎo)致DRC數(shù)據(jù)注冊庫中不斷出現(xiàn)冗余數(shù)據(jù)，通過梳理可能導(dǎo)致重復(fù)注冊的場景，設(shè)計了一種針對非結(jié)構(gòu)化數(shù)據(jù)注冊的去重算法，實現(xiàn)零重復(fù)注冊。

算法設(shè)計思路采用雙步驟模式。新建去重表，存儲非結(jié)構(gòu)化數(shù)據(jù)的MD5碼與存儲路徑，采集單元的IP地址。在采集注冊信息時，首先執(zhí)行步驟一，查詢?nèi)ブ乇恚袛辔募窂脚c采集單元IP是否在表中存在。若存在，說明該文件曾被注冊，需對比文件MD5碼來確定該文件是否進(jìn)行內(nèi)容修改；若不存在，則執(zhí)行步驟二，查詢該文件MD5碼是否存在，進(jìn)行進(jìn)一步判斷是否注冊。去重算法具體實現(xiàn)流程如圖4所示。

圖4 去重算法流程

2.6 數(shù)據(jù)注冊實時監(jiān)聽

數(shù)據(jù)架構(gòu)的核心部件是數(shù)據(jù)注冊中心(data register center，DRC)，要求對數(shù)據(jù)進(jìn)行“天生注冊”或“原生注冊”。一切數(shù)據(jù)天生注冊包括數(shù)據(jù)源本地注冊與系統(tǒng)產(chǎn)生的新數(shù)據(jù)的注冊。在實際的業(yè)務(wù)系統(tǒng)中，數(shù)據(jù)源的文件是動態(tài)變化的，比如新增文件、刪除文件、修改文件內(nèi)容、重命名文件等情況。數(shù)據(jù)注冊中間庫中存儲的注冊信息與數(shù)據(jù)源應(yīng)該是緊耦合關(guān)系，一旦數(shù)據(jù)源發(fā)生變化，注冊引擎能實時監(jiān)聽到變化，進(jìn)行動態(tài)更新。實時監(jiān)聽整體流程如圖5所示。

圖5 實時監(jiān)聽流程

2.6.1 Hook機(jī)制

非結(jié)構(gòu)化數(shù)據(jù)注冊引擎是建立在事件驅(qū)動的機(jī)制上，本質(zhì)上就是注冊信息的采集和注冊都是通過消息的傳遞來實現(xiàn)的。Hook(鉤子)是一種特殊的消息處理機(jī)制，Hook機(jī)制實時獲取文件操作，例如復(fù)制、另存為等文件操作[16]。遵循DOA數(shù)據(jù)架構(gòu)理論中的“天生注冊”的理念，及一切數(shù)據(jù)都要注冊。非結(jié)構(gòu)化數(shù)據(jù)注冊引擎利用Hook機(jī)制，在注冊信息采集單元內(nèi)部集成Hook實時監(jiān)聽函數(shù)，通過將采集單元遠(yuǎn)程部署到各數(shù)據(jù)源，實時監(jiān)聽數(shù)據(jù)源特定事件的發(fā)生，比如文件刪除、修改內(nèi)容等。

2.6.2 監(jiān)聽技術(shù)

實時監(jiān)聽是保證DRC注冊中心與數(shù)據(jù)源緊耦合關(guān)系不可或缺的一環(huán)，目前，最常見的文件監(jiān)聽技術(shù)有兩種，分別為Java WatchService API與Apache Commons IO Monitor。

對兩種監(jiān)聽技術(shù)進(jìn)行功能比較，在事件驅(qū)動處理方面，WatchService API由操作系統(tǒng)觸發(fā)的文件系統(tǒng)更改事件驅(qū)動。此方法可避免應(yīng)用程序重復(fù)輪詢文件系統(tǒng)以查找更改，另一方面，Apache Commons IO Monitor庫通過調(diào)用File類的listFiles方法以可配置的睡眠間隔輪詢文件系統(tǒng)位置。這種方法浪費了CPU周期，尤其是在沒有文件發(fā)生變化的情況下。在回調(diào)方法方面，WatchService API不提供回調(diào)方法，相反，它提供了兩種類型的輪詢方法來檢查是否有新的更改事件可用于處理，例如poll(帶有超時參數(shù))和take之類的阻塞方法或者像poll這樣的非阻塞方法(沒有超時參數(shù))，相反，Apache Commons IO庫在FileAlte-rationListener接口上提供了回調(diào)方法，當(dāng)檢測到文件系統(tǒng)位置或目錄發(fā)生更改時，將調(diào)用這些方法。

由于WatchService API是基于操作系統(tǒng)底層文件系統(tǒng)事件驅(qū)動觸發(fā)，相比Commons IO重復(fù)輪詢方式，效率更高，消耗計算機(jī)資源更少。故選擇WatchService API技術(shù)來實現(xiàn)實時監(jiān)聽。

3 實驗及分析

3.1 實驗環(huán)境

實驗環(huán)境采用集群形式搭建，利用構(gòu)建的分布式集群和單個節(jié)點對非結(jié)構(gòu)化數(shù)據(jù)注冊引擎的采集效率、注冊效率、穩(wěn)定性等功能進(jìn)行綜合測評。

注冊測試通過部署9節(jié)點的測試集群，在unstruct-01與unstruct-02節(jié)點上部署DRC數(shù)據(jù)注冊中心相關(guān)組件與服務(wù)。在unstruct-03、unstruct-04、unstruct-05節(jié)點上部署注冊信息匯集單元中的Kafka消息中間件與Zookeeper分布式協(xié)調(diào)服務(wù)。unstruct-06、unstruct-07節(jié)點作為數(shù)據(jù)源服務(wù)器，并在節(jié)點上部署中注冊信息采集單元微服務(wù)。在unstruct-08節(jié)點上部署注冊信息注冊單元微服務(wù)。在unstruct-09節(jié)點上部署支撐單元微服務(wù)，作為任務(wù)調(diào)度中心。集群及各節(jié)點的硬件配置與部署基本信息見表3、表4。

表3 計算機(jī)硬件配置

表4 節(jié)點部署基本信息

3.2 數(shù)據(jù)準(zhǔn)備

為了有效測試非結(jié)構(gòu)化數(shù)據(jù)注冊引擎，需要準(zhǔn)備大量的不同類型文件，本文的文件通過網(wǎng)上收集和代碼生成兩種方式獲取，網(wǎng)站來源有成都理工大學(xué)研究生院官網(wǎng)、成都大學(xué)研究生院官網(wǎng)、知網(wǎng)等，代碼生成DOCX、PPT、XLS、MP3、MP4、PDF等類型測試文件，總計兩萬余個文件。測試文件詳情如圖6所示。

圖6 測試文件詳情

3.3 測試及結(jié)果分析

本次測試內(nèi)容包括：對數(shù)據(jù)注冊引擎的采集注冊功能進(jìn)行測試；對數(shù)據(jù)注冊引擎的性能進(jìn)行測試；對數(shù)據(jù)注冊引擎的負(fù)載擴(kuò)展性進(jìn)行測試。

3.3.1 注冊功能測試

在DRC數(shù)據(jù)注冊中心中配置數(shù)據(jù)注冊任務(wù)，選取注冊的文件夾與需要采集注冊的文件類型，如圖7所示。該測試文件夾中共有2022個文件，選取全部類型進(jìn)行采集注冊。

圖7 注冊任務(wù)配置

點擊保存后，會將注冊任務(wù)參數(shù)傳遞到注冊引擎支撐單元中進(jìn)行采集任務(wù)調(diào)度，通過負(fù)載均衡指派采集單元進(jìn)行非結(jié)構(gòu)化數(shù)據(jù)的注冊信息采集。采集完畢后會將符合注冊標(biāo)準(zhǔn)的注冊信息傳輸?shù)絽R集單元。匯集單元Kafka集群中變化如圖8、圖9所示。

圖8 Kakfa集群初始狀態(tài)

圖9 Kakfa集群采集完畢后狀態(tài)

當(dāng)采集單元將注冊信息傳輸?shù)絽R集單元Kafka消息隊列后，注冊單元微服務(wù)會監(jiān)聽指定Topic的偏移量變化，發(fā)現(xiàn)變化后，支撐單元會指派注冊單元去拉取注冊信息，拉取后的Kafka集群狀態(tài)如圖10所示。

圖10 Kakfa集群注冊完畢后狀態(tài)

注冊單元對注冊信息運行去重算法進(jìn)行檢查，通過檢查后的注冊信息寫入DRC數(shù)據(jù)注冊庫。DRC數(shù)據(jù)注冊庫中注冊信息展示如圖11所示。

圖11 非結(jié)構(gòu)化數(shù)據(jù)注冊信息表部分展示

3.3.2 注冊性能測試

本文從橫向與縱向兩個方面對非結(jié)構(gòu)化數(shù)據(jù)注冊引擎進(jìn)行性能測試，采用控制變量法，測試相同操作系統(tǒng)下不同文件數(shù)的采集階段耗時、總注冊耗時，注冊成功率，以及在不同操作系統(tǒng)下的文件平均注冊耗時；測試對比了相同文件類型，不同文件大小的注冊效率；測試對比了不同文件類型，相同文件大小的注冊效率。

表5顯示的是相同操作系統(tǒng)下不同文件數(shù)的采集階段耗時、注冊階段耗時。

表5 不同文件數(shù)量注冊效率

由表5可以看出，隨著注冊文件數(shù)量的增加，每個文件的注冊平均耗費時間會逐漸減少。當(dāng)文件數(shù)量達(dá)到匯集單元與注冊單元的節(jié)點處理瓶頸時，文件的注冊平均耗費時間將基本保持不變。在匯集單元與注冊單元的微服務(wù)數(shù)量保持不變的情況下，本次實驗環(huán)境注冊的文件數(shù)量峰值在12 000個文件。

表6展示的是不同文件數(shù)量的注冊成功率。

表6 不同文件數(shù)量注冊成功率

由表6可知，當(dāng)注冊文件數(shù)量在12 000個以內(nèi)，注冊成功率都維持在100%。當(dāng)注冊文件數(shù)量超過12 000個時，會出現(xiàn)注冊失敗的情況。部署單個注冊單元微服務(wù)在面對大量的注冊信息處理時會出現(xiàn)異常，導(dǎo)致注冊信息寫入DRC數(shù)據(jù)注冊庫失敗。

圖12、圖13顯示的分別是非結(jié)構(gòu)化數(shù)據(jù)注冊引擎在面對不同操作系統(tǒng)的文件平均注冊耗時。

圖12 Windows操作系統(tǒng)下文件平均注冊耗時

圖13 Linux操作系統(tǒng)下文件平均注冊耗時

由圖12、圖13中可以看出注冊引擎支撐不同操作系統(tǒng)下的文件注冊。在相同的文件數(shù)量情況下，Linux操作系統(tǒng)的文件平均注冊耗時低于Windows操作系統(tǒng)。

表7展示的是在Windows操作系統(tǒng)下，相同文件類型，不同文件大小的注冊效率。這里選取最常用的Word類型進(jìn)行測試。

表7 文件類型為Word的不同文件大小的注冊效率

由表7可知，在操作系統(tǒng)和文件類型相同的情況下，文件大小對于文件注冊耗時沒有影響。

表8展示的是在Windows操作系統(tǒng)下，不同文件類型，相同文件大小的注冊效率。這里選取最常見的Word、PDF、Excel、PPT這4種類型進(jìn)行測試，文件大小都選取10 MB。

表8 不同文件類型的文件注冊效率

由表8可知，在操作系統(tǒng)和文件大小的情況下，4種常見的文件類型的注冊耗時都在32.2 ms左右，PPT類型的文件注冊耗時會比其它3種類型略大。

3.3.3 負(fù)載擴(kuò)展性測試

基于以上的測試結(jié)果，單個注冊信息注冊單元在文件數(shù)量超過12 000個時，達(dá)到了性能瓶頸。為了更進(jìn)一步測試非結(jié)構(gòu)化數(shù)據(jù)注冊引擎的性能，在當(dāng)前的實驗平臺下，討論文件數(shù)量保持不變且超過單個注冊單元處理極限的情況下，通過改變注冊單元的部署個數(shù)，測試注冊性能的影響。實驗結(jié)果如圖14所示。

圖14 不同注冊單元個數(shù)的文件平均注冊耗時

如圖14所示，隨著注冊單元微服務(wù)部署個數(shù)的增加，文件的平均注冊耗時在逐漸減少，當(dāng)節(jié)點個數(shù)達(dá)到4個及以上時，文件的平均注冊耗時將基本保持不變。說明在注冊文件數(shù)量一定時，可以測出最佳的注冊單元微服務(wù)部署個數(shù)，來達(dá)到非結(jié)構(gòu)化數(shù)據(jù)注冊引擎的性能峰值。

4 結(jié)束語

本文結(jié)合微服務(wù)與面向數(shù)據(jù)的體系架構(gòu)的相關(guān)思想和技術(shù)，同時分析非結(jié)構(gòu)化數(shù)據(jù)的特點，設(shè)計出一種非結(jié)構(gòu)化數(shù)據(jù)注冊引擎，提出一種針對非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一注冊標(biāo)準(zhǔn)和注冊方法，并利用以上的設(shè)計方案搭建了實驗平臺。

基于實驗結(jié)果和分析，本文所設(shè)計的非結(jié)構(gòu)化數(shù)據(jù)注冊引擎能夠按照非結(jié)構(gòu)化數(shù)據(jù)統(tǒng)一注冊標(biāo)準(zhǔn)對分布式數(shù)據(jù)源進(jìn)行采集注冊與實時監(jiān)聽，針對不同的操作系統(tǒng)與不同的文件類型也能實現(xiàn)自動注冊。注冊引擎與DRC數(shù)據(jù)注冊中心交互狀態(tài)穩(wěn)定，滿足數(shù)據(jù)注冊的高效性、可靠性，同時通過對非結(jié)構(gòu)化數(shù)據(jù)注冊的性能測試，可知注冊引擎在性能上能達(dá)到用戶性能需求，為DRC數(shù)據(jù)注冊中心的非結(jié)構(gòu)化數(shù)據(jù)注冊信息管理和應(yīng)用奠定堅實的基礎(chǔ)，為更深一步的理論和實踐研究提供支持。但在面對海量非結(jié)構(gòu)化數(shù)據(jù)注冊時，注冊效率會發(fā)生明顯的降低，所以今后的改進(jìn)與優(yōu)化還可在兩方面進(jìn)行，一方面是改進(jìn)注冊引擎支撐單元任務(wù)調(diào)度時使用的負(fù)載均衡算法；另一方面是優(yōu)化注冊引擎采集單元的采集模塊，提高注冊信息采集效率。