荊誠(chéng)， 王愛軍

(1．中煤科工集團(tuán)常州研究院有限公司， 江蘇 常州 213015； 2．天地(常州)自動(dòng)化股份有限公司， 江蘇 常州 213015； 3.內(nèi)蒙古準(zhǔn)格爾旗宏豐煤炭運(yùn)銷有限責(zé)任公司 紅樹梁礦， 內(nèi)蒙古 鄂爾多斯 010400)

0 引言

煤礦監(jiān)控類軟件對(duì)煤礦的安全生產(chǎn)至關(guān)重要，在煤礦日常生產(chǎn)中監(jiān)控類軟件可提供24 h不間斷的各項(xiàng)指標(biāo)監(jiān)控，并可根據(jù)監(jiān)控?cái)?shù)據(jù)的變化采取告警、斷電等措施[1-2]。傳感器設(shè)備監(jiān)控、人員位置監(jiān)控、井下車輛位置監(jiān)控等均屬于監(jiān)控軟件功能范疇。煤礦現(xiàn)場(chǎng)根據(jù)自身業(yè)務(wù)需求會(huì)配備相關(guān)的煤礦監(jiān)控類軟件，由于不同的煤礦有不同的使用場(chǎng)景和個(gè)性化的業(yè)務(wù)需求[3]，這使得煤礦監(jiān)控類軟件雖然主要功能類似，但同一款煤礦監(jiān)控類軟件卻不能不加修改就應(yīng)用于多個(gè)煤礦[4]，同款軟件的不同配置及二次開發(fā)使得煤礦監(jiān)控軟件版本復(fù)雜，難以管理[5]。這種軟件開發(fā)模式給開發(fā)人員帶來(lái)了巨大的工作量，同時(shí)也使得運(yùn)維人員的維護(hù)工作變得復(fù)雜和充滿不確定性[6-7]。

個(gè)性化定制使得煤礦監(jiān)控類軟件的主數(shù)據(jù)結(jié)構(gòu)也經(jīng)常變化，主數(shù)據(jù)結(jié)構(gòu)的不確定性導(dǎo)致不同煤礦監(jiān)控軟件之間的通信也因?yàn)檐浖ㄖ苹薷亩兊美щy重重，影響煤礦監(jiān)控類軟件的融合工作。

針對(duì)煤礦監(jiān)控類軟件開發(fā)面臨的現(xiàn)狀和問題，提出了一種采用微服務(wù)架構(gòu)的煤礦監(jiān)控類軟件統(tǒng)一開發(fā)框架，采用微服務(wù)架構(gòu)的開發(fā)框架將基礎(chǔ)業(yè)務(wù)固化在框架中，專有業(yè)務(wù)提取為公共組件，以微服務(wù)的方式供開發(fā)人員按需加載調(diào)用。該開發(fā)框架采用了當(dāng)前成熟、流行的開發(fā)語(yǔ)言，開發(fā)模式為前后端分離。使用開發(fā)框架進(jìn)行軟件開發(fā)，可降低技術(shù)復(fù)雜度，同時(shí)借助技術(shù)中的跨平臺(tái)特性將降低多平臺(tái)版本軟件的重復(fù)編碼工作。

1 煤礦監(jiān)控類軟件開發(fā)框架

煤礦監(jiān)控類軟件開發(fā)框架架構(gòu)如圖1所示，自下而上分為設(shè)備層、通信接入層、應(yīng)用服務(wù)層、數(shù)據(jù)發(fā)布層和數(shù)據(jù)交互層。組件和版本管理平臺(tái)作為支撐模塊，提供例如基礎(chǔ)設(shè)施、通用組件、存儲(chǔ)、規(guī)范、公共技術(shù)棧和組件版本管理等支撐功能。

1.1 設(shè)備層

設(shè)備層包含傳感器、讀卡器、執(zhí)行器、分站、網(wǎng)關(guān)等，設(shè)備可以采集所處環(huán)境的各種數(shù)據(jù)，并通過網(wǎng)絡(luò)與上位機(jī)通信，上位機(jī)可以利用設(shè)備數(shù)據(jù)來(lái)監(jiān)控煤礦井下的各項(xiàng)數(shù)據(jù)指標(biāo)，也可以通過下發(fā)指令來(lái)控制設(shè)備的運(yùn)行。

圖1 煤礦監(jiān)控類軟件開發(fā)框架架構(gòu)Fig.1 Development framework architecture of coal mine monitoring software series

1.2 通信接入層

通信接入層主要用于上傳井下設(shè)備采集的數(shù)據(jù)和利用上位機(jī)下發(fā)配置和控制命令，可提供各種設(shè)備的協(xié)議解析和數(shù)據(jù)包裝功能，設(shè)備和第三方系統(tǒng)可以通過以太網(wǎng)和RS485等通道連接到上位機(jī)監(jiān)控系統(tǒng)。

協(xié)議解析的主要作用：針對(duì)不同設(shè)備協(xié)議的數(shù)據(jù)進(jìn)行數(shù)據(jù)格式的拆解，并轉(zhuǎn)換成通用的數(shù)據(jù)結(jié)構(gòu)，或者把通用數(shù)據(jù)結(jié)構(gòu)封裝為設(shè)備協(xié)議格式的數(shù)據(jù)。協(xié)議包括:自有設(shè)備所使用的協(xié)議：Caribus、自定義二進(jìn)制協(xié)議、Modbus TCP/Modbus RTU、CAN；第三方系統(tǒng)協(xié)議：OPC/OPC UA、自定義文本協(xié)議等。根據(jù)接入設(shè)備的不同，通信接入層需要提供配套的解析協(xié)議。相對(duì)于非獨(dú)立的協(xié)議解析模塊，通信接入層可以將各種協(xié)議解耦包裝為可替換模塊，根據(jù)監(jiān)控系統(tǒng)接入的設(shè)備不同按需加載所需的解析協(xié)議，獨(dú)立的通信接入層可以大大減少硬件協(xié)議的適配工作。

1.3 應(yīng)用服務(wù)層

應(yīng)用服務(wù)層將煤礦監(jiān)控軟件中的很多典型業(yè)務(wù)解耦抽離，區(qū)分公有和專有業(yè)務(wù)，并使用訂閱發(fā)布機(jī)制來(lái)進(jìn)行數(shù)據(jù)通信。

(1) 訂閱發(fā)布機(jī)制。該機(jī)制提供了一對(duì)多的消息發(fā)布，以便在耦合度較低的系統(tǒng)間進(jìn)行數(shù)據(jù)通信。例如，經(jīng)過協(xié)議解析后的數(shù)據(jù)對(duì)外發(fā)布，發(fā)布者稱為生產(chǎn)者，其他應(yīng)用服務(wù)模塊可以采取訂閱的方式來(lái)獲取生產(chǎn)者的數(shù)據(jù)，接收數(shù)據(jù)的服務(wù)模塊稱為消費(fèi)者，訂閱發(fā)布機(jī)制因此也被稱為生產(chǎn)者消費(fèi)者模式。

(2) 業(yè)務(wù)模塊(公有、專有)。煤礦監(jiān)控類軟件開發(fā)框架可提供監(jiān)控類軟件中具有共性的公有模塊，比如離散數(shù)據(jù)處理、軌跡數(shù)據(jù)處理、設(shè)備故障和報(bào)警管理、電源管理等。這些業(yè)務(wù)被固化在框架中，以便框架使用者隨時(shí)調(diào)用。專有模塊由具體的監(jiān)控類軟件開發(fā)人員根據(jù)專有業(yè)務(wù)需求來(lái)編寫，比如膠輪車監(jiān)控的司機(jī)管理模塊、上下行識(shí)別模塊、人員定位系統(tǒng)的考勤模塊、逃生路線管理模塊等。

(3) 公共數(shù)據(jù)區(qū)。存儲(chǔ)經(jīng)過處理后的業(yè)務(wù)數(shù)據(jù)，比如瓦斯數(shù)據(jù)、人員位置數(shù)據(jù)、設(shè)備開停狀態(tài)數(shù)據(jù)、設(shè)備故障和報(bào)警數(shù)據(jù)、電源狀態(tài)數(shù)據(jù)等。

(4) 命令處理模塊。在應(yīng)用中，用戶通過APP或者PC可以下發(fā)對(duì)底層設(shè)備的控制指令，控制指令經(jīng)過命令處理模塊處理，再通過通信通道下發(fā)至設(shè)備實(shí)現(xiàn)控制操作。

1.4 數(shù)據(jù)發(fā)布層

數(shù)據(jù)發(fā)布分為單系統(tǒng)的接口服務(wù)和多系統(tǒng)融合的ESB(Enterprise Service Bus，企業(yè)服務(wù)總線)服務(wù)。 WebAPI應(yīng)用在移動(dòng)端和Web端。ESB宜用于多系統(tǒng)的集成類應(yīng)用中，特別是涉及到第三方廠家開發(fā)的系統(tǒng)。

數(shù)據(jù)發(fā)布層負(fù)責(zé)將數(shù)據(jù)發(fā)布至數(shù)據(jù)交互層，用戶通過數(shù)據(jù)發(fā)布層提供的數(shù)據(jù)獲取方式獲取所需數(shù)據(jù)。對(duì)于單系統(tǒng)的軟件，通過接口(WebAPI)請(qǐng)求的方式獲取數(shù)據(jù)。對(duì)于多系統(tǒng)融合的軟件，依賴ESB技術(shù)來(lái)進(jìn)行數(shù)據(jù)通信，ESB技術(shù)提供了公共數(shù)據(jù)通道，各系統(tǒng)將其他系統(tǒng)所需的數(shù)據(jù)對(duì)ESB開放，其他軟件可通過消息總線獲取本軟件所關(guān)注的數(shù)據(jù)，達(dá)到了跨系統(tǒng)通信的目的。

1.5 數(shù)據(jù)交互層

數(shù)據(jù)交互層的主要功能是與用戶交互，將底層數(shù)據(jù)通過層層通信，最終以可視化的方式展示在用戶面前，展示的方式包括圖形(車輛軌跡、人員軌跡、環(huán)境參數(shù))、報(bào)表(瓦斯數(shù)據(jù)、考勤)、表格(設(shè)備狀態(tài)、下井人員信息)等。數(shù)據(jù)交互層通過捕獲用戶的點(diǎn)擊、滑動(dòng)和其他交互動(dòng)作進(jìn)行數(shù)據(jù)查詢，下發(fā)指令控制設(shè)備等操作?？梢暬故居卸嘀赝緩剑鏦eb端網(wǎng)頁(yè)展示、PC軟件展示、移動(dòng)端展示(適配Android和IOS等智能手機(jī)操作系統(tǒng))。以往，開發(fā)一款軟件如果要適配PC、Web和移動(dòng)端，需要進(jìn)行多次設(shè)計(jì)和開發(fā)，并且需要有對(duì)應(yīng)專業(yè)技能的研發(fā)人員，人力物力消耗巨大。微服務(wù)軟件開發(fā)框架采用的開發(fā)技術(shù)可以一次開發(fā)編譯為多種平臺(tái)的運(yùn)行版本，這大大減少了開發(fā)成本和開發(fā)時(shí)間。同時(shí)，統(tǒng)一的開發(fā)技術(shù)、精簡(jiǎn)的技術(shù)棧讓研發(fā)人員可以高效、高質(zhì)地完成研發(fā)工作。

2 微服務(wù)和Docker

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

軟件研發(fā)初期，架構(gòu)的選擇是相當(dāng)重要的，軟件架構(gòu)決定了該款軟件的各方面特性[8]，軟件架構(gòu)的選擇通常是根據(jù)實(shí)際需求來(lái)決定的。軟件架構(gòu)從簡(jiǎn)單到復(fù)雜、從單體到分布式出現(xiàn)了很多種，可以應(yīng)對(duì)各種需求。

(1) 單體架構(gòu)：即所有軟件功能集成在單獨(dú)的項(xiàng)目工程中，應(yīng)用界面和后臺(tái)數(shù)據(jù)是分離的，性能提升和擴(kuò)展主要是通過后端部署數(shù)據(jù)庫(kù)集群。這種架構(gòu)比較簡(jiǎn)單，優(yōu)點(diǎn)是開發(fā)成本低、效率高，通常應(yīng)用于小型項(xiàng)目。其缺點(diǎn)也同樣明顯，由于全部功能都在一個(gè)項(xiàng)目中，這使得后期的維護(hù)和擴(kuò)展會(huì)變得越來(lái)越困難，同時(shí)性能提升也有瓶頸，提升性能所需部署的設(shè)備成本較高[9]。

(2) 垂直架構(gòu)：這種架構(gòu)通常應(yīng)用于由多個(gè)子系統(tǒng)組成的項(xiàng)目，由于項(xiàng)目之間有數(shù)據(jù)交互需求，多個(gè)單體架構(gòu)的項(xiàng)目會(huì)組成一個(gè)更大的項(xiàng)目，這種以單體架構(gòu)項(xiàng)目為單位的架構(gòu)就是垂直架構(gòu)，單體架構(gòu)項(xiàng)目之間會(huì)有相互調(diào)用，數(shù)據(jù)共享，為了保證項(xiàng)目數(shù)據(jù)一致，還需要數(shù)據(jù)庫(kù)同步。其優(yōu)點(diǎn)就是架構(gòu)依然不算復(fù)雜，同時(shí)可以通過垂直拆分，讓項(xiàng)目中的子系統(tǒng)不會(huì)無(wú)限擴(kuò)展，而且項(xiàng)目的劃分可以在不同的項(xiàng)目里采用不同的技術(shù)實(shí)現(xiàn)。其缺點(diǎn)與單體架構(gòu)類似，因?yàn)槠浔举|(zhì)上就是單體架構(gòu)項(xiàng)目的一種融合，最終所有的功能依然是在一個(gè)完整的大項(xiàng)目中，這使得項(xiàng)目規(guī)模龐大，維護(hù)和擴(kuò)展都不簡(jiǎn)單，性能提升成本較高，且有性能瓶頸。

(3) SOA：SOA(Service Oriented Architecture，面向服務(wù)的架構(gòu))的思想是面向服務(wù)，將可重用的功能抽離變?yōu)榻M件，并將這些公用組件以服務(wù)的方式提供給各系統(tǒng)。為了減少系統(tǒng)中各種接口的耦合，SOA中組件之間的通信采用的是ESB。SOA的優(yōu)點(diǎn)是組件可重復(fù)利用，提高了系統(tǒng)的可重用性，提高了開發(fā)效率，同時(shí)還可以針對(duì)不同的業(yè)務(wù)需求定制集群和優(yōu)化方案。SOA的缺點(diǎn)是這種架構(gòu)中系統(tǒng)和服務(wù)邊界模糊，其服務(wù)抽取是站在系統(tǒng)的角度抽取的，粒度較大，大部分情況下抽取的組件是松耦合的，但有時(shí)服務(wù)之間會(huì)有相互影響。SOA架構(gòu)采用中央管理方式，采用這種架構(gòu)的系統(tǒng)模板時(shí)各服務(wù)之間可以正常交互，保證了系統(tǒng)的正常運(yùn)行。

(4) 微服務(wù)架構(gòu)：與SOA有諸多相似之處，不同之處在于SOA是從系統(tǒng)往組件設(shè)計(jì)的，而微服務(wù)是直接從組件出發(fā)，在需要的時(shí)候任何業(yè)務(wù)都可以抽取為組件，從而快速開發(fā)迭代[10]。微服務(wù)更像是SOA的特殊化版本，為了徹底解耦組件，微服務(wù)中所有的服務(wù)都是松耦合的，且單個(gè)服務(wù)的部署無(wú)需考慮其他服務(wù)的影響，這使得業(yè)務(wù)可以變得更為專注[11-12]。不同于SOA的中央管理方式，微服務(wù)采用分散管理方式[13]，采用這種架構(gòu)最大的好處就是可以獨(dú)立開發(fā)某個(gè)業(yè)務(wù)，開發(fā)人員無(wú)需考慮自己與其他業(yè)務(wù)的交互，每個(gè)微服務(wù)都有自己私有的數(shù)據(jù)庫(kù)持久化業(yè)務(wù)數(shù)據(jù)[14]，同時(shí)微服務(wù)采用的接口為WebAPI接口[15]，使得數(shù)據(jù)的輸入輸出更加便捷、規(guī)范。

煤礦監(jiān)控類軟件框架采用微服務(wù)架構(gòu)使得不同業(yè)務(wù)的開發(fā)人員可以獨(dú)立開發(fā)自己的服務(wù)，并且可以便捷地發(fā)布自己的服務(wù)，同時(shí)又可以享受到使用公共服務(wù)帶來(lái)的開發(fā)效率的提升，減少了重復(fù)代碼的編寫。

2.2 Docker

Docker是一種開源的應(yīng)用容器，微服務(wù)中的每個(gè)服務(wù)通過打包封裝成鏡像，利用Docker創(chuàng)建容器后加載鏡像就可以進(jìn)行獨(dú)立的維護(hù)和部署，且借助Docker的沙盒機(jī)制，這個(gè)封裝在Docker中的服務(wù)可以正常運(yùn)行在Windows、Mac OS或是Linux下，這意味著每個(gè)服務(wù)封裝后即具備了跨平臺(tái)的特性。而一臺(tái)計(jì)算機(jī)同時(shí)運(yùn)行多個(gè)容器，即可將各種服務(wù)組合成一個(gè)復(fù)雜的系統(tǒng)，通過這種方式來(lái)完成各種業(yè)務(wù)需求。

3 微服務(wù)在煤礦監(jiān)控類軟件中的應(yīng)用

3.1 煤礦監(jiān)控軟件中的微服務(wù)提取

以煤礦監(jiān)控系統(tǒng)中的監(jiān)控軟件為例來(lái)說明煤礦監(jiān)控類軟件中微服務(wù)的提取。煤礦監(jiān)控系統(tǒng)的功能模塊眾多，包含了各種圖形和報(bào)表，且有多重告警方式和多種實(shí)時(shí)狀態(tài)。根據(jù)微服務(wù)框架架構(gòu)，將煤礦監(jiān)控系統(tǒng)中的業(yè)務(wù)劃分為公共業(yè)務(wù)和專有業(yè)務(wù)，其中日志管理、用戶權(quán)限、短信通知等作為監(jiān)控類軟件的常用功能，將其解耦抽離成為公共業(yè)務(wù)，并固化在監(jiān)控類軟件開發(fā)框架中，在加載框架時(shí)即可以啟用這些功能。瓦斯日?qǐng)?bào)、設(shè)備狀態(tài)、實(shí)時(shí)數(shù)據(jù)和歷史曲線等這些與監(jiān)控業(yè)務(wù)密切相關(guān)的模塊則以微服務(wù)的方式進(jìn)行開發(fā)和加載。煤礦監(jiān)控軟件微服務(wù)架構(gòu)如圖2所示。

圖2 煤礦監(jiān)控軟件微服務(wù)架構(gòu)Fig.2 Microservice architecture of coal mine monitoring software

煤礦監(jiān)控系統(tǒng)中常用的查詢微服務(wù)都是冪等性(一次和多次請(qǐng)求某一個(gè)資源對(duì)于資源本身應(yīng)該具有同樣的結(jié)果)的，這就意味著查詢業(yè)務(wù)的水平擴(kuò)展性會(huì)相當(dāng)出色。微服務(wù)本身是一種云原生技術(shù)，其最大優(yōu)勢(shì)是支持便捷的云端部署，當(dāng)云端托管條件成熟時(shí)，可以在云端直接部署微服務(wù)架構(gòu)的監(jiān)控軟件，利用負(fù)載均衡技術(shù)，云端部署的監(jiān)控軟件可以按需擴(kuò)展性能，低成本地實(shí)現(xiàn)高質(zhì)量的軟件部署，改變了煤礦軟件性能受現(xiàn)場(chǎng)運(yùn)行環(huán)境約束的現(xiàn)狀。

對(duì)于微服務(wù)架構(gòu)性能的提升，可以通過典型業(yè)務(wù)的查詢時(shí)間對(duì)比來(lái)進(jìn)行說明。不同架構(gòu)的數(shù)據(jù)查詢速度對(duì)比結(jié)果見表1。從表1可看出，采用垂直架構(gòu)的歷史數(shù)據(jù)查詢，耗時(shí)要遠(yuǎn)遠(yuǎn)大于采用微服務(wù)架構(gòu)的歷史數(shù)據(jù)查詢，因?yàn)樵谖⒎?wù)架構(gòu)中將數(shù)據(jù)區(qū)分為熱數(shù)據(jù)和冷數(shù)據(jù)，熱數(shù)據(jù)由于訪問頻繁，將其加載入高速緩存中，由專門的熱數(shù)據(jù)管理微服務(wù)來(lái)進(jìn)行管理，高速緩存中的數(shù)據(jù)查詢操作速度相比于常規(guī)的磁盤查詢速度有了質(zhì)的提升。

表1 不同架構(gòu)的數(shù)據(jù)查詢速度對(duì)比Table 1 Comparison of data query speeds of different architectures

3.2 煤礦監(jiān)控軟件中的微服務(wù)開發(fā)

微服務(wù)開發(fā)流程如圖3所示。首先熟悉軟件框架技術(shù)體系選定的開發(fā)技術(shù)，然后按照普通軟件的開發(fā)流程正常開發(fā)，前端項(xiàng)目或后端項(xiàng)目都可以生成微服務(wù)。

圖3 微服務(wù)開發(fā)流程Fig.3 Microservice development process

計(jì)算機(jī)根據(jù)需求編寫業(yè)務(wù)代碼，經(jīng)測(cè)試后通過Docker打包工具將項(xiàng)目打包為鏡像，若將要部署的計(jì)算機(jī)沒有Docker環(huán)境，則需要安裝Docker。在Docker環(huán)境下，導(dǎo)入鏡像后創(chuàng)建容器并加載鏡像，通過對(duì)外部映射的端口或磁盤鏡像來(lái)訪問項(xiàng)目?jī)?nèi)容。自此微服務(wù)從開發(fā)至運(yùn)行的完整流程完畢，流程中對(duì)運(yùn)行環(huán)境的依賴很少，節(jié)約了以往煤礦監(jiān)控軟件需要大量環(huán)境配置所耗費(fèi)的時(shí)間。

3.3 煤礦監(jiān)控軟件中的微服務(wù)部署

在微服務(wù)架構(gòu)下，煤礦監(jiān)控軟件微服務(wù)的部署流程如圖4所示。

每個(gè)相關(guān)的業(yè)務(wù)都可成為一個(gè)微服務(wù)，并且界面和數(shù)據(jù)庫(kù)可以分開部署，部署完成后，通過Docker對(duì)外映射的地址即可正常訪問。鏡像庫(kù)保存了所有已經(jīng)開發(fā)完成的微服務(wù)，鏡像庫(kù)的維護(hù)和托管對(duì)于框架的正常運(yùn)行至關(guān)重要，如使用本地服務(wù)器托管可以通過FTP訪問拷貝；如使用云服務(wù)器倉(cāng)庫(kù)托管可使用Docker相關(guān)命令拉取所需的鏡像。鏡像庫(kù)管理可以借助圖形界面工具，管理工具允許預(yù)先創(chuàng)建業(yè)務(wù)模板，提前配置好相關(guān)參數(shù)，以便操作人員根據(jù)需求一鍵部署所需服務(wù)，通過圖形管理工具，還可以便捷地查看鏡像運(yùn)行狀態(tài)和資源占用情況，以便在資源不足時(shí)提前做出響應(yīng)。

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

以一個(gè)前端項(xiàng)目為例進(jìn)行項(xiàng)目部署，首先將鏡像導(dǎo)入，再創(chuàng)建服務(wù)映射端口，該項(xiàng)目映射的前端端口為8088，通過瀏覽器訪問8088端口(圖5), 簡(jiǎn)單幾步部署，一個(gè)微服務(wù)即可正常運(yùn)行，根據(jù)需求，可以從鏡像庫(kù)中拷貝所需鏡像進(jìn)行部署，并且通過磁盤映射，各微服務(wù)之間可以共享交互數(shù)據(jù)，從而實(shí)現(xiàn)一個(gè)滿足復(fù)雜需求的完整功能。

圖5 微服務(wù)運(yùn)行界面Fig.5 Microservice running interface

4 結(jié)論

(1) 采用微服務(wù)架構(gòu)的煤礦監(jiān)控類軟件開發(fā)框架消除了煤礦監(jiān)控軟件之間的技術(shù)壁壘，減少了相同需求的軟件的重復(fù)開發(fā)勞動(dòng)，從源頭上降低了煤礦監(jiān)控類軟件的運(yùn)維工作復(fù)雜度，改變了現(xiàn)有監(jiān)控類軟件的開發(fā)模式，大型項(xiàng)目可從框架中獲得基礎(chǔ)服務(wù)的支持，專有業(yè)務(wù)可拆分為多個(gè)微服務(wù)，便于開發(fā)者并發(fā)進(jìn)行開發(fā)工作，提高工作效率。

(2) 微服務(wù)云原生特性為監(jiān)控類軟件的云端托管提供了底層的支持，為軟件實(shí)現(xiàn)分布式運(yùn)行打下了基礎(chǔ)。微服務(wù)大大降低了功能之間的耦合度，使得功能開發(fā)可以獨(dú)立完成，同時(shí)使后期維護(hù)、修改也變得更為可控。沙盒運(yùn)行方式讓微服務(wù)的部署不受運(yùn)行環(huán)境影響，部署更方便，跨平臺(tái)移植性強(qiáng)。