基于云原生技術的工程數據管理平臺研究

顧丹鵬 張業星 唐松強 周浩 張浩洋 何栓康

摘要： 在工程領域，工程數據管理平臺是實現全生命周期管理和數字化移交的關鍵，選用傳統單體化應用技術構建平臺面臨很大的挑戰。研究了構建工程數據管理平臺的主要設計思路、設計原則以及服務拆分等關鍵技術與方法。采用云原生微服務Spring Cloud框架進行設計與實現，使平臺具備資源按需分配和彈性伸縮以及自動化部署和管理的能力。

關鍵詞： 云原生; 微服務; 數據; 管理; Spring Cloud

中圖分類號：TP311? ? ? ? ? 文獻標識碼：A? ? ?文章編號：1006-8228（2021）10-49-05

Research on engineering data management platform based on Cloud Native technology

Gu Danpeng1，2， Zhang Yexing1，2，3， Tang Songqiang1，2， Zhou Hao1，2， Zhang Haoyang1，2， He Shuankang1，2

（1. PowerchinaHuadong Engineering Corporation Limited， Zhejiang， Hangzhou 311100， China; 2. Zhejiang Huadong Engineering Digital Technology Co. Ltd; 3. Zhejiang Engineering Digital Technology Research Center）

Abstract： In the field of engineering， the engineering data management platform is the key to realize full life cycle management and digital handover， and the monolithic application technologies are facing great challenge to construct the platform. The main design ideas， design principles and key technologies and methods of building engineering data management platform are studied. The Spring Cloud framework of Cloud Native microservice is adopted to design and implement， so that the platform has the abilities of resource on-demand allocation and elastic scaling， and the abilities of automatic deployment and automatic management.

Key words： Cloud Native; microservice; data; management; Spring Cloud

0 引言

為了推進企業數字化發展，提升水電站建設及其運行維護過程中的工作效率和質量，建設覆蓋工程全過程的工程數據管理平臺[1]具有重大意義。

近年來，基于云原生技術進行應用[2]的構建逐漸成為了一種趨勢。本文基于云原生技術，采用微服務架構，遵循微服務最佳設計原則，實現一套面向工程領域的工程數據管理系統，該系統具備數據自定義、數據存儲以及數據服務能力，覆蓋全工程項目范圍。本文從系統整體設計、服務拆分以及監控與運維共三個個方面，詳細闡述系統設計，以及相關技術難點。整個系統具備高可用、易于擴展特性，可持續交付和持續集成，并且易于監測和運維。

1 相關研究

根據Pivotal和云原生計算基金會（CNCF，Cloud Native Computing Foundation）對云原生的定義，云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。這些技術能夠構建容錯性好、易于擴展、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁、可預測的重大變更。

云原生應用通常采用微服務[3-4]架構，微服務架構的核心理念是將復雜的應用系統以獨立業務單元的形式分解為多個服務，每個服務可以采用不同的實現技術，以輕量級、更靈活的模式進行獨立設計、開發、部署，運行于獨立的進程中，形成高度內聚的自治單元。微服務架構具有非常多的優勢。其一，使大型的復雜應用可以持續交付和持續部署，軟件部署到生產環境時將面臨更少的問題和故障;其二，每個服務都相對較小、功能相對單一并且容易維護，易于調試、快速部署;其三，服務可以獨立部署，服務之間采用輕量的通信協議，耦合度低，利于快速迭代;其四，微服務架構可以使每個團隊專注于自己的服務，實現服務自治;其五，更易實驗和采納新的技術，由于微服務依靠服務注冊和發現機制，服務之間采用輕量級通信協議，各服務可以使用不同的技術方案實現服務，這樣非常方便服務嘗試新的技術。此外，微服務架構還具備更好的容錯性，微服務架構通常需要設計故障隔離機制，例如，某個服務中的內存泄露不會影響其他服務，其他服務仍舊可以正常地響應請求。

2 系統設計

2.1 架構設計

工程數據管理平臺建立在云平臺之上，系統總體架構如圖1所示，具備虛擬化、容器化、資源調度等能力，支持計算資源、存儲資源、網絡資源的配置化調整，以應對業務上需求的增長。針對涉及到的結構化、非結構化、半結構化數據，以及BIM模型空間數據，采用多種數據庫混合存儲方案。采用業內成熟鍵值對內存數據庫Redis緩存數據，文檔、圖片等選用開源MinIO[5]及云平臺提供的對象存儲服務（Object Storage Service，OSS），業務存儲采用關系型數據庫MySQL，考慮到工程數據復雜的關聯關系，采用具備圖數據庫[6]特性的ArangoDB數據庫，同時具備文檔數據數據庫特性。針對BIM空間數據，選用PostgreSQL+PostGIS以支持空間幾何數據的存儲。

服務層劃分基礎服務和應用服務，基礎服務實現微服務架構基礎組件，包括服務注冊與發現組件、集中配置組件、消息隊列等。應用服務主要實現業務功能，根據業務需求，工程數據管理平臺具備項目管理、標準、主數據存儲和管理能力，同時，可以將這些標準、數據發布成數據服務對外提供數據交換接口，提供數據服務能力。平臺具備BIM三維服務能力，BIM模型文件的存儲和轉換為在線服務的能力，支持多種數據類型（Rvt、Dgn等）。其中，系統管理指是系統層級的管理功能，包括用戶、組織機構、菜單、角色、權限、安全等方面。

各層服務經過統一的網關對外提供能力，同時，在網關層對訪問的流量進行控制，安全控制。應用層，系統可以應用于桌面端，如Bentley、Revit等BIM軟件進行數據生產和錄入。同時，系統提供基于瀏覽器的Web端可視化管理平臺，具備標準、項目、數據、服務的管理能力，以及系統層級的運維管控能力。

2.2 服務拆分

服務拆分需要遵守一些原則，原則一是定義類的職責時，應該遵循單一職責原則（Single Responsibility Principle，SRP），即設計小的、內聚的、僅僅含有單一職責的服務，以提升服務的穩定性。原則二是把類組成包時，應該遵循閉包元組（Common Closure Principle，CCP），如果由于某些原因，兩個類的修改必須耦合先后發生，那么就應該把它們放到同一個包內。

根據上述原則，將系統劃分為八個主要的微服務（如表1所示）。

按照上述服務劃分，各微服務之間拓撲關系如圖2所示，外層為微服務基礎服務組件，包括認證服務注冊與發現服務以及API網關;內部為九個核心的業務服務。每個微服務使用各自獨立的數據庫。

⑴ 服務間通信

工程數據管理平臺各微服務之間通信方式，選用同步和異步相結合的通信方式，如圖2所示，采用基于HTTP協議的REST API進行同步通信，以及基于消息隊列的消息事件處理器（消息發布、消息接收）進行異步通信。針對服務之間業務復雜度低，特別是一般的數據查詢操作的業務場景，使用同步通信機制以JSON格式進行，例如，實例數據服務需要獲取元數據服務中定義的數據模型結構、字段等信息。針對耗時較多的處理，如果使用同步方式，容易造成阻塞或超時，這種情況一般使用異步通信機制，選用消息隊列進行消息的分發，例如，將項目切換為發布狀態時，需要通知數據服務，生成項目下對應的服務實例。

針對客戶端與服務器之間一對多交互的業務場景，仍然采用基于消息隊列的異步通信機制，由事件生產方發送消息，各響應方訂閱該消息，并執行相關操作。

⑵ 微服務數據聚合

微服務架構相對傳統架構而言，業務對象數據通常會分散到各個微服務中，一個次數據請求可能跨越多個服務，數據經過多個服務返回后聚合成最后的結果。例如，項目與服務之間的關系，數據服務中每條服務信息包括所屬的項目名稱，由于只在數據服務的數據庫中存儲了項目唯一標識Project ID，每次查詢服務信息需要調用項目服務獲取項目名稱，才能獲取Project ID對應的詳細信息，響應存在延遲，并且不利于分頁查詢。為了聚合分散的數據，提升系統的響應性能，有兩種方案：①微服務之間通過關聯的唯一ID進行數據關聯，并且冗余一些項目的部分基礎信息;②在調用項目服務后對數據進行本地緩存，服務直接對緩存的數據進行讀取提升服務性能。

經過分析后，考慮到這類數據更新頻率不會太高，故選用第一種方案，在數據服務的數據庫設計上冗余項目基本信息。然而，這種方案存在項目信息更新后，數據服務中數據庫數據不一致的問題。為了避免數據不一致的問題，采用消息隊列，當項目服務需要對項目基本信息進行更新的時候發一個更新消息，數據服務訂閱這個主題消費，并更新相關數據，從而避免數據錯誤，使數據最終一致。

⑶ 分布式事務

在微服務架構下每個服務使用獨立的數據庫，一次事務可能涉及到多個服務之間的數據庫操作。根據CAP理論，在現實的網絡環境下，服務之間通信存在時間差，數據會出現不一致的情況。為了達到分布式環境下數據庫的一致性，有一些常見的分布式事務[7]方法，主要分五種：XA分布式事務、2PC（2PC，two-phase commit）、基于事務補償的TCC（Try、Confirm、Cancel）、基于消息隊列以及Saga。相比其他的事務方法，Saga更適合管理微服務架構下的事務，它由一連串的本地事務組成，每個本地事務負責更新它所在服務的私有數據庫，這些操作仍舊依賴于ACID事務框架和函數，然而，Saga缺少ACID事務中的隔離性，此外，由于每個本地事務都提交了其更改，因此需要采用補償事務回滾Saga。

在工程數據管理平臺系統中，采用基于消息隊列（RocketMQ）的事務消息（Transaction Message）和Saga相結合的事務機制。對于一般類型的數據交互，我們使用事務消息確保各個服務之間的數據一致，對應關鍵性數據場景，選用Saga進行事務操作，為解決Saga的事務缺少隔離機制，需要在業務層采取對策（語義鎖定對策[8]），確保執行事務中的數據不可見或不可操作。

2.3 監控與運維

微服務架構網絡層次多、技術復雜，這導致追蹤業務請求、排查錯誤相比單體應用復雜度急劇上升。分布式調用鏈監控工具，可以監控那些橫跨不同應用、不同服務器之間的關聯動作，進而快速定位與解決故障[9]。

工程數據管理平臺考慮到當前微服務數量，以及后續擴展，選用Spring Cloud Sleuth進行調用鏈數據記錄，并使用分布式跟蹤系統[10]ZipKin可視化系統調用鏈情況。其中，每個客戶端請求會帶上用戶基本信息，包括用戶ID，以及操作的項目ID。為了監控服務之間的調用性能，選用SkyWalking進行鏈路性能監控，通過其JVM代理非侵入式獲取服務之間的拓撲結構，并監控每個外層請求的調用鏈，獲取每個接口的響應時間。根據這些監控信息對系統進行優化與調整。

微服務架構下，每個服務獨立開發演進，為了提升系統開發效率，快速集成至開發環境。采用Jenkins進行自動化部署[11]，持續向開發環境和測試環境集成，采用基于Kubernetes的容器管理平臺Rancher，具備企業級多集群管理能力，方便服務資源調整、擴容和升級，提升微服務的部署效率。為了獲取更詳細的監控各服務之間的運行狀態，選用Prometheus拉取每個服務的JVM信息以及請求的調用次數等指標數據，同時，設置健康檢查與告警設置，當系統出現故障時，第一時間以郵件或短信的方式，通知運維人員排查問題。

3 研究成果

3.1 主數據管理

工程數據管理平臺中，數據管理界面展示的是某個建管類項目引用建管標準后，對應生成的51個數據模型，包括主表和枚舉表，如圖3所示。

可以清晰預覽每張數據模型的數據，如圖4所示建管類項目下“方案信息”表對應的數據記錄。

該建管項目對應的項目信息如圖5所示，展示了項目的行業、類型以及狀態等基本信息，同時，也統計出來項目下包含的數據模型數量、文件類型，即數據量的分布圖。

3.2 監控與運維

工程數據管理平臺微服務采用Rancher進行集中管理，如圖6所示，每一個服務對應一個Deployment，其中，根據服務的訪問量，擴充不同數量Pod，以提供系統的響應性能。

為了實時獲取并監控服務的運行狀態，采用Prometheus結合Grafana可視化的監控工具，監控每個服務在最近6個小時內的調用次數變化情況。

4 結束語

為了建設覆蓋工程全過程的工程數據管理平臺，本系統基于云平臺，采用微服務架構，服務遵循單一職責原則、獨立部署和輕量級通信等設計原則，本文從云平臺、存儲層、服務層到應用層對系統進行具體說明。針對服務拆分中涉及到的服務通信、數據聚合以及分布式事務等問題，著重說明了理論基礎與解決方案。同時，在系統監控和運維層面提供可行方案。最終完成工程數據管理平臺的實現與應用，經過實際生產實踐，整個系統具備高可用、易于擴展的特性，可持續交付和持續集成，并易于監測和運維。

參考文獻（References）：

[1] 王金鋒，張業星，陳健等.水電全生命周期工程數據中心及其關鍵技術[J].水力發電，2014.40（8）：21-24

[2] Kratzke N， Quint P. Understanding cloud-native applications after 10 years of cloud computing-A systematic mapping study[J]. Journal of Systems and Software，2017.126：1-16

[3] 馮志勇，徐硯偉，薛霄等.微服務技術發展的現狀與展望[J].計算機研究與發展，2020.57（5）：1103-1122

[4] 吳化堯，鄧文俊.面向微服務軟件開發方法研究進展[J].計算機研究與發展，2020.57（3）：525-541

[5] MinIO; MinIO， a Leader in High Performance Object Storage， Launches the MinIO Subscription Network Globally[J]. Computer Technology Journal. 2020.

[6] 于戈，谷峪，鮑玉斌等.云計算環境下的大規模圖數據處理技術[J].計算機學報，2011.34（10）：1753-1767

[7] 方意，朱永強，宮學慶.微服務架構下的分布式事務處理[J].計算機應用與軟件，2019.36（1）：152-158

[8] Frank L， Zahle T U. Semantic ACID properties in multidatabases using remote procedure calls and update propagations[J].Software-Practice and Experience，1998.28（1）：77-98

[9] 李文海，彭鑫，丁丹等.基于日志可視化分析的微服務系統調試方法[J].計算機科學，2019.46（11）：145-155

[10] Sigelman B H， Barroso L A， Burrows M， et al. Dapper， a Large-Scale Distributed Systems Tracing Infrastructure[Z]，2010.

[11] 蔡永健，路云菲，鄔遠祥等.基于Jenkins和Docker容器技術在數字化電站項目自動化部署的研究及應用[J].計算機時代，2020.2：77-80