边缘计算并不是离用户更近的云。这种混乱是危险的，因为它会导致团队在分布式节点上复制集中式架构，并在一切崩溃时感到惊讶。将处理转移到边缘会改变系统的基本契约：您放弃即时一致性、中心控制点和统一的安全表面。作为回报，您可以获得可预测的延迟、对连接故障的恢复能力以及在数据来源处处理数据的能力。问题是大多数团队想要第二组好处而不接受第一组好处的后果。
当你走到边缘时真正发生什么变化
在集中式架构中，国家位于一处。这简化了一切：交易、审计、一致性。当您将处理分布到数十个或数百个边缘节点时，状态就会变得碎片化。马瑙斯的工业传感器和阿雷格里港的另一个工业传感器可以独立运行数小时，然后与中心同步。这不是一个错误——这是分布式系统的预期功能。但它要求每个设计决策都考虑到两个节点可以同时拥有不同的世界观。
最直接的含义是，您需要在系统中的每个点上明确地在一致性和可用性之间进行选择。 CAP 定理不是一个学术抽象：这是当边缘节点失去连接并需要决定是继续处理可能过时的数据还是停止等待同步时，工程师将面临的具体问题。不故意做出这种选择的系统最终会在错误的时间、在压力下做出选择，并且通常会犯错误。
最终一致性不足以保证所有事情的一致性
最终一致性模型适用于特定类别的问题：遥测数据、日志、用户偏好、随着时间的推移自然收敛的状态。对于金融交易、访问控制、实时库存以及任何两个节点使用过时数据做出独立决策会产生不正确且代价高昂的结果的情况，它的效果很差，或者根本不起作用。
迁移到[边缘计算0而没有映射哪些工作负载依赖于强一致性以及哪些工作负载能够容忍最终一致性的团队总是会发现这一限制：在生产中。正确的设计始于这种分类。用于生产线上异常检测的视频处理可以在边缘无缝地进行周期性同步。付款授权，没有。将两者混合在同一个架构模型中，因为“它更简单”是一个将作为事件返回的决定。
Offline-first 不是降级模式，它是正常模式
对于习惯了集中式云的团队来说，最困难的心理转变之一是将连接视为可选功能，而不是保证功能。在成熟的边缘计算中，边缘节点根据定义自主运行。与中心的连接是机会性的——用于同步、更新模型、发送聚合数据。不适合正常操作。
这颠倒了设计逻辑。正确的问题不是“系统离线时我们该怎么办？”，而是“什么需要连接才能运行，以及我们如何最大限度地减少这种依赖性？”将断开连接视为例外的系统会积累无形的技术债务：当系统进入网络间歇性的环境（工厂、田野、行驶的车辆、农村地区）时，以隐式连接假设构建的每个功能都是定时炸弹。
离线优先设计需要为每个操作决定在没有同步的情况下正确的行为是什么：本地队列重试、本地决策稍后协调、阻塞直到连接可用。没有普遍的答案。每个用例都有正确的答案。
跨多个表面的分区安全性
在集中式架构中，您拥有安全边界。在边缘架构中，您有数十或数百个潜在的攻击面，物理和逻辑的，分布在不同的地理位置。受损的边缘节点不应危及整个系统，但确保这种隔离需要进行大多数云架构不需要做的工作。
认证和授权需要在本地进行，不依赖于中心。证书需要大规模管理。边缘设备固件需要安全的回滚更新管道，无需手动干预。我们之间以及我们与中心之间传输的数据需要端到端加密。异常监控需要在特定节点上的可疑行为传播之前对其进行检测。
从集中式 SaaS 转向边缘计算的团队始终低估了这一成本。不是因为他们粗心，而是因为他们从来不需要考虑物理设备安全性、没有直接访问的节点上的凭证轮换，或者分布式基础设施中的爆炸半径隔离。
哪些工作负载属于边缘，哪些工作负载应该位于中心
将工作负载转移到边缘的决定应遵循三个标准：延迟敏感性、本地生成的数据量以及对暂时同步丢失的容忍度。实时图像处理、机器学习模型对传感器数据的推理、在发送到中心之前过滤和聚合遥测数据——在这些情况下，边缘解决了集中式云无法以经济可行的方式解决的实际问题。
依赖于全局状态视图、需要同时跨多个节点进行协调或具有强一致性审计要求的工作负载应保持集中化。试图将这些工作负载推向边缘以“利用基础设施”会带来复杂性，但没有任何好处。最强大的架构并不是将所有内容移至边缘的架构，而是根据实际特征分配工作负载的架构，而不是工程团队对最新技术的热情。
实际的出发点是根据所需的延迟、生成的数据量、所需的同步频率和全局状态依赖性来映射每个关键工作负载。这种映射揭示了边缘在哪里解决了真正的问题，在哪里它只会增加复杂性。
另请阅读
- [边缘计算架构：分布式处理策略2
- [边缘计算：为什么计算正在离开云而向数据靠拢3
- [工厂中的边缘计算：本地处理更有意义4
- [边缘和物联网的 RISC-V：为什么开放架构很重要5
- [Web 应用程序的延迟：每个团队都需要了解的基础知识6
- [浏览器之外的WebAssembly：缺失的通用执行层7