基于微服務(wù)的工地安全管理系統(tǒng)架構(gòu)設(shè)計(jì)

崔 燦，周 偉

（湖北工業(yè)大學(xué)機(jī)械工程學(xué)院，湖北武漢 430068）

0 引言

人口數(shù)量的激增與城市化、工業(yè)化的推進(jìn)使高速發(fā)展的建筑業(yè)成為我國(guó)國(guó)民經(jīng)濟(jì)重要組成部分。近年來，我國(guó)經(jīng)濟(jì)飛速發(fā)展，基建水平之高、速度之快得到全世界廣泛認(rèn)可。同時(shí)，工地安全風(fēng)險(xiǎn)管理存在方式落后、水平較低、數(shù)字化程度較低等問題，傳統(tǒng)作業(yè)模式已無法滿足可持續(xù)發(fā)展的要求，阻礙了我國(guó)建筑行業(yè)進(jìn)一步發(fā)展。為實(shí)現(xiàn)建筑行業(yè)轉(zhuǎn)型和升級(jí)，保證建筑行業(yè)可持續(xù)健康發(fā)展，必須利用先進(jìn)的科技手段和完善的信息化技術(shù)。

建筑行業(yè)屬于施工密集型產(chǎn)業(yè)，有周期長(zhǎng)、投資大、業(yè)務(wù)流程復(fù)雜、施工環(huán)境特殊、危險(xiǎn)源多等特點(diǎn)，同時(shí)伴有各種不可預(yù)見的風(fēng)險(xiǎn)及影響［1］。我國(guó)建筑施工從業(yè)人員流動(dòng)性大、工作條件惡劣，且普遍缺乏安全意識(shí)、規(guī)范化程度低，使施工現(xiàn)場(chǎng)安全隱患增加，加大了作業(yè)風(fēng)險(xiǎn)。同時(shí)企業(yè)監(jiān)管力度低、信息傳達(dá)方式落后，且安全檢查人員專業(yè)化水平較低、人工數(shù)量有限，大多以現(xiàn)場(chǎng)巡查、人工通知為主，發(fā)現(xiàn)問題后難以第一時(shí)間將信息進(jìn)行上報(bào)處理，導(dǎo)致隱患整改周期長(zhǎng)，事故發(fā)生率難以降低［［2］。建立先進(jìn)的工地?cái)?shù)據(jù)管理平臺(tái)，可加強(qiáng)現(xiàn)場(chǎng)管理力度、提高信息傳遞效率、減少違規(guī)操作現(xiàn)象，從而加快隱患處理速度，降低事故發(fā)生率。在此背景下，利用物聯(lián)網(wǎng)、大數(shù)據(jù)、云計(jì)算、移動(dòng)通訊等先進(jìn)技術(shù)的“智慧工地”數(shù)據(jù)管理平臺(tái)應(yīng)運(yùn)而生［3］。

大多數(shù)現(xiàn)有“智慧工地”系統(tǒng)采用信息共享的模式，通過系統(tǒng)對(duì)工地安全信息相關(guān)數(shù)據(jù)進(jìn)行集中處理，以減少事故發(fā)生［4］。但該類系統(tǒng)以數(shù)據(jù)積累為主，信息多為單向流動(dòng)，數(shù)據(jù)形成規(guī)模后再應(yīng)用于工程實(shí)踐［5］，反饋?zhàn)饔貌?。同時(shí)該系統(tǒng)應(yīng)用過程依賴于封閉環(huán)境，建模依靠CAD 信息，無法實(shí)現(xiàn)資源整合且與施工現(xiàn)場(chǎng)信息脫離［6］。在平臺(tái)開發(fā)階段，不同開發(fā)團(tuán)隊(duì)的習(xí)慣不同，無統(tǒng)一技術(shù)架構(gòu)，在后期運(yùn)維過程中添加或開發(fā)新模塊時(shí)，易與其它模塊發(fā)生沖突，形成“信息孤島”。

為解決上述缺陷，本文提出基于微服務(wù)架構(gòu)的工地安全管理系統(tǒng)架構(gòu)設(shè)計(jì)，開發(fā)一個(gè)高效、智能、范圍廣、可控率高的數(shù)據(jù)管理平臺(tái)，以升級(jí)工地現(xiàn)場(chǎng)管理模式為目的，通過新技術(shù)、新模式對(duì)項(xiàng)目施工過程進(jìn)行參數(shù)化、可視化、信息化、可持續(xù)發(fā)展的優(yōu)化升級(jí)。

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

現(xiàn)有管理信息系統(tǒng)項(xiàng)目大多基于傳統(tǒng)單體式應(yīng)用（見圖1），由Spring Boot 或由Maven 自動(dòng)生成項(xiàng)目開發(fā)。這些項(xiàng)目一般是以業(yè)務(wù)邏輯層為中心的六邊形結(jié)構(gòu)模式，同時(shí)提供數(shù)據(jù)庫(kù)連接接口［7］、管理消息的組件以及支持UI 訪問的Web 模塊適配器等。雖然均以模塊設(shè)計(jì)為出發(fā)點(diǎn)，但最終還是會(huì)被打包成單體式結(jié)構(gòu)，當(dāng)單體模塊結(jié)構(gòu)達(dá)到瓶頸期后，通常會(huì)將其復(fù)制成多個(gè)單體式應(yīng)用，這樣就構(gòu)成一個(gè)“集群”，這些集群能夠提供相同的服務(wù)，每個(gè)服務(wù)器是該集群節(jié)點(diǎn)，后期仍可通過增加節(jié)點(diǎn)解決負(fù)載問題，并由負(fù)載均衡服務(wù)器均勻分配每一個(gè)節(jié)點(diǎn)負(fù)載。但是，這種單體式應(yīng)用會(huì)隨著后期不斷開發(fā)而變得復(fù)雜，無論后期增加多少個(gè)節(jié)點(diǎn)，集群效果都無法明顯提升，隨著應(yīng)用的增大，啟動(dòng)將會(huì)隨之減慢，從而導(dǎo)致敏捷性開發(fā)無法完成［8］。

Fig.1 Common monomer application圖1 普通單體應(yīng)用

微服務(wù)架構(gòu)模式可解決上述問題，其思路不再是開發(fā)一個(gè)大的單體式應(yīng)用（見圖2），而是將其分解為小的互相連接的微服務(wù)應(yīng)用［9］。一個(gè)微服務(wù)完成一個(gè)特定功能，每個(gè)單體式應(yīng)用獨(dú)立部署、維護(hù)以及擴(kuò)展，每子系統(tǒng)均可在WEB 容器中獨(dú)立運(yùn)行，每個(gè)應(yīng)用都是低耦合的，從而系統(tǒng)具有強(qiáng)大的擴(kuò)展能力，并且各模塊之間可通過提供Restful API 進(jìn)行相互調(diào)用，減少對(duì)其它模塊的影響。

Fig.2 Microservice application圖2 微服務(wù)應(yīng)用

本文總體架構(gòu)設(shè)計(jì)采用微服務(wù)的思路［10］。將項(xiàng)目管理、安全管理、設(shè)備管理等子模塊按功能相似性精細(xì)劃分，每一個(gè)子模塊對(duì)特定資源進(jìn)行對(duì)應(yīng)操作。從開發(fā)角度來看，每一個(gè)模塊均可交給不同的團(tuán)隊(duì)進(jìn)行開發(fā)，可以根據(jù)團(tuán)隊(duì)開發(fā)習(xí)慣利用不同的模式進(jìn)行開發(fā)，最后只需保證能提供API 服務(wù)實(shí)現(xiàn)通信即可，該方案不僅使開發(fā)效率得到提升，而且解決了后期維護(hù)和添加新模塊時(shí)技術(shù)選型等一系列問題，如圖3 所示。從部署角度來看，每個(gè)微服務(wù)都是獨(dú)立部署，減小了部署時(shí)對(duì)其它模塊的影響［11］。

Fig.3 Microservice architecture圖3 微服務(wù)架構(gòu)

2 系統(tǒng)模塊設(shè)計(jì)

設(shè)計(jì)一套安全管理系統(tǒng)對(duì)每一個(gè)項(xiàng)目工地設(shè)備信息、人員信息、監(jiān)控視屏等數(shù)據(jù)進(jìn)行統(tǒng)一匯總管理，項(xiàng)目監(jiān)管方可隨時(shí)查詢工地作業(yè)、現(xiàn)場(chǎng)實(shí)時(shí)監(jiān)控，在發(fā)現(xiàn)安全隱患時(shí)，可實(shí)時(shí)向建筑作業(yè)方發(fā)出安全信息預(yù)警和報(bào)警，建立全方位的安全管理系統(tǒng)［12］。系統(tǒng)按具體需求進(jìn)行劃分，如圖4 所示。

Fig.4 Function modules圖4 功能模塊

（1）項(xiàng)目信息管理。該模塊包含工地管理和通訊錄管理，項(xiàng)目監(jiān)管方可通過該功能查看該地區(qū)所有項(xiàng)目信息，如項(xiàng)目名稱、地點(diǎn)、規(guī)模、項(xiàng)目施工方單位、監(jiān)理單位等。這些信息由相關(guān)人員通過PC 端或APP 端口錄入，通訊錄管理可查詢到每一個(gè)項(xiàng)目對(duì)應(yīng)負(fù)責(zé)人信息和該項(xiàng)目下作業(yè)人員信息。

（2）環(huán)境監(jiān)測(cè)管理。施工場(chǎng)地環(huán)境和天氣狀況能是施工安全的重要因素，項(xiàng)目負(fù)責(zé)人員和施工人員可根據(jù)近一周的天氣、風(fēng)向和溫度、濕度安排工作任務(wù)，如有影響施工的惡劣天氣可及時(shí)通過平臺(tái)向各施工人員手機(jī)APP 發(fā)出警報(bào)停止作業(yè)或根據(jù)實(shí)際情況重新安排。

（3）安全監(jiān)督。該模塊隨著每一個(gè)項(xiàng)目的施工進(jìn)度變更，政府監(jiān)管人員可查詢到該項(xiàng)目施工狀況，發(fā)起安全檢查，若發(fā)現(xiàn)項(xiàng)目?jī)?nèi)存在未達(dá)標(biāo)或危險(xiǎn)源地區(qū)，則可以通過平臺(tái)對(duì)該項(xiàng)目的危險(xiǎn)源進(jìn)行記錄，并向各個(gè)項(xiàng)目管理方提出危險(xiǎn)源處理通知，發(fā)起安全整改［13］。同時(shí)，施工方在管理平臺(tái)接到通知后可根據(jù)檢查方記錄的問題對(duì)危險(xiǎn)源地區(qū)進(jìn)行安全整改，在對(duì)危險(xiǎn)源整改過程中，監(jiān)管人員能隨時(shí)查看危險(xiǎn)地區(qū)處理狀態(tài)并對(duì)處理結(jié)果及時(shí)審核，同時(shí)提交安全日志進(jìn)行記錄。這樣施工方和監(jiān)管方從發(fā)現(xiàn)施工問題到解決問題形成閉環(huán)，避免因監(jiān)管不嚴(yán)帶來的安全隱患。安全檢查流程如圖5 所示。

（4）設(shè)備管理。該模塊安全事故大多是設(shè)備管理不當(dāng)或物料堆放不符合安全要求導(dǎo)致的，該模塊可錄入設(shè)備信息，讓施工人員根據(jù)該設(shè)備使用年限、設(shè)備圖片及受損程度規(guī)劃作業(yè)強(qiáng)度，并對(duì)每個(gè)地區(qū)設(shè)備進(jìn)行監(jiān)控管理。

Fig.5 Business flow圖5 業(yè)務(wù)流程

（5）視頻監(jiān)控。該模塊項(xiàng)目中的監(jiān)控功能可實(shí)時(shí)獲取該項(xiàng)目中各地區(qū)影像資料，同時(shí)可查詢過去一周內(nèi)的監(jiān)控資料。

（6）移動(dòng)端APP。該模塊包含iOS 和Android 平臺(tái)，隨行工作人員可隨時(shí)在移動(dòng)端查看項(xiàng)目所有信息，在遇到作業(yè)需求變更或危險(xiǎn)預(yù)警時(shí)可第一時(shí)間在移動(dòng)端收到安全警報(bào)和通知，同時(shí)可在PC 端對(duì)各項(xiàng)數(shù)據(jù)進(jìn)行錄取和查詢操作，以便施工后期對(duì)項(xiàng)目數(shù)據(jù)進(jìn)行調(diào)整變動(dòng)［14］。

此外，報(bào)表導(dǎo)出功可嵌入在各個(gè)模塊之中，包含安全檢查記錄表、安全整改表、危險(xiǎn)源信息表、人員管理統(tǒng)計(jì)表等，可根據(jù)需要導(dǎo)出Excel 表格。

3 系統(tǒng)架構(gòu)實(shí)現(xiàn)

對(duì)于現(xiàn)有業(yè)務(wù)情況，為了保證項(xiàng)目統(tǒng)一性，采用Java語言進(jìn)行開發(fā)，選擇Spring 作為容器框架，Spring MVC 作為模型控制器框架，選用Spring Cloud 作為整體應(yīng)用架構(gòu)，每個(gè)子項(xiàng)目均基于SpringBoot［15］。在該安全管理系統(tǒng)中，考慮到單個(gè)數(shù)據(jù)庫(kù)會(huì)因?yàn)楹笃诙伍_發(fā)模塊的增加重新設(shè)計(jì)數(shù)據(jù)庫(kù)，所以對(duì)每個(gè)模塊均設(shè)立對(duì)應(yīng)的數(shù)據(jù)庫(kù)與其連接。安全管理系統(tǒng)架構(gòu)總體架構(gòu)使用SpringCloud+Mysql+Redis+RabbitMQ 搭建。

Spring Cloud 作為一套完整的分布式系統(tǒng)，常作為解決各種問題的方案。它通過Zuul 組件實(shí)現(xiàn)服務(wù)網(wǎng)關(guān)，向外界提供RESTAPI、Eureka 實(shí)現(xiàn)服務(wù)注冊(cè)和發(fā)現(xiàn)，再到Hystrix熔斷機(jī)制阻止服務(wù)故障蔓延［16］。項(xiàng)目中每個(gè)獨(dú)立的子模塊均包含能獨(dú)立運(yùn)行和部署的基礎(chǔ)模塊。

（1）網(wǎng)關(guān)和服務(wù)注冊(cè)。在系統(tǒng)使用過程中，管理負(fù)責(zé)人員在使用該管理系統(tǒng)查詢某工地詳情時(shí)，該詳情可能包含該施工地環(huán)境信息、人員狀況、設(shè)備情況等，但是這些數(shù)據(jù)由不同的微服務(wù)提供數(shù)據(jù)，由于本文采用的是微服務(wù)架構(gòu)，所以無法按照傳統(tǒng)單一型架構(gòu)采用join 的方式對(duì)數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)查詢，需引入API 網(wǎng)關(guān)。本文使用Spring?CloudZuul API 網(wǎng)關(guān)實(shí)現(xiàn)，Zuul 是一種可執(zhí)行認(rèn)證、動(dòng)態(tài)路由、負(fù)載均衡的邊緣服務(wù)。API 網(wǎng)關(guān)處理請(qǐng)求的方式是將Zuul 路由配置到合適的后端服務(wù)，例如根據(jù)工地詳情請(qǐng)求可知，其后端服務(wù)彼此獨(dú)立，調(diào)用各服務(wù)（設(shè)備信息、負(fù)責(zé)人信息、工地信息等）合并結(jié)果處理請(qǐng)求（見圖6）。

將請(qǐng)求路由注冊(cè)到Eureka 組件上，由Eureka 的Eu?rekaservice 組件實(shí)現(xiàn)服務(wù)的注冊(cè)。每個(gè)服務(wù)在啟動(dòng)時(shí)會(huì)在Eureka service 中儲(chǔ)存注冊(cè)信息，然后周期性地向Eurekas?ervice 發(fā)送默認(rèn)為30s 的心跳續(xù)約信息，同時(shí)Eurekaservice會(huì)以周期為60s 的間隔監(jiān)測(cè)實(shí)銷服務(wù)，若檢測(cè)到失效服務(wù)，則Eurekaservice 會(huì)將失效服務(wù)從注冊(cè)信息中進(jìn)行默認(rèn)90s的暫時(shí)移除操作，當(dāng)在服務(wù)啟動(dòng)后，某一個(gè)模塊出現(xiàn)故障時(shí)不會(huì)導(dǎo)致整個(gè)系統(tǒng)崩潰。Eureka 通過心跳檢查機(jī)制保證整個(gè)安全管理系統(tǒng)高擴(kuò)展性和靈活性。

Fig.6 Registration schematic for gateways and services圖6 網(wǎng)關(guān)和服務(wù)注冊(cè)原理

（2）熔斷機(jī)制。在安全管理系統(tǒng)運(yùn)行過程中，設(shè)備管理模塊、人員信息管理模塊，環(huán)境監(jiān)測(cè)模塊等各個(gè)服務(wù)相互依賴，以下簡(jiǎn)稱A、B、C、D 模塊。若在某一情況下，A 因?yàn)榫W(wǎng)路異?；蜇?fù)載較高的情況下導(dǎo)致響應(yīng)變慢或發(fā)生異常時(shí)，由于一系列鏈?zhǔn)椒磻?yīng)使B、C、D 狀態(tài)也會(huì)轉(zhuǎn)為異常，導(dǎo)致用戶訪問其它模塊的線程得不到響應(yīng)，則線程得不到釋放，內(nèi)存會(huì)一直被占用，如果該類情況過多，會(huì)耗盡資源。這時(shí)需引入Hystrix 組件熔斷機(jī)制保證服務(wù)運(yùn)行穩(wěn)定性，如圖7 所示。

Fig.7 Fuse圖7 熔斷器

Hystrix 組件是一個(gè)實(shí)現(xiàn)了斷路模式的庫(kù)，原理是通過隔離服務(wù)的訪問點(diǎn)防止因?yàn)槟滁c(diǎn)故障而導(dǎo)致整個(gè)系統(tǒng)崩潰。在特定情況下，系統(tǒng)多個(gè)使用者在短時(shí)間內(nèi)大量訪問某個(gè)API 接口，若次數(shù)超過設(shè)定的閾值時(shí)，即Hystrix Com?mand 請(qǐng)求后端服務(wù)出現(xiàn)錯(cuò)誤的次數(shù)超過該閾值時(shí)，Hystrix組件提供的熔斷功能會(huì)開啟，進(jìn)行服務(wù)降級(jí)策略，使用fall?back 返回默認(rèn)值，告訴使用者該服務(wù)已不可用。在一段時(shí)間后，已經(jīng)打開的熔斷功能會(huì)變?yōu)榘氪蜷_模式，并先處理一定量的請(qǐng)求，熔斷器模塊使系統(tǒng)具有更好的彈性。

（3）緩存數(shù)據(jù)庫(kù)。在實(shí)際系統(tǒng)運(yùn)行時(shí)，在項(xiàng)目初期數(shù)據(jù)錄入過程中，項(xiàng)目管理訪問量可能會(huì)高于其它功能，在項(xiàng)目檢查階段，安全檢查功能會(huì)被監(jiān)管方更加關(guān)注，若用戶每次請(qǐng)求訪問這些信息時(shí)，均從數(shù)據(jù)庫(kù)里直接查詢，則短時(shí)間內(nèi)會(huì)消耗大量數(shù)據(jù)庫(kù)請(qǐng)求。Redis 是一個(gè)高性能的key-value 數(shù)據(jù)庫(kù)，能支持超過100K+每秒的讀寫頻率，具有豐富的數(shù)據(jù)類型［17］，為了減輕數(shù)據(jù)庫(kù)壓力，本文使用re?dis 作為緩存框架，儲(chǔ)存大量短時(shí)間內(nèi)不會(huì)變化卻又經(jīng)常需要讀取的數(shù)據(jù)，同時(shí)可提高用戶響應(yīng)速率。

（4）數(shù)據(jù)存儲(chǔ)數(shù)據(jù)庫(kù)。Mysql 作為當(dāng)下最穩(wěn)定的關(guān)系型數(shù)據(jù)庫(kù)之一，特別是在Web 開發(fā)項(xiàng)目下廣為使用［18］。在該項(xiàng)目中，考慮到每個(gè)模塊本身需儲(chǔ)存大量數(shù)據(jù)，在進(jìn)行安全檢查和提交安全日志一系列流程也將產(chǎn)生大量數(shù)據(jù)信息，系統(tǒng)需不斷進(jìn)行數(shù)據(jù)存儲(chǔ)和更替，故采用穩(wěn)定高效的Mysql 作為數(shù)據(jù)庫(kù)系統(tǒng)。

（5）消息中間件。在系統(tǒng)安全檢查過程中，實(shí)際作業(yè)項(xiàng)目復(fù)雜多樣性，往往是多項(xiàng)檢查并行，檢察人員在新增安全檢查時(shí)，將問題信息以表單的方式提交到數(shù)據(jù)庫(kù)，傳統(tǒng)方法是調(diào)用數(shù)據(jù)庫(kù)接口寫入或修改數(shù)據(jù)，但當(dāng)并發(fā)量在短時(shí)間內(nèi)很高時(shí)，數(shù)據(jù)庫(kù)可能出現(xiàn)故障，將導(dǎo)致所有請(qǐng)求的數(shù)據(jù)失敗，這時(shí)為保障系統(tǒng)穩(wěn)定性，本文引用RabbitMQ作為消息隊(duì)列協(xié)議的消息中間件，當(dāng)用戶請(qǐng)求數(shù)據(jù)時(shí)，將請(qǐng)求信息寫入消息隊(duì)列，并向用戶反饋給予反饋信息。即便消息傳遞的某環(huán)節(jié)出現(xiàn)故障，消息也不會(huì)丟失。

（6）界面。PC 端展示界面主要通過jQueryMiniUI 實(shí)現(xiàn)前端頁面展示。手機(jī)APP 采用APICloud 手機(jī)APP 框架，以前后端分離的方式開發(fā)，手機(jī)端與PC 端具有共享數(shù)據(jù)和功能，打包部署完成后可生成二維碼供使用者下載。

（7）持久層設(shè)計(jì)。由于每個(gè)單獨(dú)的業(yè)務(wù)模塊均基于SpringBoot，所以采用SpringBoot JPA 作為持久化框架，SpringBoot JPA 提供的Repsitory 脫離了Dao 層操作，基本上所有crud 操作均可依賴它實(shí)現(xiàn)，減少數(shù)據(jù)訪問層代碼量。

（8）邏輯實(shí)現(xiàn)。用戶從前端輸入的數(shù)據(jù)，傳入后臺(tái)均為Json 格式，通過路由的方式匹配到對(duì)應(yīng)控制層進(jìn)行業(yè)務(wù)邏輯處理，控制層根據(jù)接收的數(shù)據(jù)調(diào)用相應(yīng)服務(wù)層對(duì)數(shù)據(jù)進(jìn)行業(yè)務(wù)邏輯判斷處理，同時(shí)操作數(shù)據(jù)訪問層根據(jù)具體業(yè)務(wù)對(duì)數(shù)據(jù)進(jìn)行具體操作，最后逐層向上返回，同樣以Json的格式給前端，將頁面渲染數(shù)據(jù)展示給用戶。

（9）部署。在傳統(tǒng)項(xiàng)目部署過程中，需在每一臺(tái)服務(wù)器上裝載運(yùn)行環(huán)境，如果項(xiàng)目運(yùn)行的需求環(huán)境發(fā)生改變，則必須重新安裝部署，若服務(wù)器數(shù)量巨大，這將是一項(xiàng)非常耗時(shí)的工作。本文采用Docker 容器部署技術(shù)，將所需的基礎(chǔ)鏡像與微服務(wù)生成的鏡像部署在Docker 容器中［19］，讓Docker Swarm 管理各項(xiàng)目運(yùn)行的容器。綜上所述，將微服務(wù)部署在Docker 容器中可以實(shí)現(xiàn)微服務(wù)的快速部署，方便管理和服務(wù)打包［20］。系統(tǒng)整體架構(gòu)如圖8 所示。

Fig.8 System architecture圖8 系統(tǒng)架構(gòu)

4 結(jié)語

本文結(jié)合當(dāng)前行業(yè)內(nèi)管理系統(tǒng)存在的問題，提出一種基于微服務(wù)架構(gòu)的安全管理系統(tǒng)，并介紹了系統(tǒng)各模塊組成和運(yùn)用的技術(shù)。本文開發(fā)的基于微服務(wù)安全管理系統(tǒng)已在湖北省某政府項(xiàng)目上預(yù)運(yùn)行，該架構(gòu)相比之前的單體式架構(gòu)，雖然在開發(fā)層面彌補(bǔ)了單體式應(yīng)用的不足之處，使運(yùn)行更加穩(wěn)定，但仍存在一些不足，比如Http 請(qǐng)求耗時(shí)問題、微服務(wù)的多服務(wù)部署復(fù)雜性問題等，這些是下一步研究方向。同時(shí)，本文開發(fā)架構(gòu)不具備行業(yè)普適性，在實(shí)際研發(fā)中，研究人員可參考本文微服務(wù)思想，根據(jù)實(shí)際行業(yè)背景選擇合適的技術(shù)架構(gòu)。