博客

面向工业企业的电子台账系统技术架构设计指南

电子台账系统技术架构技术架构总览

整体架构图怎么划分

系统可按接入层、数据层、平台层、应用层和基础设施层划分。

各层通过标准接口连接，避免设备协议、业务逻辑和数据库直接耦合。

接入层负责连接PLC、传感器、仪表、MES、ERP及人工填报终端。

数据层承担实时数据、业务数据、文件资料和历史归档数据的管理。

平台层提供台账服务、流程引擎、规则计算、消息通知和审计能力。

应用层面向设备、生产、安全、能源、质量及环保等业务场景。

基础设施层包含计算、网络、存储、容器平台和运维安全组件。

建议在方案图中标明数据流、控制流及接口方向，方便评估系统边界。

各层职责怎么界定

设备接入不应直接写业务表，而应经网关、消息队列或采集服务进入平台。

业务服务只处理规则和流程，不承担协议解析、报文清洗等底层工作。

报表服务与交易服务需要分开，防止复杂统计查询拖慢日常台账操作。

文件、图片和视频不宜保存到关系数据库，可使用对象存储保存原始内容。

统一身份认证、授权和审计应作为公共能力，不能由每个应用重复建设。

这种分层方式便于替换组件，也能缩小单个模块升级带来的影响范围。

技术选型遵循哪些原则

技术选型需要看并发量、设备数量、数据频率和保留年限，不能只看品牌。

例如，200台设备每秒上传一次，与2万台设备每秒上传10次差异很大。

核心组件应优先选择有长期维护版本、成熟驱动和稳定社区支持的产品。

平台应支持横向扩容，新增节点后可提升接入、计算或查询能力。

接口要采用开放标准，减少对某一家数据库、云平台或硬件厂商的依赖。

采购阶段还应核算许可证、服务器、实施、迁移和5年运维成本。

架构评审的核心不是用了多少新技术，而是故障时能否隔离和恢复。

电子台账系统技术架构数据层架构

数据采集方案

工业现场常见协议包括Modbus TCP、OPC UA、MQTT、Profinet和串口协议。

边缘网关负责协议转换、点位映射、时间校准、断线缓存和数据压缩。

设备网络与办公网络应分区部署，通过工业防火墙控制访问方向和端口。

采集点需配置设备编码、点位编码、单位、精度、采样周期和质量标记。

网络中断时，网关应将数据写入本地队列，恢复连接后按时间顺序补传。

补传报文必须带唯一标识，服务端据此去重，避免同一记录重复入账。

人工台账可通过Web、移动端或扫码终端录入，并配置必填项和范围校验。

来自MES、ERP等系统的数据，可通过REST API、数据库CDC或文件交换接入。

采集时间、设备时间和入库时间要分别保存，便于定位延迟问题。

高频数据可在边缘侧进行聚合，例如将毫秒级数据计算为秒级统计值。

涉及质量追溯的数据不能只保留平均值，还要按法规保存原始记录。

数据存储设计

设备、人员、组织、点位和台账模板适合保存到关系型数据库。

MySQL、PostgreSQL等数据库可满足事务、一致性及复杂关联查询需求。

温度、压力、电流和振动等连续数据，可保存到时序数据库。

时序表应按时间和设备分区，防止单表达到数十亿行后无法维护。

报警、操作记录及接口日志可进入检索引擎，提升条件组合查询速度。

巡检照片、检验报告和电子签名文件，应保存到对象存储。

数据库仅记录文件地址、哈希值、版本号、上传人和业务关联关系。

冷热数据需要分层管理，例如近90天放在高性能存储，历史数据转入归档。

归档不是删除，系统仍需提供按设备、日期和批次恢复查询的能力。

关键业务表应增加创建人、修改人、版本号及逻辑删除标识。

台账记录一旦签审完成，不建议直接覆盖，应通过新版本进行更正。

数据治理策略

系统应建立统一编码规则，覆盖工厂、产线、设备、部件和测点。

同一设备在ERP、MES和平台中的编码不同，会直接造成数据无法关联。

主数据可由一个权威系统维护，再通过事件或接口同步给其他系统。

数据质量规则包括非空校验、范围校验、重复校验和时间连续性检查。

异常数据不能简单丢弃，应进入隔离区，并保留原报文和失败原因。

对数据表设置责任部门、保留期限、敏感等级和访问范围。

审计人员应能查到数据由谁产生、经过哪些处理、在哪个版本被修改。

电子台账系统技术架构平台层架构

微服务架构设计

平台可拆分为设备服务、台账服务、模板服务、流程服务和用户服务。

报警中心、通知中心、文件中心及报表中心也适合建设为独立服务。

服务边界应围绕业务能力划分，不能按数据库表机械拆分。

规模较小的项目可先采用模块化单体，避免十几个服务带来运维负担。

当用户数、工厂数或发布频率上升后，再拆分高负载或高变化模块。

服务之间优先通过API或领域事件通信，禁止跨服务直接访问数据库。

每个服务独立管理数据表，可减少表结构变更对其他模块的影响。

跨服务事务可采用事件驱动和补偿机制，不建议依赖大型分布式事务。

配置中心统一管理数据库地址、限流参数和业务开关。

注册发现组件负责服务定位，网关负责鉴权、路由、限流及协议转换。

服务拆得越多，网络调用、监控和排障成本越高。

采购方应要求供应商提供服务清单、依赖关系和故障降级说明。

消息中间件选型

MQTT适合设备端轻量通信，支持低带宽网络和不同质量等级。

Kafka适合高吞吐数据流，可用于设备数据、审计事件及实时计算链路。

RabbitMQ适合业务任务、通知和流程事件，路由方式更灵活。

选型要关注每秒消息数、消息大小、积压时长和顺序要求。

消息必须设计重试、死信队列、消费幂等和积压告警。

生产者确认与消费者确认需要同时启用，减少消息无声丢失。

重要业务可保存消息轨迹，记录发送、入队、消费和处理结果。

缓存与性能优化

Redis可缓存组织结构、设备档案、权限结果和高频字典数据。

缓存只能作为性能组件，不能成为关键台账数据的唯一存储位置。

缓存键需要包含租户、工厂和业务对象，防止不同范围的数据串读。

热点数据可设置5分钟至30分钟过期时间，并在修改后主动失效。

权限数据更新后要立即清除旧缓存，避免离职人员继续访问系统。

大列表应使用分页和索引查询，不能一次返回数万条记录。

报表查询可通过只读副本、预计算表或分析数据库分担压力。

附件上传应采用分片和断点续传，避免大文件占满应用线程。

接口需要设置超时、并发数和熔断规则，防止故障持续扩散。

对热点台账可做读写分离，但必须明确主从延迟的允许范围。

压测应覆盖登录、查询、提交、审批、导出和批量导入场景。

性能指标要写成数字，例如500并发下接口95分位小于2秒。

电子台账系统技术架构应用层架构

前端技术方案

管理端可采用Vue或React，移动端可选择原生应用或跨端框架。

前端组件应覆盖动态表单、流程审批、图表、扫码和文件预览。

台账模板经常变化时，建议使用元数据驱动的动态表单。

字段类型、校验规则、显示条件和审批权限由后台配置下发。

设备现场网络不稳定，移动端应支持离线填写和恢复联网后同步。

离线数据需要本地加密，并设置登录失效和自动清理时间。

大屏不应直接查询生产库，可读取聚合接口或缓存结果。

前端还需统一处理错误码、登录过期、重复提交和请求追踪编号。

API设计规范

API可采用REST风格，复杂查询和内部聚合场景也可使用GraphQL。

接口路径需要包含明确的资源名称和版本，例如“/api/v1/ledgers”。

请求与响应应统一编码、分页结构、时间格式和错误码规则。

写入接口需要支持幂等键，防止扫码或网络重试生成重复台账。

批量导入不能只返回成功或失败，应反馈每一行的错误位置。

开放接口需要配置签名、时间戳、防重放和调用频率限制。

接口文档可使用OpenAPI生成，并提供测试环境和调用示例。

每次接口调用都应带追踪编号，便于跨网关和服务定位故障。

权限与安全机制

权限模型可采用RBAC，并叠加工厂、部门、设备和数据范围控制。

同一用户可能只能查看本工厂，却能审批跨部门的特定台账。

因此，菜单权限不能替代数据权限，两者必须分别校验。

重要操作可启用多因素认证、电子签名或二次口令确认。

密码、密钥、身份证号等敏感信息需要加密存储或脱敏展示。

传输链路应启用TLS，内部服务也不应默认使用明文通信。

审计日志要记录登录、查询、导出、修改、审批和权限变更。

日志应具备防篡改能力，并按企业制度保留6个月、3年或更久。

权限校验必须在服务端执行，隐藏前端按钮并不等于安全。

电子台账系统技术架构部署架构与运维

部署方案选择

企业可选择本地部署、私有云部署、公有云部署或混合部署。

生产数据不能出厂时，可在厂内运行采集、存储和核心业务服务。

集团统计服务可部署在云端，只同步经过筛选和脱敏的汇总数据。

应用服务适合使用Docker封装，减少测试与生产环境之间的差异。

工厂数量多、发布频繁时，可采用Kubernetes进行调度和弹性扩缩容。

规模较小的单厂项目使用虚拟机部署，成本和维护难度可能更低。

采购时问“多少钱”，不能只计算服务器，还要纳入数据库授权费用。

网络专线、证书、备份空间、运维人员和升级服务也属于长期成本。

部署方案应提供测试、预生产和生产环境，禁止直接在生产环境试功能。

监控与日志体系

监控体系应覆盖服务器、容器、中间件、数据库、接口和业务指标。

基础指标包括CPU、内存、磁盘、网络、连接数和队列积压量。

应用指标包括请求量、错误率、响应时间和线程池使用率。

业务指标包括设备在线率、数据延迟、台账提交量和审批超时量。

Prometheus可采集指标，Grafana可进行展示和趋势分析。

日志可通过集中式平台收集，按服务、工厂、用户及追踪编号检索。

告警需要分级，严重故障可通过电话和短信通知值班人员。

普通告警可进入企业微信或工单系统，避免所有问题都触发电话。

每条告警应带时间、对象、指标、当前值和处置链接。

只有监控没有响应流程，故障依然无法及时处理。

容灾与备份策略

数据库可采用主从复制或高可用集群，避免单节点故障造成停机。

应用服务至少部署两个实例，并由负载均衡器分发请求。

消息队列、缓存和对象存储也要评估单点，不能只保护数据库。

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

备份文件需要加密，访问权限应独立于生产系统管理员权限。

恢复目标要明确RPO和RTO，而不是只写“支持容灾”。

例如，RPO为15分钟，表示最多允许丢失15分钟内的数据。

RTO为2小时，表示故障发生后2小时内恢复核心业务。

企业至少每半年执行一次恢复演练，验证数据库和附件能否匹配。

演练还要覆盖域名切换、证书恢复、账号登录及接口联通。

未经恢复验证的备份，只能算文件副本，不能算容灾能力。

项目验收时应交付部署拓扑、端口清单、备份脚本和应急操作手册。

声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：sales@idmakers.cn删除，任何个人或组织，需要转载可以自行与原作者联系。