基于元數據的通用數據查詢接口系統的設計

王正華

關鍵詞：數據查詢；服務接口；元數據；數據庫；系統安全

0 引言

人保財險江蘇省分公司2022年保費收入近500 億元，是整個財產保險行業最大的一家省級分支機構。為支持公司業務發展，江蘇省分公司開發了眾多適合公司管理需求的應用系統。近年來，為順應微服務架構和中臺戰略的潮流，公司積極進行應用的改造，基于微服務將原來的單體應用架構升級為分布式架構，同時為提高安全性，將跨應用的數據庫直接訪問改造成服務接口調用。在進行應用間調用關系的梳理后，發現大部分調用為數據查詢調用，如果每個查詢服務都進行獨立開發，將耗費大量的資源，因此決定開發一套基于元數據的通用查詢接口系統，通過界面進行查詢配置，快速生成查詢服務接口，加快應用改造的進度，也為后續應用開發打下堅實的基礎。

1 系統概述

系統采用Java 作為開發語言，基于傳統的三層B/S架構，Spring Boot構建后端應用，前端通過HTML+CSS+JavaScript（jQuery） 提供WEB配置和管理界面。

系統支持單機部署或集群部署，單機部署時使用Ehcache緩存，集群部署時使用Redis緩存，通過F5或Nginx進行負載均衡。

系統主要由元數據配置、數據源動態管理、數據查詢接口、接口安全控制、日志監控和配置元數據庫及數據緩存等部分構成，其中數據源動態管理、數據查詢接口和接口安全控制是整個系統的核心。

總體架構如圖1所示。

2 系統設計

2.1 數據源動態管理

系統提供配置界面配置數據源名稱、數據庫連接的驅動、連接串、用戶名和密碼以及連接池的大小等參數。系統采用Druid連接池管理數據庫連接，開發連接池管理器，在內存中建立數據源名稱與連接池之間的映射關系，對連接池進行命名管理。連接池按需創建，系統僅創建實際查詢需要的連接池。

注冊連接池時，連接池管理器創建DruidData?Source連接池對象，并添加到名稱與連接池映射表。

刪除連接池時，連接池管理器從映射表中摘除名稱對應的連接池，并將連接池添加到待刪除連接池隊列，由連接池關閉線程在連接池無連接時執行關閉操作并刪除連接池。

連接池的連接數等參數調整時，連接池管理器從映射表取得對應的連接池，修改對應的連接池參數。

系統查詢數據時，連接池管理器從映射表取得對應的連接池，并通過連接池取得數據庫連接，如數據庫連接池尚未創建，則創建連接池。

集群部署時，系統啟用連接池發現線程定期從元數據表中查詢連接池的配置，如發現配置變更則參照上述操作調整連接池。

2.2 數據查詢接口

數據查詢接口是一個遵循REST 架構風格的API[1]，支持根據配置的元數據從關系數據庫中查詢滿足條件的數據，并以適當的格式返回調用者。

2.2.1 元數據配置

系統提供配置界面配置數據查詢接口元數據，數據查詢接口配置項目包括：

1） 查詢的數據表，如果查詢多個數據表，定義表之間的連接類型（內連接、左右外連接等）以及連接條件，系統根據數據庫元數據可自動生成連接條件。

2） 查詢的項目，支持原始的數據表字段、聚合函數，以及基于上述查詢項目的表達式運算。

3） 查詢的條件，分為固有條件和客戶端請求條件兩類。客戶端請求條件定義客戶端請求參數對應的數據表字段或聚合函數，以及實施的控制類型。控制類型包括是否允許模糊匹配、是否為必選項（單個項目必選或一組項目中至少一個必選）。接口查詢元數據配置如圖2所示。

2.2.2 關鍵技術

作為通用的數據查詢接口，支持常見的數據庫類型是系統的基本要求。這方面，系統重點解決以下三個問題：

1） 獲取數據庫表結構以及數據表之間的關系，用于數據查詢接口元數據的配置、查詢條件的解析以及查詢結果輸出格式的選擇。然而不同的數據庫系統，其數據字典存儲的位置也不盡相同，比如Informix使用systables和syscolumns存儲數據表和字段的定義，而PostgreSQL使用pg_class和pg_attribute存儲數據表和字段的定義。

2） 在涉及大量數據查詢時，需要使用合適的參數進行分頁處理，但是各種數據庫在分頁處理上也千差萬別，如Informix數據庫（v11以上版本）使用“SELECTSKIP m FRIST n …”查詢第m條起共n條數據，而Post?greSQL 數據庫使用“SELECT … OFFSET m LIMIT n”實現Informix類似功能。

3） 不同數據庫系統對GROUP BY和ORDER BY 格式要求不同，如Informix可以使用數字序號代替查詢字段，而Oracle要求使用查詢字段名稱；Informix排序字段可以不出現在查詢結果中，而PostgreSQL要求排序字段必須是查詢字段。

本系統從兩個層面解決上述問題：

1） 通過JDBC的DatabaseMetaData獲取數據庫共性元數據[2]。

JDBC中，描述數據庫表等數據字典的數據稱為元數據。系統通過數據庫連接獲得DatabaseMetaData 對象，并使用該對象查詢以下內容：①數據庫中包含的數據表、同義詞或視圖（以下如無特殊說明將數據表、同義詞及視圖統稱為數據表）的Catalog，Schema及數據表名。

②數據表包含的字段以及字段的類型、長度和精度。

③數據表（不包括同義詞和視圖）主鍵字段、表之間的主外鍵關聯關系。

2） 通過方言接口實現數據庫的差異化處理。

系統定義數據庫方言接口，不同的數據庫實現差異化的實現類。接口定義了以下方法：

①getSupportFeatures（）

取得數據庫支持的功能特性，主要用于檢查數據庫是否支持指定查詢起始記錄序號、GROUP BY 和ORDER BY的表示方式和限制條件等。

②splitTableName（String name）

將數據表名拆分為Catalog、Schema和Table名稱三個部分，以便以合適的參數調用DatabaseMetaData 中的方法獲取數據表元數據。

③addLimit（String sql， int start， int count）

在SQL語句中增加查詢范圍限制條件。

數據庫方言工廠通過數據庫連接的Databas?eMetaData獲得數據庫名稱及版本，創建適配的數據庫方言對象。

系統實現了Oracle、SQL Server、DB2、Informix、MySQL、PostgreSQL、Greenplum 和SQLite 等數據庫的方言，同時提供了支持其他數據庫的擴展能力。

2.3 接口安全控制

接口安全控制模塊對查詢請求進行客戶端身份認證、防篡改、超時訪問、地址白名單、流量管控和查詢項目鑒權等安全檢查，并保存訪問日志記錄[3]。

系統使用過濾器實現接口的安全控制，過濾器前置于數據查詢接口，只有過濾器檢查通過的請求才能到達實際的數據查詢接口。

2.3.1 元數據配置

元數據配置功能提供調用者接入代碼、簽名密鑰、白名單地址、允許訪問的接口代碼、訪問流量限制等配置項目，實現上述安全控制功能。

系統定義安全檢查接口，簽名驗證、地址白名單檢查、請求超時檢查以及流量管控等功能實現該接口，安全檢查時，系統根據安全規則中配置的檢查類型使用工廠方法創建安全檢查對象對請求進行檢查，只有通過全部安全檢查的請求才予以放行。

2.3.2 關鍵技術

1） 接口參數的簽名

接口參數簽名是接口安全的重要組成部分，通過數據簽名，可以進行用戶身份識別以及參數的防篡改，配合時間戳完成超時訪問的控制，避免簽名密鑰的暴力破解。

系統為每個接口的調用方分配一個接入代碼和簽名密鑰，客戶端使用簽名密鑰對請求參數進行簽名，系統使用同樣的算法對簽名進行校驗。

請求參數的簽名算法如下：

①按參數名稱的字母（區分大小寫）順序排列請求參數，如兩個參數name和address：

②連接按參數名稱排列的參數值：“江蘇省南京市長江路69號”+“張三”=“江蘇省南京市長江路69號張三”

③添加接入代碼（以test為例），當前時間戳和簽名密鑰（以Doak！937為例）：“test”+“江蘇省南京市長江路69 號張三”+Sys?tem.currentTimeMillis（）+“Doak！937”=“test江蘇省南京市長江路69號張三1688434016264Doak！937”

④計算SHA256的哈希值（使用UTF-8編碼），得到簽名值：DigestUtils. sha256Hex（src. getBytes（StandardChar?sets.UTF_8））=“d0058403e6a1cf3f16e7e0187d4ec92c0da17d31ce3a483ab946c8dc9fa87cef”調用者在實際請求時，除原參數外添加接入代碼（appCode） 、時間戳（time） 和簽名值（sign） 構建完整的請求參數。

2） 流量管控

流量管控依賴歷史調用統計數據，而接口調用為高頻操作，如果實時地存取數據庫中的統計數據，將執行大量的SQL請求，嚴重影響系統性能。

系統采用數據緩存保存調用統計數據，查詢時直接使用緩存數據，操作成功或失敗后更新緩存數據，通過獨立的數據持久化線程，每分鐘執行一次將最近一分鐘的日志數據批量保存到數據表，達到削峰平谷的效果。當系統異常重啟時，首先將數據庫中歷史數據加載到緩存，以保證流量管控的正確運行。

為控制流量日志數據表的大小，系統每天將超過時效的日志數據轉儲到歷史數據表，供日志監控功能查詢。

系統支持以分鐘、小時及天為單位進行流量控制。系統為每對調用者/接口分別按需建立一組包含12個元素的循環隊列，每個元素對應一個時間片，圖4 和圖5分別為分鐘（單位秒）、小時（單位分）和天（單位小時）時間片劃分。

系統記錄循環隊列列頭位置以及對應的時間點，時間點計算公式如下：

分鐘時間片時間點=System.currentTimeMillis（）/1000/5小 時時間片時間點=System.currentTimeMillis（）/

1000/60/5 天時間片時間點=System. currentTimeMillis（）/1000/3600/2

當客戶端請求到達時，系統計算當前時間對應的時間點，與隊列頭時間點進行比較，如果值不相同，則移動隊列頭到適當位置，同時清空過期的元素，最后更新隊列頭的元素值。

單機部署環境下，系統使用JVM內存保存時間片隊列。

集群環境下，系統使用Redis的哈希表模擬循環隊列[4]，哈希表中命名為item0，...，item11的元素對應隊列的第0到第11個元素，head表示隊列頭元素名，time 表示隊列頭對應的時間點，lock表示隊列鎖。當請求的時間點與隊列頭時間點不一致時，使用HSETNX指令鎖定隊列，更新隊列數據后釋放隊列鎖，為避免重復更新，鎖定后進行二次檢查。最后使用HINCBY指令增加統計記數。

3） 客戶端地址的識別

集群部署使用負載均衡器場景下，使用HttpServ?letRequest 的getRemoteAddr 方法已經無法獲得客戶端原始IP地址，導致白名單檢查錯誤。這就需要在系統部署時由負載均衡器在請求頭中添加XForwarded-For記錄通過負載均衡的地址列表[5]，系統在解析請求頭值后，獲得客戶端原始地址。

實際應用中，客戶端（尤其是互聯網客戶端）可能會通過構造X-Forwarded-For請求頭，將非法的地址偽裝成合法的請求地址，為此系統設置可信負載均衡器地址參數，只認可X-Forwarded-For請求地址中可信負載均衡器地址的上一級地址。

3 結束語

實踐表明，基于元數據的通用數據查詢接口系統顯著地提升了查詢類接口對接效率，單個查詢接口實現時長由以前的平均2個工作日縮短到半個小時，而且杜絕了直連數據庫查詢的現象，增強了系統的安全性。系統上線后，配置各類查詢240個，日均訪問量9 萬余次，取得了良好的效果。