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

崔 燦，周 偉

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

Fig.4 Function modules圖4 功能模塊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fig.7 Fuse圖7 熔斷器

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

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

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

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

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

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

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

（9）部署。在傳統(tǒng)項目部署過程中，需在每一臺服務(wù)器上裝載運行環(huán)境，如果項目運行的需求環(huán)境發(fā)生改變，則必須重新安裝部署，若服務(wù)器數(shù)量巨大，這將是一項非常耗時的工作。本文采用Docker 容器部署技術(shù)，將所需的基礎(chǔ)鏡像與微服務(wù)生成的鏡像部署在Docker 容器中［19］，讓Docker Swarm 管理各項目運行的容器。綜上所述，將微服務(wù)部署在Docker 容器中可以實現(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)各模塊組成和運用的技術(shù)。本文開發(fā)的基于微服務(wù)安全管理系統(tǒng)已在湖北省某政府項目上預(yù)運行，該架構(gòu)相比之前的單體式架構(gòu)，雖然在開發(fā)層面彌補了單體式應(yīng)用的不足之處，使運行更加穩(wěn)定，但仍存在一些不足，比如Http 請求耗時問題、微服務(wù)的多服務(wù)部署復(fù)雜性問題等，這些是下一步研究方向。同時，本文開發(fā)架構(gòu)不具備行業(yè)普適性，在實際研發(fā)中，研究人員可參考本文微服務(wù)思想，根據(jù)實際行業(yè)背景選擇合適的技術(shù)架構(gòu)。