胡宏澤，杜志剛，儲 楠，羅 克

（1.中煤科工集團常州研究院有限公司，江蘇常州 213015；2.天地（常州）自動化股份有限公司，江蘇常州 213015）

當(dāng)今社會正處于數(shù)字化礦山向智慧礦山發(fā)展的重要過渡階段[1-3]，智慧礦山平臺的建設(shè)要求包括人員定位系統(tǒng)在內(nèi)的多異構(gòu)系統(tǒng)之間能夠?qū)崿F(xiàn)多元數(shù)據(jù)融合和信息共享，特別強調(diào)了在緊急情況下的多系統(tǒng)之間的應(yīng)急處理、預(yù)警和告警能力[4-7]。

現(xiàn)有的人員定位系統(tǒng)所采用的設(shè)計框架，業(yè)務(wù)模塊大多集成在統(tǒng)一的項目框架中，同時為了實現(xiàn)數(shù)據(jù)共享和同步，各個模塊之間的耦合性極強，任一業(yè)務(wù)功能的擴展往往會“牽一發(fā)而動全身”[8]。隨著業(yè)務(wù)邏輯的不斷深化和復(fù)雜化，項目規(guī)模會變得非常龐大，使得維護成本越來越高。通過對智慧礦山進行調(diào)研后發(fā)現(xiàn)，在我國大部分煤礦的人員定位系統(tǒng)中數(shù)據(jù)處理能力依然不足，特別對于人員實時軌跡、歷史軌跡的信息顯示依然存在著反應(yīng)慢的問題，同時系統(tǒng)主數(shù)據(jù)結(jié)構(gòu)仍然束縛在本系統(tǒng)之內(nèi)，智慧礦山平臺中其他系統(tǒng)若想調(diào)用本系統(tǒng)的數(shù)據(jù)往往需要進行二次設(shè)備部署和開發(fā)，這無疑對平臺實現(xiàn)多系統(tǒng)的融合造成了極大的困難[9]。為此，通過對現(xiàn)有的人員定位系統(tǒng)存在的問題進行分析，提出了一種基于微服務(wù)架構(gòu)的設(shè)計方案，引入時序數(shù)據(jù)庫[10]和系統(tǒng)軟總線結(jié)構(gòu)，實現(xiàn)業(yè)務(wù)層級和系統(tǒng)層級間的輕量級通信機制，極大提高了人員定位系統(tǒng)在智慧礦山平臺中的可擴展性和可移植性。

1 現(xiàn)有的人員定位系統(tǒng)架構(gòu)

現(xiàn)有的人員定位系統(tǒng)中業(yè)務(wù)一般采用集中式管理，系統(tǒng)維護著一個統(tǒng)一的關(guān)系型數(shù)據(jù)庫，各個業(yè)務(wù)模塊之間的數(shù)據(jù)交互都是以這個數(shù)據(jù)庫為中心進行?，F(xiàn)有的人員定位系統(tǒng)架構(gòu)如圖1?，F(xiàn)有的人員定位系統(tǒng)主要存在以下幾個問題：1）業(yè)務(wù)之間耦合性強，可擴展性差。因為采用封閉式的系統(tǒng)架構(gòu)，所有業(yè)務(wù)大多固化在一個復(fù)雜的單體應(yīng)用中，隨著業(yè)務(wù)需求的不斷增加和處理邏輯的不斷深化，項目中的代碼的耦合度會越來越嚴(yán)重，每一個功能的開發(fā)都需要開發(fā)人員理清相關(guān)業(yè)務(wù)之間的邏輯關(guān)系，甚至極大可能會產(chǎn)生重復(fù)開發(fā)工作，這將使得系統(tǒng)的水平擴展性難以滿足要求。

圖1 現(xiàn)有的人員定位系統(tǒng)架構(gòu)Fig.1 System architecture of current personnel positioning platform

2）無法彈性部署，難以維護。因為煤礦企業(yè)的業(yè)務(wù)需求往往千差萬別，所以開發(fā)人員需要針對不同的煤礦企業(yè)的業(yè)務(wù)需求對人員定位系統(tǒng)進行私有化定制，這就導(dǎo)致同一個人員定位系統(tǒng)會存在非常多的系統(tǒng)版本，開發(fā)人員需要花費大量的精力進行版本控制，而且每一個功能模塊的更改，都需要對整個項目重新打包、編譯和部署，維護工作變得極其復(fù)雜。

3）數(shù)據(jù)庫成為系統(tǒng)運行效率的瓶頸。系統(tǒng)中所有業(yè)務(wù)訪問同一個關(guān)系數(shù)據(jù)庫，每一個業(yè)務(wù)的處理能力都受到了數(shù)據(jù)庫承載能力的制約。隨著智能礦山平臺的推進，現(xiàn)有的數(shù)據(jù)庫結(jié)構(gòu)顯然已經(jīng)成為制約著系統(tǒng)數(shù)據(jù)處理能力的關(guān)鍵因素。

4）多系統(tǒng)數(shù)據(jù)共享、融合能力差。外部系統(tǒng)對本系統(tǒng)訪問的數(shù)據(jù)大多來自公共數(shù)據(jù)和實時數(shù)據(jù)，針對不同的數(shù)據(jù)訪問需求，系統(tǒng)需要對現(xiàn)有數(shù)據(jù)進行結(jié)構(gòu)化處理，往往會牽扯到過多的業(yè)務(wù)邏輯。

2 基于微服務(wù)架構(gòu)的系統(tǒng)設(shè)計方案

2.1 微服務(wù)

微服務(wù)架構(gòu)的核心思想是將一個復(fù)雜的單體應(yīng)用，按照業(yè)務(wù)邏輯和使用頻次拆分為多個公共服務(wù)和私有業(yè)務(wù)服務(wù)，每個服務(wù)之間都是松耦合的，可以獨立部署，最終達到徹底的組件化、服務(wù)化和去中心化[11-12]。

因為業(yè)務(wù)按照微服務(wù)進行分散管理，所以開發(fā)人員在開發(fā)私有業(yè)務(wù)過程中，可以快速訪問系統(tǒng)公共資源，無需考慮其他業(yè)務(wù)的影響，不僅減少了大量重復(fù)性工作，而且開發(fā)過程變得更為規(guī)范。同時，每一個服務(wù)都具備強大的水平擴展能力，針對不同煤礦企業(yè)的私有化定制需求，開發(fā)人員不僅可以對系統(tǒng)中的服務(wù)進行動態(tài)裁剪，而且還可以對每個微服務(wù)單獨進行升級和部署，使得維護難度大大降低。

2.2 系統(tǒng)架構(gòu)

針對現(xiàn)有的人員定位系統(tǒng)水平擴展性差、維護困難且無法滿足智慧礦山平臺對多異構(gòu)系統(tǒng)間的數(shù)據(jù)融合和共享的需求的情況，從主流的微服務(wù)架構(gòu)設(shè)計思想作為出發(fā)點，提出了一種基于微服務(wù)架構(gòu)的人員定位系統(tǒng)設(shè)計方案。系統(tǒng)架構(gòu)主要分為主引擎、硬件層、數(shù)據(jù)驅(qū)動層、軟總線、服務(wù)層、接口層和交互層。

1）主引擎。主引擎是一個輕量級的應(yīng)用服務(wù)引擎，主要提供公共服務(wù)、數(shù)據(jù)存儲服務(wù)、部署管理和服務(wù)管理的功能。公共服務(wù)包括系統(tǒng)日志、權(quán)限管理、文件同步等系統(tǒng)公共業(yè)務(wù)；數(shù)據(jù)存儲提供統(tǒng)一的數(shù)據(jù)庫訪問規(guī)范；部署管理提供平臺無關(guān)性、一鍵化和自動化部署的支持；服務(wù)管理實現(xiàn)對服務(wù)的控制和服務(wù)間的數(shù)據(jù)共享。

2）硬件層。硬件層主要包括定位基站、網(wǎng)關(guān)、定位卡、接收器等設(shè)備。

3）數(shù)據(jù)驅(qū)動層。數(shù)據(jù)驅(qū)動層實現(xiàn)數(shù)據(jù)采集、數(shù)據(jù)接入、數(shù)據(jù)優(yōu)化算法和控制命令解析的功能。數(shù)據(jù)采集就是根據(jù)不同的通信協(xié)議（Modbus-RTU、TCP/UDP等）將采集的信息進行解析和接收；數(shù)據(jù)接入是將接收的數(shù)據(jù)進行拆解，并且按照統(tǒng)一數(shù)據(jù)規(guī)范寫入軟總線中；數(shù)據(jù)優(yōu)化算法主要提供高精度的定位算法和數(shù)據(jù)壓縮算法等；控制命令解析負責(zé)將接收到的命令信息解析成硬件設(shè)備能夠識別的命令字段，并且下發(fā)到硬件層。

4）軟總線。軟總線提供了數(shù)據(jù)訪問、數(shù)據(jù)緩存、數(shù)據(jù)融合以及控制命令通道的功能。數(shù)據(jù)訪問提供統(tǒng)一的數(shù)據(jù)訪問接口，規(guī)范化數(shù)據(jù)訪問格式。數(shù)據(jù)融合是將系統(tǒng)中重用性和共享性高的數(shù)據(jù)進行結(jié)構(gòu)化統(tǒng)一構(gòu)建；數(shù)據(jù)緩存存儲公共數(shù)據(jù)、實時數(shù)據(jù)以及數(shù)據(jù)融合的結(jié)構(gòu)化數(shù)據(jù)，并且按照統(tǒng)一的存儲規(guī)范將數(shù)據(jù)存儲到數(shù)據(jù)庫；控制指令通道用于提供低延時、獨立的指令傳送機制。

5）服務(wù)層。服務(wù)層以微服務(wù)的方式加載和運行各個私有業(yè)務(wù)，例如唯一性檢測、位置服務(wù)、井口大屏、GIS 服務(wù)、多系統(tǒng)融合、考勤管理和聯(lián)網(wǎng)上傳等私有模塊。各個微服務(wù)之間是水平排列關(guān)系，開發(fā)人員在開發(fā)過程中，不僅可以從主引擎獲取公共服務(wù)接口，而且還可以從軟總線獲取公共數(shù)據(jù)、實時數(shù)據(jù)以及數(shù)據(jù)融合的結(jié)構(gòu)化數(shù)據(jù)，無需關(guān)心下層和數(shù)據(jù)庫的具體實現(xiàn)細節(jié)，大大減少了重復(fù)性工作。同時，各個私有服務(wù)可在托管平臺中，以Docker 鏡像方式獨立部署，實現(xiàn)服務(wù)之間的松耦合。

6）接口層。接口層主要包括公有業(yè)務(wù)的接口、私有業(yè)務(wù)的接口和多系統(tǒng)融合接口，為交互層提供了各類功能的WebAPI 接口和gRPC。其中公有業(yè)務(wù)接口由主引擎提供，私有業(yè)務(wù)接口由服務(wù)層各個私有服務(wù)提供，多系統(tǒng)融合接口由系統(tǒng)融合服務(wù)提供。

7）交互層。交互層包括移動端、PC 端和融合平臺的用戶交互?？刹捎们昂蠖朔蛛x的開發(fā)技術(shù)[13]，利用主流的Angular、Vue 等框架，最終實現(xiàn)一次開發(fā)，多平臺運行，極大提高了開發(fā)人員的開發(fā)效率。

2.3 系統(tǒng)部署

在微服務(wù)的架構(gòu)中，開發(fā)人員可將自己開發(fā)的業(yè)務(wù)、運行環(huán)境以及依賴包打包成Docker 鏡像文件，系統(tǒng)中所有已經(jīng)開發(fā)完成的業(yè)務(wù)則可以鏡像文件的形式存放在鏡像倉庫中。微服務(wù)是基于云原生的技術(shù)，具備快捷的云端部署能力。因此不僅可在本地服務(wù)器上通過拷貝等方式獲取全部的鏡像文件，也可在云端的托管平臺中通過Docker 命令的方式從鏡像倉庫中拉取所需的鏡像文件。系統(tǒng)部署流程如圖2。

圖2 系統(tǒng)部署流程圖Fig.2 System deployment process

開發(fā)人員在部署的過程中，可根據(jù)拉取的鏡像文件創(chuàng)建和啟動Docker 容器作為服務(wù)運行的載體。系統(tǒng)在啟動時，首先運行系統(tǒng)框架中的主引擎模塊，其中公共服務(wù)、數(shù)據(jù)存儲服務(wù)等平臺支撐的功能模塊已經(jīng)固化在了主引擎中；接著主數(shù)據(jù)、融合數(shù)據(jù)等會依次導(dǎo)入軟總線數(shù)據(jù)緩存中；最后主引擎會加載所有容器中的私有服務(wù)，私有服務(wù)通過主引擎和系統(tǒng)軟總線的接口實現(xiàn)對公共數(shù)據(jù)、實時數(shù)據(jù)和融合數(shù)據(jù)的訪問。用戶可通過Docker 的映射地址訪問具體的業(yè)務(wù)模塊，最終所有的服務(wù)都可動態(tài)配置和彈性部署，使得整個系統(tǒng)滿足復(fù)雜化應(yīng)用場景的需求。

3 關(guān)鍵技術(shù)

3.1 數(shù)據(jù)融合技術(shù)

智慧礦山平臺的建設(shè)要求包括人員定位系統(tǒng)在內(nèi)的各個子系統(tǒng)之間能夠?qū)崿F(xiàn)數(shù)據(jù)融合及信息共享。大多數(shù)煤礦企業(yè)中各個子系統(tǒng)都是由不同廠家開發(fā)和部署，因此不同系統(tǒng)之間的數(shù)據(jù)結(jié)構(gòu)大多不同，這就導(dǎo)致了融合過程往往需要大量的重復(fù)性翻譯工作。

設(shè)計了一種系統(tǒng)軟總線結(jié)構(gòu)。軟總線確定了公共數(shù)據(jù)、實時數(shù)據(jù)和融合數(shù)據(jù)的描述規(guī)則和存儲規(guī)范，它將人員定位系統(tǒng)中的共享性、公共性、重用性高的數(shù)據(jù)進行抽象和結(jié)構(gòu)化存入數(shù)據(jù)緩存，并且為各個服務(wù)提供統(tǒng)一的數(shù)據(jù)訪問接口和控制命令通道。同時軟總線采用數(shù)據(jù)的訂閱發(fā)布機制，數(shù)據(jù)的發(fā)布者稱為生產(chǎn)者，接收數(shù)據(jù)的服務(wù)稱為消費者，系統(tǒng)中各個服務(wù)都可通過軟總線提供的接口訂閱感興趣的數(shù)據(jù)?？刂泼钔ǖ来鎯ιa(chǎn)者發(fā)布、消費者訂閱的控制命令信息，這種異步消息傳遞機制確保了控制命令傳遞過程中的低時延和獨立性。對于融合數(shù)據(jù)的訪問接口，開發(fā)人員可根據(jù)融合平臺需求創(chuàng)建融合接口服務(wù)，將軟總線打包供融合平臺調(diào)用，這樣就可從軟總線獲取融合后的數(shù)據(jù)信息。

3.2 基于時序數(shù)據(jù)庫的數(shù)據(jù)分類存儲技術(shù)

現(xiàn)有的人員定位系統(tǒng)架構(gòu)都是將系統(tǒng)主數(shù)據(jù)、融合數(shù)據(jù)、歷史數(shù)據(jù)等存放在統(tǒng)一的關(guān)系數(shù)據(jù)庫中。隨著業(yè)務(wù)需求越來越多，統(tǒng)一的數(shù)據(jù)庫存儲逐漸制約著系統(tǒng)對數(shù)據(jù)的處理能力。

InfluxDB 是一個由InfluxData 開發(fā)的開源時序型數(shù)據(jù)庫，著力于高性能地查詢與存儲時序型數(shù)據(jù)[14]，被廣泛應(yīng)用于存儲系統(tǒng)的監(jiān)控數(shù)據(jù)。為了提高人員定位系統(tǒng)數(shù)據(jù)處理的時效性，可引入時序數(shù)據(jù)庫對數(shù)據(jù)進行分類存儲。例如MySQL+InfluxDB 的存儲方案，將系統(tǒng)主數(shù)據(jù)、融合數(shù)據(jù)存入MySQL 中，并且同步軟總線數(shù)據(jù)緩存。歷史數(shù)據(jù)結(jié)構(gòu)簡單可存入InfluxDB 中，將極大地加快對歷史報警信息、人員歷史軌跡、設(shè)備歷史狀態(tài)等業(yè)務(wù)的查詢速度。MySQL 和InfluxDB 查詢速度對比見表1。

表1 MySQL 和InfluxDB 查詢速度對比Table 1 Comparison of data query speeds of MySQL and InfluxDB

3.3 容器虛擬化技術(shù)

傳統(tǒng)的虛擬化技術(shù)是通過中間層將1 臺或者多臺獨立的機器虛擬運行與物理硬件之上，而容器則是直接運行在操作系統(tǒng)內(nèi)核之上的用戶空間。容器作為微服務(wù)運行的載體，就像是一個完整的宿主機一樣，不僅具備獨立的用戶空間和運行環(huán)境，真正做到服務(wù)之間的隔離和松耦合，而且還支持網(wǎng)絡(luò)端口映射、數(shù)據(jù)持久化以及資源管理功能[15]。Docker 是一個開源的應(yīng)用容器引擎，開發(fā)人員可將自己開發(fā)的業(yè)務(wù)模塊和依賴包進行打包，創(chuàng)建Docker 鏡像文件，1 個Docker 鏡像擁有完整的文件系統(tǒng)結(jié)構(gòu)。當(dāng)需要對業(yè)務(wù)進行部署時，開發(fā)者只需要在宿主機中根據(jù)Docker 鏡像創(chuàng)建并運行Docker 容器，Docker容器類似于1 個鏡像文件的運行實例，包含特定應(yīng)用的代碼及所需的依賴文件，最終用戶即可根據(jù)容器的網(wǎng)絡(luò)映射端口訪問具體的業(yè)務(wù)模塊。

4 結(jié) 語

1）基于微服務(wù)的人員定位系統(tǒng)架構(gòu)，依托主引擎提供的公共服務(wù)、數(shù)據(jù)存儲服務(wù)等基礎(chǔ)支撐功能，實現(xiàn)了私有業(yè)務(wù)之間的按需分配，具備敏捷開發(fā)、彈性部署和維護簡單的優(yōu)勢。

2）人員定位系統(tǒng)、安全監(jiān)控系統(tǒng)等多源異構(gòu)系統(tǒng)之間的數(shù)據(jù)融合、信息共享和大數(shù)據(jù)處理能力是實現(xiàn)智慧礦山平臺的重要前提。軟總線結(jié)構(gòu)構(gòu)建了統(tǒng)一的數(shù)據(jù)的接入和存儲規(guī)范，引入時序數(shù)據(jù)庫實現(xiàn)了對海量歷史數(shù)據(jù)的高效查詢，以Docker 容器作為運行載體的微服務(wù)之間相互隔離，方便開發(fā)人員可對融合接口服務(wù)進行獨立升級和部署。