基于云原生技術(shù)的工程數(shù)據(jù)管理平臺研究

顧丹鵬 張業(yè)星 唐松強 周浩 張浩洋 何栓康

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

關(guān)鍵詞： 云原生; 微服務(wù); 數(shù)據(jù); 管理; Spring Cloud

中圖分類號：TP311? ? ? ? ? 文獻標(biāo)識碼：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 引言

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

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

1 相關(guān)研究

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

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

2 系統(tǒng)設(shè)計

2.1 架構(gòu)設(shè)計

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

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

各層服務(wù)經(jīng)過統(tǒng)一的網(wǎng)關(guān)對外提供能力，同時，在網(wǎng)關(guān)層對訪問的流量進行控制，安全控制。應(yīng)用層，系統(tǒng)可以應(yīng)用于桌面端，如Bentley、Revit等BIM軟件進行數(shù)據(jù)生產(chǎn)和錄入。同時，系統(tǒng)提供基于瀏覽器的Web端可視化管理平臺，具備標(biāo)準(zhǔn)、項目、數(shù)據(jù)、服務(wù)的管理能力，以及系統(tǒng)層級的運維管控能力。

2.2 服務(wù)拆分

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

根據(jù)上述原則，將系統(tǒng)劃分為八個主要的微服務(wù)（如表1所示）。

按照上述服務(wù)劃分，各微服務(wù)之間拓?fù)潢P(guān)系如圖2所示，外層為微服務(wù)基礎(chǔ)服務(wù)組件，包括認(rèn)證服務(wù)注冊與發(fā)現(xiàn)服務(wù)以及API網(wǎng)關(guān);內(nèi)部為九個核心的業(yè)務(wù)服務(wù)。每個微服務(wù)使用各自獨立的數(shù)據(jù)庫。

⑴ 服務(wù)間通信

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

針對客戶端與服務(wù)器之間一對多交互的業(yè)務(wù)場景，仍然采用基于消息隊列的異步通信機制，由事件生產(chǎn)方發(fā)送消息，各響應(yīng)方訂閱該消息，并執(zhí)行相關(guān)操作。

⑵ 微服務(wù)數(shù)據(jù)聚合

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

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

⑶ 分布式事務(wù)

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

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

2.3 監(jiān)控與運維

微服務(wù)架構(gòu)網(wǎng)絡(luò)層次多、技術(shù)復(fù)雜，這導(dǎo)致追蹤業(yè)務(wù)請求、排查錯誤相比單體應(yīng)用復(fù)雜度急劇上升。分布式調(diào)用鏈監(jiān)控工具，可以監(jiān)控那些橫跨不同應(yīng)用、不同服務(wù)器之間的關(guān)聯(lián)動作，進而快速定位與解決故障[9]。

工程數(shù)據(jù)管理平臺考慮到當(dāng)前微服務(wù)數(shù)量，以及后續(xù)擴展，選用Spring Cloud Sleuth進行調(diào)用鏈數(shù)據(jù)記錄，并使用分布式跟蹤系統(tǒng)[10]ZipKin可視化系統(tǒng)調(diào)用鏈情況。其中，每個客戶端請求會帶上用戶基本信息，包括用戶ID，以及操作的項目ID。為了監(jiān)控服務(wù)之間的調(diào)用性能，選用SkyWalking進行鏈路性能監(jiān)控，通過其JVM代理非侵入式獲取服務(wù)之間的拓?fù)浣Y(jié)構(gòu)，并監(jiān)控每個外層請求的調(diào)用鏈，獲取每個接口的響應(yīng)時間。根據(jù)這些監(jiān)控信息對系統(tǒng)進行優(yōu)化與調(diào)整。

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

3 研究成果

3.1 主數(shù)據(jù)管理

工程數(shù)據(jù)管理平臺中，數(shù)據(jù)管理界面展示的是某個建管類項目引用建管標(biāo)準(zhǔn)后，對應(yīng)生成的51個數(shù)據(jù)模型，包括主表和枚舉表，如圖3所示。

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

該建管項目對應(yīng)的項目信息如圖5所示，展示了項目的行業(yè)、類型以及狀態(tài)等基本信息，同時，也統(tǒng)計出來項目下包含的數(shù)據(jù)模型數(shù)量、文件類型，即數(shù)據(jù)量的分布圖。

3.2 監(jiān)控與運維

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

為了實時獲取并監(jiān)控服務(wù)的運行狀態(tài)，采用Prometheus結(jié)合Grafana可視化的監(jiān)控工具，監(jiān)控每個服務(wù)在最近6個小時內(nèi)的調(diào)用次數(shù)變化情況。

4 結(jié)束語

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

參考文獻（References）：

[1] 王金鋒，張業(yè)星，陳健等.水電全生命周期工程數(shù)據(jù)中心及其關(guān)鍵技術(shù)[J].水力發(fā)電，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] 馮志勇，徐硯偉，薛霄等.微服務(wù)技術(shù)發(fā)展的現(xiàn)狀與展望[J].計算機研究與發(fā)展，2020.57（5）：1103-1122

[4] 吳化堯，鄧文俊.面向微服務(wù)軟件開發(fā)方法研究進展[J].計算機研究與發(fā)展，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] 于戈，谷峪，鮑玉斌等.云計算環(huán)境下的大規(guī)模圖數(shù)據(jù)處理技術(shù)[J].計算機學(xué)報，2011.34（10）：1753-1767

[7] 方意，朱永強，宮學(xué)慶.微服務(wù)架構(gòu)下的分布式事務(wù)處理[J].計算機應(yīng)用與軟件，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] 李文海，彭鑫，丁丹等.基于日志可視化分析的微服務(wù)系統(tǒng)調(diào)試方法[J].計算機科學(xué)，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] 蔡永健，路云菲，鄔遠(yuǎn)祥等.基于Jenkins和Docker容器技術(shù)在數(shù)字化電站項目自動化部署的研究及應(yīng)用[J].計算機時代，2020.2：77-80