企业官网建设流程全解析

接到这个“云边端三层架构设计”的题，我第一反应是想起上周一个客户在群里追着问：“你们的边缘网关到底放在汇聚还是核心？汇聚跟核心之间是同一个VLAN互联还是三层IP互联？给个准话。”这个问题看起来是网络配置的小事，但背后恰恰是把云边端三层架构真正落实时，最容易被忽略、也最影响稳定性的一个决策点。畅联云平台在边缘计算系列（一）里说清楚了什么是边缘计算，这篇就专门拆开“云、边、端”这三层到底怎么设计，以及那些网络层面的实际问题该怎么答。

1. 为什么非要从两层架构走向三层：业务规模先把架构逼出来的

1.1 两层架构在真实场景里撑不住

十年前很多物联网项目还是“端+云”的简单两级：传感器、PLC、摄像头通过各种协议把数据直接推到云平台，云端做存储、展示和控制。那时候设备数量少，几十个点，几秒上报一次，服务器扛得住。但到了现在，一个中等规模的智慧工厂，光温度、振动、电流、压力传感器就有两三千个，采集周期要求100毫秒甚至更低。我们来算一笔账：假设每个数据点一条报文256字节，每秒采集10次，那就是2000 × 256 × 10 = 5.12MB/s，单条产线就要占掉接近40Mbps的持续带宽。这还不算视频流、PLC之间的高频互锁数据。

云端要处理这么多实时数据，要么疯狂堆带宽和算力，要么牺牲实时性做批量上报。更致命的是，一旦现场到云端的网络抖动或断连，产线直接失去监控，设备该停的没停，该报警的没报，谁来担这个责任？所以现实逼着我们在靠近设备的地方加一层“会算数”的边缘节点，这就是边缘计算存在的根本原因，不是概念炒作，是规模和可靠性倒逼出来的。

1.2 云、边、端三层各自的定义

畅联云平台在落地时对三层的定义很明确：

• 云层：负责全局设备管理、数据汇聚存储、算法模型训练、可视化应用、多租户权限控制。云层不关心单台设备的毫秒级动作，它关心的是整体趋势、成本能耗和复杂的跨域调度。
• 边层：部署在现场的网关或边缘服务器，负责多协议接入、数据解析清洗、实时计算、本地联动控制、断网缓存和续传。边层是“现场的大脑”，即使云不可达，产线依然能安全运转。
• 端层：具体的物理设备，包括传感器、执行器、PLC、摄像头、仪表等。端层只负责采集物理量、执行指令，自己不具备复杂逻辑处理能力。

这三层之间不是简单的“端采集—边转发—云存储”的线性链路，而是各有职责边界的协作体系。边层会上报过滤后的数据，云层会下发模型和策略，端层只跟边层通信。也就是说，端侧设备的“唯一联系人”是边层，而不是云。

1.3 用MVC和数字孪生的三层思想来理解

很多做软件的朋友对“三层架构”不陌生，MVC就是典型：Model负责数据，Controller负责业务逻辑，View负责展示。云边端三层也有同样的味道——端层类似于Model，是数据源；边层类似于Controller，在靠近现场的地方执行实时判断和控制；云层类似于View，提供全局可视化和远程管理界面。这样比喻给团队里的软件工程师一讲，他们很快就理解了自己的模块应该放在哪一层。

数字孪生的三层架构也有类似映射：物理空间（端）、数据空间（边）、应用空间（云）。数字孪生要实时反映物理世界状态，边缘节点负责把物理实体同步成结构化数据，云端负责构建高保真模型和业务应用。所以云边端三层架构是所有数字化项目的地基，理解了它，MVC和数字孪生都只是这个底座上不同视角的表达。

2. 每层到底该干什么：职责边界决定技术选型

2.1 端侧：不是所有数据都值得上报

端侧设备五花八门，有4-20mA模拟量传感器，有Modbus RTU的仪表，有OPC UA的PLC，有RTSP的摄像头。他们的共性是计算资源极其有限，MCU级别的CPU，几KB内存，跑不了复杂的算法。所以端侧只做最基础的事：按固定周期采样、把模拟量转成数字量、响应对点读写指令。

但有一点在设计时必须注意：端侧并不是简单地“每秒上报一次”，而是在本地上做第一步过滤。比如温度传感器，如果一分钟内波动不超过0.5℃，就没必要每一秒都往外发数据，只有超过阈值变化、越限报警或者定时心跳时才上报。这个“阈值判断”逻辑可以放在端侧，也可以放在边缘网关。我的建议是优先放在边缘网关，因为端侧设备种类太多，每个设备嵌一套规则后期维护成本极高，统一在边层做规则引擎更划算。

2.2 边层：协议转换、实时控制和断网自治

边缘网关是三层架构里最核心、也最容易被轻视的一层。硬件上可以是几瓦功耗的工业网关，也可以是带了GPU的边缘服务器，软件上必须包含几个关键组件：

• 协议适配器：把Modbus、OPC UA、BACnet、S7、CAN、MQTT等异构协议统一转换成内部标准数据模型。
• 实时数据库：在本地保留一段窗口内的原始数据和派生数据，保证查询和联动不依赖云端。
• 规则引擎：支持“如果…那么…”的本地联动，比如温度高于80℃就关断加热器，不再需要云端下发命令再绕一圈回来。
• 断网缓存与续传：网络中断时数据先存本地磁盘或内存队列，恢复后按时间顺序补传到云端。

边层的实时性要求通常在10到100毫秒以内。比如两个机械臂的协同防碰撞，我们实测通过边缘网关做联动控制，端到端延迟稳定在8毫秒左右；但要是绕道云端，最少也要200毫秒以上，这在工业现场是不可接受的。所以边层绝对不能只是一个“协议转换器”，它必须是一个能独立运行的微型控制系统。

2.3 云层：全局优化，不做毫秒级干预

云层如果也去下发每一个开关动作，那三层架构就名存实亡了。云层的核心价值在于：

• 全局设备资产台账：所有边缘节点、端侧设备统一建模，支持批量配置和固件升级。
• 算法模型的训练与下发：在云端利用历史数据训练预测性维护模型，然后把模型参数下发到边缘节点，让边层按模型阈值做预判。
• 报表和大屏可视化：面向管理层和生产调度，展示OEE、能耗、报警统计等。
• 多租户与权限隔离：不同工厂、不同车间数据隔离，互不可见。

云层接收的数据应该是“边层过滤后的特征数据”，比如设备运行状态、报警事件、统计指标，而不是原始波形。这样云端的存储和计算压力会小两个数量级。

2.4 一个冷库项目的完整数据流

说个实际的例子。我们做过一个冷链仓储项目，端层是温湿度传感器和冷库压缩机控制柜，边层是一台工业边缘网关，云层是畅联云平台。平时传感器每30秒把温度数据通过串口送到网关，网关做有效性校验后，每5分钟把平均值上报到云端。如果温度瞬间超过8℃，网关立即执行本地规则：关掉冷库门电磁阀、启动备用压缩机，同时以1秒一条的频率向云端推送报警。云端收到报警后生成工单，推送给运维人员，并把这段报警前后的温度历史数据拉出来做分析，用来优化后续的温控策略。

如果三层职责不清，温度数据全部走云端再回来控制，一旦网络延迟或者断线，整个冷库的货品就危险了。所以说，职责边界不是文档上的空话，它直接决定了系统能不能在极端工况下兜住底。

3. 网络架构的关键决策：汇聚与核心之间，同VLAN互联还是三层IP互联

3.1 先把网络拓扑和云边端三层对应起来

很多人在设计时把“云边端”逻辑架构和实际的园区网络物理架构搞混。逻辑上的三层，在物理网络上通常体现为：核心交换机（机房）—汇聚交换机（车间/楼栋）—接入交换机（设备现场）。边缘网关一般位置在汇聚层。为什么不是接入层？因为接入层设备通常在机柜角落或者生产现场，空间小、灰尘大、温湿度不可控，而且接入交换机的端口和性能都很有限，塞不下高性能边缘服务器。为什么不在核心层？核心承载着整个园区的骨干流量，在上面挂一堆边缘网关，一旦网关被攻击或产生广播风暴，会直接影响所有业务。所以汇聚层是边缘节点最合适的位置——每个汇聚区域覆盖一定数量的设备，数据在这里汇聚、计算、再转发到核心。

3.2 同VLAN互联和三层IP互联的本质区别

回到那个灵魂拷问：汇聚和核心之间，到底是同一个VLAN的二层互联，还是走三层IP路由？

同一个VLAN互联，意味着汇聚和核心在同一个广播域里，二层报文可以透传。这种做法的优点是配置简单，只要把核心和汇聚之间的端口配成Trunk，放行相关VLAN就行。缺点也很明显：

• 广播域太大，一台设备发ARP广播，全网所有交换机都得转发，设备一多性能急剧下降。
• 故障域太大，一台接入交换机出现二层环路或MAC地址漂移，可能会拖垮整个核心区域。
• 策略无法精细化，核心交换机如果只做二层转发，就没法基于IP地址做ACL和QoS，因为三层网关在汇聚上，核心看不到终端的IP层信息。

而汇聚与核心之间走三层IP互联，意味着每个汇聚区域是一个独立的三层路由域，核心和汇聚之间通过路由协议交换网段信息。这样广播域被限制在接入层到汇聚层之间，汇聚层以上的流量都是路由转发。带来的好处是故障隔离、扩展性好、策略控制灵活。

3.3 网关放在汇聚时，正确的网络姿态是什么

当你说“网关放在汇聚”的时候，已经默认终端设备的VLANIF网关在三层交换机上创建。这时汇聚和核心之间如果还是同一个VLAN的二层透传，就会出现一个很别扭的局面：同一个VLAN跨了接入、汇聚、核心三层设备，但网关只在汇聚上。核心下面的服务器要访问这个VLAN里的设备，报文到核心后发现目的MAC根本不是自己，只能通过二层的Trunk链路转发给汇聚，由汇聚来代理网关回应。这种情况下，核心对这部分流量完全没有路由控制能力，而且很容易出现次优路径和环路隐患。

所以，网关放在汇聚，汇聚与核心之间就应该用三层互联。它们之间的链路接口直接配置IP地址，比如核心侧接口是10.10.0.1/30，汇聚侧接口是10.10.0.2/30，然后各自写路由。终端网关VLANIF 10.10.10.254/24建在汇聚上，汇聚需要写一条默认路由指向核心10.10.0.1，核心需要写一条10.10.10.0/24的路由指向汇聚10.10.0.2。这样每一层都清楚自己该把包交给谁。

3.4 一个参考配置思路（华为/华三设备写法）

很多做平台的朋友不是网络出身，但至少要看得懂配置，我贴一段核心思路，具体命令因厂商略有差异，但原理通用：

• 汇聚交换机：

vlan 10 interface vlanif 10 ip address 10.10.10.254 255.255.255.0 interface GigabitEthernet0/0/1 port link-type route ip address 10.10.0.2 255.255.255.252 ip route-static 0.0.0.0 0.0.0.0 10.10.0.1

• 核心交换机：

interface GigabitEthernet0/0/1 port link-type route ip address 10.10.0.1 255.255.255.252 ip route-static 10.10.10.0 255.255.255.0 10.10.0.2

如果汇聚数量多，建议启用OSPF，把汇聚和核心之间的直连网段以及VLANIF网段都宣告进OSPF区域。这样新增一个汇聚时，只要把它的VLANIF网段通告进OSPF，核心和其他汇聚就能自动学习到路由，不用一条条手动加静态路由，减少割接时的遗漏风险。

3.5 什么时候可以继续用同VLAN互联？

也不能一棒子打死。如果项目规模很小，比如一个独立机房，只有一台汇聚，核心也在这个机房，总共不到20台设备，数据量也不大，那么汇聚与核心之间同VLAN互联完全够用，省掉路由配置，维护起来简单。但这种情况下的“核心”其实更像是二层汇聚的汇聚，谈不上真正的三层架构。

从我个人的维护经验看，云边端架构下的边缘节点会越来越多，今天可能一个汇聚下面挂10台网关，明年就变成50台，二层网络在初期看着省事，后期扩容和排障会让你崩溃。所以除非你已经能够明确判定这个项目永远长不大，否则直接选三层互联。

4. 边缘网关部署实战：从选型到调试的完整链路

4.1 网关硬件选型：先算一下你要在边侧干什么

选硬件不能拍脑袋。如果边缘侧只要做Modbus采集和MQTT转发，一个ARM Cortex-A53、512MB内存的工业网关就够了，功耗低，支持DIN导轨安装，工作温度-20到70℃。但如果你要在边侧跑视频流AI识别，比如质检相机拍100张/秒，那必须上带GPU的边缘服务器，至少8G内存，还得有独立风扇散热，体积和功耗都会大不少。

一个比较实用的估算方法是：先列边侧要跑的规则引擎条数、要维护的实时数据点数、以及做本地Web配置页面的并发连接数。数据点数一万以下，规则不超过二十条，用入门级工业网关完全没问题；要跑容器化多服务，建议x86或高性能ARM平台，内存至少2G起步。预算允许的话，所有网关都选支持Docker的，后面部署规则更新和模型下发会轻松非常多。

4.2 网关软件架构：容器化和规则引擎是标配

我们推荐的边缘软件架构是这样的：底层是Linux系统，上面跑Docker容器，每个功能模块一个容器，包括协议采集容器、规则引擎容器、断网续传容器、IPsec或TLS隧道容器、远程管理agent容器。云平台通过管理通道下发Docker Compose配置，远程启动或停止服务，不用到现场接串口。

规则引擎一定要支持热更新。我们遇到过现场工况变化，希望把温度报警阈值从70℃改成65℃，总不能每次改个参数都要重启网关。所以规则引擎最好做成参数和逻辑分离，逻辑固定，参数动态从云端下发。畅联云平台在这一点上做得比较到位，边缘节点会周期性地向云侧同步规则状态，云侧改完参数后，边侧几秒钟内自动生效。

4.3 时间同步是一件你不提就一定会坏的事

边缘计算里所有报警和趋势分析都依赖准确的时间戳。网关刚开机时RTC（实时时钟）往往是出厂默认时间，如果接不到NTP服务器，本机时间可能偏差数小时。这会导致数据到达云端后排序错乱，报警时间完全不可信。

我的建议是：把NTP服务部署在云平台或核心网络里，要求所有边缘网关在启动时以及每半小时强制同步一次。如果网关部署在无法访问互联网的内网环境，那就在边缘网关上启用本地NTP服务，同时允许下挂设备向它做时间同步。这个看似不起眼的设置，能省掉后期数据分析大量的对数时间。

4.4 网络安全：别让边缘节点成为突破口

云边之间的通信建议走TLS加密，边缘网关作为客户端主动连接云端，不需要暴露公网端口。设备侧和边缘网关之间使用独立VLAN隔离，限制设备网段只能访问网关的特定端口。汇聚交换机上最好配置端口安全，比如只允许指定MAC地址的设备接入，防止别人在车间随便插一个网线就能抓包。

网关本身也要加固：修改默认密码，关闭SSH的密码登录改用密钥，只开放443和指定上行端口。曾经有个项目就是边缘网关被弱口令扫到，被人植入挖矿程序，CPU占用飙升导致采集中断，虽然没造成生产事故，但排查过程非常折腾。从那以后我们对所有出厂的网关都做了默认口令强制修改和防火墙策略预置。

4.5 一个真实排查案例：网关能上云但下不了配置

这里分享一个曾经踩过的坑。某项目现场，边缘网关注册到云平台后，状态显示在线，但云端下发的任何配置都不生效。排查过程从网关的管理界面看，上行MQTT连接正常，但配置下发走的是单独的WebSocket通道，需要云端先访问网关的某个端口。问题是云端所在的机房和现场汇聚之间是二层VLAN互联，核心交换机看不到汇聚下面的设备网段，导致云端发出的HTTPS请求根本无法路由到网关的管理地址。把汇聚和核心之间从Trunk改造为三层互联，并在核心上添加指向汇聚网段的路由后，配置下发立即恢复。你看，又是同一个问题：二层互联导致的三层路由缺失。所以别再纠结“能不能二层搞”，在云边端这种需要云端主动访问边缘节点的场景里，三层互联几乎是唯一的可靠选择。

5. 从三层架构到落地：规划、地址、迁移和最终建议

5.1 实施前先把逻辑架构和网络拓扑画清楚

不要一边施工一边设计。我强烈建议项目启动前，用draw.io或Visio画两张图：一张是逻辑架构图，画清云、边、端三层之间的协议和数据流；另一张是网络拓扑图，画清核心、汇聚、接入三层设备以及搭配的IP网段。两张图必须能对上：逻辑上的每个边缘节点，在网络拓扑里都能找到一个具体位置的汇聚设备。

画图的过程也是对业务梳理的过程。哪个区域划到哪个汇聚，哪些设备需要跨区域通信，哪些数据只在本地闭环，这些不提前想清楚，后面设备上线了再调整VLAN，成本是几何级增长的。

5.2 IP地址规划模板和VLAN划分建议

这里给一套可以抄作业的规划思路。首先把IP网段按业务类型分开，比如：

原则是：设备数据网段和网关管理网段必须分离，防止终端设备被攻破后直接横向访问到网关管理口。汇聚和核心之间的互连网段用30位掩码，比如10.10.255.0/30、10.10.255.4/30，一个链路一段，避免浪费地址。如果将来边缘节点很多，还可以把不同车间划到不同汇聚，每个汇聚独立C段。

5.3 从二层平滑迁移到三层架构的方法

很多存量项目一开始图简单，整个工厂一个大二层。真要按三层架构改造，不能一口气割接，否则所有设备同时断网，工厂必然炸锅。稳妥的路径是分四步走：

第一步，把汇聚和核心之间的互联接口改成三层接口，先配好互联IP和路由协议，保持原有VLAN在汇聚上仍然有二层网关，不影响现有终端。 第二步，在汇聚上创建新的VLANIF网关，逐步把终端的网关从核心或老设备迁移到汇聚上，可以先拿一个不影响生产的VLAN试点。 第三步，清理核心上残留的终端VLAN，把广播域收敛。 第四步，把边缘网关逐个接入新的汇聚区域，验证云、边、端数据链路。

整个过程每做一步都需要验证，尤其要盯住ARP表项变化和路由表是否出现黑洞。

5.4 最后分享一点真实的感受

我做过好几个边缘计算项目的网络方案，最大的体会是：很多团队把精力花在选型云平台、调算法模型上，却在网络架构上栽跟头。其实云边端三层设计的骨架，有百分之七十的网络问题都出在“二层还是三层”这个选择上。如果你在方案阶段就坚持“汇聚与核心之间三层互联，网关放在汇聚，VLAN只在下联和接入层划分”这个原则，后期的运维会省掉无数个半夜被叫醒的紧急工单。另外还有一个细节，所有汇聚和核心之间的物理链路，尽量用双链路做链路聚合，并配合路由协议检测，避免单根光纤断了导致整个区域失联。这些听着基础，但在图纸上多画一笔，现场调试时就少熬一夜。