李 鵬 ，程建遠(yuǎn)

（1.西安科技大學(xué) 地質(zhì)與環(huán)境學(xué)院，陜西 西安 710054；2.中煤科工集團(tuán)西安研究院有限公司，陜西 西安 710077）

煤炭地質(zhì)工作橫跨煤田勘探、設(shè)計、開拓、生產(chǎn)、關(guān)閉等不同階段，貫穿于煤炭工業(yè)的全生命周期，是實現(xiàn)煤炭資源安全高效綠色智能開采的基礎(chǔ)和前提，面向煤炭地質(zhì)工作的地質(zhì)保障系統(tǒng)對煤礦的安全生產(chǎn)至關(guān)重要[1-4]。

國家能源局印發(fā)的《煤礦智能化建設(shè)指南（2021 版）》提出了建設(shè)智能地質(zhì)保障系統(tǒng)的要求和建議，要求基于“數(shù)字采礦”“數(shù)據(jù)驅(qū)動”的理念，將地質(zhì)數(shù)據(jù)與采掘數(shù)據(jù)進(jìn)行深度融合，采用地質(zhì)預(yù)測、多源異構(gòu)數(shù)據(jù)融合等方法，建立基于地質(zhì)數(shù)據(jù)與采掘工程數(shù)據(jù)可動態(tài)更新的模型，實現(xiàn)礦井地質(zhì)信息的透明化。由于不同煤礦有不同的地質(zhì)工作需求，根據(jù)自身的地質(zhì)情況會配置相關(guān)的地質(zhì)勘探、監(jiān)測系統(tǒng)，使得集成各地質(zhì)子系統(tǒng)的地質(zhì)保障系統(tǒng)雖然主要功能類似，但是需要定制開發(fā)，同一軟件的不同配置及二次開發(fā)使得地質(zhì)保障系統(tǒng)的開發(fā)與維護(hù)變得復(fù)雜和充滿不確定性。

系統(tǒng)架構(gòu)設(shè)計從宏觀上解釋軟件系統(tǒng)的組成和特點，架構(gòu)的好壞決定著系統(tǒng)的可開發(fā)性、魯棒性、擴展性、可維護(hù)性等重要問題。MVC 架構(gòu)是一種比較常用的傳統(tǒng)分層架構(gòu)，是由Trygve Reenskaug 在1979 年提出的面向?qū)ο蠛驮O(shè)計模式的一種軟件架構(gòu)[5]。架構(gòu)將軟件設(shè)計劃分為“模型（Model）-視圖（View）-控制器（Controller）”，簡稱MVC 架構(gòu)。3 層結(jié)構(gòu)，每一層都有明確的功能劃分，降低了層與層之間的耦合度，但是這種架構(gòu)的分層只是對系統(tǒng)進(jìn)行了邏輯劃分，最終系統(tǒng)運行在同一進(jìn)程中，MVC 架構(gòu)又可以稱為單體架構(gòu)（圖1）。隨著系統(tǒng)業(yè)務(wù)的不斷發(fā)展，功能的持續(xù)增加，單體架構(gòu)逐漸難以滿足業(yè)務(wù)快速變化的要求，單體架構(gòu)系統(tǒng)維護(hù)部署困難、擴展能力差、技術(shù)選型受限的缺點逐漸暴露。

盧新明等[6]等提出了實現(xiàn)地質(zhì)保障系統(tǒng)的服務(wù)架構(gòu)；馬麗等[7]等提出了基于精細(xì)勘查的煤礦地質(zhì)保障信息系統(tǒng)，采用了傳統(tǒng)的分層結(jié)構(gòu)；董憲海[8]總結(jié)了地質(zhì)保障系統(tǒng)的關(guān)鍵技術(shù)，提出了礦井多元地質(zhì)信息集成系統(tǒng)。針對煤礦地質(zhì)保障系統(tǒng)開發(fā)面臨的數(shù)據(jù)來源多樣、集成地質(zhì)監(jiān)測系統(tǒng)開發(fā)語言不統(tǒng)一，軟件的定制化開發(fā)導(dǎo)致的地質(zhì)保障平臺在不同煤礦適應(yīng)性差的問題，本文提出了微服務(wù)的地質(zhì)保障系統(tǒng)開發(fā)3 層架構(gòu)，將通用的技術(shù)業(yè)務(wù)固化在開發(fā)架構(gòu)，將需要集成的地質(zhì)類子系統(tǒng)等專業(yè)屬性強的業(yè)務(wù)通過微服務(wù)方式進(jìn)行開發(fā)和部署運行。本架構(gòu)集成當(dāng)前成熟、流行的開發(fā)語言，采用前后端分離的開發(fā)模式，使用微服務(wù)的地質(zhì)保障系統(tǒng)架構(gòu)進(jìn)行軟件開發(fā)，可降低集成其他地質(zhì)子系統(tǒng)的技術(shù)復(fù)雜度，借助架構(gòu)的跨平臺特性提高系統(tǒng)的多平臺移植性。

1 系統(tǒng)架構(gòu)技術(shù)

系統(tǒng)架構(gòu)設(shè)計是根據(jù)一定原則，從業(yè)務(wù)、技術(shù)、數(shù)據(jù)等角度對系統(tǒng)各部分進(jìn)行規(guī)劃和匹配，形成系統(tǒng)的多重結(jié)構(gòu)，包括各組件的劃分、組件間關(guān)系、開發(fā)技術(shù)、實現(xiàn)目的等內(nèi)容。

1.1 微服務(wù)架構(gòu)技術(shù)

1）微服務(wù)架構(gòu)

微服務(wù)[9]架構(gòu)的概念于2012 年開始出現(xiàn)，2014 年開始受到廣泛的關(guān)注和使用。微服務(wù)架構(gòu)是一種分布式系統(tǒng)架構(gòu)，采用微服務(wù)架構(gòu)的應(yīng)用系統(tǒng)按照業(yè)務(wù)功能、技術(shù)實現(xiàn)等拆分成最小組件，組件間彼此獨立，通過組件間的合作共同完成一個任務(wù)，其中每一個組件或者流程都是一個微服務(wù)。這種架構(gòu)設(shè)計方法強調(diào)業(yè)務(wù)的細(xì)粒度、通信的輕量化、服務(wù)的高內(nèi)聚、服務(wù)間的低耦合，每一個服務(wù)單獨部署。在業(yè)務(wù)需要的時候，同一個服務(wù)可以在多個業(yè)務(wù)流程中重用，也可以在不同的業(yè)務(wù)渠道中使用。這些服務(wù)通常擁有自己的技術(shù)棧，包括數(shù)據(jù)庫、業(yè)務(wù)邏輯；服務(wù)之間通過消息代理、事件流和REST API[10]的組合相互通信；服務(wù)組合通過業(yè)務(wù)體系驅(qū)動。微服務(wù)架構(gòu)相比傳統(tǒng)單體架構(gòu)的優(yōu)點主要有以下方面：由于微服務(wù)之間可使用不同的技術(shù)棧、單獨部署，因此系統(tǒng)代碼的更新和修改更加簡便，可以在不涉及整個應(yīng)用程序的情況下添加新的功能；開發(fā)團(tuán)隊可以采用不同的技術(shù)棧，例如不同的編程語言開發(fā)自己的微服務(wù)作為系統(tǒng)的一部分；組成系統(tǒng)的每個功能組件可以獨立伸縮，減少了由于單個功能面臨太多負(fù)載而不得不擴展整個應(yīng)用程序過程中的成本浪費。在面對業(yè)務(wù)多、系統(tǒng)龐大時，微服務(wù)架構(gòu)的適應(yīng)性就越好（圖2）。

圖2 微服務(wù)架構(gòu)Fig.2 Schematic diagram of microservice architecture

2）地質(zhì)保障系統(tǒng)微服務(wù)技術(shù)選型

主流的微服務(wù)開發(fā)工具集有Spring Cloud[11-12]、Dubbo、Motan、gRPC 和Thrift 等，其中，Spring Cloud具有完整的微服務(wù)框架，Dubbo 專注于RPC 和服務(wù)治理，Motan RPC 框架整合了ZK 或Consul，gRPC 和Thrift均為RPC 框架。其主要參數(shù)或性能對比見表1。

由表1 可知，Spring Cloud 比其他框架模塊較多，是構(gòu)建微服務(wù)架構(gòu)的更全面工具集，包含了微服務(wù)架構(gòu)的所有核心工具，優(yōu)于其他框架；Spring Cloud 具有服務(wù)注冊發(fā)現(xiàn)、服務(wù)監(jiān)控、多語言支持等功能，支持以用戶為核心、逐步迭代、循序漸進(jìn)的方法開發(fā)、升級新服務(wù)，相比其他架構(gòu)更適合敏捷開發(fā)；該框架采用Eureka 維護(hù)各微服務(wù)的運行，且實現(xiàn)了服務(wù)的熔斷和服務(wù)降級機制，保障服務(wù)之間、網(wǎng)關(guān)與服務(wù)之間調(diào)用，保障微服務(wù)的高可用和高并發(fā)。Dubbo 等其他架構(gòu)主要包含了微服務(wù)架構(gòu)的網(wǎng)關(guān)、鏈路追蹤等服務(wù)治理、服務(wù)調(diào)用工具，缺少很多功能模塊。由于地質(zhì)保障系統(tǒng)整合多種業(yè)務(wù)，需要支持多語言，所以選擇Spring Cloud 作為地質(zhì)保障系統(tǒng)架構(gòu)設(shè)計主要使用的工具集。

表1 微服務(wù)選型對比Table 1 Comparison of the microservice selections

1.2 Docker 技術(shù)

為了解決微服務(wù)架構(gòu)下大量應(yīng)用部署的問題，引入容器[13-14]。容器是將程序運行所需要的依賴環(huán)境打包的一個標(biāo)準(zhǔn)化軟件單元，可以使應(yīng)用程序快速、可靠地從一個計算機環(huán)境遷移到另一個計算機環(huán)境。使用容器技術(shù)，用戶可以將微服務(wù)及其所需的所有配置、依賴關(guān)系和環(huán)境變量打包成容器鏡像，輕松移植到全新的服務(wù)器節(jié)點上，無需重新配置環(huán)境，使得容器成為部署單個微服務(wù)最理想的工具。

Docker 是一個開源的容器引擎，可以將程序和操作系統(tǒng)等基礎(chǔ)設(shè)施進(jìn)行隔離，Docker 可運行于Windows 和Linux 操作系統(tǒng)。地質(zhì)保障系統(tǒng)需要集成水文監(jiān)測、微震監(jiān)測、視電阻率監(jiān)測、隨采隨掘監(jiān)測等多種地質(zhì)系統(tǒng)，各子系統(tǒng)的分析方法、模型等采用了不同的開發(fā)語言和運行環(huán)境，采用微服務(wù)架構(gòu)進(jìn)行開發(fā)可以將各子系統(tǒng)解耦為微服務(wù)，打破多開發(fā)語言集成的壁壘。使用Docker 打包各子系統(tǒng)微服務(wù)和運行依賴環(huán)境之后，可快速進(jìn)行部署，便于程序測試和運行維護(hù)。結(jié)合使用K8S 容器管理工具，實現(xiàn)微服務(wù)的自動部署、彈性伸縮，將微服務(wù)按照業(yè)務(wù)關(guān)系組建成大型的地質(zhì)保障應(yīng)用程序。

2 微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)設(shè)計

隨著我國煤炭開采技術(shù)的發(fā)展，煤炭地質(zhì)保障系統(tǒng)的內(nèi)涵與外延也不斷豐富和完善，其發(fā)展可以概括為煤炭資源勘探地質(zhì)保障、高產(chǎn)高效礦井地質(zhì)保障、安全高效生產(chǎn)地質(zhì)保障和智能化開采地質(zhì)保障4 個階段[15]?，F(xiàn)階段的地質(zhì)保障系統(tǒng)是根據(jù)“安全、高效、綠色、智能”發(fā)展理念的需要，以地質(zhì)量化預(yù)測為先導(dǎo)，以物探、鉆探、化探、井巷測量等綜合技術(shù)為手段，并依托先進(jìn)的計算機技術(shù)、物聯(lián)網(wǎng)技術(shù)、人工智能技術(shù)，實現(xiàn)煤礦地質(zhì)透明化和煤炭開采智能化及隱蔽致災(zāi)因素預(yù)警[6,16-17]。

2.1 地質(zhì)保障系統(tǒng)構(gòu)建及功能

2.1.1 地質(zhì)透明化

1）地質(zhì)數(shù)據(jù)庫構(gòu)建

收集地質(zhì)調(diào)查、鉆探、三維地震、物探、化探、抽水試驗、采樣測試、測量變形、位移、地表沉陷和巖移觀測等數(shù)據(jù)，按數(shù)據(jù)規(guī)范要求對各階段勘探成果數(shù)據(jù)統(tǒng)一入庫管理，建立地質(zhì)勘查、觀測資料數(shù)據(jù)庫；重新數(shù)字化各種與地質(zhì)、測量、水文、儲量有關(guān)的柱狀圖、平面圖、剖面圖、素描圖、物探成果解析圖等并配置屬性，通過分析、對比、校驗、補探、補測等進(jìn)行入庫，得到完善的、準(zhǔn)確的、可再利用的包括煤巖層、地質(zhì)構(gòu)造、災(zāi)害防治、井巷工程、采空區(qū)、帷幕等礦井地測歷史資料和圖庫關(guān)聯(lián)的數(shù)字化空間信息庫系統(tǒng)。

2）地層及構(gòu)造地質(zhì)模型

綜合利用鉆探、物探、井巷揭露、采掘揭露等數(shù)據(jù)，采用數(shù)據(jù)分級、空間配準(zhǔn)、交叉驗證等手段實現(xiàn)多源異構(gòu)數(shù)據(jù)融合，構(gòu)建高精度的三維地質(zhì)幾何模型，實現(xiàn)地層、構(gòu)造的三維可視化，地質(zhì)模型任意剖切及剖面圖件輸出。

3）水文地質(zhì)模型

利用地質(zhì)、水文地質(zhì)及水文探測數(shù)據(jù)，建立水文地質(zhì)模型，實現(xiàn)各含/隔水層、富水區(qū)的空間關(guān)系、產(chǎn)狀、賦存狀態(tài)（潛水、承壓）、水位水壓的可視化，實現(xiàn)充水水源、導(dǎo)水通道的動態(tài)可視化和預(yù)警[18]。對地面定向分支孔、井下定向分支孔軌跡建模，實現(xiàn)水害超前區(qū)域治理數(shù)字化工程評價、出水點信息、注漿量統(tǒng)計信息的三維展示，注漿工程的管理、水文監(jiān)測系統(tǒng)的實時數(shù)據(jù)更新和動態(tài)成圖顯示。

4）瓦斯地質(zhì)模型

利用瓦斯放散初速度、釋放量、吸附性實驗數(shù)據(jù)，結(jié)合煤層瓦斯賦存狀態(tài)（連續(xù)分布型、構(gòu)造依附型等），預(yù)測煤層中瓦斯壓力和瓦斯含量分布，在地質(zhì)模型基礎(chǔ)上結(jié)合采掘破壞規(guī)律，構(gòu)建瓦斯地質(zhì)模型，實時輸入瓦斯監(jiān)測數(shù)據(jù)，實現(xiàn)瓦斯動態(tài)演變的三維可視化。

5）火區(qū)地質(zhì)建模

綜合分析地層、煤層自然發(fā)火特性、漏風(fēng)供氧、采空區(qū)氣成分及溫度、圍巖溫度等基礎(chǔ)數(shù)據(jù)，對煤層火區(qū)煤氧復(fù)合化學(xué)場、放熱溫度場、煤巖變形應(yīng)力場進(jìn)行耦合分析，根據(jù)火區(qū)燃燒特性、燃燒反應(yīng)速率，構(gòu)建火區(qū)地質(zhì)模型，輸入束管監(jiān)測、光纖溫度監(jiān)測等數(shù)據(jù)，實現(xiàn)火區(qū)動態(tài)演變的可視化及預(yù)測。

6）擾動地質(zhì)及力學(xué)模型

根據(jù)煤、巖的力學(xué)性質(zhì)和測試結(jié)果，結(jié)合礦壓、地應(yīng)力等監(jiān)測數(shù)據(jù)，求出煤層各分區(qū)的損傷變量，預(yù)測采掘?qū)γ簬r層的破壞深度，通過對煤層受載過程中的裂隙演化規(guī)律，分析構(gòu)建煤層的擾動地質(zhì)及力學(xué)模型，可作為分析采掘擾動下煤巖變形引發(fā)地質(zhì)災(zāi)害的基礎(chǔ)判據(jù)。

7）綜合地質(zhì)模型

融合上述各模型，實現(xiàn)包括地質(zhì)體的各種物理、化學(xué)屬性的可視化，建立完整、全息的透明地質(zhì)體，并可進(jìn)行各種剖切、透視等可視化操作，為精準(zhǔn)地質(zhì)災(zāi)害預(yù)警提供基礎(chǔ)信息。

2.1.2 地質(zhì)災(zāi)害監(jiān)測預(yù)警

1）地質(zhì)災(zāi)害綜合預(yù)警

將水文監(jiān)測數(shù)據(jù)（含水層及采空區(qū)水位、水溫、水壓、管道流量監(jiān)測、水質(zhì)監(jiān)測、電阻率監(jiān)測等）、瓦斯監(jiān)測數(shù)據(jù)（瓦斯?jié)舛取⒎植家?guī)律）、火區(qū)監(jiān)測數(shù)據(jù)等數(shù)據(jù)信息接入系統(tǒng)，與三維模型進(jìn)行同步映射顯示，以圖和表的形式對數(shù)據(jù)進(jìn)行融合分析和展示，從而構(gòu)建動態(tài)多屬性地質(zhì)模型，并通過設(shè)置綜合預(yù)警閾值組合，實現(xiàn)多系統(tǒng)的聯(lián)動預(yù)警。

2）掘進(jìn)工作面地質(zhì)透明化及災(zāi)害預(yù)警

構(gòu)建掘進(jìn)工作面透明地質(zhì)模型[19-20]，實現(xiàn)掘進(jìn)巷道動態(tài)更新、自動規(guī)劃、掘進(jìn)斷面自動下發(fā)的地質(zhì)導(dǎo)航功能；集成煤礦長距離定向鉆、孔中物探顯示掘進(jìn)前方地質(zhì)異常，提高掘進(jìn)安全和速度；實時顯示隨掘隨探信息，不斷提高掘進(jìn)前方探測精度，為快速掘進(jìn)保駕護(hù)航。

3）回采工作面地質(zhì)透明及災(zāi)害預(yù)警

構(gòu)建回采工作面透明模型[16,21]，基于采前槽波勘探、音頻電透視、孔中瞬變成果，采中微震監(jiān)測、隨采地震監(jiān)測[22]、孔中電阻率監(jiān)測的在線分析，實現(xiàn)回采前方地質(zhì)信息的同步映射；微震監(jiān)測實時預(yù)警底板破壞深度和頂板裂隙發(fā)育高度，與電阻率實時監(jiān)測的富水異常區(qū)疊加分析，實現(xiàn)地質(zhì)災(zāi)害初步預(yù)警；隨采地震實時采集采煤機振動信號，分析工作面內(nèi)部地質(zhì)異常和應(yīng)力變化，提高采煤工作面安全性。

2.1.3 地質(zhì)保障工作臺

地質(zhì)保障工作臺需要實現(xiàn)地質(zhì)、測量、水文、儲量管理。地質(zhì)管理包括地質(zhì)圖件、鉆孔基礎(chǔ)數(shù)據(jù)、地質(zhì)臺賬、地質(zhì)預(yù)報、地質(zhì)卡片、地質(zhì)三書、地質(zhì)類報告等內(nèi)容；測量管理包括測量圖件、測量數(shù)據(jù)、測量文檔、巷道貫通管理等內(nèi)容；水文管理包括水文臺賬、水文報告、防治水計劃、防治水工程、水文地質(zhì)預(yù)報、水文地質(zhì)探測、水文圖件、水質(zhì)分析等內(nèi)容；儲量管理包括儲量更新上報、儲量圖件和儲量報告等內(nèi)容。

2.2 微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)的構(gòu)建

微服務(wù)的地質(zhì)保障系統(tǒng)架構(gòu)主要分為3 層，分別是應(yīng)用層、平臺層和基礎(chǔ)設(shè)施層（圖3）。

圖3 微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)Fig.3 Architecture of the geological guarantee system based on microservices

1）應(yīng)用層

采用VUE 用戶界面漸進(jìn)式前端框架進(jìn)行開發(fā)，形成以透明地質(zhì)、地質(zhì)災(zāi)害監(jiān)測預(yù)警、地質(zhì)工作臺為主要功能的用戶交互界面。每一個前端的業(yè)務(wù)都配有后臺配置界面，實現(xiàn)數(shù)據(jù)、圖片、報告的修改、更新等管理，配置歷史及數(shù)據(jù)存儲于基礎(chǔ)設(shè)施層數(shù)據(jù)庫。

2）平臺層

平臺層包含網(wǎng)關(guān)層和服務(wù)層。網(wǎng)關(guān)層采用Spring Cloud Gateway 實現(xiàn)負(fù)載均衡，地質(zhì)保障平臺后端部署多臺云服務(wù)器，可實現(xiàn)通過流量分發(fā)的負(fù)載均衡服務(wù)擴展系統(tǒng)對外服務(wù)能力，多服務(wù)器負(fù)載均衡可以消除單點故障，提升地質(zhì)保障系統(tǒng)的可靠性。用戶使用瀏覽器打開地質(zhì)保障系統(tǒng)，向Spring Cloud Gateway 發(fā)出請求，請求發(fā)送給負(fù)責(zé)路由的Gateway Handler Mapping，找到相匹配的路由后發(fā)送到Gateway Web Mapping，實現(xiàn)執(zhí)行前端請求的業(yè)務(wù)邏輯（圖4）。

圖4 Spring Cloud Gateway 的處理流程Fig.4 Processing flow of Spring Cloud Gateway

服務(wù)層以微服務(wù)的形式實現(xiàn)支持前端UI 顯示及業(yè)務(wù)交互的分析預(yù)警服務(wù)、三維模型構(gòu)建服務(wù)、地質(zhì)工作報表服務(wù)、數(shù)據(jù)解析傳輸服務(wù)和基礎(chǔ)服務(wù)；集成了Spring Cloud Config 組件和Apollo 配置管理中心實現(xiàn)對微服務(wù)的治理和配置；采用熔斷保護(hù)、安全控制、調(diào)用鏈追蹤、日志記錄、監(jiān)控報警組件實現(xiàn)對微服務(wù)狀態(tài)的控制，保障微服務(wù)的有效、可靠運行。

分析預(yù)警模型服務(wù)模塊構(gòu)建掘進(jìn)地質(zhì)預(yù)警模型、回采地質(zhì)預(yù)警模型，水害分析模型支持前端地質(zhì)預(yù)測預(yù)報；三維模型構(gòu)建服務(wù)集成地層模型、構(gòu)造模型、水文地質(zhì)模型、瓦斯地質(zhì)模型等構(gòu)建方法，支撐前端透明地質(zhì)相關(guān)內(nèi)容；地質(zhì)工作報表服務(wù)實現(xiàn)地測基本信息、超前探測信息、排水系統(tǒng)、地質(zhì)臺賬等報表服務(wù)，用于前端地質(zhì)保障工作臺的報表數(shù)據(jù)錄入、報表生成、報表上報、打印功能；數(shù)據(jù)解析傳輸服務(wù)提供水文監(jiān)測、微震監(jiān)測、隨采監(jiān)測、隨掘監(jiān)測等地質(zhì)數(shù)據(jù)的傳輸、解釋、分析微服務(wù)，為模型構(gòu)建、地質(zhì)預(yù)警、工作報表提供基礎(chǔ)數(shù)據(jù)和分析模型。

采用這種微服務(wù)的方式整合地質(zhì)保障系統(tǒng)的各種業(yè)務(wù)（圖5），每一種監(jiān)測系統(tǒng)的接入、數(shù)據(jù)處理、預(yù)警都可以采用獨立微服務(wù)，復(fù)雜度可控制；可靈活水平擴展和集成，不會受到開發(fā)語言的限制；可獨立部署運維；開發(fā)針對性強、支持小團(tuán)隊敏捷開發(fā)；提高系統(tǒng)的可組合性和可替代性。

圖5 微服務(wù)業(yè)務(wù)邏輯調(diào)用關(guān)系Fig.5 Logic calling relationship of microservice business

3）基礎(chǔ)設(shè)施層

采用MySQL 等數(shù)據(jù)庫實現(xiàn)數(shù)據(jù)存儲，Redis 實現(xiàn)數(shù)據(jù)的緩存和前端高速調(diào)用，RabbitMQ 消息隊列實現(xiàn)微服務(wù)之間的異步消息溝通，Search 搜索服務(wù)實現(xiàn)分布式搜索，OSS 對象實現(xiàn)分布式云存儲，LCN 實現(xiàn)多個微服務(wù)之間的分布式事務(wù)控制。基礎(chǔ)設(shè)施層主要保障整個微服務(wù)地質(zhì)保障系統(tǒng)的有序、高效、可靠運轉(zhuǎn)。

3 微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)應(yīng)用

3.1 微震監(jiān)測中的微服務(wù)提取

以地質(zhì)保障系統(tǒng)中的微震監(jiān)測數(shù)據(jù)傳輸、展示為例來說明地質(zhì)保障各微服務(wù)的提取。微震監(jiān)測系統(tǒng)的功能模塊包含數(shù)據(jù)采集、傳輸以及各種圖形和報表，且有二維、三維多種展示形式。根據(jù)微服務(wù)的地質(zhì)保障架構(gòu)，將煤礦微震監(jiān)測中的業(yè)務(wù)劃分為公共業(yè)務(wù)和微服務(wù)專有業(yè)務(wù)（圖6）。日志管理、用戶權(quán)限、推送通知等作為與其他業(yè)務(wù)系統(tǒng)相同或者類似的通用功能，將其解耦抽離成為通用的公共業(yè)務(wù)，整合到服務(wù)層（圖3）的基礎(chǔ)設(shè)施層。將微震數(shù)據(jù)提取、實時數(shù)據(jù)展示、歷史數(shù)據(jù)展示解耦為微服務(wù)進(jìn)行開發(fā)和加載。

圖6 微震監(jiān)測微服務(wù)實現(xiàn)Fig.6 Implementation of the microseismic monitoring microservice

微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)性能相比傳統(tǒng)單體架構(gòu)的提升，可以通過微震數(shù)據(jù)的查詢速度對比來進(jìn)行說明。將微震監(jiān)測數(shù)據(jù)查詢服務(wù)部署于相同的硬件、網(wǎng)絡(luò)條件下進(jìn)行了測試，查詢數(shù)據(jù)量為10 000 條的情況下，單體架構(gòu)需要時間15 200 ms，微服務(wù)架構(gòu)只需要1 250 ms。采用微服務(wù)架構(gòu)的微震監(jiān)測數(shù)據(jù)查詢，相比采用單體架構(gòu)的微震監(jiān)測數(shù)據(jù)查詢速度提升非?？欤疚脑O(shè)計在微服務(wù)架構(gòu)中將微震監(jiān)測數(shù)據(jù)區(qū)分為熱數(shù)據(jù)和冷數(shù)據(jù)，將訪問頻繁的數(shù)據(jù)加載入高速緩存中，由專門的緩存數(shù)據(jù)微服務(wù)來進(jìn)行管理，速度相比于單體架構(gòu)有了質(zhì)的提升。

3.2 微震監(jiān)測微服務(wù)開發(fā)

與傳統(tǒng)單體架構(gòu)的開發(fā)相比，微服務(wù)開發(fā)更側(cè)重于單服務(wù)拆分后每個服務(wù)的快速迭代。在傳統(tǒng)單體架構(gòu)模式下，每個功能的改造都會引起所有代碼的重新發(fā)布，耗時耗力，改造微服務(wù)后，每個微服務(wù)實現(xiàn)相對較單一獨立的功能。以微震監(jiān)測為例說明微服務(wù)系統(tǒng)的開發(fā)流程。

①使用maven 構(gòu)建代碼，使用yml 文件指定微服務(wù)端口

② 生成啟動類，用于啟動服務(wù)

④ 對程序進(jìn)行測試，驗證微服務(wù)程序的可用性，構(gòu)建微震監(jiān)測服務(wù)的鏡像（圖7）

圖7 微服務(wù)測試界面Fig.7 Microseismic microservice test interface

3.3 微震監(jiān)測微服務(wù)部署和使用

在微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)下，采用容器技術(shù)封裝微服務(wù)，提高部署的速度，降低部署的困難度。微震監(jiān)測的每個具體業(yè)務(wù)可以單獨形成并且界面和數(shù)據(jù)庫可以分開部署，部署完成后通過Docker 對外映射的地址即可正常訪問。地質(zhì)保障Docker 鏡像庫保存了所有已經(jīng)開發(fā)完成的微服務(wù)，可以通過FTP 訪問拷貝、Docker 相關(guān)命令拉取所需的鏡像（圖8）。

圖8 微服務(wù)部署流程Fig.8 Microservice deployment process

以微震監(jiān)測數(shù)據(jù)顯示分析微服務(wù)項目為例說明部署的過程，只要將鏡像拷貝至服務(wù)器，將訪問該服務(wù)的映射端口為8003，通過瀏覽器訪問該服務(wù)器的8003端口可顯示圖9 所示微震界面。通過使用微服務(wù)的Docker 鏡像技術(shù)可快速實現(xiàn)微震監(jiān)測微服務(wù)快速部署、運行、上線，各微服務(wù)之間通過消息隊列技術(shù)可以共享交互數(shù)據(jù)，從而實現(xiàn)地質(zhì)保障系統(tǒng)的多系統(tǒng)集成功能。

圖9 微震監(jiān)測數(shù)據(jù)展示Fig.9 Microseismic monitoring data display

3.4 微服務(wù)地質(zhì)保障系統(tǒng)運維

基于微服務(wù)的地質(zhì)保障系統(tǒng)開發(fā)集成了眾多地質(zhì)類微服務(wù)，采用Spring Cloud Config 進(jìn)行微服務(wù)的分布式配置和維護(hù)。微服務(wù)部署在Dokcer 容器中，采用K8S 管理工具對Docker 進(jìn)行自動管理。通過遠(yuǎn)程訪問部署在礦端超融合系統(tǒng)之上的K8S 管理Docker，實現(xiàn)微服務(wù)地質(zhì)保障系統(tǒng)的遠(yuǎn)程運維。

3.5 微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)應(yīng)用效果

使用微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)開發(fā)了唐家會煤礦智能地質(zhì)保障系統(tǒng)（圖10）。系統(tǒng)基于鉆探、物探、監(jiān)測等數(shù)據(jù)，采用微服務(wù)形式集成多種地質(zhì)監(jiān)測子系統(tǒng)和地質(zhì)管理子功能，實現(xiàn)了一體化模型、防治水工程、掘進(jìn)地質(zhì)透明、回采地質(zhì)透明、地質(zhì)預(yù)測預(yù)報、工作面數(shù)字孿生、地質(zhì)透明化高精度數(shù)據(jù)采集等多項應(yīng)用功能，為唐家會煤礦安全、高效生產(chǎn)提供了地質(zhì)保障基礎(chǔ)。

圖10 智能地質(zhì)保障系統(tǒng)Fig.10 Intelligent geological guarantee system

4 結(jié) 論

a.微服務(wù)地質(zhì)保障架構(gòu)規(guī)范了開發(fā)過程，簡化了使用的技術(shù)棧，優(yōu)化了系統(tǒng)集成開發(fā)流程；將通用的技術(shù)業(yè)務(wù)固化在開發(fā)架構(gòu)，將需要集成的地質(zhì)類子系統(tǒng)等專業(yè)屬性強的業(yè)務(wù)通過微服務(wù)方式進(jìn)行開發(fā)和部署運行，降低了開發(fā)、集成難度；使用Docker 技術(shù)封裝微服務(wù)鏡像，讓微服務(wù)的部署運行不再受到運行環(huán)境的影響，提高跨平臺移植性，降低了系統(tǒng)的部署難度，縮短了部署時間。

b.微服務(wù)地質(zhì)保障系統(tǒng)架構(gòu)在唐家會煤礦地質(zhì)保障系統(tǒng)中的開發(fā)實踐證明：架構(gòu)的應(yīng)用改變了現(xiàn)有地質(zhì)保障類軟件的開發(fā)模式，通用業(yè)務(wù)與專有業(yè)務(wù)分離，以微服務(wù)的形式實現(xiàn)多專業(yè)應(yīng)用集成，便于多團(tuán)隊并行開發(fā)，提高工作效率；微服務(wù)實現(xiàn)了系統(tǒng)內(nèi)部各功能之間的高內(nèi)聚低耦合，不同方法的鉆探、物探等專業(yè)功能開發(fā)可獨立完成，使后期運維、修改的可控性大大提高。