微服務架構下企業(yè)元數(shù)據(jù)管理平臺的設計和應用

梁晨 王耀俊

摘要：越來越多的金融科技公司開始采用微服務架構設計核心業(yè)務系統(tǒng)，傳統(tǒng)元數(shù)據(jù)管理軟件雖然功能龐雜，但多適用于數(shù)據(jù)倉庫或者大數(shù)據(jù)平臺，架構相對較“重”，且價格不菲，不適用于微服務這種“小快靈”的敏捷開發(fā)模式。微服務架構下，各個微服務可能由多個團隊獨立開發(fā)，元數(shù)據(jù)如果管控不好，以后會造成各個微服務之間數(shù)據(jù)字段定義沖突以及接口交互困難。該文提出了微服務架構下元數(shù)據(jù)管理的流程，并自主研發(fā)了一個適用于微服務模式開發(fā)使用的元數(shù)據(jù)管理平臺，將其與自動化測試以及持續(xù)集成結合使用，有效地提高了微服務開發(fā)的數(shù)據(jù)質量和開發(fā)效率。

關鍵詞：元數(shù)據(jù)管理;微服務;金融科技

中圖分類號：TP311 ? ? ? ?文獻標識碼：A

文章編號：1009-3044（2020）17-0049-02

1 元數(shù)據(jù)和元數(shù)據(jù)管理

元數(shù)據(jù)（meta-data）簡單的定義是描述數(shù)據(jù)的數(shù)據(jù)，元數(shù)據(jù)管理是企業(yè)數(shù)據(jù)治理中最核心和最基礎的工作，也是企業(yè)數(shù)據(jù)中臺的基礎。OMG（國際對象管理組織，BPMN和UML語言標準的制定者）將數(shù)據(jù)模型定義為數(shù)據(jù)、元數(shù)據(jù)、元模型和元元模型從下到上四個層次，每一層都是下層的抽象。元數(shù)據(jù)和元模型是其中管理的核心。

企業(yè)中一般進行管理的元數(shù)據(jù)主要為業(yè)務元數(shù)據(jù)、技術元數(shù)據(jù)。業(yè)務元數(shù)據(jù)主要包括業(yè)務術語、業(yè)務指標、業(yè)務規(guī)則和取值范圍等，業(yè)務術語通常會被拆分和建模成更細的業(yè)務詞典，即元模型。技術元數(shù)據(jù)主要包括數(shù)據(jù)字典、表結構，字段屬性，服務接口等。例如“結算金額”，它的業(yè)務定義和統(tǒng)計規(guī)則是業(yè)務元數(shù)據(jù)，它在數(shù)據(jù)庫存儲的字段類型、長度和精度就屬于技術元數(shù)據(jù)。

2 微服務架構下元數(shù)據(jù)設計和管理的難點

在微服務架構下應用服務被拆分成多個小粒度的微服務，不同的微服務可以由不同的團隊開發(fā)，甚至可以使用不同的開發(fā)語言。如果元數(shù)據(jù)無法統(tǒng)一管理，無法形成統(tǒng)一的元模型，那么微服務之間無法形成統(tǒng)一的“語言”，就無法完成數(shù)據(jù)的通訊和交互。例如一個微服務中日期字段定義成了年-月-日，它的下游接口卻只能接收年/月/日的日期格式，那這兩個微服務就無法交互。

因此有必要對微服務的元數(shù)據(jù)進行統(tǒng)一管理。

3 微服務下元數(shù)據(jù)的管理范圍

為了適應微服務的開發(fā)，業(yè)務元數(shù)據(jù)和技術元數(shù)據(jù)按如下分類納入元數(shù)據(jù)管理：其中業(yè)務詞典、標準技術類型、標準業(yè)務類型、默認值、數(shù)據(jù)字典及關聯(lián)關系和標準字段屬于企業(yè)級的元數(shù)據(jù)，是各個微服務團隊需要統(tǒng)一遵守的元數(shù)據(jù)，這些被定義為公用元數(shù)據(jù)。數(shù)據(jù)庫相關表、視圖等數(shù)據(jù)庫元數(shù)據(jù)和服務接口由每個微服務團隊自己定義，不屬于公用元數(shù)據(jù)。

4 元數(shù)據(jù)的設計過程

設計元數(shù)據(jù)首先要從業(yè)務或用戶需求入手，收集整理業(yè)務需求和場景中所有業(yè)務術語和取值范圍，并對這些業(yè)務術語分解成最新粒度的“單詞”。例如將“參與者交易限額”拆分為“參與者”“交易”和“限額”。各微服務團隊之間如果有“單詞”重復，則以主數(shù)據(jù)源的團隊定義為標準，合并各團隊間不一致的“單詞”，最終形成全系統(tǒng)統(tǒng)一的業(yè)務詞典、默認值和數(shù)據(jù)字典，完成業(yè)務數(shù)據(jù)的建模。

根據(jù)技術上的數(shù)據(jù)庫選型，定義標準技術類型，包括變長字符、定長字符、整數(shù)、小數(shù)、日期和時間等類型?；跇藴始夹g類型，定義標準業(yè)務類型用于標識業(yè)務對象的數(shù)據(jù)類型，賦予業(yè)務含義。

結合業(yè)務詞典和標準業(yè)務類型生成標準字段，標準字段的中文名稱必須全系統(tǒng)唯一，原則上需滿足“修飾符”+“實體名”的格式。

以“結算金額”字段的定義過程為例，首先根據(jù)數(shù)據(jù)庫使用的數(shù)值類型作為標準技術類型ChTNumeric，再根據(jù)業(yè)務含義基于此標準技術類型定義一個“金額”的標準業(yè)務類型ChAmt，長度為18位，小數(shù)精度為2位。在標準字段定義時將“結算金額”定義為ChAmt類型的標準字段（ChAmt類型也可以被其他標準字段如將“交易面額”使用）。

有了標準字段就可以定義表字段和建數(shù)據(jù)表。同時接口對象需按照標準字段定義，不允許接口對象中出現(xiàn)非標準字段，通過給接口對象賦予輸入和輸出屬性可以完成微服務接口的定義。這樣有了元數(shù)據(jù)的控制，表的定義和微服務接口的定義就得到了嚴格的管理。

5 元數(shù)據(jù)管理流程

元數(shù)據(jù)管理涉及三種角色：微服務開發(fā)團隊中的開發(fā)人員、微服務組長、元數(shù)據(jù)管理員。開發(fā)人員負責進行元數(shù)據(jù)的錄入，微服務組長檢查和復核團隊成員錄入的元數(shù)據(jù)，確保組內(nèi)成員申請的元數(shù)據(jù)無歧義和無沖突。如果提交的是公共元數(shù)據(jù)，則在組長復核通過后提交元數(shù)據(jù)管理員審核。元數(shù)據(jù)管理員站在企業(yè)級視角，審核各個微服務團隊提交的公共元數(shù)據(jù)，確保各組之間的定義沒有沖突和違反元數(shù)據(jù)定義規(guī)范。同時元數(shù)據(jù)管理員應該不定期的檢查各個微服務團隊獨立定義的專有元數(shù)據(jù)，確保各自提交的元數(shù)據(jù)符合組織的規(guī)范。

6 元數(shù)據(jù)的平臺架構和實現(xiàn)

筆者從2017年開始元數(shù)據(jù)管理平臺的調研，發(fā)現(xiàn)適合微服務架構開發(fā)的元數(shù)據(jù)管理平臺較少，大部分是傳統(tǒng)數(shù)據(jù)倉庫使用的元數(shù)據(jù)管理平臺，功能雖多但架構較重使用不方便。于是筆者所在公司就自行研發(fā)了針對微服務開發(fā)元數(shù)據(jù)管理平臺（ONE-META）。下面對該平臺整體架構和功能做個簡介。

6.1 整體系統(tǒng)架構

本平臺采用當前較為流行的Spring Boot架構做后臺開發(fā)，Vue.JS做前臺界面開發(fā)。主要包括：1）前端展示層，使用Vue.JS+瀏覽器方式提供用戶界面。2）接入控制層，負責用戶崗位管理、服務監(jiān)控、異常日志和登錄認證等控制功能。3）業(yè)務邏輯層，提供的業(yè)務功能主要包括公用元數(shù)據(jù)管理、數(shù)據(jù)庫元數(shù)據(jù)管理和服務接口元數(shù)據(jù)管理功能模塊，負責各自領域元數(shù)據(jù)的錄入管理;同時本層提供統(tǒng)一公共技術組件包括代碼自動生成、元數(shù)據(jù)核對、影響分析和血緣分析供上層功能模塊統(tǒng)一使用。4）數(shù)據(jù)存儲層，為MySQL數(shù)據(jù)和Redis緩存。

6.2 核心框架技術

1）Spring Boot框架

Spring Boot提供了 Spring組件一站式解決方案，主要是為了簡化使用 Spring 框架的難度和配置。Spring Boot提供了各種組件的啟動器（starters），開發(fā)者只要能配置好對應組件參數(shù)，Spring Boot 就會自動配置，讓開發(fā)者能快速搭建依賴于 Spring 組件的 Java 項目。

2）Vue.JS框架

Vue.JS是一套用于構建B/S前端界面的新一代Javascript框架。Vue.JS采用自底而上的增量開發(fā)模式，重點關注View視圖層的開發(fā)并通過API實現(xiàn)前端響應的數(shù)據(jù)綁定和網(wǎng)頁視圖組件的自動更新。

6.3 核心業(yè)務功能

1）元數(shù)據(jù)的錄入審批功能

主要是公用元數(shù)據(jù)、數(shù)據(jù)庫元數(shù)據(jù)和服務接口元數(shù)據(jù)等各類元數(shù)據(jù)的提交錄入、復核和審批等功能，實現(xiàn)了元數(shù)據(jù)的登記和管控。

2）元數(shù)據(jù)的版本管理

通過拉鏈算法跟蹤元數(shù)據(jù)變化情況，進行版本管理。 拉鏈算法主要是用來記錄整條數(shù)據(jù)的生命周期，然后通過版本號記錄每個元數(shù)據(jù)每次的變更情況，為版本追溯和增加代碼自動生成提供基礎。

3）SQL腳本和JAVA代碼自動生成

根據(jù)數(shù)據(jù)庫元數(shù)據(jù)和版本，自動生成可以交付直接生產(chǎn)的SQL腳本（全量或增量）。例如表結構、字段數(shù)據(jù)字典變更后的SQL語句，減少手工SQL手工編寫SQL腳本操作，提高軟件版本交付質量。

數(shù)據(jù)庫表定義完成后，本平臺還可以自動生成數(shù)據(jù)訪問層的DAO和SQLMAP等JAVA代碼。服務接口定義完成后，可自動生成前后端接口層的JAVA代碼。這兩種代碼自動生成功能減少了開發(fā)人員手工JAVA代碼編寫，提高開發(fā)效率。

4）服務接口注冊及依賴關系管理

包括接口對象的定義，服務接口請求和相應報文定義以及服務接口注冊。本平臺管理的服務接口包括MQ接口和系統(tǒng)間接口。

同時每個接口注冊時需登記調用方，有助于明確微服務之間調用關系和以后調用鏈的分析比對。元數(shù)據(jù)發(fā)生變化后，自動根據(jù)調用關系通知調用方。

5）緩存命名管理

隨著微服務架構中REDIS緩存技術越來越多地被使用，REDIS緩存KEY的命名數(shù)據(jù)的定義也納入技術元數(shù)據(jù)統(tǒng)一管理統(tǒng)一注冊在本平臺，以防止不同微服務之間緩存KEY定義相同，導致緩存沖突。

6）對外REST接口

本元數(shù)據(jù)管理平臺通過REST接口對外提供元數(shù)據(jù)查詢功能，包括服務接口查詢、標準字段查詢和數(shù)據(jù)庫腳本查詢等。因此元數(shù)據(jù)管理可以納入自動化測試或者持續(xù)集成等軟件開發(fā)流程并被調用，進而納入統(tǒng)一的開發(fā)流程管理。

7 元數(shù)據(jù)與持續(xù)集成結合

持續(xù)集成已經(jīng)從軟件工程的最佳實踐變?yōu)槭聦嵣衔⒎臻_發(fā)的行業(yè)標準，它鼓勵開發(fā)人員頻繁地向主干分支提交代碼，頻率為至少每天一次。每次提交完都觸發(fā)完整的編譯構建和自動化測試流程，縮短反饋周期。一旦軟件出現(xiàn)問題都可以第一時間發(fā)現(xiàn)并進行修復，從而保證代碼質量讓軟件隨時處于可發(fā)布狀態(tài)。

在微服務架構開發(fā)測試中，自動化測試中主要的一部分為服務接口的自動化測試，這通常需要測試人員手動根據(jù)開發(fā)人員的接口定義編寫案例。如果開發(fā)人員編寫的接口無法和測試人員的案例有效同步，那么測試是無效的。

本平臺在與自動化測試工具結合時，對外提供了微服務接口定義的查詢功能，自動化測試工具自動讀取元數(shù)據(jù)管理平臺定義的接口，自動生成接口案例，提高了接口案例編寫的效率。接口發(fā)生變更時，自動化測試工具可手工觸發(fā)案例自動更新。

在數(shù)據(jù)庫腳本打包中，持續(xù)集成平臺自動讀取本元數(shù)據(jù)平臺的數(shù)據(jù)庫全量/增量腳本，減少了開發(fā)人員手工編寫數(shù)據(jù)腳本的工作，提升了交付的質量。

8 總結

本文研究了微服務下元數(shù)據(jù)的管理，并自研了適合微服務開發(fā)模式的元數(shù)據(jù)管理平臺。提高了微服務下的元數(shù)據(jù)管理水平和應用系統(tǒng)的設計開發(fā)效率，改善了微服務設計不規(guī)范的現(xiàn)象，促進了金融科技公司數(shù)據(jù)治理向“一致性、規(guī)范性、開放性和共享性”邁進。

參考文獻：

[1] 楊鴻賓，宋明.元數(shù)據(jù)管理平臺總體架構設計研究[J].計算機系統(tǒng)應用，2007，16（11）：17-20.

[2] 于千城.企業(yè)數(shù)據(jù)倉庫中元數(shù)據(jù)的應用研究[J].電腦與信息技術，2008，16（6）：43-45.

[3] 劉麗娟.基于CWM的ETL元數(shù)據(jù)管理系統(tǒng)研究與實現(xiàn)[D].西安：西北大學，2008.

【通聯(lián)編輯：代影】