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

李 鵬 ，程建遠(yuǎn)

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

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

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

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

盧新明等[6]等提出了實(shí)現(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)。針對(duì)煤礦地質(zhì)保障系統(tǒng)開(kāi)發(fā)面臨的數(shù)據(jù)來(lái)源多樣、集成地質(zhì)監(jiān)測(cè)系統(tǒng)開(kāi)發(fā)語(yǔ)言不統(tǒng)一，軟件的定制化開(kāi)發(fā)導(dǎo)致的地質(zhì)保障平臺(tái)在不同煤礦適應(yīng)性差的問(wèn)題，本文提出了微服務(wù)的地質(zhì)保障系統(tǒng)開(kāi)發(fā)3 層架構(gòu)，將通用的技術(shù)業(yè)務(wù)固化在開(kāi)發(fā)架構(gòu)，將需要集成的地質(zhì)類(lèi)子系統(tǒng)等專(zhuān)業(yè)屬性強(qiáng)的業(yè)務(wù)通過(guò)微服務(wù)方式進(jìn)行開(kāi)發(fā)和部署運(yùn)行。本架構(gòu)集成當(dāng)前成熟、流行的開(kāi)發(fā)語(yǔ)言，采用前后端分離的開(kāi)發(fā)模式，使用微服務(wù)的地質(zhì)保障系統(tǒng)架構(gòu)進(jìn)行軟件開(kāi)發(fā)，可降低集成其他地質(zhì)子系統(tǒng)的技術(shù)復(fù)雜度，借助架構(gòu)的跨平臺(tái)特性提高系統(tǒng)的多平臺(tái)移植性。

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

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

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

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

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

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

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

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

由表1 可知，Spring Cloud 比其他框架模塊較多，是構(gòu)建微服務(wù)架構(gòu)的更全面工具集，包含了微服務(wù)架構(gòu)的所有核心工具，優(yōu)于其他框架；Spring Cloud 具有服務(wù)注冊(cè)發(fā)現(xiàn)、服務(wù)監(jiān)控、多語(yǔ)言支持等功能，支持以用戶為核心、逐步迭代、循序漸進(jìn)的方法開(kāi)發(fā)、升級(jí)新服務(wù)，相比其他架構(gòu)更適合敏捷開(kāi)發(fā)；該框架采用Eureka 維護(hù)各微服務(wù)的運(yùn)行，且實(shí)現(xiàn)了服務(wù)的熔斷和服務(wù)降級(jí)機(jī)制，保障服務(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ù)，需要支持多語(yǔ)言，所以選擇Spring Cloud 作為地質(zhì)保障系統(tǒng)架構(gòu)設(shè)計(jì)主要使用的工具集。

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

1.2 Docker 技術(shù)

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

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

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

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

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

2.1.1 地質(zhì)透明化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

微服務(wù)的地質(zhì)保障系統(tǒng)架構(gòu)主要分為3 層，分別是應(yīng)用層、平臺(tái)層和基礎(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)行開(kāi)發(fā)，形成以透明地質(zhì)、地質(zhì)災(zāi)害監(jiān)測(cè)預(yù)警、地質(zhì)工作臺(tái)為主要功能的用戶交互界面。每一個(gè)前端的業(yè)務(wù)都配有后臺(tái)配置界面，實(shí)現(xiàn)數(shù)據(jù)、圖片、報(bào)告的修改、更新等管理，配置歷史及數(shù)據(jù)存儲(chǔ)于基礎(chǔ)設(shè)施層數(shù)據(jù)庫(kù)。

2）平臺(tái)層

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

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

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

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

采用這種微服務(wù)的方式整合地質(zhì)保障系統(tǒng)的各種業(yè)務(wù)（圖5），每一種監(jiān)測(cè)系統(tǒng)的接入、數(shù)據(jù)處理、預(yù)警都可以采用獨(dú)立微服務(wù)，復(fù)雜度可控制；可靈活水平擴(kuò)展和集成，不會(huì)受到開(kāi)發(fā)語(yǔ)言的限制；可獨(dú)立部署運(yùn)維；開(kāi)發(fā)針對(duì)性強(qiáng)、支持小團(tuán)隊(duì)敏捷開(kāi)發(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ù)庫(kù)實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)，Redis 實(shí)現(xiàn)數(shù)據(jù)的緩存和前端高速調(diào)用，RabbitMQ 消息隊(duì)列實(shí)現(xiàn)微服務(wù)之間的異步消息溝通，Search 搜索服務(wù)實(shí)現(xiàn)分布式搜索，OSS 對(duì)象實(shí)現(xiàn)分布式云存儲(chǔ)，LCN 實(shí)現(xiàn)多個(gè)微服務(wù)之間的分布式事務(wù)控制。基礎(chǔ)設(shè)施層主要保障整個(gè)微服務(wù)地質(zhì)保障系統(tǒng)的有序、高效、可靠運(yùn)轉(zhuǎn)。

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

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

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

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

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

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

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

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

② 生成啟動(dòng)類(lèi)，用于啟動(dòng)服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié) 論

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

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