李 涛，朱自强，鲁光银，白冬鑫

(1.中南大学地球科学与信息物理学院，湖南 长沙 410083;2.湖南省有色资源与地质灾害勘查重点实验室，湖南 长沙 410083;3.中南大学，有色金属成矿预测与地质环境监测教育部重点实验室，湖南 长沙 410083)

1 介 绍

桥梁是交通设施中重要的组成部分，需要充分保证其安全。据2019年6月统计结果显示，中国已建成运行的公路桥梁超过80万座，铁路桥梁超过20万座，是世界上桥梁最多的国家之一。而其中有超过10万座的病桥、危桥，因此需要对运营的桥梁进行定期的安全评价。

目前对桥梁进行安全评价的常用手段为桥梁检测，主要包括无损检测和荷载试验两种。无损检测整体花费较少但效果较差；桥梁荷载试验效果较好但是花费巨大，同时需要在封闭交通的情况下才能进行。无论哪种检测方式都具有检测频率低，不能实时性的提供数据的缺点，而桥梁健康监测系统作为实时监测工具，能够全天候监测桥梁运营状况，分析桥梁运营状态下结构响应，对问题桥梁进行及时的安全预警，同时提供丰富的数据依据。因此对桥梁建立健康监测系统是一种经济有效的保障桥梁运营安全的方式。

在过去的几十年，不同的学者在桥梁健康监测的技术难点和研究热点上开展了大量的研究，主要集中于决策设计、传感器、信号处理、模态识别、状态评估等方面，取得了大量的研究成果。而在监测系统架构领域研究的比较少。目前大多数桥梁健康监测系统主要通过B/S(浏览器/服务端)和C/S(客户机/服务器)模式实现主要的访问功能，而无论哪种模式，后端服务始终是web程序的核心，因此对服务器体系结构的研究应该获得更多的关注。

目前来说，相关的研究总体上经历了三层架构、面向服务架构以及微服务架构的发展过程。早期的三层架构基于面向对象(OOP)设计，主要包括应用层、数据访问层以及业务逻辑层.系统通过数据访问层与数据库连接，而相关的业务逻辑封装一个包内构成业务逻辑层，实现系统的主要功能.控制器是一个特殊的类，通过“控制器”可以实现数据的前后端交互。这种架构最大特点就是简单，适合业务量小，逻辑简单，对性能要求低的web应用程序，但是随着业务量的增多，它的弊端就渐渐显露，这主要体现在三个方面：一是响应缓慢，该架构将整个服务放在同一个内存空间，无法实现分布式部署，而单台机器的处理能力有限，当业务量增大到这个极限时，服务器响应就会变慢，用户体验就会急剧下降；二是维护难度大，业务量增加往往伴随着编码复杂度增加，相应的代码膨胀问题以及兼容性问题会增大后期的维护成本。三是系统容错性差，某个模块出现问题可能会导致整个系统宕机。

为了解决三层架构的瓶颈问题，提出了基于面向服务理念的框架(SOA)，这种架构要求开发者从服务集成的角度出发，考虑复用现有的服务。SOA架构将整个web应用拆成一个一个的业务单元(称之为服务)每个服务可以基于不同的技术栈、编程语言开发，各个服务之间通过统一的接口或者协议进行通信，以Restful API和Json协议为代表。这种架构可以降低系统的耦合性，每个服务部署在不同的服务器上，便于实现分布式集群部署，解决单台服务器瓶颈问题。但是SOA架构同样也存在一定的缺陷，首先耦合度越低，系统开发难度越大，同时维护成本也相应增加。其次就是整个系统的性能受到各个服务之间数据通信效率的影响。最后一个常见的问题是一旦某个服务宕机，可能会拖累整个系统的性能。

目前，大多数的桥梁健康监测系统都基于三层架构，也有一部分是基于SOA架构的，当监测的桥梁数量少，监测时间较短时能够满足监测预警需求，但是当桥梁监测数量以及接收的数据量快速增大的时候，系统整体的性能就会受到挑战，出现响应不及时等问题，因此就需要一个更加健壮和灵活的系统。

采用微服务架构设计开发的桥梁健康监测系统，将功能拆分成多个微服务，实现了分布式存储和分布式部署，各个服务实例通过注册中心将各个分布式微服务连接起来，采用轮询策略实现负载均衡，应用实例表明采用微服务架构的桥梁监测系统提供了海量数据的处理能力，分散了计算和服务压力，有效的解决了分布式系统单点故障和模块兼容性问题，提高了系统的稳定性和可扩展性。

2 监测系统设计

桥梁健康监测系统层次架构，主要包含四个部分：感知层、数据层、服务层和应用层。感知层由现场的各种监测传感器、采集仪、传输设备、供电系统和保护装置组成；数据层由分布式数据库、数据接收与解析服务构成；服务层是采用微服务架构搭建的管理与分析系统，主要实现对数据、用户、项目和设备的管理，同时在此基础上还实现数据的处理、预警、和评估等功能；应用层由web端应用构成。

2.1 感知层

感知层主要负责实时采集桥梁监测的各类数据并传输到数据层，当某座桥梁需要建立健康监测系统后首先要制定监测方案，在桥梁有限元分析结果的基础上，结合大桥的静、动力计算结果、确定监测参数、测点数量、布置位置以及设备选型。并在此基础上也会根据经验、成本以及现场实际情况进行调整，力争以最少的传感器获取最完整的监测数据。传感器通过有线或者无线与采集仪进行相连，采集仪是整个感知层的核心，向下可实现对传感器采样间隔的控制，当监测数据不良好的时候，缩短采样周期和增大采样频率，向上可通过其内置的DTU和现场的网络将数据发送到数据层。通常整个现场使用生活用电作为供电源，对于现场条件恶劣的桥使用太阳能、风能和蓄电池组合提供。

2.2 数据层

对于感知层发来的数据包，首先通过数据解析服务进行接收和解析，该服务是一个利用c#语言编写的微服务，可单独进行部署，当监测的桥梁数目增多、采集频率加快时，该服务承接的数据压力增大，很容易造成拥挤和过载，因此该部分采用多个实例服务器分散压力。数据解析完成以后不仅仅要存入数据库，还要转发给其他服务进行下一步处理或者进行实时数据分析，因此用消息队列Rabbit MQ进行消息的发布，不同的服务只要订阅消息队列就能够实时获得采集的数据，从而进行下一步操作。为了防止消息队列拥堵或者网络中断等原因造成的数据丢失，采用Redis进行缓存。

2.3 服务层

根据实际项目的需求，本系统共设计开发了7个微服务：数据解析、数据管理、用户管理、桥梁项目管理、数据分析、预警预报和安全评估。相关部署见表1，其中数据解析、数据管理、数据分析和预警由于承担大量的读写压力和并发访问，因此采用多实例分布式部署。数据解析服务主要进行数据的解析以及推送；数据管理服务主要负责数据的增删改查操作，基于SpringBoot框架编写；数据分析服务主要提供数据的分析算法，例如对异常值的识别(肖维纳准则、拉依达准则、四分位法)、数据去噪声(小波、EMD、SVM等)、回归(多项式回归、贝叶斯回归)以及预测(灰色模型)等算法，由于算法编写难度较大，因此该部分采用python及其开源算法包从而降低开发难度；预警主要分为两部分，一部分是对实时接收的数据进行计算，如果满足预警条件则发送通知，另一部分是对过往的数据进行周期性分析，产生周期报告，同时根据之前的大量数据去修正有限元模型，使它更符合实际桥梁状况，从而使阈值更准确；用户管理以及项目管理所承担的压力较小，访问频率不高，因此部署在一台服务器上足以满足实际需求。

表1 系统服务部署情况

每个微服务都有自己的网关，实现路由转发以及充当一个过滤器的功能。路由转发是指接收外界请求，转发到后端的微服务上去，而过滤器则是在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等。服务与服务之间需要彼此相互发现，这种机制称为服务发现机制，通过注册中心来实现，本系统的注册中心为consul。注册中心可抽象为一张注册表，每个服务启动后会向注册中心发送自己的IP和端口号，然后每隔一段时间刷新注册中心，保证注册中心知道每个注册服务的运行状态。一个来自终端的请求，首先会先到达通过Nginx搭建的负载均衡，然后采用轮训策略发送到注册中心的注册执行单元上，执行单元执行之后返回响应，通过这种方式可以将请求进行分摊，能够有效降低服务器压力，同时又有很好的容错性。

2.4 应用层

应用层为用户提供一个交互的终端，本系统的终端为web应用，基于浏览器提供UI与云服务器进行交互，利用VUE前端框架搭配webpack4.0项目构建工具进行开发。VUE是一套用于构建用户界面的渐进式框架，它的核心库只关注视图层，不仅便于与第三方库或既有项目整合，而且当与现代化的工具链以及各种支持类库结合使用时，VUE也完全能够为复杂的单页应用提供驱动。数据可视化方面采用echarts.js进行开发，针对不同类型的数据选取最直观合理的展示方式，部分系统页面如图1所示。

图1 系统部分应用图

2.5 性能测试

为了保障系统在线上环境中稳定运行，需要对系统进行性能测试。常用来考察系统性能的指标有系统吞吐量和响应时间。在本研究中，采用Apache JMeter压力测试工具对三种架构的桥梁健康监测系统进行测试。选取一个查询数据的API接口进行测试，改变线程组的数量为100、200、300、400、500、800、900、1 000、1 400、1 800、2 000、2 400、3 000、3 500，分别对三种架构系统进行测试，查看吞吐量以及响应时间。

3 结 果

3.1 性能分析

图2(a)是吞吐量曲线图，可以看出三种架构的系统随着并发数的增加，吞吐量都在增大，并且都遵循先快速增长然后缓慢增长到饱和状态后在快速下降的趋势。相同并发数情况下，微服务架构的吞吐量最大，其次是SOA，最后是三层架构。同时在支持的并发数方面，微服务架构支持更高的并发数，其次是SOA，最后是三层架构。图2(b)是平均响应时间曲线，在并发数很小的情况下，三种架构的响应时间差距很小，随着并发的增大差距也增大，三层架构高于SOA，SOA高于微服务架构。

图2 JMeter性能测试

综合吞吐量曲线和响应时间曲线，在相同并发情况下微服务架构的吞吐量更高，响应时间更快，然后是SOA，最后是三层架构。因此在性能方面，微服务架构系统的性能更好。

3.2 赤石特大桥概况

赤石特大桥位于湖南省郴州市宜章县赤石镇下欧村、渔溪村之间的河流阶地及河漫滩上，大桥横跨青头江河道，是一座四塔预应力混凝土斜拉桥，于2019年6月布设相关监测传感器并接入基于微服务架构研发的系统。

3.3 监测方案

考虑到桥梁类型、现场情况和成本控制，该桥的监测参数类型主要为环境激励，应力应变以及振动和索力，详细设备选型见表2。

表2 固定传感器布设一览表

3.4 监测结果

本系统完成布设和调试后于2019年4月1日正式投入使用，截止到2021年12月1日共产生54 329条数据，其中应力应变数据17 076条，索力数据20 068条，挠度数据与倾角数据共15 074条，其他监测类型数据2 111条。本文中选取2019年6月12到7月14的部分传感器数据进行分析，选取CH-S2截面中的梁端位移两测点以及CH-S4中的两个对称索力测点、一个挠度测点和8个应力测点数据进行分析，数据曲线见图3，对应测点阈值见表3。

表3 监测点阈值表

图3 应用实例图

图3中(a)是梁端位移曲线图(CS-BD1，CS-BD2)，剔除由于载荷变化或者环境变化引起的数据波动，选取稳定段数据进行观察分析，梁端位移数据波动较小，均在合理范围内，低于该测点的预警值，同时对称位置传感器数据一致性良好；(b)是索力数据图(CS-CG1，CS-CG2)，索力值分布较为正常，上下游对称位置的索力差别不大，大桥斜拉索受力状态正常；(c)是挠度数据曲线图(CS-PT1)，剔除外在环境引起的明显数据毛刺变化，数据整体波动范围正常，呈现较好的波动规律性；(d)是同一截面内的应力数据(CS-SG-4)，桥梁同一截面相近应力测点数据波动规律一致性较好，且波动幅值在允许范围内。

4 结 论

微服务架构是对传统单体架构以及SOA的一个升级，它具有小、独、轻、松四个要素，性能稳健，可扩展性强，能够满足日益增长的业务需求。采用微服务架构开发桥梁健康监测系统，并将各个服务进行多实例部署，不仅分散了服务压力，同时由于微服务架构的自身特点降低了开发难度以及提升了系统的计算能力。在性能方面，通过测试三种不同架构系统的性能实验发现，微服务架构具有更高的吞吐量、支撑更多并发用户数以及拥有更小的响应时间。同时通过实际案例表明微服务的架构健康监测系统可以容纳更多的传感器和更快的计算速度。