system: [SYSTEM]

user: 4. 系统设计与实现 4.1. 系统总体架构设计 根据系统的实际需要以及甲方的要求，本系统采用如图3所示的总体架构设计。整个系统采用微服务化的特点 [ 7 ]，包括数据的采集，数据的存储，数据的分析处理，后台服务以及人机交互模块构成。 数据可以分为数据采集器自动采集的数据以及目前为止无法自动采集需要手动测量的数据，对于采集器自动采集的数据，通过http协议发送到服务器，对于目前无法自动化采集的数据，本系统提供一个接口，目前通过前端输入到服务器。 从高可用考虑，防止后台服务器的负载过大，出现单点问题，采用服务器集群来提高系统的可用性，同时采用Nginx服务器做负载均衡，进行反向代理，无论是深基坑工程本地服务器的数据传输请求，还是人机交互客户端终端的数据查询请求，都经过Nginx反向代理服务器，将请求均衡地分给后端服务器处理。 为了满足实时性的要求，采用Redis数据库做缓存，提高数据的实时显示，同时为了保证可靠的实时性，防止出现单个Redis服务器崩了，实时性就得不到保证，我们采用Redis的Cluster模式集群Redis数据库，提高Redis的可用性以及整个系统的实时性。 图3. 系统总体架构设计图 4.2. 系统主要功能模块的设计与实现 4.2.1 . 数据采集模块 根据需求以及《GB50497-2009建筑基坑工程监测技术规范》中对建筑基坑工程仪器监测项目的规定 [ 8 ]，基坑现场应测项目有：围护墙(边坡)顶部水平位移，围护墙(边坡)顶部竖向位移，深层水平位移，立柱竖向位移，支撑内力，锚杆内力，地下水位，周边地表竖向位移，周边建筑相关参数等。有些位移，内力，水位都可以通过斜侧仪，水准仪，水位计，测力计等进行采集测量，根据目前物联网的发展状况 [ 9 ]，我们可以对深层水平位移，地下水位，锚杆内力，支撑内力利用自动化装置进行自动测量，但是对于周边建筑的沉降，围护墙顶部水平位移等目前无法通过装置进行自动测量，通过人工进行观测。 如下图4所示，本系统对于这两种数据的采集配套两种接口，自动采集接口和手动上传接口。自动采集接口可以利用自动化装置直接通过http协议发送到后端服务器，后端服务器对数据的类型和数值进行解析获取；手动上传接口则在前端页面提供上传页面，监测人员可以将自己采集到的数据通过指定格式的文件进行上传，后端服务器解析文件，获取监测数据。随着科技的发展，有些数据会逐渐可以通过自动化装置进行采集，此时本系统也预留了自动采集的接口，自动化装置只需要按照指定的数据格式进行发送数据，即可集成到该系统中。 图4. 数据采集模块设计图 4.2.2 . 存储模块 本系统对于采集器的数据需要进行存储，一方面为了留档，另一方面为了能够在页面进行图表显示，供相关人员进行查看。本系统将监测数据直接发送到后端服务器，在数据库中进行存储，存储方案如下： 常规数据的持久化可以采用MySQL数据库。原因有三个：第一从成本上考虑，MySQL是免费的。第二从项目本身考虑，数据量比较大，并发性比较高，MySQL支持事务的操作，同时对高并发的读写也提供了很好的支持。第三从系统可用性考虑，MySQL可以做主从配置，主服务器进行写操作，从服务器进行读操作，可以加快数据的查询效率，同时也可以做多个主从的MySQL服务器集群，提高系统的可用性。 本系统使用Mybatis以及相关的组件整合MySql，对常规数据进行增删改查的操作。其中常规数据模型主要有三个，表1所示的地下水位记录信息，表2所示的深层水平位移记录信息，以及表3所示的支撑应力记录信息。 Table 1 Groundwater level record information table data mode 名称 类型 长度 PK 备注 id int 11 primary key 主键 section varchar 24 no 工程标段 pointId int 11 no 测量点序号 date date default no 测量时间 groundwater double (16， 2) no 地下水位(mm) 表1. 地下水位记录信息表数据模型 Table 2 Deep horizontal displacement record information table data mode 名称 类型 长度 PK 备注 id int 11 primary key 主键 section varchar 24 no 工程标段 pointed int 11 no 测量点序号 depth int 11 no 测量深度(m) date date default no 测量时间 displacement double (16， 2) no 水平位移(mm) 表2. 深层水平位移记录信息表数据模型 Table 3 Support stress record information table data mode 名称 类型 长度 PK 备注 id int 11 primary key 主键 section varchar 24 no 工程标段 pointed int 11 no 测量点序号 date date default no 测量时间 stress int 11 no 力的大小(N) 表3. 支撑应力记录信息表数据模型 数据的缓存存储可以采用Redis数据库。原因有以下几点：第一从系统的响应速度考虑，数据如果都要从MySQL中读取显示，那相应速度就降低了，Redis是内存型数据库，访问速度远远高于数据库的磁盘操作，所以可以用Redis来提高系统的响应性。第二从容灾性考虑，一般的缓存没有持久化的操作，一旦崩了就不能恢复，而Redis不仅支持持久化操作，和MySQL一样，还支持集群模式，可以提高缓存服务器的容灾性。 4.2.3 . 预测报警模块 在《GB50497-2009建筑基坑工程监测技术规范》中，每一个监测项目都有预警值 [ 8 ]。本系统对每个监测项目都有一个实际的监测值，如果监测值达到了预警值，系统进行报警。另外本系统基于灰色系统理论，对监测项目(周围建筑物沉降量)做预测分析，如果预测值达到了预警值，同样给出报警，及时通过短信以及邮件的方式通知相关的人员。 查看周边建筑物的沉降的监测数据可以发现，沉降量随着时间有一定的规律性，本系统利用上述改进的灰色系统理论对其进行预测，灰色系统理论建立在对监测数据建模的基础上，所要求的数据量不是很大，要求观测数据量只需要大于4，就可以建立灰色模型GM。灰色模型预测所需要的数据量比较小，便于系统的数据处理，数据样本可随机分布，所需要的数据处理复杂度较低，简单实用，同时精度和准确度都比较高，对于本系统具有很好的适应性。因此基于灰色系统理论，本系统对周边建筑物的沉降提供了预测分析 [ 10 ] [ 11 ]。 如图5所示，本系统的预测报警模块分为如下几个重要组成部分：预测分析接口，预测算法，以及报警方式。 图5. 预测报警模块设计图 灰色模型预测关键代码如下： 同时本系统提供了预测分析接口，目前只对周围建筑物沉降量做了预测分析，后续的系统改进中，如果需要对别的监测项目进行预测，同样适用，只需要给定输入的序列，规范中该检测项目的预警值即可；对于预测算法，本系统也采用了插拔式的设计，目前基于灰色系统预测做了实现，后续的系统如果需要用到别的预测算法，也可以集成到本系统中，只需要对输入输出数据的序列进行特定的处理即可；对于报警方式，本系统利用简单有效的邮件和短信的方式进行了实现。 4.2.4 . Web服务模块 如图6所示，本系统Web服务模块主要包括负载均衡服务器，Web应用服务器，Mysql数据库，Redis内存数据库和人机交互客户端。其中负载均衡服务器采用Nginx，内部采用原地址哈希的负载均衡算法进行分发不同的请求，保证在高并发的情况下，同一个客户端的多次请求能够始终被发送给同一台应用服务器进行处理；应用服务器采用的是Tomcat，主要实现的是用户的注册登录，权限管理，数据的分析处理，同时将预测模块集成在其中，进行预测分析，必要的时候做出警报发送短信和邮件；数据库采用的是MySql + Redis的组合，对于常规数据，我们将其存放到数据库中，进行持久化存储，对于客户端经常访问的数据，我们将其放在Redis中，提高响应的速度，同时采用Redis自带的LRU策略进行缓存的更新，保证Redis中缓存的数据都是最新的数据；客户端包括人机交互的浏览器以及现场的数据采集器设备客户端，对于现场的数据采集设备，通过发送HTTP请求到Nginx服务器，Nginx服务器将现场的数据分发到不同的后台服务器进行分析处理，并入库；对于浏览器，联网的机器只需要登录指定网址，即可访问本系统，用户可以通过浏览器查看实时数据曲线，查询历史的数据曲线图，上传手工测量的数据的文件，以及直接在页面获取报警的信号。 图6. Web服务器模块设计图