王 磊，黃 晴，尚偉棟，萇延輝，張曉霞

（1.山西天地王坡煤業(yè)有限公司，山西 晉城 048016；2.煤炭科學研究總院有限公司礦山大數(shù)據(jù)研究院，北京 100000；3.天地科技股份有限公司，北京 100000）

0 引言

隨著煤礦智能化建設(shè)的推進，煤炭行業(yè)不斷加大“兩化”融合的投入，基于傳統(tǒng)架構(gòu)的煤礦生產(chǎn)系統(tǒng)極大地提高了煤礦信息化能力[1-2]，但數(shù)據(jù)采集仍處于單系統(tǒng)運行模式，業(yè)務(wù)與模塊的耦合度仍相對較低。為了解決此類問題，國家提出采用工業(yè)互聯(lián)網(wǎng)平臺作為礦山賦能的智能化基礎(chǔ)設(shè)施，通過基于工業(yè)互聯(lián)網(wǎng)平臺的微服務(wù)運行方式解決礦井生產(chǎn)系統(tǒng)單系統(tǒng)數(shù)據(jù)采集運行可靠性差、各業(yè)務(wù)子系統(tǒng)煙囪式孤島運行等問題，為推動煤礦“統(tǒng)一標準、互聯(lián)互通、業(yè)務(wù)重構(gòu)、系統(tǒng)優(yōu)化”提供解決方案[3-5]，提高煤礦智能化生產(chǎn)監(jiān)控水平，以新一代信息化手段實現(xiàn)煤礦“無人則安”的安全生產(chǎn)發(fā)展理念。

數(shù)據(jù)采集問題是推動煤炭行業(yè)智能化的關(guān)鍵環(huán)節(jié)，眾多學者和企業(yè)對此開展了研究與實踐。賀耀宜[6]等提出采用OID 編碼技術(shù)實現(xiàn)煤礦設(shè)備的對象標志方案，實現(xiàn)設(shè)備統(tǒng)一數(shù)據(jù)編碼；采用主備方式采集設(shè)備數(shù)據(jù)，主鏈路正常時，備鏈路僅保持連接而不傳數(shù)據(jù)，同時對路由協(xié)議進行優(yōu)化，實現(xiàn)路由自發(fā)現(xiàn)和故障自恢復，從而保證鏈路的穩(wěn)定可靠。孟光偉[7]提出了數(shù)據(jù)采集平臺提供統(tǒng)一的SDK，讓應(yīng)用通過SDK 編碼獲取采集數(shù)據(jù)進行可視化。李國民等[8]提出將協(xié)議封裝為驅(qū)動動態(tài)鏈接庫(Dynamic Link Library，DLL)，通過采用單體進程開辟多線程加載適配協(xié)議驅(qū)動的方式實現(xiàn)各業(yè)務(wù)系統(tǒng)的數(shù)據(jù)采集。杜毅博等[9]提出自己的設(shè)備編碼規(guī)則，便于后期處理過程中的數(shù)據(jù)關(guān)聯(lián)分析；提出應(yīng)用基于面向服務(wù)架構(gòu)（SOA），調(diào)用Restful 和RPC 協(xié)議，研發(fā)定制化數(shù)據(jù)報表系統(tǒng)實現(xiàn)應(yīng)用界面與業(yè)務(wù)邏輯的數(shù)據(jù)快速展示。

然而，隨著智能化的推進，礦山對數(shù)據(jù)采集的數(shù)量和質(zhì)量要求大幅度提高。目前，數(shù)據(jù)采集架構(gòu)在煤礦信息化發(fā)展過程中逐漸暴露出一定的局限性，主要表現(xiàn)如下：

(1)數(shù)據(jù)采集系統(tǒng)數(shù)據(jù)管理編碼機制，雖然對設(shè)備按照統(tǒng)一規(guī)則進行的數(shù)字編碼，數(shù)據(jù)編碼在不同的工程中編碼會變化，語義不統(tǒng)一帶來了解析困難，應(yīng)用通過編碼級聯(lián)的方式關(guān)聯(lián)設(shè)備和測點，造成數(shù)據(jù)冗余；且對于設(shè)備測點采用順序排序的方式編碼，造成不同設(shè)備對象測點編碼不統(tǒng)一，對于數(shù)據(jù)可視化需要語義轉(zhuǎn)換和測點關(guān)聯(lián)不能復制等問題。

(2)數(shù)據(jù)采集基于單體架構(gòu)模式，采集多個通道數(shù)據(jù)通過單進程實現(xiàn)，如果局部通道出問題，整個采集進程受到影響，其他采集通道不能正常采集數(shù)據(jù)；不能容器化部署，難以以微服務(wù)方式運行為其他應(yīng)用提供數(shù)據(jù)服務(wù)。

(3)數(shù)據(jù)可視化工具靈活性與效率不足，主流方式是采用面向服務(wù)的軟件架構(gòu)（SOA），微服務(wù)化效果不好，系統(tǒng)整體可靠性低下；實現(xiàn)采用定制化表格對數(shù)據(jù)進行監(jiān)視，不具備靈活性；而且，通過無狀態(tài)的Restful 和RPC協(xié)議請求數(shù)據(jù)，如果需要實時刷新數(shù)據(jù)，界面需要利用定時器周期向后臺請求數(shù)據(jù)，效率低下。

(4)數(shù)據(jù)采集進程采用主備方式，主備切換過程中需要周期測試主備心跳，導致數(shù)據(jù)丟失，難以做到智能化切換，數(shù)據(jù)采集系統(tǒng)的整體可靠性降低。

針對目前數(shù)據(jù)采集的不足，本文提出一種面向微服務(wù)架構(gòu)煤礦生產(chǎn)系統(tǒng)數(shù)據(jù)采集的設(shè)計與應(yīng)用，以實現(xiàn)煤礦生產(chǎn)監(jiān)控數(shù)據(jù)的安全高效采集。

1 數(shù)據(jù)采集系統(tǒng)架構(gòu)設(shè)計

微服務(wù)架構(gòu)是基于單一功能組件的模塊化組合方式，能夠?qū)崿F(xiàn)松耦合的應(yīng)用開發(fā)。一個微服務(wù)是一個能夠獨立運行的小型應(yīng)用，通過API 接口實現(xiàn)微服務(wù)間的通信，將多個不同功能、相互隔離的微服務(wù)應(yīng)用按需組合，構(gòu)成完整的綜合應(yīng)用系統(tǒng)[10-13]。隨著大數(shù)據(jù)、云計算、分布式組件和互聯(lián)網(wǎng)技術(shù)的發(fā)展，采用微服務(wù)架構(gòu)已成為煤礦生產(chǎn)系統(tǒng)數(shù)據(jù)采集的趨勢，受到煤礦系統(tǒng)集成商和用戶的重視[14-17]。但是，由于煤礦開采系統(tǒng)的復雜性，如何將龐大的數(shù)據(jù)采集模塊拆分成獨立的微服務(wù)應(yīng)用成為煤礦生產(chǎn)系統(tǒng)數(shù)據(jù)采集亟需解決的難題。

數(shù)據(jù)采集系統(tǒng)整體架構(gòu)按照工業(yè)互聯(lián)網(wǎng)體系要求，將礦井生產(chǎn)系統(tǒng)數(shù)據(jù)采集模塊拆分為小型應(yīng)用，部署在PaaS（Platform as a Service）平臺上，以微服務(wù)的方式為其他應(yīng)用提供服務(wù)。核心思想是每個通道采用獨立的微服務(wù)的方式進行數(shù)據(jù)的接入[18-20]，綜采、綜掘、主運輸、供電、排水等系統(tǒng)的數(shù)據(jù)采集以微服務(wù)方式為用戶提供服務(wù)。

面向微服務(wù)架構(gòu)監(jiān)控平臺的總體架構(gòu)如圖1 所示。底層為數(shù)據(jù)采集層，各通道部署到獨立容器中，利用PaaS 平臺的docker 化能力，采用工業(yè)監(jiān)控協(xié)議，以微服務(wù)的方式把煤礦設(shè)備數(shù)據(jù)采集到實時數(shù)據(jù)庫中，作為監(jiān)控平臺的數(shù)據(jù)源，實現(xiàn)實時庫存儲的標準化。中間層為數(shù)據(jù)服務(wù)層，包含數(shù)據(jù)統(tǒng)一登錄、權(quán)限管理、告警、服務(wù)監(jiān)控、數(shù)據(jù)共享等模塊，為數(shù)據(jù)可視化提供后臺服務(wù)，向下與數(shù)據(jù)采集層相連，接入不同工業(yè)協(xié)議的設(shè)備數(shù)據(jù)，向上以統(tǒng)一接口的方式支撐礦井級生產(chǎn)監(jiān)控系統(tǒng)數(shù)據(jù)可視化的開發(fā)。頂層是數(shù)據(jù)可視化層，利用數(shù)據(jù)服務(wù)共享模塊提供的數(shù)據(jù)服務(wù)接口，按照統(tǒng)一的數(shù)據(jù)格式，使用低代碼可視化組件通過拖拉拽方式，構(gòu)建礦井生產(chǎn)控制系統(tǒng)專項數(shù)據(jù)可視化應(yīng)用，為用戶實現(xiàn)對礦井數(shù)據(jù)的監(jiān)視。

圖1 煤礦生產(chǎn)監(jiān)控數(shù)據(jù)采集系統(tǒng)總體架構(gòu)

2 微服務(wù)架構(gòu)數(shù)據(jù)采集關(guān)鍵技術(shù)

2.1 數(shù)據(jù)統(tǒng)一標準化

工業(yè)互聯(lián)網(wǎng)平臺的技術(shù)體系能夠解決煤礦智能化建設(shè)過程中的統(tǒng)一數(shù)據(jù)標準問題[21]。煤礦統(tǒng)一數(shù)據(jù)標準主要采用對象分類方法，采用json 數(shù)據(jù)格式表示設(shè)備對象，設(shè)備屬性采用key-value 方式訪問，其中設(shè)備屬性的key 是固定的，這樣做的好處是統(tǒng)一了語義，方便不用的應(yīng)用交互數(shù)據(jù)。描述主要分為兩部分：(1)設(shè)備描述：主要包括子系統(tǒng)類型、設(shè)備類型、位置信息、設(shè)備關(guān)聯(lián)關(guān)系、實時數(shù)據(jù)狀態(tài)等方面的屬性[22]。(2)設(shè)備測點：定義id，名稱、單位類型、數(shù)據(jù)類型、數(shù)據(jù)長度，讀寫標志等，其中測點id 采用是固定的，這樣做的好處是固定了測點id，實現(xiàn)項目工程實施從一個工程到另外一個工程的復制，不需要修改屬性id，減少工程開發(fā)工作量。

設(shè)備對象json 描述如下：

其中，uuid 是通過雪花算法自動生成，保證礦井設(shè)備的唯一性，避免設(shè)備識別錯誤的問題，points 以數(shù)組的方式表示。

2.2 單通道采集微服務(wù)化處理

單體架構(gòu)構(gòu)建所有的通信通道，一個通道對應(yīng)一種協(xié)議[23-25]。該模式可伸縮性差，如果在生產(chǎn)運行過程新增通道或協(xié)議，需要重啟程序，影響正常的生產(chǎn)數(shù)據(jù)采集。此外，單體運行系統(tǒng)錯誤隔離性差，由于煤礦接入設(shè)備數(shù)量較多，需要多通道接入煤礦設(shè)備數(shù)據(jù)，如果某個通道出現(xiàn)問題，其他的數(shù)據(jù)采集通道也會受影響。為了解決以上難題，本文采用基于微服務(wù)的方式設(shè)計數(shù)據(jù)采集模塊，即單通道采用獨立的微服務(wù)方式為應(yīng)用提供服務(wù)。

數(shù)據(jù)采集組單通道微服務(wù)化如圖2 所示，包括配置信息前后端同步、配置信息存儲、通道啟動、標準模型映射和統(tǒng)一標準服務(wù)。

圖2 數(shù)據(jù)采集模塊流程圖

(1) 配置信息前后端同步：現(xiàn)有數(shù)據(jù)采集模塊主要采用客戶端/服務(wù)端架構(gòu)，雖然服務(wù)端可以使用 Docker容器化部署，但客戶端無法容器化部署，也不能以微服務(wù)方式為用戶提供服務(wù)。因此，采用前后端分離技術(shù)，基于VUE 框架開發(fā)前端，利用Axios 組件和后臺通信，webpackage 打包獨立部署到Nginx docker 容器中；后端基于SpringBoot 開發(fā)，提供Restful API 和前端提供數(shù)據(jù)訪問服務(wù)，后端可以獨立部署在docker 容器中。

(2) 配置信息存儲：WEB 配置工具后臺根據(jù)前端用戶的配置信息，按照工程、通道、協(xié)議、點的組織關(guān)系存儲到工程信息庫中，工程信息庫的種類包括關(guān)系型數(shù)據(jù)庫（MySQL）和非關(guān)系型數(shù)據(jù)庫（Minio），為了滿足不同的數(shù)據(jù)庫存儲接口，本架構(gòu)采用對應(yīng)的互聯(lián)網(wǎng)數(shù)據(jù)庫訪問中間件，并封裝統(tǒng)一的存儲接口。信息的存儲封裝SaveInfo 接口，接收參數(shù)為信息類型，底層調(diào)用Mybatis組件把關(guān)系型數(shù)據(jù)存到MySQL 中，調(diào)用Minio 訪問組件把非關(guān)系型數(shù)據(jù)存到Minio 中。

(3) 通道啟動：通道啟動采用微服務(wù)方式，一個通道啟動一個微服務(wù)，需要保證每個微服務(wù)啟動通道的唯一性，同時保證采集通道服務(wù)的完整性。通道啟動分為兩步：一是讀取配置，二是信息同步。讀取配置是微服務(wù)讀取通道信息表，獲取唯一標識通道名稱作為微服務(wù)啟動的參數(shù)。信息同步過程為：微服務(wù)利用輸入的通道名稱啟動，啟動之前，首先查詢ZooKeeper 服務(wù)注冊中心已經(jīng)啟動的通道信息，接著從通道信息表過濾已經(jīng)啟動的通道，然后選擇剩下未啟動的通道進行啟動，啟動成功后向ZooKeeper 服務(wù)注冊中心注冊啟動信息。如果通道運行過程中出現(xiàn)異常，PaaS 平臺自動重新啟動該微服務(wù)，啟動過程按照信息同步步驟執(zhí)行。

(4) 標準模型映射：由于煤礦設(shè)備種類多，其通信協(xié)議不統(tǒng)一，數(shù)據(jù)采集存在通信協(xié)議的兼容性和一致性差等問題，需要向下利用不同協(xié)議采集數(shù)據(jù)，向上對應(yīng)用提供統(tǒng)一的數(shù)據(jù)標準。為了保證上層應(yīng)用數(shù)據(jù)的統(tǒng)一性，采用基于面向?qū)ο蟮腗QTT 協(xié)議統(tǒng)一進行數(shù)據(jù)采集。通過對象方式打通全礦井縱向和橫向各系統(tǒng)層級間的數(shù)據(jù)流，達到各個子系統(tǒng)間“統(tǒng)一標準”的目的，增強數(shù)據(jù)資源共享能力。協(xié)議庫用C 語言實現(xiàn)，JSON 模型封裝采用Java 語言實現(xiàn)，首先通過Java JNA 接口獲取協(xié)議庫數(shù)據(jù)，然后采用Gson 組件把數(shù)據(jù)按照key 映射成設(shè)備對象，實現(xiàn)標準模型映射。

(5) 標準服務(wù)：通過統(tǒng)一的接口，以對象的方式為其他應(yīng)用提供數(shù)據(jù)服務(wù)。這種方式有利于其他應(yīng)用的開發(fā)，能夠提高應(yīng)用的開發(fā)效率和應(yīng)用系統(tǒng)的集成能力。提供一個Restful API 接口，參數(shù)為設(shè)備類型和設(shè)備id，根據(jù)此，通過Redis 訪問接口遍歷Redis key 定位到設(shè)備數(shù)據(jù)，從Redis 取出數(shù)據(jù)返回，為應(yīng)用提供數(shù)據(jù)訪問服務(wù)。

2.3 數(shù)據(jù)服務(wù)狀態(tài)監(jiān)控

為了實現(xiàn)對數(shù)據(jù)服務(wù)的監(jiān)控，采用監(jiān)控服務(wù)的方式對數(shù)據(jù)服務(wù)進行監(jiān)視。傳統(tǒng)上數(shù)據(jù)服務(wù)單體運行的方式監(jiān)控復雜度較低，監(jiān)控服務(wù)采用輪詢監(jiān)控單體系統(tǒng)的運行情況就可以滿足數(shù)據(jù)服務(wù)狀態(tài)監(jiān)控要求。本文數(shù)據(jù)采集采用微服務(wù)方式運行，每個微服務(wù)擁有獨立的運行環(huán)境，導致數(shù)據(jù)服務(wù)數(shù)量顯著增加，各數(shù)據(jù)服務(wù)的發(fā)布次數(shù)增加，對監(jiān)控服務(wù)的要求也大大提高。采用輪詢的前提條件是監(jiān)控服務(wù)明確數(shù)據(jù)服務(wù)的信息，監(jiān)視服務(wù)采用輪詢監(jiān)視方式和數(shù)據(jù)服務(wù)通信，實現(xiàn)數(shù)據(jù)服務(wù)監(jiān)視，由于微服務(wù)啟動的數(shù)量是動態(tài)變化的，無法采用輪詢的方式。因此需要采用數(shù)據(jù)服務(wù)向監(jiān)控服務(wù)周期自動傳輸?shù)姆绞?，實現(xiàn)數(shù)據(jù)服務(wù)監(jiān)控功能。

服務(wù)狀態(tài)監(jiān)控設(shè)計如圖3 所示，基于SpringBoot Actuator 組件，分別開發(fā)服務(wù)端（StateServer）和客戶端（StateClient），其中服務(wù)端提供Restful API 接口供應(yīng)用進行可視化，客戶端嵌入到微服務(wù)應(yīng)用中，封裝health endpoint 獲取應(yīng)用的健康狀態(tài)；封裝heapdump endpoint獲取JVM 虛擬機的使用情況，包括堆內(nèi)存使用率、線程數(shù)量、垃圾回收數(shù)量和時間；封裝auditevent endpoint 獲取認證信息，包括用戶名、登錄時間等。

圖3 服務(wù)狀態(tài)監(jiān)控設(shè)計

2.4 數(shù)據(jù)可視化組件

數(shù)據(jù)采集系統(tǒng)可視化采用WEB 報表組件，表現(xiàn)形式包括表格、曲線、餅圖和柱狀圖，實現(xiàn)數(shù)據(jù)實時展示、通道狀態(tài)監(jiān)視、數(shù)據(jù)統(tǒng)計等功能。

目前主流廠家已實現(xiàn)WEB 化報表組件，但他們采用前后端一體化緊耦合架構(gòu)，難以實現(xiàn)微服務(wù)化部署，只要一個程序出故障，會導致整個系統(tǒng)崩潰，錯誤隔離差，整體運行可靠性低。本文采用前后端分離松耦合架構(gòu)，前端可分拆成一個微服務(wù)，后端可拆分成多個微服務(wù)，當某個微服務(wù)出故障，不會影響其他微服務(wù)的運行，提高了系統(tǒng)運行可靠性。

報表組件設(shè)計如圖4 所示，包括數(shù)據(jù)源層、服務(wù)層和報表開發(fā)層。

圖4 報表組件設(shè)計

(1) 數(shù)據(jù)源層：為了滿足數(shù)據(jù)源的多樣化需求，數(shù)據(jù)源的數(shù)據(jù)庫類型包括關(guān)系型數(shù)據(jù)庫（如：MySQL，Oracle）和非關(guān)系數(shù)據(jù)庫（如Redis）。在數(shù)據(jù)源層能夠嵌入不同的數(shù)據(jù)庫訪問接口，以供數(shù)據(jù)源配置組件根據(jù)不同的數(shù)據(jù)庫類型智能匹配對應(yīng)的數(shù)據(jù)庫接口。采用SpringBoot 框架，通過動態(tài)注冊和切換DataSource bean來實現(xiàn)按照配置信息動態(tài)匹配數(shù)據(jù)源的功能，動態(tài)數(shù)據(jù)源類繼承AbstractRoutingDataSource，重寫determineCurrentLookupKey 函數(shù)，采用mybatis-plus 屏蔽不同數(shù)據(jù)庫訪問的差異。

(2) 服務(wù)層：數(shù)據(jù)模型配置根據(jù)用戶利用通用控件包融合ECharts 圖表組件，提供圖表交互接口，設(shè)置圖表的樣式、形狀，數(shù)據(jù)列等，為報表設(shè)計組件提供模板服務(wù)。利用VUE 父子組件數(shù)據(jù)交換框架，設(shè)計ReadInfo 接口讀取Echarts 屬性，設(shè)計WriteInfo 接口從實時庫讀取數(shù)據(jù)回寫Echarts 組件進行顯示。

(3) 報表開發(fā)層：報表設(shè)計器調(diào)用數(shù)據(jù)庫模型提供的圖表組件，按照項目的實際需求，通過托拉拽設(shè)計表格樣式，調(diào)用圖表插入到表格中，通過表格和圖表關(guān)聯(lián)數(shù)據(jù)，為報表展示界面展示提供數(shù)據(jù)模型服務(wù)。報表展示界面根據(jù)數(shù)據(jù)模型進行數(shù)據(jù)刷新和圖表渲染。利用VUE 框架的鼠標mousedown 和mouseup 事件實現(xiàn)組件的拖拽功能，利用組件封裝的接口（ReadInfo 和WriteInfo）實現(xiàn)讀寫數(shù)據(jù)功能。

(4) 數(shù)據(jù)的實時刷新：現(xiàn)階段煤礦基于WEB 的數(shù)據(jù)監(jiān)視主要采用HTTP 協(xié)議，前端設(shè)定定時器采用HTTP協(xié)議向后臺請求數(shù)據(jù)來進行刷新。由于HTTP 每次請求都需執(zhí)行三次握手流程，導致通信效率低下，為了解決此問題，本文采用WebSocket 通信協(xié)議，一旦界面和后臺建立了連接，后臺可以自動周期性往界面推送數(shù)據(jù)，避免了HTTP 協(xié)議每次訪問都需要三次握手流程導致效率低下的缺點。利用Netty 框架，通信類繼承SimpleChannelInboundHandler 類，重寫channelRead0 接口獲取推送周期，然后按照周期設(shè)置定時器往調(diào)用者推送數(shù)據(jù)。兩種方式實時刷新對比結(jié)果如表1 所示：

表1 實時數(shù)據(jù)刷新結(jié)果對比

2.5 微服務(wù)實現(xiàn)技術(shù)

本文采用Docker 容器實現(xiàn)微服務(wù)，將數(shù)據(jù)采集規(guī)約、數(shù)據(jù)庫、數(shù)據(jù)服務(wù)狀態(tài)監(jiān)控和可視化組件構(gòu)建標準化Docker 容器，組件彼此通過提供的接口進行通信，從而實現(xiàn)微服務(wù)。Docker 容器的自動化部署、擴展和管理，主流的方式是通過Kubernetes 實現(xiàn)，本文基于Kubernetes 開發(fā)適用數(shù)據(jù)采集的管理組件。

管理組件通過調(diào)用Kubernetes 提供的API 接口來管理Docker 容器，提供Docker 容器的創(chuàng)建、刪除、啟動、遷移、擴容與縮減、調(diào)度、網(wǎng)關(guān)代理設(shè)置、集群管理等功能，保證Docker 容器的高可靠運行，實現(xiàn)為用戶提供遠程協(xié)同控制Docker 的目的。

數(shù)據(jù)采集微服務(wù)設(shè)計如圖5 所示，命令解析器利用MySQLsql 接口讀取配置庫信息，根據(jù)通道、報表組件需要創(chuàng)建的pod 的數(shù)量，利用Sendcmd 接口向主節(jié)點API sServer 發(fā)出指令，API Sserver 響應(yīng)命令,通過一系列認證授權(quán),把通道、報表等pod 數(shù)據(jù)（包括每個pod 的docker 數(shù)據(jù)）存儲到 etcd，封裝StartResouce 接口創(chuàng)建部署資源并初始化；controller-manager 通過 List-watch 接口，監(jiān)測發(fā)現(xiàn)新的部署資源，將該資源加入到內(nèi)部工作隊列，發(fā)現(xiàn)該資源沒有關(guān)聯(lián)的 pod 和副本，啟用 ReplicasetCreate 接口創(chuàng)建副本資源；創(chuàng)建完成后，將副本資源更新存儲到 etcd；scheduler 通過 List-watch 接口,監(jiān)測發(fā)現(xiàn)新的 pod，經(jīng)過主機過濾、主機打分規(guī)則，將 pod 綁定 (binding) 到合適的主機；將綁定結(jié)果存儲到 etcd。工作節(jié)點kubelet 每隔 20 s (可以自定義)調(diào)用IntervalCall接口向 API Sserver 通過節(jié)點名稱獲取自身節(jié)點上所要運行的 pod 清單，通過與自己的內(nèi)部緩存進行比較,新增加 pod；kubelet 調(diào)用 Docker API 創(chuàng)建并啟動 pod；kube-proxy 為新創(chuàng)建的pod 注冊動態(tài)DNS 到緩存中；為pod 的服務(wù)添加負載均衡規(guī)則，用于服務(wù)發(fā)現(xiàn)和負載均衡。controller-manager 通過 control loop（控制循環(huán)）將當前pod 狀態(tài)與用戶所期望的狀態(tài)做對比，如果當前狀態(tài)與用戶期望狀態(tài)不同，則controller 會將pod 修改為期望狀態(tài)。

圖5 數(shù)據(jù)采集微服務(wù)設(shè)計

3 應(yīng)用案例

通過采用微服務(wù)架構(gòu)設(shè)計煤礦生產(chǎn)監(jiān)控系統(tǒng)數(shù)據(jù)采集，符合煤礦智能化建設(shè)和信息化基礎(chǔ)設(shè)施安裝部署工業(yè)互聯(lián)網(wǎng)平臺底座的要求。目前，該平臺已經(jīng)在山西天地王坡煤業(yè)有限公司進行試運行。將該平臺部署在王坡煤礦PaaS 平臺上，其中數(shù)據(jù)采集組件啟動了10 個微服務(wù)，同時通過可視化組件開發(fā)了10 個子系統(tǒng)數(shù)據(jù)監(jiān)視應(yīng)用，滿足了綜采、綜掘、主運輸、排水、通風、供電、智能污水處理、智能壓風、鐵路智能裝車和汽車智能裝運系統(tǒng)數(shù)據(jù)的智能監(jiān)控。數(shù)據(jù)采集系統(tǒng)展示效果如圖6～圖8 所示。

圖6 綜采工作面采集通道微服務(wù)部署界面

圖7 實時數(shù)據(jù)展示界面

圖8 數(shù)據(jù)監(jiān)控展示界面

應(yīng)用結(jié)果表明，該系統(tǒng)的部署操作簡便，通過“一鍵部署”可快速部署到王坡煤礦PaaS 平臺中，減少技術(shù)人員的項目部署工作量；在運行期間，微服務(wù)應(yīng)用的自愈和切換、分布式運行、運行監(jiān)控日志等都由PaaS 平臺統(tǒng)一管理，減少了運維人員的工作量。平臺應(yīng)用后，監(jiān)控系統(tǒng)運維人員數(shù)量由原來的4 人減至2 人，節(jié)省了王坡煤礦用戶的人力成本，符合智能礦山的“少人、無人”趨勢。

4 結(jié)論

本文以工業(yè)互聯(lián)網(wǎng)平臺為底座，以微服務(wù)架構(gòu)理念為指導，設(shè)計了一套全新的數(shù)據(jù)采集、監(jiān)控系統(tǒng)。該系統(tǒng)通過對綜采、綜掘、主運輸、排水、通風、供電系統(tǒng)設(shè)備數(shù)據(jù)進行采集，當某個數(shù)據(jù)采集服務(wù)出現(xiàn)異常時，不會影響其他數(shù)據(jù)采集服務(wù)的正常運行，從而提高了監(jiān)控系統(tǒng)的可靠性。此外，該系統(tǒng)還實現(xiàn)了礦井生產(chǎn)監(jiān)控系統(tǒng)子系統(tǒng)的數(shù)據(jù)監(jiān)視，滿足了用戶對數(shù)據(jù)可視化的要求。

雖然該平臺對煤礦生產(chǎn)監(jiān)控系統(tǒng)數(shù)據(jù)采集進行了微服務(wù)化初步嘗試，但仍處于初級應(yīng)用階段。為了能夠更好地支撐煤礦安全高效生產(chǎn)，需要進一步應(yīng)用云計算技術(shù)，并利用分布式技術(shù)在微服務(wù)的基礎(chǔ)上不斷改進煤礦生產(chǎn)監(jiān)控系統(tǒng)數(shù)據(jù)采集架構(gòu)，以實現(xiàn)礦井級海量數(shù)據(jù)采集、監(jiān)控功能，此外，微服務(wù)應(yīng)用的部署和運維對運維人員的要求更高，為更方便監(jiān)控微服務(wù)應(yīng)用的運行狀態(tài)，需要開發(fā)易用性更好的工具供運維人員使用。