Web 的未来在边缘
起初，瑞士地下室的桌子上有一台电脑。它有一个红色墨水标签。
32 年后，全世界有数亿台该电脑的变体。有些甚至默认是关机的。
但是，Web 开发仍然感觉好像只有一台机器。我们开发时就好像我们的代码将被部署在弗吉尼亚州、加利福尼亚州或瑞士的某个大型数据中心的单个服务器实例上。
但现在不必再这样了。多年来，任何静态内容都从全球各地的 CDN 提供，靠近用户。现在，动态 Web 应用程序也开始如此。你可以将所有内容部署到任何地方。
什么是边缘？
当人们说“边缘”时，他们的意思是你的网站或应用程序将同时托管在全球各地的多台服务器上，始终靠近用户。当有人请求你的网站/应用程序时，他们将被定向到地理位置上离他们最近的服务器。这些分布式服务器不仅提供静态资源，还可以执行自定义代码，从而驱动动态 Web 应用程序。
将服务器移近最终用户也是一种物理方法来优化延迟。这意味着每次页面加载的延迟都更低。页面加载时间越长，用户就越有可能跳出。根据 Google 研究，加载速度从 1 秒变为 3 秒时，跳出率增加 32%。当速度从 1 秒变为 5 秒时，跳出率增加 90%。当页面在 2 秒内加载时，用户将访问 9 个页面，但当页面在 7 秒内加载时，用户只会访问 3 个页面。
这就是要点。现在是细微之处。
你已经构建了一个应用程序。它很酷。它可以做有趣的事情。你想向世界展示它，所以你部署了它。为了方便起见，你使用 Heroku。你 git push heroku main 然后前往 myfunapp.com 查看你的杰作。
默认情况下，Heroku 中的运行时部署在弗吉尼亚州北部的 AWS 数据中心。这对某些人来说很棒。例如，如果你住在离弗吉尼亚州北部数据农场仅几英里的地方。你发出的几乎所有请求都会非常快。但并非每个人都足够幸运地住在巨大的米色、无窗仓库附近。事实证明，有些人住在宜人的地方。
让我们看看对于托管在弗吉尼亚州的应用程序，世界各地不同位置的首次字节时间 (TTFB—服务器响应第一个数据字节的速度)
| 位置 | Heroku TTFB |
|---|---|
| 法兰克福 | 339.95 毫秒 |
| 阿姆斯特丹 | 382.62 毫秒 |
| 伦敦 | 338.09 毫秒 |
| 纽约 | 47.55 毫秒 |
| 达拉斯 | 144.64 毫秒 |
| 旧金山 | 302 毫秒 |
| 新加坡 | 944.14 毫秒 |
| 悉尼 | 889.85 毫秒 |
| 东京 | 672.49 毫秒 |
| 班加罗尔 | 984.39 毫秒 |
正如法兰克福人会说的那样，nicht so gut（不太好）。因为每个请求都必须从这些位置往返美国东部，所以用户离得越远，等待数据的时间就越长。
一旦你到达世界的另一端，即使只是从服务器获取第一个字节也需要将近一秒钟，更不用说单个页面的所有数据了。加上用户可能想要访问的站点上的所有页面，对于班加罗尔或悉尼 (或者，说实话，任何不在美国东部的人) 的任何人来说，这都是非常糟糕的体验。你正在失去页面浏览量、失去用户并损失金钱。
让我们在 deno.com 上重试我们的速度检查，该网站部署在我们的边缘网络 Deno Deploy 上
| 位置 | Heroku TTFB | Deno TTFB |
|---|---|---|
| 法兰克福 | 339.95 毫秒 | 28.45 毫秒 |
| 阿姆斯特丹 | 382.62 毫秒 | 29.72 毫秒 |
| 伦敦 | 338.09 毫秒 | 22.3 毫秒 |
| 纽约 | 47.55 毫秒 | 41.29 毫秒 |
| 达拉斯 | 144.64 毫秒 | 29.28 毫秒 |
| 旧金山 | 302 毫秒 | 44.24 毫秒 |
| 新加坡 | 944.14 毫秒 | 528.57 毫秒 |
| 悉尼 | 889.85 毫秒 | 26.46 毫秒 |
| 东京 | 672.49 毫秒 | 19.04 毫秒 |
| 班加罗尔 | 984.39 毫秒 | 98.23 毫秒 |
除了新加坡，我们获得了全球低于 100 毫秒的 TTFB。这是因为这些位置中的每一个都可以使用离他们最近的边缘服务器，而不是前往弗吉尼亚州获取站点。边缘的意义在于获得 50 毫秒的响应时间与 150 毫秒的响应时间。你可以使用 VPN 自行测试。如果你
curl -I https://deno.land你将获得离你位置最近的服务器
server: deno/us-east4-a使用 VPN 通过代理服务器路由我的请求，我们可以看到来自该位置最近的边缘服务器的响应。假设我们在日本，我们会得到
server: deno/asia-northeast1-a假设我们在爱尔兰，我们会得到
server: deno/europe-west2-a假设我们在澳大利亚悉尼，我们会得到
server: deno/australia-southeast1-b每次请求都会路由到最佳选项。
集中式服务器模型曾经奏效，并且对许多应用程序仍然有效。但是 Web 的规模和 Web 的未来正在与此模型作斗争。让我们回顾一下这种架构是如何形成的，以及多年来它如何 (以及为什么) 发生变化。
服务器作为一个概念是在 网络工作组 1969 年的 RFC 中引入的。蒂姆·伯纳斯·李办公室里的那台 NeXT 机器是第一台 Web 服务器，但到那时互联网已经发展了 20 多年。
69 年的 RFC 奠定了如何在 “服务器主机” 和 ARPANET (最初连接美国西部四所大学的 OG 军方资助的互联网) 上的用户之间传输和接收数据的基础。服务器于 1971 年启动并运行，罗伯特·布拉登 (ARPANET 上的连接之一) 于 1977 年在 UCLA 发表了一篇名为 “ARPANET 上的服务器主机系统” 的论文，详细介绍了最初的设置。
本文介绍了主机软件扩展的设计，这些扩展允许运行广泛使用的操作系统的大型机器为 ARPANET 提供服务。自 1971 年以来，该软件使 UCLA 的 IBM 360/91 主机能够为 ARPANET 用户提供生产计算服务。
这是第一台 互联网 服务器：IBM 360/91。硬件和软件已经改变，你不再需要自己构建，但从根本上来说，这仍然是当今互联网的工作方式：服务器提供服务。
将内容缓存到靠近用户的位置
这种架构在很长一段时间内都运行良好。但是到了 90 年代后期和 2000 年代初期，当 Web 开始变得庞大时，裂缝开始出现。
第一个问题是 Akamai 在 1998 年推出第一个内容分发网络 (CDN) 时所称的“热点”。基本上，服务器因流量过大而崩溃，或者来自 90 年代黑客 的早期 DDoS 攻击。
Akamai 的 CDN 将内容缓存在分布式服务器系统中。请求被路由到最近的服务器。但是，这些仅限于静态文件：你网站的 HTML 和 CSS，或其上的图像、视频或其他内容。任何动态内容仍然必须由你的核心服务器处理。
CDN 继续成为现代 Web 的核心组件。大多数静态文件都缓存在某个地方。你第一次访问网站时，可能会直接从源服务器拉取 HTML、CSS 或图像，但随后它们将被缓存在靠近你的节点上，因此你 (以及你网络区域中的其他人) 之后将获得缓存的内容。
更少的服务器，更多的 serverless
服务器在与过载相反的方向上也存在问题：利用率不足。服务器，就像蒂姆·伯纳斯·李的机器一样，不能“关闭电源”，必须 100% 的时间都处于运行状态。即使你的应用程序每天只有十秒钟的访问量，你仍然需要为其他 86,390 秒付费。
Serverless 缓解了这个问题。它们可以随意启动和关闭。“Serverless” 是一个用词不当的名称——仍然涉及到服务器。但是你没有一个始终运行的专用服务器。相反，服务器是事件驱动的，仅在发出请求时才会启动。
虽然有更早的版本，但 AWS Lambda 是第一个被广泛使用的 serverless 框架。
Serverless 的好处是双重的
- 你只需为你使用的东西付费——如果你的应用程序上只发生了这 10 秒钟的事情，那么就只支付这 10 秒钟的费用。
- 你不必担心服务器的所有 DevOps 方面。无需计划、无需管理、无需维护。
缺点主要来自性能。serverless 函数存在“冷启动”问题，其中每次都必须配置资源，从而增加延迟。而且，serverless 的服务器仍然是集中式的，因此你仍然需要进行长途往返。
因此，我们来到了现在。服务器并没有消亡，但它们很遥远并且可能会崩溃；CDN 将你的内容缓存到靠近用户的位置，但仅限于静态内容；而 serverless 意味着更少的 DevOps 和 (可能) 更低的成本，但冷启动会导致更高的延迟。
活在边缘
边缘的优点在于它结合了 CDN (靠近用户) 的最佳部分和 serverless (运行函数) 的最佳部分。
通过边缘，你可以执行靠近用户的自定义代码。这有很多好处。
更好的性能
这是你的用户唯一关心的事情。你的网站加载速度快吗？会卡顿吗？使用起来是否令人沮丧？
由于站点或应用程序是从附近的边缘服务器提供的，因此它将比在集中式服务器上更快。
但性能优势并不仅限于此。由于计算是在边缘执行的，而不是由用户的浏览器执行
- 应用程序对最终用户的机器资源占用更少，因此 CPU 和内存使用更少，浏览器卡顿的机会也更少。
- 发送到最终用户的有效负载更小，因此使用的带宽更少。
- 由于函数在受控环境中运行，因此函数和 API 的行为是一致的。
更好的安全性
将计算从客户端/设备移动到 serverless 边缘也减少了应用程序上潜在的攻击媒介。用 Deno 的 DX 工程主管 Kitson Kelly 的话来说，“这意味着你立即减少了暴露给最终用户的表面积。” 他说 (为了清晰起见，已缩写)
你的设备不必向你的后端服务发出 API 调用。我认为我们所有人都必须防御这一点。但是，如果你将计算从设备上移开，并且你发送的所有内容都是 HTML 和 CSS，那么你就消除了这个问题。唯一离开你网络的是你想要呈现给客户的内容。
此外，DDoS 攻击更加困难。任何攻击者都不是只攻击一台服务器，他们需要攻击全球数十个、数百个甚至数千个服务器。即使他们成功地使 10 台服务器脱机，也可能仍有 20 台可用服务器可以将流量重新路由到这些服务器。
更好的开发者体验
目前，为边缘编写代码比需要的要棘手。在很大程度上，这是由于边缘开发的混合性质。大多数实现它的框架都不是边缘优先的，因此开发人员必须选择任何给定的函数或页面是在边缘进行服务器端渲染还是在浏览器中渲染。
这使得边缘开发更加复杂。但是，更新的框架，例如 Fresh (默认情况下向客户端交付零 JavaScript)，通过采用服务器端渲染和 islands 架构，简化了边缘优化。使用 Fresh 和我们全球分布式的 JavaScript serverless 边缘网络 Deno Deploy 的开发人员可以获得边缘和延迟优化的好处，例如 实现完美的 Lighthouse 分数。
边缘是互联网的下一次迭代。从 IBM 360/91 到伯纳斯·李的 NeXT 机器，再到 Akamai 的 CDN，再到亚马逊的数据农场，再到 serverless，再到边缘。每个阶段都建立在前一个阶段的基础上，吸取教训并纠正错误。边缘是使 Web 成为用户和开发人员更快、更安全场所的下一个阶段。