崔 灿，周 伟

（湖北工业大学机械工程学院，湖北武汉 430068）

0 引言

人口数量的激增与城市化、工业化的推进使高速发展的建筑业成为我国国民经济重要组成部分。近年来，我国经济飞速发展，基建水平之高、速度之快得到全世界广泛认可。同时，工地安全风险管理存在方式落后、水平较低、数字化程度较低等问题，传统作业模式已无法满足可持续发展的要求，阻碍了我国建筑行业进一步发展。为实现建筑行业转型和升级，保证建筑行业可持续健康发展，必须利用先进的科技手段和完善的信息化技术。

建筑行业属于施工密集型产业，有周期长、投资大、业务流程复杂、施工环境特殊、危险源多等特点，同时伴有各种不可预见的风险及影响［1］。我国建筑施工从业人员流动性大、工作条件恶劣，且普遍缺乏安全意识、规范化程度低，使施工现场安全隐患增加，加大了作业风险。同时企业监管力度低、信息传达方式落后，且安全检查人员专业化水平较低、人工数量有限，大多以现场巡查、人工通知为主，发现问题后难以第一时间将信息进行上报处理，导致隐患整改周期长，事故发生率难以降低［［2］。建立先进的工地数据管理平台，可加强现场管理力度、提高信息传递效率、减少违规操作现象，从而加快隐患处理速度，降低事故发生率。在此背景下，利用物联网、大数据、云计算、移动通讯等先进技术的“智慧工地”数据管理平台应运而生［3］。

大多数现有“智慧工地”系统采用信息共享的模式，通过系统对工地安全信息相关数据进行集中处理，以减少事故发生［4］。但该类系统以数据积累为主，信息多为单向流动，数据形成规模后再应用于工程实践［5］，反馈作用差。同时该系统应用过程依赖于封闭环境，建模依靠CAD 信息，无法实现资源整合且与施工现场信息脱离［6］。在平台开发阶段，不同开发团队的习惯不同，无统一技术架构，在后期运维过程中添加或开发新模块时，易与其它模块发生冲突，形成“信息孤岛”。

为解决上述缺陷，本文提出基于微服务架构的工地安全管理系统架构设计，开发一个高效、智能、范围广、可控率高的数据管理平台，以升级工地现场管理模式为目的，通过新技术、新模式对项目施工过程进行参数化、可视化、信息化、可持续发展的优化升级。

1 微服务架构

现有管理信息系统项目大多基于传统单体式应用（见图1），由Spring Boot 或由Maven 自动生成项目开发。这些项目一般是以业务逻辑层为中心的六边形结构模式，同时提供数据库连接接口［7］、管理消息的组件以及支持UI 访问的Web 模块适配器等。虽然均以模块设计为出发点，但最终还是会被打包成单体式结构，当单体模块结构达到瓶颈期后，通常会将其复制成多个单体式应用，这样就构成一个“集群”，这些集群能够提供相同的服务，每个服务器是该集群节点，后期仍可通过增加节点解决负载问题，并由负载均衡服务器均匀分配每一个节点负载。但是，这种单体式应用会随着后期不断开发而变得复杂，无论后期增加多少个节点，集群效果都无法明显提升，随着应用的增大，启动将会随之减慢，从而导致敏捷性开发无法完成［8］。

Fig.1 Common monomer application图1 普通单体应用

微服务架构模式可解决上述问题，其思路不再是开发一个大的单体式应用（见图2），而是将其分解为小的互相连接的微服务应用［9］。一个微服务完成一个特定功能，每个单体式应用独立部署、维护以及扩展，每子系统均可在WEB 容器中独立运行，每个应用都是低耦合的，从而系统具有强大的扩展能力，并且各模块之间可通过提供Restful API 进行相互调用，减少对其它模块的影响。

Fig.2 Microservice application图2 微服务应用

本文总体架构设计采用微服务的思路［10］。将项目管理、安全管理、设备管理等子模块按功能相似性精细划分，每一个子模块对特定资源进行对应操作。从开发角度来看，每一个模块均可交给不同的团队进行开发，可以根据团队开发习惯利用不同的模式进行开发，最后只需保证能提供API 服务实现通信即可，该方案不仅使开发效率得到提升，而且解决了后期维护和添加新模块时技术选型等一系列问题，如图3 所示。从部署角度来看，每个微服务都是独立部署，减小了部署时对其它模块的影响［11］。

Fig.3 Microservice architecture图3 微服务架构

2 系统模块设计

设计一套安全管理系统对每一个项目工地设备信息、人员信息、监控视屏等数据进行统一汇总管理，项目监管方可随时查询工地作业、现场实时监控，在发现安全隐患时，可实时向建筑作业方发出安全信息预警和报警，建立全方位的安全管理系统［12］。系统按具体需求进行划分，如图4 所示。

Fig.4 Function modules图4 功能模块

（1）项目信息管理。该模块包含工地管理和通讯录管理，项目监管方可通过该功能查看该地区所有项目信息，如项目名称、地点、规模、项目施工方单位、监理单位等。这些信息由相关人员通过PC 端或APP 端口录入，通讯录管理可查询到每一个项目对应负责人信息和该项目下作业人员信息。

（2）环境监测管理。施工场地环境和天气状况能是施工安全的重要因素，项目负责人员和施工人员可根据近一周的天气、风向和温度、湿度安排工作任务，如有影响施工的恶劣天气可及时通过平台向各施工人员手机APP 发出警报停止作业或根据实际情况重新安排。

（3）安全监督。该模块随着每一个项目的施工进度变更，政府监管人员可查询到该项目施工状况，发起安全检查，若发现项目内存在未达标或危险源地区，则可以通过平台对该项目的危险源进行记录，并向各个项目管理方提出危险源处理通知，发起安全整改［13］。同时，施工方在管理平台接到通知后可根据检查方记录的问题对危险源地区进行安全整改，在对危险源整改过程中，监管人员能随时查看危险地区处理状态并对处理结果及时审核，同时提交安全日志进行记录。这样施工方和监管方从发现施工问题到解决问题形成闭环，避免因监管不严带来的安全隐患。安全检查流程如图5 所示。

（4）设备管理。该模块安全事故大多是设备管理不当或物料堆放不符合安全要求导致的，该模块可录入设备信息，让施工人员根据该设备使用年限、设备图片及受损程度规划作业强度，并对每个地区设备进行监控管理。

Fig.5 Business flow图5 业务流程

（5）视频监控。该模块项目中的监控功能可实时获取该项目中各地区影像资料，同时可查询过去一周内的监控资料。

（6）移动端APP。该模块包含iOS 和Android 平台，随行工作人员可随时在移动端查看项目所有信息，在遇到作业需求变更或危险预警时可第一时间在移动端收到安全警报和通知，同时可在PC 端对各项数据进行录取和查询操作，以便施工后期对项目数据进行调整变动［14］。

此外，报表导出功可嵌入在各个模块之中，包含安全检查记录表、安全整改表、危险源信息表、人员管理统计表等，可根据需要导出Excel 表格。

3 系统架构实现

对于现有业务情况，为了保证项目统一性，采用Java语言进行开发，选择Spring 作为容器框架，Spring MVC 作为模型控制器框架，选用Spring Cloud 作为整体应用架构，每个子项目均基于SpringBoot［15］。在该安全管理系统中，考虑到单个数据库会因为后期二次开发模块的增加重新设计数据库，所以对每个模块均设立对应的数据库与其连接。安全管理系统架构总体架构使用SpringCloud+Mysql+Redis+RabbitMQ 搭建。

Spring Cloud 作为一套完整的分布式系统，常作为解决各种问题的方案。它通过Zuul 组件实现服务网关，向外界提供RESTAPI、Eureka 实现服务注册和发现，再到Hystrix熔断机制阻止服务故障蔓延［16］。项目中每个独立的子模块均包含能独立运行和部署的基础模块。

（1）网关和服务注册。在系统使用过程中，管理负责人员在使用该管理系统查询某工地详情时，该详情可能包含该施工地环境信息、人员状况、设备情况等，但是这些数据由不同的微服务提供数据，由于本文采用的是微服务架构，所以无法按照传统单一型架构采用join 的方式对数据库进行数据查询，需引入API 网关。本文使用Spring⁃CloudZuul API 网关实现，Zuul 是一种可执行认证、动态路由、负载均衡的边缘服务。API 网关处理请求的方式是将Zuul 路由配置到合适的后端服务，例如根据工地详情请求可知，其后端服务彼此独立，调用各服务（设备信息、负责人信息、工地信息等）合并结果处理请求（见图6）。

将请求路由注册到Eureka 组件上，由Eureka 的Eu⁃rekaservice 组件实现服务的注册。每个服务在启动时会在Eureka service 中储存注册信息，然后周期性地向Eurekas⁃ervice 发送默认为30s 的心跳续约信息，同时Eurekaservice会以周期为60s 的间隔监测实销服务，若检测到失效服务，则Eurekaservice 会将失效服务从注册信息中进行默认90s的暂时移除操作，当在服务启动后，某一个模块出现故障时不会导致整个系统崩溃。Eureka 通过心跳检查机制保证整个安全管理系统高扩展性和灵活性。

Fig.6 Registration schematic for gateways and services图6 网关和服务注册原理

（2）熔断机制。在安全管理系统运行过程中，设备管理模块、人员信息管理模块，环境监测模块等各个服务相互依赖，以下简称A、B、C、D 模块。若在某一情况下，A 因为网路异常或负载较高的情况下导致响应变慢或发生异常时，由于一系列链式反应使B、C、D 状态也会转为异常，导致用户访问其它模块的线程得不到响应，则线程得不到释放，内存会一直被占用，如果该类情况过多，会耗尽资源。这时需引入Hystrix 组件熔断机制保证服务运行稳定性，如图7 所示。

Fig.7 Fuse图7 熔断器

Hystrix 组件是一个实现了断路模式的库，原理是通过隔离服务的访问点防止因为某点故障而导致整个系统崩溃。在特定情况下，系统多个使用者在短时间内大量访问某个API 接口，若次数超过设定的阈值时，即Hystrix Com⁃mand 请求后端服务出现错误的次数超过该阈值时，Hystrix组件提供的熔断功能会开启，进行服务降级策略，使用fall⁃back 返回默认值，告诉使用者该服务已不可用。在一段时间后，已经打开的熔断功能会变为半打开模式，并先处理一定量的请求，熔断器模块使系统具有更好的弹性。

（3）缓存数据库。在实际系统运行时，在项目初期数据录入过程中，项目管理访问量可能会高于其它功能，在项目检查阶段，安全检查功能会被监管方更加关注，若用户每次请求访问这些信息时，均从数据库里直接查询，则短时间内会消耗大量数据库请求。Redis 是一个高性能的key-value 数据库，能支持超过100K+每秒的读写频率，具有丰富的数据类型［17］，为了减轻数据库压力，本文使用re⁃dis 作为缓存框架，储存大量短时间内不会变化却又经常需要读取的数据，同时可提高用户响应速率。

（4）数据存储数据库。Mysql 作为当下最稳定的关系型数据库之一，特别是在Web 开发项目下广为使用［18］。在该项目中，考虑到每个模块本身需储存大量数据，在进行安全检查和提交安全日志一系列流程也将产生大量数据信息，系统需不断进行数据存储和更替，故采用稳定高效的Mysql 作为数据库系统。

（5）消息中间件。在系统安全检查过程中，实际作业项目复杂多样性，往往是多项检查并行，检察人员在新增安全检查时，将问题信息以表单的方式提交到数据库，传统方法是调用数据库接口写入或修改数据，但当并发量在短时间内很高时，数据库可能出现故障，将导致所有请求的数据失败，这时为保障系统稳定性，本文引用RabbitMQ作为消息队列协议的消息中间件，当用户请求数据时，将请求信息写入消息队列，并向用户反馈给予反馈信息。即便消息传递的某环节出现故障，消息也不会丢失。

（6）界面。PC 端展示界面主要通过jQueryMiniUI 实现前端页面展示。手机APP 采用APICloud 手机APP 框架，以前后端分离的方式开发，手机端与PC 端具有共享数据和功能，打包部署完成后可生成二维码供使用者下载。

（7）持久层设计。由于每个单独的业务模块均基于SpringBoot，所以采用SpringBoot JPA 作为持久化框架，SpringBoot JPA 提供的Repsitory 脱离了Dao 层操作，基本上所有crud 操作均可依赖它实现，减少数据访问层代码量。

（8）逻辑实现。用户从前端输入的数据，传入后台均为Json 格式，通过路由的方式匹配到对应控制层进行业务逻辑处理，控制层根据接收的数据调用相应服务层对数据进行业务逻辑判断处理，同时操作数据访问层根据具体业务对数据进行具体操作，最后逐层向上返回，同样以Json的格式给前端，将页面渲染数据展示给用户。

（9）部署。在传统项目部署过程中，需在每一台服务器上装载运行环境，如果项目运行的需求环境发生改变，则必须重新安装部署，若服务器数量巨大，这将是一项非常耗时的工作。本文采用Docker 容器部署技术，将所需的基础镜像与微服务生成的镜像部署在Docker 容器中［19］，让Docker Swarm 管理各项目运行的容器。综上所述，将微服务部署在Docker 容器中可以实现微服务的快速部署，方便管理和服务打包［20］。系统整体架构如图8 所示。

Fig.8 System architecture图8 系统架构

4 结语

本文结合当前行业内管理系统存在的问题，提出一种基于微服务架构的安全管理系统，并介绍了系统各模块组成和运用的技术。本文开发的基于微服务安全管理系统已在湖北省某政府项目上预运行，该架构相比之前的单体式架构，虽然在开发层面弥补了单体式应用的不足之处，使运行更加稳定，但仍存在一些不足，比如Http 请求耗时问题、微服务的多服务部署复杂性问题等，这些是下一步研究方向。同时，本文开发架构不具备行业普适性，在实际研发中，研究人员可参考本文微服务思想，根据实际行业背景选择合适的技术架构。