自定義查詢系統架構設計分析

自定義查詢系統架構設計分析

背景

最近參與某新自定義查詢系統開發，系統是鋒哥設計的，核心代碼也是鋒哥寫的。做爲一個搬磚者自下而上的分析學習一下大神的系統設計。文中的談到架構設計內容是根據對代碼理解從新整理出來的，不表明系統的實際架構和實現。同時因爲業務和技術的複雜性及其餘緣由，不對實現細節做說明。

設計場景

在該系統以前已經有兩個自定義查詢系統，一個爲競爭對手的CS系統，一個爲我司開發的BS系統。兩個系統均用了MS SQLSERVER爲數據存儲和查詢引擎，實現的業務功能不少，同時也有比較嚴重的性能問題。新系統的主要使命是用新技術提升自定義查詢性能，改善可用性，同時對飆競爭對手的系統。所以也有不少設計上不合理但必須的功能。

必備知識

系統中用到了一些新技術，這些新技術或者非主流的技術是該系統實現的基石，這裏作一個簡單介紹。

• Elasticsearch全文搜索引擎。須要對ES的DSL查詢語言和數據模型有深刻的理解。
• FreeMarker 模板引擎。前端界面及大量的模型類和數據轉換類使用該技術自動生成。
• layui 前端UI組件。採用先後端分離設計，界面及一些重要的組件用此技術實現，並作了一些改造。
• RocketMQ 消息隊列，在該系統中作數據同步使用。

邏輯架構

系統的主要目的是將若干業務系統的數據信息，清洗轉換匯聚到ES中，利用ES在查詢方面的性能優點，來實現自定義查詢。系統邏輯上大概能夠分爲如下幾個模塊：

數據模型

• 什麼是數據模型？
  數據模型出現的本質緣由是RDBMS與ES的數據建模方式不一樣，須要一套對應規則將各業務系統的數據庫表及數據對應到ES中。本系統中數據模型是什麼呢？不是代碼，是四張核心的excel。這四張excel是本系統的靈魂和精華所在，10萬行代碼本質上就是圍繞這四張excel編寫的，同時excel中的數據固化到元數據庫中。

• 數據模型解決了什麼問題？

  • 數據從哪裏來的問題
    定義了從哪些子系統中獲取什麼數據及數據的關聯方式
  • 數據到哪裏去的問題
    定義了在ES中數據存儲到哪幾個索引、類型和數據文檔嵌套方式
  • 查什麼數據的問題
    定義了系統中能夠查詢哪些字段和展現哪些數據字段
  • 怎麼查數據的問題
    定義了數據字段在ES中的路徑和不一樣字段類型在ES中使用的查詢方式及結果集處理方式

數據同步

經過如下幾個主要的步驟實現數據從業務庫到ES中的同步：

• 業務系統中埋點或者數據庫觸發器將要同步的元信息推送到MQ
• 消費端（新自定義查詢）將要同步的數據以任務的形式落庫
• 新自定義查詢系統定時的根據任務從其餘系統拉取數據
• 將拉取的數據作清洗轉換導入到ES集羣

數據清洗

系統經過如下幾個步驟實現數據的裝載和轉換：

• 根據同步任務，各批量裝載器實現業務數據的加載
• 將數據轉換的中間結果落盤
• 從磁盤中讀出中間數據，各轉換器轉換後，導入到ES。

查詢引擎

• 什麼是查詢引擎？
  查詢引擎主要將前臺頁面選擇的條件和展現字段、排序方式、分頁方式、數據合併方式等在後臺轉換成ES的DSL查詢語言並查詢出結果。是系統最重要的模塊，同時也是代碼邏輯最複雜的模塊。

• 查詢條件的組合方式
  從組合方式上來講，查詢條件有與、或、非、異或、全或幾種組合，分別對應着DSL的 must、should、must_not 和其組合。

• 值的比較方式
  從值的比較方式上來講，主要有精確匹配、範圍匹配、前綴匹配、模糊匹配等，分別對應着DSL的term、terms、range、prefix、wildcard等

• ES的數據建模方式
  從ES的數據建模方式來看，查詢主要能夠分爲嵌套查詢、父子查詢、子父查詢、父子+嵌套查詢等

系統主要以流水線得思想將一個複雜的查詢拼裝，分配給各組件完成，並統一組裝，主要有嵌套查詢流水線、父子查詢流水線、子父查詢流水線等

模板引擎

模板引擎主要將大量重複勞動或者須要靈活變更或者特殊對應關係的代碼用模板生成，主要生成前端Html、pojo類，mapper映射和其餘元數據磁盤緩存等。

對外服務

• 對外服務主要提供了將ES中的數據以某種方式輸出，提供給外部系統。

系統總結

首先，優勢:

• 實現了系統的使命，查詢性能有很大提升，且因爲ES的橫向可擴展性，數據量增大也能保證基本查詢性能。
• 引入了新技術新模式，爲解決相似問題提供了另一條思路。且對ES的深刻使用，應該是走到了研發中心各團隊的前面。
• 其設計思想和部分代碼能夠複用借鑑到其餘項目。

其次，缺點：

• 不只要有新技術新模式，更要引入新思想新用法。還按照傳統的方法去使用ES，引入了幾個疑難問題，好比複雜排序問題和深分頁問題(解決方法參見本人博客)。
• 設計思想的執行和代碼質量由於交付壓力大打折扣，代碼上有很強的業務耦合，比較難作到直接複用。
• 數據同步設計有待商榷，好比數據同步的及時性和穩定性及對其餘系統的壓力。
• 查詢引擎代碼有很多重複且後續邏輯有點混亂，耦合度高。
• 對ES等新技術的特性研究還不夠，掉入了一些坑裏。