微服務下DRC非結構化數(shù)據(jù)注冊引擎設計

黃安琪，楊文暉+，苗 放

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

0 引 言

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

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

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

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

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

1 非結構化數(shù)據(jù)注冊引擎

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

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

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

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

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

1.2 注冊信息采集單元

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

1.3 注冊信息匯集單元

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

1.4 注冊信息注冊單元

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

1.5 支撐單元

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

2 關鍵技術

2.1 非結構化數(shù)據(jù)統(tǒng)一注冊標準

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

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

表1 非結構化數(shù)據(jù)統(tǒng)一注冊標準

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

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

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

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

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

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

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

2.3 注冊信息采集

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

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

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

輸入：非結構化數(shù)據(jù)存放路徑

輸出：非結構化數(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)敷設時應特別注意對分支器及終端連接器的保護，先用封口袋把尾纖和終端連接器封起來再進行穿槽盒、進屏柜等工作。

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

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

表2 消息中間件對比

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

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

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

2.5 零重復注冊

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

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

圖4 去重算法流程

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

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

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

2.6.1 Hook機制

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

2.6.2 監(jiān)聽技術

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

對兩種監(jiān)聽技術進行功能比較，在事件驅動處理方面，WatchService API由操作系統(tǒng)觸發(fā)的文件系統(tǒng)更改事件驅動。此方法可避免應用程序重復輪詢文件系統(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)方法，當檢測到文件系統(tǒng)位置或目錄發(fā)生更改時，將調(diào)用這些方法。

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

3 實驗及分析

3.1 實驗環(huán)境

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

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

表3 計算機硬件配置

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

3.2 數(shù)據(jù)準備

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

圖6 測試文件詳情

3.3 測試及結果分析

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

3.3.1 注冊功能測試

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

圖7 注冊任務配置

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

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

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

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

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

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

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

3.3.2 注冊性能測試

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

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

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

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

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

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

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

圖12、圖13顯示的分別是非結構化數(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類型進行測試。

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

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

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

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

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

3.3.3 負載擴展性測試

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

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

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

4 結束語

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

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