智慧商砼解决方案技术架构：从数据采集到平台部署的完整设计

智慧商砼解决方案技术架构技术架构总览

整体分层设计

一套可落地的商砼数字化系统，通常划分为设备层、数据层、平台层、应用层和运维层。

设备层连接搅拌主机、地磅、砂石含水率传感器、车辆GPS、摄像头及实验室检测设备。

数据层负责采集、清洗、存储和管理生产数据，为质量追溯、成本分析提供统一数据基础。

平台层承载订单、调度、生产、运输、质检、结算等服务，并处理系统之间的数据交换。

应用层面向调度员、实验员、生产经理、财务人员、客户和司机，提供不同业务入口。

运维层负责部署、监控、日志、安全、备份和故障恢复，保障系统能够连续稳定运行。

架构图的核心链路

典型数据链路是“设备采集—边缘网关—消息平台—业务服务—数据中心—应用终端”。

搅拌站设备可通过PLC或工业网关采集数据，再经MQTT、OPC UA等协议上传平台。

订单进入系统后，平台生成生产任务，并将配方、方量和强度等级发送至生产控制系统。

车辆装料完成后，调度服务结合工地位置、道路距离和车辆状态，自动生成配送计划。

签收、退料、质检和结算数据回传平台，形成一车一码、一盘一档的业务闭环。

技术选型理念

技术选型不看名词多不多，而要看设备能否接入、系统能否扩容、数据能否追溯。

核心业务建议采用成熟的Java或.NET技术栈，边缘采集可使用C++、Go或轻量化Python服务。

数据库、消息队列和容器平台应优先选择团队能维护、有商业支持或社区活跃的产品。

企业还要提前回答三个问题：并发有多大、数据保留几年、停机一小时损失多少钱。

这些数字决定服务器规模、容灾等级和授权模式，也决定项目预算是否合理。

智慧商砼解决方案技术架构数据层架构

数据采集方案

商砼数据来源复杂，既有订单和合同，也有PLC信号、车辆轨迹、视频及检测报告。

生产设备接入可采用OPC UA、Modbus TCP、串口或厂商私有协议。

老旧设备不宜直接改控制程序，可增加工业网关，读取关键点位并进行协议转换。

网关需要缓存生产盘次、称量值、投料时间和设备状态，断网时至少保存24小时数据。

网络恢复后，网关按时间顺序补传，并通过唯一流水号避免同一盘数据重复入库。

车辆定位建议按10秒至30秒上报一次，进入工地或搅拌站电子围栏时立即触发事件。

含水率、温度和料位数据应附带设备编号、采集时间、单位及质量标识。

人工录入数据要记录操作人、修改前值、修改后值和修改原因，不能只保存最终结果。

关键点位可设置合理范围。例如含水率超过阈值时，平台要求复核后再参与配方修正。

数据存储设计

交易类数据适合存入MySQL、PostgreSQL或SQL Server，包括订单、合同和结算记录。

车辆轨迹、设备指标等时序数据，可使用TimescaleDB、InfluxDB或其他时序数据库。

配方单、质检报告、签收图片及电子小票，可保存到S3兼容对象存储。

Redis用于保存车辆在线状态、待执行任务和高频查询结果，但不能替代业务数据库。

数据库表需要统一企业、站点、生产线、车辆和设备编码，避免跨站汇总时无法关联。

生产盘次建议建立不可变更的业务主键，将订单、任务单、车辆、配方和检测结果串联。

对报表查询量较大的项目，可建立分析库，将历史数据通过CDC同步到ClickHouse等系统。

生产交易库与分析库分开后，大屏查询不会占用开单、调度和生产指令的数据库资源。

数据保留周期要写入方案。在线数据可保留1至2年，历史数据按月归档5年以上。

数据治理策略

数据治理重点不是补录报表，而是建立统一编码、质量规则和责任归属。

主数据应覆盖客户、工地、合同、配方、原材料、供应商、车辆、司机和设备。

平台可按完整率、及时率、准确率生成数据质量分数，并定位异常来源。

配方修改、称量修正和质检结果变更必须保留版本，满足质量事故追溯要求。

数据接口还要定义字段类型、单位、精度和时区，防止吨与千克、分钟与秒混用。

智慧商砼解决方案技术架构平台层架构

微服务架构设计

平台服务可按业务边界拆分，而不是按页面数量拆分。

常见服务包括用户中心、客户合同、订单、智能调度、生产执行和车辆运输。

还可设置配方、原材料、实验室、设备管理、电子签收、对账结算和消息通知服务。

服务之间通过REST、gRPC或事件消息通信，禁止多个服务随意修改同一张数据库表。

订单服务负责订单状态，生产服务负责盘次记录，调度服务负责车辆与任务匹配。

每个服务拥有明确的数据边界后，单个模块升级不会迫使整个平台同步停机。

企业早期只有一个站点时，可以采用模块化单体，减少服务器和运维投入。

站点增加到10个以上，或日订单达到数千单时，再拆分高并发服务更合适。

不是服务拆得越细越好。服务过多会提高链路排查、部署和数据一致性成本。

跨服务业务可使用状态机、事务消息和补偿机制，避免依赖复杂的分布式强事务。

消息中间件选型

设备数据和业务事件需要解耦，消息中间件可选Kafka、RabbitMQ或RocketMQ。

Kafka适合轨迹、设备指标和日志等高吞吐场景，便于进入实时分析链路。

RabbitMQ适合指令下发、状态通知等路由规则较复杂的业务。

RocketMQ适合订单、生产任务和结算事件，可使用顺序消息及延迟消息。

选型时要评估每秒消息量、消息大小、顺序要求、保存时间和团队维护能力。

所有消费端都要实现幂等处理，并设置重试队列和死信队列。

生产指令不能无限重试。超过次数后应进入人工处置，并记录失败原因。

缓存与性能优化

高频访问的车辆状态、站点产能、配方摘要和字典数据，可以放入Redis。

缓存键应带企业和站点维度，避免多租户场景发生数据串读。

热点数据可设置5分钟至30分钟有效期，实时状态则由设备事件主动刷新。

订单列表和生产报表应采用分页查询，不允许一次读取数十万条明细。

轨迹查询可按车辆和日期分区，生产记录可按站点、月份或生产线分表。

接口层应配置超时、限流和熔断。例如地图服务超时后，仍允许人工完成派车。

大屏指标可每10秒或30秒刷新，没有必要对所有指标进行毫秒级计算。

正式上线前要进行压力测试，至少覆盖开单高峰、集中发车和月末对账场景。

测试结果应明确每秒请求数、95分位响应时间和数据库连接池占用率。

智慧商砼解决方案技术架构应用层架构

前端技术方案

管理端可使用Vue或React，适配办公室电脑、调度大屏和平板设备。

司机端适合微信小程序或Android应用，用于接单、导航、排队和电子签收。

工地端可通过小程序查询车辆位置、预计到达时间、方量及质量证明文件。

生产现场页面需要减少复杂动画，保证工控机配置较低时也能正常使用。

离线场景下，司机端应缓存任务和签收记录，网络恢复后自动补传。

大屏不是项目核心，关键是异常能否直接定位到订单、车辆、盘次和责任人。

前端还应统一时间、方量、强度等级和车辆状态的展示规则。

API设计规范

接口建议采用RESTful规范，并通过HTTPS提供服务。

URL需要包含版本，例如“/api/v1/orders”，为后续升级保留兼容空间。

每个请求应携带租户、用户和追踪标识，便于跨服务查询完整调用链。

响应结构要统一错误码、错误信息和数据对象，不能只返回“操作失败”。

新增订单、下发生产任务等接口应支持幂等键，防止重复点击生成两条记录。

对外接口需要通过API网关管理，配置身份验证、签名、限流和访问日志。

涉及ERP、财务或监管平台时，还应明确字段映射、重试规则和对账机制。

接口文档可使用OpenAPI维护，并提供测试环境与脱敏样例数据。

权限与安全机制

权限体系建议采用RBAC模型，按角色分配菜单、按钮、接口和数据范围。

集团人员可查看多个站点，站点经理只能查看授权区域，司机只能看到本人任务。

配方、价格、合同和结算数据属于敏感信息，应配置字段级权限。

密码、令牌和数据库凭据不得写入代码，应交由密钥管理系统保存。

传输链路使用TLS，重要字段可采用国密算法或AES进行存储加密。

平台还要防范SQL注入、越权访问、接口重放和批量导出造成的数据泄露。

智慧商砼解决方案技术架构部署架构与运维

部署方案选择

部署怎么做，要看企业站点数量、网络条件、合规要求和现有IT能力。

单站企业可采用本地服务器加云端备份，保障断网时生产系统仍可运行。

多站集团适合中心云部署，在站点配置边缘网关，集中管理订单和经营数据。

对数据不出厂有要求的企业，可采用私有云或超融合平台。

应用服务建议使用Docker容器部署，规模较大时由Kubernetes进行编排。

生产环境、测试环境和开发环境必须隔离，数据库也不能共用同一实例。

预算多少钱不能只算服务器，还要计入数据库授权、网络专线和安全设备。

运维人员、备份空间、地图接口、短信服务和三至五年升级费用也要纳入预算。

监控与日志体系

基础监控需要覆盖CPU、内存、磁盘、网络、容器和数据库连接数。

应用监控要统计接口成功率、响应时间、消息积压量和任务失败数量。

Prometheus可采集指标，Grafana用于展示，Alertmanager负责告警分发。

日志可通过ELK或Loki集中管理，按企业、站点、服务和追踪标识检索。

核心链路应接入分布式追踪，快速判断问题发生在网关、服务还是数据库。

告警必须分级。生产指令失败属于高等级告警，普通报表延迟可降低等级。

告警通知可发送到短信、电话或企业微信，并建立确认与关闭流程。

每月应复盘重复告警，处理根因，避免运维人员长期被无效信息干扰。

容灾与备份策略

数据库可采用主从复制或高可用集群，应用服务至少部署两个实例。

同一机房的双机不等于容灾，关键数据还要复制到不同故障域。

备份策略可采用每日增量、每周全量，并将副本保存到异地对象存储。

备份文件必须加密，下载和恢复操作需要审批并记录审计信息。

恢复目标要量化。核心生产数据可设置RPO不超过5分钟，RTO不超过30分钟。

普通分析数据可放宽恢复要求，以控制硬件和云资源成本。

每季度至少执行一次恢复演练，验证数据库、附件和配置文件能否完整恢复。

采购验收时应要求供应商现场演示故障切换，而不是只提交一份容灾文档。

真正可用的架构，要在设备断线、服务器故障和网络中断时仍保住核心生产链路。