📚 课程目录第3章工程数字孪生平台总体架构设计

3. 工程数字孪生平台总体架构设计

工程数字孪生平台的总体架构不是把传感器、模型和页面简单堆在一起，而是要回答三个问题：数据从哪里来、模型在哪里算、服务如何被业务稳定调用。围绕这三个问题，工程上通常采用“五层纵向分层 + 云边端横向协同”的总体结构，再以微服务和事件驱动作为服务层与应用层之间的组织方式，最后用高可用与可扩展设计保证平台在真实工程中长期运行。

一、五层分层架构的设计方法

分层架构的核心价值是“职责单一、依赖单向”。工程数字孪生平台一般划分为感知层、数据层、模型层、服务层、应用层，上层依赖下层提供的能力，下层不反向依赖上层。

感知层负责把物理工程对象的状态变成可传输的数据。对象包括结构应力传感器、GNSS 位移监测点、温湿度计、摄像头、PLC 控制器、BIM 模型文件、施工进度台账等。设计要点是统一接入协议与统一时间基准：现场总线（Modbus、OPC UA）经边缘网关转换为 MQTT/HTTP，所有数据打上设备编号、测点编号、采集时间戳和质量码。例如某桥梁监测项目设定采样周期 1 s、上报周期 5 s，边缘侧先做滑动平均与阈值过滤，只把有效值上传，可显著降低带宽占用。

数据层解决“存得下、找得到、对得上”。典型做法是分类型存储：时序数据（测点读数）入时序库，如 InfluxDB 或 TDengine；结构化业务数据（构件、工序、人员）入关系库；BIM、点云、图纸等大文件入对象存储；实时流经消息队列 Kafka 缓冲。关键设计是建立统一编码体系，让“构件 ID—测点 ID—模型构件 ID”三者可互相映射，否则模型层无法把数据挂到正确位置。

模型层是数字孪生的核心，包含几何模型、机理模型和数据驱动模型。几何模型来自 BIM/GIS，负责空间定位与可视化；机理模型如有限元、温度场、水力学模型，负责物理规律推演；数据驱动模型如回归、LSTM，负责从历史数据中学习趋势。设计上建议采用“模型容器化 + 版本管理”，每个模型以镜像形式发布，输入输出用统一 JSON 契约描述，便于替换和回滚。

服务层把数据和模型能力封装成可复用接口，例如测点查询服务、模型计算服务、告警判定服务、三维场景服务。服务层不直接面向最终用户，而是面向应用层提供稳定 API。

应用层面向具体业务角色，如进度看板、安全预警、设备运维、能耗分析。应用层只调用服务层接口，不直接访问数据库，从而保证业务变化不影响底层数据与模型。

二、云边端协同架构

五层是逻辑划分，云边端是物理部署。端侧负责采集与执行，边侧负责就近处理，云侧负责全局汇聚与重算。协同的关键在于“任务分工”和“断网续传”。

以桥梁健康监测为例：端侧传感器每 1 s 采一次数据；边侧网关做 5 s 滑动平均、剔除跳变值，并运行轻量阈值模型，一旦超过预警值立即本地声光报警，同时把原始值和特征值上传；云侧接收后运行有限元模型做整体受力反演，并把结果写回模型层。若现场网络中断，边侧将数据写入本地环形缓存（例如保留 72 h），网络恢复后按时间戳顺序补传，云侧按时间戳去重合并，保证时序连续。

分工原则可以概括为：实时性要求高、数据量大、隐私敏感的任务下沉到边侧；需要全局数据、算力密集、跨项目对比的任务上移到云侧。边侧不做长期存储，云侧不做毫秒级控制，二者通过消息队列解耦。

三、微服务与事件驱动架构选型

服务层采用微服务架构，把测点查询、模型计算、告警判定、场景服务拆成独立部署单元，各自独立扩缩容。例如模型计算服务在汛期调用量激增，可单独扩容到 8 个实例，而不影响测点查询服务。

但微服务之间如果全部用同步 HTTP 调用，会出现“告警判定等模型计算、模型计算等数据写入”的链式阻塞。因此引入事件驱动：数据层写入新测点数据后，向 Kafka 发布 sensor.data.updated 事件；告警判定服务订阅该事件并异步判定；模型计算服务也订阅同一事件触发反演。这样生产者与消费者解耦，新增一个“能耗分析”消费者不需要改动任何已有服务。

# 事件契约示例（JSON）
{
  "event": "sensor.data.updated",
  "deviceId": "BR-001",
  "pointId": "STRAIN-023",
  "value": 128.6,
  "unit": "MPa",
  "timestamp": "2025-03-18T09:12:05+08:00",
  "quality": "good"
}

选型建议：查询类、强一致类接口用同步微服务；状态变化通知、模型触发、告警联动用事件驱动。两者不是二选一，而是同一平台内并存。

四、高可用与可扩展性设计

高可用的目标是“单点故障不导致平台不可用”。工程上通常从四个层面落实：

接入高可用：边缘网关双机热备，MQTT Broker 集群部署，端侧配置两个 Broker 地址，主节点失联自动切换。
数据高可用：时序库采用多副本（如 3 副本），Kafka 分区副本数设为 2 以上，对象存储开启跨可用区冗余。
服务高可用：微服务多实例部署，前置负载均衡与健康检查，实例异常自动摘除；关键服务设置熔断与降级，例如模型计算超时时返回上一次有效结果并标注“缓存值”。
模型高可用：模型镜像多副本，计算任务失败自动重试，重试仍失败则进入死信队列并告警。

可扩展性分为纵向与横向。纵向扩展是提升单机配置，成本高且有上限；横向扩展是增加实例或分区。设计时应优先保证横向扩展能力：服务无状态化，会话与缓存外置到 Redis；数据按项目或时间分区，便于增加节点；事件主题按业务域拆分，避免单一主题成为瓶颈。

判断平台是否具备可扩展性的一个实用检查：新增一类传感器或新增一个业务应用时，是否需要修改已有服务的代码？如果不需要，只增加配置和消费者，说明解耦到位。

综合来看，工程数字孪生平台的总体架构可以概括为：五层分层定职责，云边端协同定部署，微服务与事件驱动定交互，高可用与可扩展定运行底线。四者共同支撑平台从“能看”走向“能算、能预警、能长期稳定运行”。