一種分布式數據管理中心軟件架構設計

2022-07-18 00:08:30孟景濤王濤蔣浩孫婧徐朽輝

計算機與網絡 2022年10期

孟景濤王濤蔣浩孫婧徐朽輝

摘要：隨著國產化新研航天地面測控數傳裝備需求的爆發式增長，帶來了更復雜多樣的數據，傳統單體數據庫在此類數據面前明顯吃力。為滿足各型裝備用戶對高效、綜合運維管理的客觀需求，提出了一種基于國產化面向服務軟件架構的多維數據管理平臺，對吞吐數據進行統一管理，來完成測控數傳設備的數據積累，形成良性循環，逐步提高測控數傳設備可用度與可靠性。后續其他類似的項目數據中心部分建設，只需要對數據中心進行參數配置，即可實現數據管理功能。同時為項目的微服務化提供技術棧架構支撐。

關鍵詞：分布式；數據管理；Linux；Zookeeper；

中圖分類號：TP319文獻標志碼：A文章編號：1008-1739（2022）10-49-5

分布式數據管理中心軟件[1]是航天地面測控數傳裝備的組成部分，作為整個系統的數據管理中心，擔負著整個系統設備的數據存儲和管理等功能[2]?，F有系統中數據存儲的形式主要有XML數據文件[3]、自定義格式數據文件和SQL Lite等，在數據安全性、擴展性和維護性上與現有應用場景和技術已不再匹配，并且現有系統架構不支持高并發和大批量的數據存儲和數據檢索，所以提出將系統中的業務數據、基礎配置及其日志信息數據剝離出來，以數據庫為支撐，建立數據中心，實現對數據存儲和訪問的集中化管理[4]。

對測控軟件從整體架構上進行了全新的設計，實現對數據存儲以數據庫為基礎，通過模塊化將系統中的業務數據、配置數據和日志信息數據由之前的分散性和數據格式的多樣性進行了數據存儲的統一化、訪問的規范化和數據的獨立性。以此建立數據中心，實現數據和業務的隔離，在數據的管理和操作上方便、快捷、高效；在數據維護上簡單、安全[5]；實現數據的集中控制、數據一致性和可維護性、數據共享、減少數據的冗余度、數據安全和數據的備份[6]。建立數據中心后，系統模塊劃分更加合理，降低了系統的耦合性，增強了系統訪問的高效性、可維護性和可擴展性。

目標的項目架構在具有關系數據接口插件和ES（elasticsearch）數據接口插件上使用了Zookeeper，Kafka，Mycat等開源服務，通過對MySQL數據庫、神通數據庫、redis數據庫和ES數據存儲的使用，實現在不同場景下對于數據存儲和檢索的支持，項目架構如圖1所示。

項目架構對于系統性能、可用性和數據安全性均有優化作用，能夠支持當前的業務需求，對系統的易維護性也有很好的支持。經過實驗驗證，數據存儲服務在國產環境中的效率評估也有不凡表現。

2.1服務之間接口訪問設計

創建Dbserver插件處理關系數據[7]，訂閱消息cti/dbserver/ request/*（cti/dbserver/receive/接口命令字/交易流水號），返回消息發送cti/dbserver/response/*（cti/dbserver/response/請求時命令字/請求時交易流水號）。

Dbserver插件通過thrift提供的RPC接口通信方式作為與數據庫服務間調用方式，調用方和服務提供方通過Thrift方式生成統一的方法string invoke（1：string para），入參和返回值均為json傳輸，這樣保持具體接口方法增加和修改的穩定性。

出入參統一格式：

入參：{“reqtype”：“請求接口名”，“param”： “{param1”：“param2value”，“param1”：“param2value”}}

出參：{“restype”：“返回數據類型”，“param”：{“param1”：“param2value”，“param1”：“param2value”}}

ES插件部分與服務通信采用同樣方式處理。

2.2關系數據服務插件

關系數據服務插件與系統其他模塊間通過異步消息方式交互[8]，上節描述了交互的方式及報文格式，插件在加載時向zk讀取可用關系數據服務列表，根據配置文件配置，可以采用主備方式優先調用主數據服務，當主數據服務異常時切換到備用服務；或者采用無主混合模式隨機選用可用服務進行接口調用，當某一臺數據服務異常后插件主動剔除異常服務的鏈接。

關系數據服務插件架構如圖2所示，插件采用zk提供的對于節點觀察的方式，通過zk的機制來進行及時的關系數據服務的主動斷開或者加入；關系數據插件與關系數據服務之間通過Thrift框架進行接口調用，連接的維持方法調用細節通過框架透明，只需要關注業務即可。

2.3關系數據服務

關系數據服務模塊由接口層、邏輯層和數據庫操作層組成[4]，向上通過Thrift的RPC通信框架承接測控邏輯層的業務接口需求向下與Mycat交互，Mycat經過數據庫代理對數據庫的分布式進行透明化處理，關系數據服務模塊如圖3所示。

業務數據服務負責業務相關的配置報表等持久化數據，在邏輯劃分上分為接口層、邏輯層和數據庫連接層。各個層直接通過虛基類的方式向上提供功能，接口層承接上層對于功能的需求向外釋放功能接口，邏輯層根據業務需要和數據庫的設計進行數據加工，數據庫操作層負責數據庫的基礎操作功能和數據庫連接池的保持。

在數據庫連接層可根據配置方式選擇采用“讀寫都是MySQL”“寫MySQL+神通讀MySQL”“讀寫都是神通”的模式控制。

在數據連接層可根據配置文件配置主備2個Mycat組，連接層自檢測鏈接的可用性，當主Mycat可用性異常時自動切換到備用Mycat連接，上層業務層無感知。

2.4 ES日志數據插件

ES日志數據服務插件與系統其他模塊間通過異步消息方式交互，上文描述了交互的方式及報文格式，插件在加載時向zk讀取可用ES日志數據服務列表，根據配置文件配置可以采用主備方式優先調用主ES服務，當主ES服務異常時切換到備用服務；或者采用無主混合模式隨機選用可用服務進行接口調用，當某一臺ES服務異常后插件主動剔除異常服務的鏈接，日志數據插件架構如圖4所示。

ES日志數據服務插件采用zk提供的對于節點觀察的方式，通過zk的機制來進行及時的ES數據服務的主動斷開或者加入。ES數據插件與ES數據服務之間通過Thrift框架進行接口調用，連接的維持方法調用細節通過框架透明，只需要關注業務即可。

2.5日志模塊服務

由于項目中日志的數據輸出量比較大，所以不能不考慮對整個系統性能的影響。從另外一方面來看，大量的日志數據需要方便檢索，增強日志的可閱讀性和檢索效率。模塊基于使用方便，包括開發和信息檢索；組織合理，日志內容被有效地組織起來。有助于基于日志內容的分析；過程重現，基于日志的分析，最重要的是重現當時運行的過程，日志模塊服務架構如圖5所示。

模塊向上通過Thrift的RPC通信框架承接測控邏輯層的日志持久化需求，向下與消息中間件做對接將需要持久化的數據寫入文件數據庫ES。

項目對于消息中間件的引入在保證日志的完整性的同時，采用異步寫入的方式降低了日志寫入對業務系統性能的影響；另外，此部分增加日志異步寫入服務，讀取消息隊列中的日志數據進行必要的數據加工，可以根據需要增加邏輯處理對日志進行格式化匹配業務日志場景，然后再寫入ES進行持久化存儲。功能劃分上，日志模塊只負責接收上層日志寫入消息中間件，日志加工寫入模塊對日志數據進行格式化，或者根據業務場景進行日志數據的加工寫入ES。

通過對項目目標的分析，結合以往成熟的項目經驗，針對當前流行的相關技術和框架進行分析，系統采用如下技術棧進行架構實現：通過MySQL進行業務數據的存儲；Mycat進行數據庫和項目的隔離到達數據庫的分布式部署和容災自動切換；Redis作為緩存數據的存儲提高系統的響應效率；ES作為日志存儲，達到大數據的檢索；Kafka作為消息中間件支持大并發數據的通信，通過異步方式降低系統調用延遲，對于后端數據持久化提供多服務支持；ZooKeeper[9]來實現微服務治理，保障系統的穩定性[10]，為系統的低耦合高內聚做穩定性支持[11]；Thrift+Json來完成服務間調用，并方便地達到對于語言的透明，在業務設計上采用業務提取屬性的方式到達對業務配置化的支持。

運行環境采用銀河麒麟Kylin V10 Liunx操作系統、 Phytium FT-2000/4（64位，4核）處理器、8 GB內存和銀河麒麟飛騰PC機，開發環境為Qt集成開發環境[12]。針對目標架構中MySQL和ES在國產化機器設備中的存取效率測試評估如下：MySQL基礎數據為102萬條現有數據的基礎上插入10萬條數據做平均插入耗時計算；在銀河麒麟飛騰PC機中，帶有2個索引字段的MySQL表中以102萬數據為原始數據，再增加10萬條數據為計算依據，每秒可插入1 886條記錄；數據查詢單條查詢耗時均在1 ms以下；以一億數據為基準根據時間范圍條件查詢，每條查詢用時4 ms，效率評估結果如圖6所示。