边缘节点部署的延迟真相：58% vs 29% 的实测之外，热点和容量才是大坑
做后端的人看到“边缘计算”，第一反应通常是：把代码扔到离用户近的地方，RTT 降了就是赚。但拉出实测数据看，边缘部署真正要处理的不是延迟本身，而是延迟分布不均、容量有限和路由热点。这篇笔记整理一组 NSF 论文里的实测数据，以及 CDN 工程里的实际做法，说清楚什么时候边缘化值得，什么时候别硬上。
延迟收益是真的，但不是均匀的
一项基于 RIPE Atlas 的大规模测量：8456 个探测端点，对 6341 台 Akamai 边缘服务器和 69 个云数据中心做 RTT 测量。结果：约 58% 的探测端点到边缘服务器 RTT 小于 10ms，而就近云数据中心只有约 29% 达到同样延迟。
边缘的延迟优势是实打实的，但注意，这个优势不是均匀分布的。你不能假设把所有请求扔到边缘就都能吃到这 29 个百分点的差距。
幂律分布：按“就近原则”布点必出热点
更麻烦的是延迟的幂律分布。6341 台边缘服务器里，只有约 2855 台被至少一个探测端点选为“最近”。写成百分比，就是约 45% 的边缘服务器在就近路由下可能被用到，剩下 55% 几乎不会成为任何端点的最优解。
这意味着什么？完全按地理就近原则路由，流量会严重偏向少数热点节点，大多数节点却闲着。边缘提供方必须做非均匀部署——按实际用户密度、网络路径质量去布点，并且提前做负载均衡。否则热点先被打满，延迟再低也没用。
边缘节点的容量比云端敏感得多
云数据中心一台物理机塞几千台虚拟机，自动扩缩容和“资源无限”的错觉让容量问题被掩盖了。但边缘服务器往往就是一台小机器，放在 IXP、校园或机场，承接的是真实的终端请求。在人口密集区，边缘节点可能因为物理容量直接承接不了请求。容量规划在边缘比云端敏感得多，误判的代价是直接丢请求，而不是云上等调度器慢慢扩容。
CDN 是怎么用边缘节点的
传统 CDN 边缘节点位于网络逻辑边缘，作为端和源站之间的连接点。主要工作：
- 就近缓存静态资源：图片、HTML、JS
- 从源站卸载流量，防止源站过载
- 放在 IXP 减少网络跳数
- 消除 trombone 效应：没有 CDN 时，同城跨街请求可能先绕到全国骨干节点再回来，边缘节点把路径拉直
注意：CDN 边缘不替代源站逻辑。鉴权、数据库、状态这类东西仍然留在源站。边缘节点只管缓存和卸载，它不是把你的整个后端搬到机房。
Edge CDN 和 vCDN：推进到几英里内的代价
传统 CDN 服务器集中在 IXP/数据中心，对直播和游戏这种毫秒级 QoE 场景还是不够近。Edge CDN 把服务器放得更深——移动核心网 inner edge 或 RAN outer edge，或者校园、机场这类本地场地。
vCDN 是虚拟化的 CDN，跑在共享基础设施、裸金属或容器上。取舍在于：虚拟化层本身吃服务器容量。高吞吐单机处理海量数据时，上虚拟化可能会成为瓶颈，这种场景直接跑裸金属更实在。
Vercel 的 CDN 分层是一个值得参考的工程模式
请求先到最近的 PoP（目前 126 个），PoP 终结 TCP 连接，并路由到最近的 region；region 负责终结 TLS 和压缩。两级缓存：
- CDN cache：在就近 PoP 层，靠 Cache-Control 控制
- ISR cache：在函数 region 的持久层，最长 31 天
另外还有 request collapsing，把多个并发请求合并成一个回源请求，避免缓存击穿。
这个分层的关键在于：PoP 只干连接终止、路由和缓存，TLS 和压缩集中在 region 做。这样边缘节点不需要承担完整的计算开销，容量压力可控。
什么时候边缘化值得，什么时候别硬上
值得的场景：静态资源、视频、软件包下载。这些负载缓存命中率高、无状态、不需要回源拼接数据，放到边缘几乎都是正收益。
对延迟特别敏感且本地可处理的计算（游戏状态同步、实时媒体处理），如果能在边缘完成而不依赖远端数据库，推进到几英里内的 Edge CDN 也值得考虑。
别硬上的场景：计算强依赖源站数据或鉴权。边缘节点只是把问题挪了个位置——用户到边缘的 RTT 降了，但边缘到源站的 RTT 还在，某些场景下总链路反而更糟。
另外，如果业务有突发性且难以预测，边缘的物理容量可能扛不住。云端自动扩缩容能处理的波动，边缘一台小机器不一定接得住。
给一个判断标准：边缘化之前，先用真实用户轨迹算一下当前到源站的 RTT 分布，再看边缘节点能覆盖多少百分比的 <10ms 请求。如果覆盖率没有显著提升，或者负载分布过于集中，先别硬上。把缓存层做好，收益可能更大。