用户等一两秒就可能走人。视频卡一下，支付转圈，流失就已经发生了。集中式云架构足够成熟，但请求要绕到远端机房再回来，链路一长，抖动也跟着来。工业控制、直播互动、门店收银这类场景对此最敏感。边缘计算要处理的就是这个问题。
阿里云边缘计算是什么
说白了，就是把计算、存储和网络能力往离用户和设备更近的地方放。依托分布在各地的边缘节点，企业可以在靠近终端的位置处理数据，只把需要的结果回传中心。中心云仍然负责统一管理，不用每个节点各搞一套。
一般会涉及下面几块：
- 边缘节点：部署在城市或园区的计算资源，就近接入，实时处理在这里完成。
- 边缘容器与函数服务：应用的打包方式和中心云基本一致，发布和扩缩容的习惯可以沿用。
- 边缘网络加速：由调度系统选择链路，减少跨网传输带来的抖动。效果仍取决于用户到节点的距离。
- 云边协同管理：配置下发、状态监控和版本更新从中心统一完成，方便排查问题。
三个典型场景
直播互动：连麦不再卡顿
某在线教育平台的晚间高峰期经常遇到连麦卡顿。原来音视频要回到区域中心机房转发，热门课程并发一上来，链路就堵了。后来他们把实时转发和音频处理迁到阿里云边缘节点，学生就近接入，转发路径缩短了一半以上。平台反馈连麦延迟明显下降，课堂互动也顺畅了。中心云只保留课程管理、账号和数据分析，分工比以前清楚。
工厂质检：网络抖动时产线不停
汽车零部件工厂的质检摄像头每秒都产生大量画面。如果全部上传云端判断，网络一波动就可能停线。现在识别模型运行在车间附近的边缘节点上，只把异常样本和统计结果同步到云端，用来迭代模型。外网短时中断时，产线照常检测，数据等网络恢复后再补传。
连锁超市：门店不用各配一套服务器
门店设备分散，一家家上门维护的成本很高。某区域连锁超市把人流统计、货架识别和收银数据的预处理放在门店侧的边缘设备里，促销策略和商品模型则由中心平台统一下发。门店不需要复杂的服务器配置，运维人员在云端控制台就能批量升级，日常工作量明显减少。
哪些业务值得下沉
不是所有业务都需要边缘。可以从三点判断：业务对延迟是否敏感，数据是否必须就地处理（比如合规要求或带宽成本），以及网络断开后本地能否继续运行。三点都不明显的话，留在中心云通常更省钱，也更省事。
落地的五个步骤
- 先梳理业务链路，找出真正被延迟拖累的环节。很多系统只有一两段需要下沉，别急着整体迁移。
- 节点覆盖范围按用户和设备的实际分布来定。比如用户集中在某个区域，就先在那里布点，不必一开始全国铺开。
- 应用用容器封装，让边缘和中心环境保持一致。环境不一致时，线上问题很难复现。
- 监控和发布要做到云边统一。节点数量一多，逐台登录手动操作很快就撑不住。
- 先挑一个场景试点，效果看得见了再复制到其他节点。
延迟到底能不能降下来
回到标题的问题。延迟能不能降，主要看两件事：用户和节点之间的距离，以及业务是不是真的卡在网络传输上。如果瓶颈在数据库查询或应用自身的逻辑，把应用搬到边缘也快不了多少。先测清楚时间都花在哪里，再决定要不要部署边缘节点，比直接上新架构更稳妥。
边缘计算不是要取代中心云。中心负责全局管理和深度分析，边缘负责就近响应和实时处理，两者分工合理，才能发挥各自的价值。
