现在柔性生产，超级工厂的MES常规，常用的系统架构❤️

admin

开发

2026-6-29

结论：现在超级工厂的 MES 架构分两派 —— 传统工业派和互联网新派，差别很大

传统大厂（西门子、SAP、富士康老系统）偏稳，不用 Redis/MQ 也能跑；

新一代灯塔工厂 / 工业互联网派，喜欢微服务、云边协同、消息队列全套。

一、当前超级工厂 MES 的主流架构（五层标准架构）

不管是哪一派，基本都遵循 ISA-95 标准 的分层思路，从上到下大概 5 层：

plaintext

┌─────────────────────────────────────┐
│  应用层（L5）：MES功能模块          │
│  工单、报工、质量、追溯、OEE、看板   │
├─────────────────────────────────────┤
│  业务平台层（L4）：微服务/业务中台   │
│  服务编排、流程引擎、规则引擎       │
├─────────────────────────────────────┤
│  数据层（L3）：数据存储与处理       │
│  关系库、时序库、数据湖、消息队列   │
├─────────────────────────────────────┤
│  采集/边缘层（L2）：设备接入        │
│  工业网关、OPC UA、边缘计算         │
├─────────────────────────────────────┤
│  设备层（L1）：生产设备             │
│  PLC、SMT、机器人、传感器、AGV      │
└─────────────────────────────────────┘

二、两派架构对比

派 1：传统工业派（西门子、SAP、罗克韦尔、国内老牌 MES）

代表： 西门子 Opcenter、SAP ME、宝信、石化盈科、富士康老系统

架构特点：

单体或简单分层，不是微服务
核心数据存在关系型数据库（Oracle/SQL Server 为主）
设备采集走专用协议（OPC、Modbus、专用网关）
重业务流程，轻大数据

用不用 Redis 和 MQ？

大多不用 Redis：缓存直接用应用内存或数据库
消息队列用得少：系统间集成用 ESB / 中间件，不是互联网那种 Kafka
不是不会，是不需要：并发不高、业务稳定、追求稳不追新

优点：

稳，跑了十几年的都有
工业 know-how 深，行业适配好
运维简单，DBA 就能搞定

缺点：

扩展性差，加功能慢
海量设备采集有点吃力
界面丑，体验差

派 2：互联网新派（灯塔工厂、工业互联网平台、创业公司）

代表： 富士康新灯塔工厂、阿里犀牛智造、树根互联、海尔卡奥斯、创业公司 MES

架构特点：

微服务架构，按功能拆成独立服务
云边协同：边缘端采集 + 实时处理，云端存大数据 + 全局优化
消息队列是标配（Kafka/RabbitMQ），数据从设备到应用全链路异步
多数据库混搭：关系库 + 时序库 + 文档库 + 数据湖
Redis 用来做缓存、实时计算、分布式锁

典型技术栈：

plaintext

设备接入：OPC UA、MQTT、工业网关
边缘层：边缘网关 + 流处理（Flink/Spark）
消息队列：Kafka / RabbitMQ
数据存储：
  - 业务数据：MySQL/PostgreSQL/OceanBase
  - 时序数据：InfluxDB/TDengine/时序库
  - 缓存：Redis
  - 大数据：Hadoop/ClickHouse
应用层：微服务（Spring Cloud） + 前端（Vue/React）

优点：

扩展性强，加设备加功能快
海量数据处理能力强
界面好看，体验好
适合柔性生产、多品种小批量

缺点：

复杂，运维重
出问题排查难
工业 know-how 不如传统派
有些是 "为了技术而技术"，实际价值存疑

三、柔性生产对 MES 架构的特殊要求

柔性生产（多品种、小批量、快速换型）对架构的要求：

1. 配置化、低代码

产品工艺、流程经常变
不能每次都改代码
所以新一代 MES 都搞低代码、可配置

2. 数据实时性要求高

换型快，设备状态变化快
需要实时监控、实时调整
所以边缘计算、流处理用得多

3. 系统集成要求高

要和 ERP、WMS、APS、PLC、AGV、机器人对接
接口多，数据流转复杂
所以消息队列、服务总线用得多

4. 数据量大

柔性生产设备多、品种多、数据维度多
采集频率高
所以时序库、大数据平台用得多

四、超级工厂的典型部署模式

模式 1：单工厂集中式

所有系统都部署在工厂本地
数据不出去，安全
适合单一大厂

模式 2：云边协同（集团多工厂）

总部云端：全局优化、大数据分析、模型训练
工厂边缘：实时采集、实时控制、本地 MES
数据双向同步：核心数据上云，边缘指令下发
适合集团型、多工厂企业

模式 3：全云化

MES 直接跑在云上
工厂通过专线 / 5G 连云端
适合中小企业，或者对实时性要求不高的场景

五、给你的建议（结合你的情况）

你的情况：

4000 设备 / 采集点
自己开发，C# 技术栈
运维能力一般
做 MES + OEE + 追溯

推荐架构："传统派为主，新派为辅"，别上来就搞微服务全套

初期架构（简单、稳、好维护）：

plaintext

设备层 → 采集网关/OPC → C#采集服务 → 数据库
                                       ↓
                                  MES业务系统（单体或简单分层）
                                       ↓
                                  前端（Web/移动端）

数据库组合：

OceanBase：业务数据（工单、报工、质量、追溯）
TDengine：时序采集数据（设备参数、状态）
不用 Redis：应用内存缓存热点数据
不用消息队列：应用层批量写入 + 本地文件兜底

理由：

4000 设备，数据量真不大，直接写库没问题
简单架构，出问题好排查
你运维能力一般，少组件少操心
先跑起来验证业务，比什么都重要

后期演进（数据量大了、系统复杂了再加）：

plaintext

设备 → 边缘网关 → 消息队列（Kafka） → 流处理 → 时序库
                                      ↓
                                   业务数据 → OceanBase
                                      ↓
                                微服务MES应用 → Redis缓存
                                      ↓
                                   前端/看板/APP

什么时候加？

设备翻几倍，每秒上万条写入
系统模块多了，单体维护不动了
实时性要求更高，毫秒级响应
多工厂、集团化了

六、一句话总结

超级工厂 MES 没有 "标准答案"，传统派稳，新派炫，适合自己的才是最好的。

你的阶段，先搞个简单可靠的架构跑起来，比追什么 "微服务、云原生、工业互联网" 概念靠谱得多。

工厂里，能稳定跑三年不出事的系统，就是好系统。

🎯要做就要押注未来，不要改过去改过来。

实在不行，就分多条MES产品路线，多个团队开发多个产品。

重点：骨架要做好，骨架一定要靠谱。

MES 这种生产系统，架构骨架一开始没搭好，后期改起来就是伤筋动骨，成本极高

但要区分：架构骨架要一步到位，功能模块可以逐步加。不是说一开始就要把所有东西都做完，而是把扩展的位置留好、边界划清，以后加东西不用动骨架。

给你一套 "面向未来 10 年、一步到位但不过度设计" 的 MES 架构方案。

一、核心设计原则（重压未来趋势）

1. 解耦原则：层与层之间通过标准接口，不直接依赖

设备换了，采集层改，业务层不动
数据库换了，数据层改，业务层不动
前端换了，应用层改，后端不动

2. 可扩展原则：每个层面都能横向扩展

设备从 4000 台涨到 4 万台，加采集节点就行
用户从 100 人涨到 1000 人，加应用服务器就行
数据从 1TB 涨到 100TB，加数据库节点就行

3. 数据驱动原则：数据是核心，业务围绕数据转

所有数据统一采集、统一存储、统一标准
上层应用只是数据的不同 "视图"
以后加 AI、数字孪生、大数据分析，直接拿数据用

4. 云边协同原则：本地实时，云端全局

工厂本地：实时采集、实时控制、核心 MES
集团云端：全局分析、大数据、AI 模型、多工厂协同
数据双向同步，断网也能正常生产

二、目标架构（未来 3~5 年的终态）

plaintext

┌─────────────────────────────────────────────────────────┐
│                    应用层（多端接入）                     │
│  Web端  │  移动端  │  看板大屏  │  第三方系统API         │
├─────────────────────────────────────────────────────────┤
│                    业务服务层（微服务）                   │
│  工单服务 │ 报工服务 │ 质量服务 │ 追溯服务 │ OEE服务      │
│  设备服务 │ 物料服务 │ 人员服务 │ 看板服务 │ 告警服务      │
│  统一API网关 │ 流程引擎 │ 规则引擎 │ 权限中心             │
├─────────────────────────────────────────────────────────┤
│                    数据服务层                            │
│  关系型数据（OceanBase） │ 时序数据（TDengine）          │
│  文档数据（MongoDB）    │ 缓存（Redis）                  │
│  消息队列（Kafka）      │ 数据湖/数仓（后期加）           │
├─────────────────────────────────────────────────────────┤
│                    边缘采集层                            │
│  工业网关 │ OPC UA服务 │ 协议转换 │ 边缘计算 │ 本地缓存   │
│  数据预处理 │ 断网续传 │ 本地告警                        │
├─────────────────────────────────────────────────────────┤
│                    设备层                               │
│  PLC │ SMT │ AOI │ SPI │ 机器人 │ AGV │ 传感器 │ 测试设备 │
└─────────────────────────────────────────────────────────┘

三、关键技术选型（一步到位，未来 5 年不用换）

1. 数据库层（最核心，不能轻易换）

表格

类型	选型	为什么选它
关系型数据库	OceanBase 三节点	分布式、强一致、在线 DDL、容量无上限，撑 10 年没问题
时序数据库	TDengine	工业采集专用，写入快、压缩高、查询快，天生适合设备数据
文档数据库	MongoDB	灵活存配置、日志、非结构化数据，Schema 不用提前定
缓存	Redis	工业标准，热点数据、实时统计、分布式锁都能用
消息队列	Kafka	高吞吐、持久化、多消费者，采集数据一条进多条出

2. 应用层

表格

类型	选型	为什么选它
后端语言	C# / .NET 8	你熟悉，性能好，工业界用得多
架构风格	模块化单体（初期）→ 微服务（后期）	先单体跑起来，边界划好，后期拆微服务不用重写
API 网关	后期加	初期不用，服务多了再加
前端	Blazor / Vue	你熟悉 Blazor，工业软件用着合适

3. 采集层

表格

类型	选型	为什么选它
工业协议	OPC UA	工业标准，未来主流，设备都支持
边缘网关	自研 / 开源网关	数据预处理、断网续传、本地缓存
采集服务	C# 采集服务	和你技术栈统一

四、一期做什么？（骨架搭好，功能做核心）

不是说一步到位就全做完，而是骨架搭好，核心功能先上，其他留好接口。

一期必须做的（6 个月内）：

✅ 1. 数据层：三个数据库全部搭好

OceanBase 三节点：业务数据
TDengine 三节点：时序数据
MongoDB：配置、日志
为什么一期就上？ 数据库是骨架，后期换数据库成本最高，一开始就选对

✅ 2. 消息队列：Kafka 一期就上

采集数据全部走 Kafka
为什么一期就上？ 这是数据总线，后期再加的话所有采集都要改
而且 Kafka 也没那么复杂，三节点集群很稳

✅ 3. 采集层：OPC UA + 边缘网关

统一接入标准，后期加设备不用改业务
断网续传、本地缓存，保证数据不丢
为什么一期就上？ 设备接入是基础，协议不统一，后期越接越乱

✅ 4. 业务层：模块化单体，边界划清

按模块划分：工单、报工、质量、追溯、设备、OEE
模块之间通过内部 API 调用，不直接查对方的表
为什么这么做？ 后期拆微服务，直接把模块拆出去就行，不用重写

✅ 5. Redis：一期就上

缓存热点数据（产品、工艺、设备信息）
实时统计（当日产量、OEE）
分布式锁
为什么一期就上？ 简单好用，后期加的话代码要改很多

一期不用做的（后期再加）：

❌ 微服务拆分（先单体，边界划好就行）

❌ API 网关（服务少，用不着）

❌ 数据湖 / 数仓（数据量还小）

❌ AI、数字孪生（先有数据再说）

❌ 云边协同多工厂（先做好一个厂）

五、为什么这么设计？（重压未来趋势）

1. 应对柔性生产

模块化设计，新工艺、新产品、新设备，加配置就行，不用改代码
规则引擎、流程引擎，业务变化不用改代码
多品种小批量，数据模型灵活，不用改表结构

2. 应对数据量爆炸

OceanBase 分布式，容量无限扩
TDengine 时序专用，海量采集也不怕
Kafka 消息队列，削峰填谷，再高并发也不怕

3. 应对智能化升级

数据统一存储、统一标准，以后加 AI、大数据分析直接用
不用重新做数据治理
数字孪生也直接拿数据

4. 应对多工厂扩张

云边协同架构预留好
以后开新厂，直接复制一套边缘节点
总部云端统一看数据

六、关键：边界划清，接口标准化（最重要！）

架构好不好，不在于用了多少技术，而在于边界清不清。

必须定义清楚的边界：

1. 采集层 → 数据层：统一走 Kafka

所有采集数据都发到 Kafka 的固定 Topic
格式统一（JSON，标准字段）
后面谁想用数据，直接消费 Kafka 就行，不用改采集程序

2. 业务层 → 数据层：统一数据访问层

业务代码不直接写 SQL
通过 Repository/DAO 层访问数据
以后换数据库，只改数据访问层，业务代码不动

3. 业务模块之间：通过 API 调用

模块之间不直接查对方的表
调用对方提供的 API
以后拆微服务，直接把模块独立部署就行

4. 应用层 → 业务层：统一 REST API

前端、移动端、第三方系统，都通过统一的 API 访问
后端怎么变，前端不用改

七、给你的具体落地路线图

第 1~2 个月：搭骨架

✅ 搭基础设施：服务器、网络、监控
✅ 搭数据库：OceanBase、TDengine、MongoDB、Redis
✅ 搭消息队列：Kafka
✅ 搭开发框架：.NET 8 + 模块化架构
✅ 定义数据标准、API 标准

第 3~4 个月：核心功能 + 采集

✅ 设备数据采集：OPC UA → Kafka → TDengine
✅ 基础数据：产品、工艺、设备、人员
✅ 工单管理
✅ 生产报工
✅ 基础看板

第 5~6 个月：扩展功能

✅ 质量检验
✅ 产品追溯
✅ OEE 统计
✅ 设备管理
✅ 告警通知

第 6~12 个月：优化 + 智能化

✅ 性能优化
✅ 报表完善
✅ 高级分析
✅ 预留 AI 接口

1 年后：按需要扩展

微服务拆分
多工厂云边协同
AI 应用
数字孪生

八、一句话总结

架构骨架要一步到位（数据库、消息队列、分层边界），功能模块可以逐步加。

这样既保证了未来 5~10 年不用大改架构，又不会一开始就搞太复杂导致项目做不下去。

好的架构不是 "什么都有"，而是 "想加什么都能加，不用动骨架"。

阅读剩余

THE END

传统 MES、甚至很多大型工厂的 MES，确实都不用 Redis 和消息队列

<<上一篇

好的架构不是 "什么都有"，而是 "想加什么都能加，不用动骨架"。能做到吗？？？

下一篇>>