【系统架构设计】边缘计算架构：算力下沉的设计挑战
内容提要
本文探讨边缘计算架构，指出其核心矛盾是地理分散与一致性，而非AI推理的算力集中。文章强调边缘PoP是分布式系统，默认最终一致，需处理控制面配置传播、回源风暴、会话亲和等难题。通过Discord案例展示有状态负载上边缘的挑战，并讨论多租户隔离安全。结论是边缘计算需针对状态形状选择合适方案，无通用解法。
延伸解读
边缘计算的核心矛盾：地理分散与一致性
文章指出，边缘计算与AI推理的工程约束不同，其核心矛盾是地理分散与一致性，而非算力集中。边缘PoP是分布式系统，默认最终一致，需处理跨PoP的读写一致性问题。架构师应明确，将区域机上的单体应用复制到多个PoP并不能自动获得全球低延迟，反而会面临一致性、配置传播、回源风暴和本地状态等更棘手的问题。
控制面与数据面的爆炸半径需分别建模
文章强调，控制面推送的陈旧配置与数据面的陈旧缓存是两类不同的爆炸半径。控制面需处理配置如何快速抵达数千节点，以及旧配置滞留的影响范围；数据面则需关注缓存未命中、主动失效和边缘写回源站可能放大源站压力。设计时应分别建模，并采用版本化、可回滚的配置推送机制，以及Origin Shield、SWR等缓解措施。
Anycast不提供可靠的会话亲和性
文章指出，Anycast的“最近”是单流视角，多方有状态会话需要应用层放置，不能假设网络层亲和足够。Anycast与ECMP下，会话亲和并不稳定，粘滞失败可能将用户绑死在即将下线的节点。对于长连接或实时媒体，应避免依赖Anycast进行会话保持，而应采用应用层显式放置或使用Durable Objects等平台级抽象。
多租户隔离的安全边界在沙箱层
文章认为，多租户边缘计算的安全边界在Isolate/沙箱层，但Spectre类侧信道使“证明级隔离”仍是开放问题。Cloudflare采用V8 Isolate而非容器/VM，以换取毫秒级启动和低内存，但需通过能力API、进程隔离等缓解措施。架构师应认识到，这种隔离并非证明级，高敏感负载需额外评估风险。
Q&A
边缘计算的核心矛盾是什么？
边缘计算的核心矛盾是地理分散与一致性，而不是AI推理的算力集中与尾延迟。
边缘计算中，为什么默认是最终一致性？
因为边缘PoP之间没有共享磁盘，跨PoP的读写同步延迟高且链路不可靠，在CAP理论下，为了可用性，边缘副本通常采用AP模式，即最终一致性。
边缘计算中，配置传播的主要挑战是什么？
配置传播的主要挑战包括：如何将WAF规则、路由表、租户代码等配置在分钟级内推送到数千个节点，以及旧配置滞留时可能造成的爆炸半径，例如安全规则差异导致部分PoP暴露漏洞窗口。
什么是回源风暴？如何缓解？
回源风暴是指大量缓存未命中同时发生，导致源站压力激增的现象。缓解方法包括使用Origin Shield、stale-while-revalidate、请求合并（singleflight）以及按标签预热等。
为什么Anycast不能保证会话亲和？
因为Anycast通过BGP路由将请求导向最近的PoP，但同一TCP连接内的包可能因ECMP哈希变化而落在不同机器上，且RFC 7094指出Anycast对长连接流缺乏简单的失败语义，因此会话亲和性不稳定。
Discord将语音服务迁移到边缘时遇到了哪些挑战？
Discord迁移到Cloudflare边缘时遇到的主要挑战包括：最近PoP不一定是多方通话的最佳位置（如冰岛案例）、服务发现方向反转（主机主动注册）、共享NIC导致的丢包和延迟问题，以及25秒无日志卡顿（由脏页刷新引起）。
边缘计算中，多租户隔离的主要安全风险是什么？
主要风险是Spectre类侧信道攻击，因为Workers使用V8 Isolate共享宿主地址空间，无法提供证明级的隔离，只能通过拖慢攻击等缓解措施。
边缘计算中，强一致性如何实现？
强一致性可以通过缩小作用域实现，例如在单个PoP内使用本地SQLite或Raft小组，或者使用全局单writer模型（如Durable Objects），或者写穿回源站（Edge作为代理）。
