微服務下DRC非結構化數據注冊引擎設計

黃安琪，楊文暉+，苗 放

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

0 引 言

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

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

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

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

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

1 非結構化數據注冊引擎

1.1 非結構化數據注冊引擎的系統結構

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

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

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

圖1 非結構化數據注冊引擎的系統結構

1.2 注冊信息采集單元

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

1.3 注冊信息匯集單元

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

1.4 注冊信息注冊單元

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

1.5 支撐單元

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

2 關鍵技術

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 實驗及分析

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個及以上時，文件的平均注冊耗時將基本保持不變。說明在注冊文件數量一定時，可以測出最佳的注冊單元微服務部署個數，來達到非結構化數據注冊引擎的性能峰值。

4 結束語

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

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