边缘计算架构：端-边-云三层架构详解
聊到边缘计算，我第一个想跟你聊的就是架构。说白了，没有清晰的架构，边缘计算就是一盘散沙。我在2018年刚接触这个领域时，踩过不少坑——最典型的就是把边缘节点当成了“小号云服务器”来用，结果延迟没降下来，运维成本反而翻倍了。
今天咱们把端-边-云三层架构彻底讲透。你想想看，一个典型的工业质检场景：摄像头采集图像（端），本地工控机做初步推理（边），最终模型训练和报表汇总上云。这三层各司其职，缺一不可。
端-边-云三层架构拆解
端侧（End）：这是最靠近数据源的地方。传感器、摄像头、PLC、智能终端都属于这一层。端侧的特点是资源受限，算力弱，但实时性要求极高。我建议你在端侧只做两件事：数据采集和简单预处理。比如去噪、格式转换，千万别在端侧跑复杂模型，功耗和散热都扛不住。
边侧（Edge）：这是整个架构的核心。边缘节点通常部署在离端侧一跳或两跳的网络位置。边侧承担着数据过滤、实时推理、本地决策的重任。我在项目中遇到过最头疼的问题就是边侧存储规划——日志写得太猛，128G的SSD三天就写满了。后来我强制设了日志轮转策略，才稳住局面。
云侧（Cloud）：云侧负责全局调度、模型训练、长期存储和大数据分析。云侧不追求毫秒级响应，但需要海量计算和存储能力。嗯，这里要注意：云边通信一定要设计断网续传机制。我曾经吃过这个亏，工厂网络抖动30秒，丢了上千条质检记录，被生产经理追着骂了一周。
核心原则：数据在边缘处理，知识在云端沉淀。能本地处理的绝不送云，必须送云的尽量压缩。
边缘节点的分类
边缘节点不是铁板一块。根据部署位置和算力规模，我习惯把它们分成三类：
| 类型 | 典型部署位置 | 算力规模 | 典型设备 |
|---|---|---|---|
| MEC（多接入边缘计算） | 基站侧、运营商机房 | 中高（8-32核） | X86服务器、ARM服务器 |
| Cloudlet | 企业园区、商场 | 中等（4-16核） | 微型服务器、工控机 |
| 雾节点 | 路边、工厂产线 | 低（2-8核） | 网关、路由器、树莓派 |
MEC：这是运营商主导的方案。我记得在5G智慧港口项目中，MEC节点就部署在港口的5G基站旁边。延迟能压到5ms以内，吊车控制指令几乎感觉不到延迟。MEC的优势是网络质量有保障，但成本高，适合对延迟极度敏感的场景。
Cloudlet：你可以把它理解成“装在盒子里的微型云”。Cloudlet通常部署在企业内部，WiFi覆盖范围内。我建议你在做智慧零售、AR导览这类场景时优先考虑Cloudlet。它比MEC灵活，比雾节点算力强，是个折中方案。
雾节点：雾节点是最贴近端侧的边缘设备。说白了，很多工业网关、智能路由器就是雾节点。它们算力不高，但功耗低、成本低、部署方便。我曾经在一条汽车产线上部署了40多个雾节点，每个节点只负责3-4个工位的数据汇聚和简单判断。效果出奇的好，故障响应时间从分钟级降到了秒级。
选型建议：如果延迟要求<10ms，选MEC；如果10-50ms，Cloudlet够用；如果>50ms且成本敏感，雾节点是性价比之王。
主流参考架构
理论讲完了，咱们看看业界是怎么落地的。我重点讲三个主流架构：ECC、OpenYurt、KubeEdge。这三个我都亲手部署过，各有各的脾气。
ECC（边缘计算联盟架构）
ECC是边缘计算联盟提出的参考架构。它把边缘计算分成了四个域：设备域、网络域、数据域、应用域。我个人觉得ECC最大的价值是给出了一个标准化的分层模型，方便不同厂商的设备互联互通。
但说实话，ECC偏理论化，落地时你会发现很多细节没定义清楚。比如数据域和应用域的边界在哪里？不同厂商的实现差异很大。我建议你把ECC当作“思想框架”来用，具体实现还是得看实际场景。
OpenYurt
OpenYurt是阿里云开源的项目。它的核心思路是“把Kubernetes延伸到边缘”。你想想看，云原生生态那么成熟，为什么不在边缘复用呢？OpenYurt做的就是这件事——它给K8s加了一层边缘管理能力，让云端能统一管理成千上万个边缘节点。
我在一个智慧园区项目中用过OpenYurt。部署过程还算顺利，但有个坑：边缘节点和云端网络断开后，OpenYurt的节点控制器会误判节点失联，触发Pod驱逐。解决方案是调整节点心跳超时时间，从默认的40秒改成300秒。代码很简单：
# 修改kube-controller-manager配置
--node-monitor-grace-period=300s
--node-monitor-period=10s
注意：OpenYurt适合边缘节点数量多、网络不稳定的场景。但如果你的边缘节点算力极低（比如树莓派），跑K8s本身就会消耗大量资源，这时候OpenYurt就不太合适了。
KubeEdge
KubeEdge是华为云贡献给CNCF的项目。它和OpenYurt思路类似，但实现方式不同。KubeEdge在边缘侧运行一个轻量化的EdgeCore，云端运行CloudCore，两者通过WebSocket保持连接。
KubeEdge最大的亮点是支持离线自治。边缘节点断网后，EdgeCore能继续管理本地容器，网络恢复后再和云端同步状态。这个特性在工业场景中太重要了。我曾经在矿山项目中用KubeEdge，矿井下网络时好时坏，但边缘设备一直稳定运行，数据也没丢。
部署KubeEdge时有个小技巧：边缘节点的证书有效期默认只有一年。如果你不想每年手动续期，可以在生成证书时把有效期改成10年：
# 生成10年有效期的证书
keadm init --kubeedge-version=v1.15.0 --cert-days=3650
我的选择建议：
- 团队K8s经验丰富 → OpenYurt（学习成本低）
- 需要离线自治能力 → KubeEdge（断网场景首选）
- 标准化参考 → ECC（适合做方案评审）
架构选型决策树
最后，我画了一张决策图，帮你快速判断该选哪种架构。这张图是我在多个项目中总结出来的，不一定100%覆盖所有场景，但80%的情况够用了。
这张图的核心逻辑很简单：节点少、场景简单，用轻量方案；节点多、团队强，上云原生方案。别为了炫技选最复杂的架构，稳定落地才是王道。
最后说一句：架构选型没有银弹。我在不同项目中用过MEC、Cloudlet、雾节点，也折腾过OpenYurt和KubeEdge。每次切换架构都意味着学习成本和迁移成本。所以我的建议是：先跑通最小闭环，再考虑架构升级。别一开始就想着“大而全”，那往往是项目烂尾的开始。