过去这些年，企业上云大多是把计算和数据放进数据中心，业务通过网络去调用。互联网应用里这样运行很顺畅，但如果数据从产线、路口和货架上产生，每次都要绕一趟云端再返回结果，问题就来了：延迟高，带宽费用不低，网络一断，现场也跟着停。于是行业开始讨论云和设备之间的那一层计算，也就是雾计算。云在天上，雾贴着地面，离设备更近。阿里云的雾，指的就是它在云与端之间搭建的这套协同计算能力。
雾计算要解决什么问题
雾计算不替代云，它做的是把一部分计算挪到靠近数据源的地方。实际用下来，主要有三类好处。
- 延迟：设备告警、机械臂急停这类动作，多等几百毫秒的往返就可能造成损失，本地处理能省掉这段路。
- 带宽：摄像头和传感器产生的原始数据量很大，先在本地过滤和聚合，只把有用的结果上传，费用会低很多。
- 断网后的可用性：网络抖动时，现场还能按本地规则继续运行，网络恢复后再把数据补同步上去。
有了这些好处，云厂商把边缘能力纳入整体产品线就顺理成章了。阿里云的思路是统一管理：开发者仍然使用同一套云原生工具，在中心和边缘之间部署、更新和监控应用，不必为每个现场单独维护一套系统。
阿里云的雾大致怎么分层
从能力构成看，阿里云的雾可以粗略分成三层，每层的职责不同。
- 设备接入层：通过物联网平台把各类设备接进来，支持主流通信协议。现场设备品牌杂、协议乱，这一层先把它们对齐。
- 边缘计算层：在网关或边缘服务器上运行本地推理、规则引擎和数据预处理。目标很明确，让现场的判断尽量不等网络。
- 云端管理层：负责模型训练、应用分发、版本管理和全局监控，把各个边缘节点连成一个整体来看。
分层的好处是边界清楚。现场只处理需要实时响应的数据，复杂分析和长期存储仍放在云上。如果企业已经在用阿里云的容器服务、对象存储或数据库，迁移起来通常不会太痛苦，因为中心和边缘的运维习惯是衔接的。不过老系统的改造量还是要单独评估，“通常”不等于“一定”。
三个场景怎么落到实处
下面三个场景是按行业常见做法拆解的示意，用来说明思路，不代表某家客户的实际数据。真要算收益，还得用自己项目的指标去衡量。
汽车零部件工厂的视觉质检
常见的情况是，产线摄像头的图像全部传到云端做缺陷识别。遇到高峰时段，带宽先紧张，判定结果回来又要等几秒，产线只能跟着降速。改成在车间部署边缘服务器，运行轻量化的缺陷检测模型，只把疑似不良品的图片和统计结果上传。中心模型定期复训，新版本再推送到各个车间。这个做法的重点在于，计算离数据最近，原始图像不用全部搬走。
城市路口的信号优化
路口的摄像头和雷达每秒都在产生车流数据。全部上传中心，既占资源，也很难保证信号灯及时切换。更稳妥的做法是在路口边缘节点完成车辆识别和排队长度估算，直接给出配时建议，中心平台负责区域协调和历史分析。连接短暂中断时，路口的基础控制照常运行。这对公共交通尤其要紧，信号灯停摆的代价远比一次数据延迟大。
连锁超市门店的本地服务
门店系统要处理收银、库存和会员推荐。如果每一笔请求都回总部，网络一抖，门店就结不了账。门店本地保留交易和库存的核心服务，夜间再与云端对账同步；促销策略和价格规则仍由总部统一下发。门店数量一多，总部的运维压力如果能不随门店数线性增长，这套安排的价值就很明显了。
落地前要先过的几关
真正上线时，团队通常会卡在以下几个地方。
- 边缘资源有限：模型要压缩，服务要裁剪，直接照搬云端的部署包，往往跑不动。先摸清边缘设备的内存和算力，再决定模型大小。
- 安全边界变宽：节点分散在现场，物理接触的风险比机房高。设备身份认证、传输加密和远程运维权限要在一开始就设计好，别等上线后再补。
- 版本一致：几十上百个节点版本不统一，出了问题很难复现。灰度发布和回滚机制要提前建好，先在一两个节点验证，再逐批推开。
- 任务划分：并非所有任务都适合下沉。可以问三个问题：是否需要毫秒级响应，是否涉及大量原始数据，是否必须在断网时照常运行。三个都不是的话，留在云上更省心。
写在最后
阿里云的雾更适合理解成一种工作方式，即把云能力延伸到现场。业务需要哪一段计算靠近设备，就把哪一段挪过去，不必推倒重来。制造、交通、零售这类数据分散、实时性要求高的行业，值得认真评估。建议先挑一个痛点清楚的场景做试点，用实际指标验证收益，再决定要不要扩大范围。
