边缘计算：为什么计算正在离开云而向数据靠拢

云不会消失。但一切都需要在距离数据生成地数百公里的集中式数据中心运行的想法已经开始显现出其缺陷。当生产线需要实时检测缺陷时，当自动驾驶汽车决定在几毫秒内制动时，或者当零售商需要在不依赖稳定连接的情况下处理商店库存时，云的往返延迟不是一个技术细节，而是一个对运营产生直接影响的业务问题。

为什么中心化是有成本的

公有云对于能够容忍数十毫秒延迟、具有可用于连续传输数据的带宽、并且数据驻留位置不受严格限制的工作负载来说效果非常好。对于不符合此描述的所有内容，集中化开始对您不利。

典型的工业传感器每小时可以生成千兆字节的数据。将所有这些发送到云端、处理并返回决策不仅在带宽方面成本高昂，而且对于任何需要实时响应的流程来说都太慢。在这里，中心化模式不仅效率低下，而且效率低下。他是无法生存的。当前模型中的延迟无法优化，因为问题是物理的：电磁信号有速度限制。

数据主权又增加了一层。 [LGPD0] 等法规以及医疗保健、金融和关键基础设施领域的部门规则限制或复杂化了向受控范围之外的服务器发送某些类别的数据。本地处理或网络边缘处理不再是一种架构选项，而是成为一项监管要求。

边缘计算是将部分计算能力转移到物理上靠近数据源的点——工厂车间、5G 塔的天线、零售连锁店的销售点、车辆中嵌入的硬件。不是每条数据都一路传输到中央云，而是在数据离开生成它的环境之前就进行大量处理。

这不会取代云。它取代了云所做的特定部分：需要快速响应、在本地处理敏感数据或不能依赖持续连接的部分。中央云仍然是您汇总历史、训练模型、协调全局的地方。边缘就是你行动的地方。

边缘计算和雾计算之间的区别就出现在这里。雾是一个中间层——变电站、区域仓库中的服务器——在将数据发送到云端之前聚合来自多个设备的数据。边是距离原点最近的可能节点。在实践中，许多架构将两者结合起来。

制造业是最明显的例子。实时计算机视觉、检测设备异常、根据传感器调整生产参数——所有这些都需要在毫秒内做出响应，而中央云无法提供。工厂车间的边缘处理器解决了延迟问题，而无需牺牲与中央管理系统的链接。

电信和5G是另一个载体。运营商正在自己的塔中建设处理能力，这使他们能够直接在运营商网络边缘运行应用程序。对于云游戏、远程辅助手术、工业增强现实——任何需要低于 10 毫秒延迟的事物——这种架构是唯一有效的架构。

实体零售面临着特定的连接和本地处理挑战。自主结账系统、基于摄像头的库存监控、过道中的实时个性化——这些应用程序迫不及待地等待云对每一帧视频的响应。店内处理和定期同步可以解决这个问题。

自动驾驶汽车也许是最引人注目的例子。汽车需要根据摄像头、激光雷达和雷达做出瞬间决策。等待云并不是一个可接受的技术限制——这是一个物理安全问题。所有感知和决策处理都在车辆内进行，不依赖网络。

边缘最大的风险不是技术风险。它是可操作的。如果架构从一开始就没有为此设计，那么将计算能力分布在数十、数百或数千个节点上会产生复杂性，这种复杂性可能会超过其带来的好处。

第一个决定是定义哪些流程在哪里。并非所有可以在边缘运行的东西都应该在边缘运行。高频、低延迟处理属于边缘。历史聚合、模型训练、全局关联都属于中央云。保持这种划分清晰可以避免重复逻辑和在环境之间造成不一致。

第二个问题是编排。在分布式节点上管理软件更新需要与云中使用的部署策略不同的部署策略。混合配置中的 Kubernetes 等解决方案，或 AWS IoT Greengrass 或 Azure IoT Edge 等专用于边缘管理的平台，可提供集中可见性，无需在每个节点进行手动干预。

第三是数据模型。同步什么、何时同步以及如何解决冲突需要在构建之前决定。边缘计算不是云的扩展——它是一种分布式架构，具有该术语所暗示的一切：分区、最终一致性、需要聚合的本地状态。

分布式环境中的安全性也发生了变化。每个边缘节点都是一个物理攻击面。静态和传输中的加密、节点和云之间的相互身份验证以及远程禁用受感染设备的能力都需要在投入生产之前纳入架构计划中。