第二章:部署环境规划

部署环境规划这件事,说白了就是给MES系统找个「家」。我见过太多项目,系统选型做得漂漂亮亮,结果环境规划一塌糊涂,最后上线天天出问题。嗯,今天咱们就把这块掰开揉碎了讲清楚。

2.1 硬件选型:服务器、存储、网络

硬件选型,我个人习惯先问三个问题:
- 这个MES要管多少条产线?
- 数据量有多大?
- 对实时性要求多高?

这三个问题决定了你该砸多少钱买硬件。

服务器选型

MES系统通常分三层:应用服务器、数据库服务器、接口服务器。我建议这样配:

服务器类型 推荐配置 说明
应用服务器 CPU:16核以上
内存:64GB起步
硬盘:SSD 500GB
跑业务逻辑,并发高
数据库服务器 CPU:32核以上
内存:128GB起步
硬盘:SSD 1TB(RAID10)
IO密集型,内存越大越好
接口服务器 CPU:8核
内存:32GB
硬盘:SSD 256GB
对接PLC、SCADA等设备
我的经验:数据库服务器千万别省内存。我在一个项目里遇到过,客户为了省钱配了64GB内存,结果每天凌晨跑报表时数据库直接卡死。后来加到256GB,问题全没了。

存储选型

MES的数据存储,我一般分三类:

  • 热数据(最近3个月):全闪存阵列,响应时间<1ms
  • 温数据(3-12个月):混合存储,SSD+HDD组合
  • 冷数据(1年以上):大容量HDD,甚至可以上对象存储

你想想看,一条产线一天产生几百万条数据,全放SSD里成本扛不住。但热数据放HDD里,查询慢得你想砸键盘。

网络规划

网络这块,我踩过坑。曾经有个项目,MES和PLC之间走的是公司办公网络,结果一到下午网络拥堵,产线数据传不上来,差点造成停线事故。

我的建议是:

  • MES核心网络:万兆光纤,独立VLAN
  • 产线设备网络:千兆工业以太网,最好用Profinet或EtherNet/IP
  • 办公网络:千兆,与MES网络物理隔离
注意:MES网络和办公网络一定要做物理隔离或强逻辑隔离。我曾经见过一个工厂,员工在办公区下载大文件,直接把MES网络带宽占满,产线数据延迟了30分钟。

2.2 操作系统选择:Windows Server vs Linux

这个问题,每次做项目都会被问到。我的回答很简单:看你的数据库和中间件。

场景 推荐OS 理由
数据库用SQL Server Windows Server 2022 原生支持,性能最优
数据库用Oracle/MySQL Linux(RHEL 9或Ubuntu 22.04) 稳定性好,运维成本低
容器化部署 Linux(推荐Rocky Linux) Docker/K8s原生支持

我个人习惯,能用Linux就用Linux。为什么?你想想看,Windows Server重启一次要多久?Linux呢?而且Linux的日志管理、性能监控,比Windows强太多了。

避坑指南:我曾经在一个项目里,客户坚持用Windows Server跑Oracle数据库。结果呢?每两周就要重启一次服务器,不然内存泄漏到爆炸。后来换成Linux,半年没重启过。

2.3 数据库选型:SQL Server / Oracle / MySQL

数据库选型,是MES系统最核心的决策之一。我见过太多项目,因为数据库选错,后期改得痛不欲生。

SQL Server

适合场景:
- 企业本身是微软生态
- 需要和Office、Power BI深度集成
- 中小型MES(数据量<10TB)

优点:图形化管理工具好,上手快。
缺点:贵,Linux支持不好,高并发下性能一般。

Oracle

适合场景:
- 大型MES(数据量>10TB)
- 对数据一致性要求极高
- 需要RAC做高可用

优点:稳定,功能强大,支持海量数据。
缺点:贵得离谱,运维需要专人。

MySQL

适合场景:
- 中小型MES
- 预算有限
- 配合Linux使用

优点:免费,轻量,社区活跃。
缺点:默认配置性能差,需要调优。

我的建议:如果你预算充足,直接上Oracle。如果预算有限,MySQL+读写分离也能扛住。但千万别用SQL Server跑大型MES,我见过一个项目,数据量到5TB后,查询慢到怀疑人生。

2.4 中间件与容器化技术:Docker / K8s

现在做MES部署,容器化几乎是标配了。为什么?因为MES系统太复杂了,依赖一大堆:Java环境、消息队列、缓存、数据库驱动...传统部署方式,每台服务器都要手动配一遍,累死人。

Docker:让部署变简单

我习惯把MES的每个组件都做成Docker镜像:

# 应用服务镜像示例
FROM openjdk:11-jre-slim
COPY mes-app.jar /app/
COPY config/ /app/config/
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/mes-app.jar"]

这样做的好处是:开发环境、测试环境、生产环境完全一致。再也不会出现「在我电脑上能跑啊」这种尴尬情况。

K8s:让运维变轻松

当你的MES有多个微服务时,K8s就派上用场了。我一般这样规划:

  • 命名空间:按环境分(dev/staging/prod)
  • Pod:每个微服务一个Pod,至少2个副本
  • Service:用ClusterIP做内部通信,NodePort对外暴露
  • ConfigMap:管理配置文件,不用重新打包镜像
核心逻辑图:下面这张图展示了MES容器化部署的整体架构。
MES容器化部署架构图 用户/客户端 Nginx/Ingress 负载均衡 Kubernetes 集群 Pod: MES-API 副本数: 2 端口: 8080 Pod: MES-Worker 副本数: 3 端口: 8081 Pod: MES-Report 副本数: 1 端口: 8082 数据库、Redis、RabbitMQ 等中间件独立部署在集群外
注意:容器化虽好,但别把所有东西都塞进容器。数据库、消息队列这些有状态的服务,我建议还是独立部署。为什么?因为容器重启后数据就丢了,除非你配了持久化存储,但那又增加了复杂度。

嗯,部署环境规划这块,说白了就是「量体裁衣」。小厂用MySQL+Docker就够了,大厂得上Oracle+K8s。别盲目追求新技术,稳定才是第一位的。

最后说一句:不管选什么方案,一定要先做压力测试。我见过太多项目,硬件买回来才发现扛不住并发。花一周时间做压测,能省你后面三个月的运维时间。