术语 · 部署与运行

边缘运行时

Edge Runtime

让代码在靠近用户的边缘节点运行,以降低网络延迟。

代码搬到离用户最近的节点

距离就是延迟
代码搬过去,体验平过来
传统部署只有一个机房,全球用户都绕道而来;边缘运行时把代码复制到遍布全球的节点,就近响应。

换个角度想

边缘节点像连锁便利店:不管住哪,楼下都有一家。中心机房则是唯一的总店——住得远的人,买瓶水也要跨城。

同一个网站,东京用户为什么慢出两秒?

  1. 部署完成

    位置美国弗吉尼亚 × 1

    全球用户都得绕到这来

    一次部署

    自动分发到全球 300+ 节点

  2. 东京用户发起请求

    跨太平洋 · 往返上万公里

    东京用户发起请求

    接入东京节点 · 就在城里

  3. 在弗吉尼亚执行

    鉴权一次跨洋往返

    取页面再一次跨洋往返

    在东京节点执行

    鉴权就地完成

    页面就地返回

  4. 2.1 秒页面还没出来,用户已经想关了每次往返都在付距离的账
    0.1 秒东京用户像在访问本地网站近了,一切都快了

一次部署,全球分发

什么时候会遇到它

  1. 全球用户的站点

    各大洲访问速度都稳定,不再取决于机房建在哪。

  2. 边缘中间层

    鉴权、A/B 分流、重定向在边缘做,又快又省。

  3. Workers 这类平台

    Cloudflare Workers 等边缘平台:部署一次,全球生效。

想一想

机房在美国,日本用户抱怨网站打开要两秒多。把什么搬到边缘能立竿见影?

看答案

先把静态资源和可缓存页面放到边缘节点,再把鉴权、跳转这类轻逻辑放进边缘运行时——日本用户的请求在东京就被处理,不再横跨太平洋。

最容易踩的坑

边缘节点是轻量环境:不是所有 Node.js 能力都有,长计算和重依赖不适合。数据库还在中心时,边缘反复查库反而更慢——先算清数据在哪的账。

⌘K搜索知识库

最近收录

正在载入知识索引…