网络的未来在边缘
在最初，只有一台计算机放在瑞士地下室的桌子上。它有一个红色的标签
32 年后，全球各地都有数亿台这种计算机。一些甚至默认情况下处于关机状态。
但是，为网络开发仍然感觉只有一台机器。我们开发就像我们的代码要部署在弗吉尼亚、加州或瑞士某个大型数据中心的单个服务器实例上。
但这不再需要这样。多年来，任何静态内容都从全球各地的 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每次请求都路由到最佳选项。
集中式服务器模型适用于许多应用程序，并将继续适用于许多应用程序。但网络的规模和网络的未来正在与这种模型作斗争。让我们看看这种架构是如何形成的，以及它在过去几年中是如何（以及为什么）发生变化的。
服务器作为一种概念是在 网络工作组 1969 年的 RFC 中引入的。蒂姆·伯纳斯·李办公室的那台 NeXT 机器是第一台 Web 服务器，但在那时，互联网已经运行了 20 多年。
1969 年的 RFC 为“服务器主机”与 ARPANET 上用户之间如何传输和接收数据奠定了基础。ARPANET 是最初连接美国西部四所大学的最初由军方资助的互联网。该服务器在 1971 年启动并运行，一篇名为 “ARPANET 上的服务器主机系统” 的论文在 1977 年由加州大学洛杉矶分校（ARPANET 的一个连接）的罗伯特·布拉登发表，该论文详细介绍了最初的设置
本文描述了主机软件扩展的设计，这些扩展允许运行广泛使用操作系统的规模庞大的机器为 ARPANET 提供服务。自 1971 年以来，该软件使主机（加州大学洛杉矶分校的 IBM 360/91）能够为 ARPANET 用户提供生产计算服务。
这是第一个互联网服务器：IBM 360/91。硬件和软件已经改变，您不再自行构建，但从根本上说，这仍然是互联网今天的工作方式：服务器提供服务。
将内容缓存在靠近用户的区域
这种架构已经运行了很长时间。但是到了 90 年代后期和 2000 年代初期，当网络开始变得庞大时，一些裂缝开始出现。
第一个是 Akamai 在 1998 年推出第一个内容交付网络 (CDN) 时称之为“热点”。基本上，服务器因流量过多而崩溃（因为受欢迎程度），或者早期的 DDoS 攻击 来自 90 年代的黑客。
Akamai 的 CDN 在分布式服务器系统中缓存内容。请求被路由到这些服务器中最接近的服务器。但是，这些服务器仅限于静态文件：您的网站的 HTML 和 CSS，或其中的图像、视频或其他内容。任何动态内容仍然必须由您的核心服务器处理。
CDN 仍然是现代网络的核心组件。大多数静态文件都缓存在某处。您第一次访问网站时，可能会直接从原始服务器提取 HTML、CSS 或图像，但随后它们将缓存在靠近您的节点上，因此您（以及您网络区域中的其他人）将在之后获得缓存的内容。
更少的服务器，更多的无服务器
服务器在与过载相反的方向也有问题：未充分利用。服务器（如蒂姆·伯纳斯·李的机器，无法“关闭”）必须始终处于开启状态。即使您的应用程序每天只访问一次，持续 10 秒，您仍然要为剩余的 86,390 秒付费。
无服务器可以缓解这个问题。它们可以按需启动和关闭。“无服务器”是一个误称 - 仍然涉及服务器。但是，您没有一个始终处于开启状态的专用服务器。相反，服务器是事件驱动的，只有在发出请求时才会启动。
虽然有更早的版本，但 AWS Lambda 是第一个被广泛使用的无服务器框架。
无服务器的好处有两方面
- 您只需为使用付费 - 如果您的应用程序只发生了 10 秒，那么只需为这 10 秒付费。
- 您无需担心服务器的 DevOps 方面。无需规划、管理或维护。
缺点主要来自性能。无服务器函数存在“冷启动”问题，其中每次都需要配置资源，从而增加延迟。而且，无服务器的服务器仍然是集中式的，因此您仍然要进行长时间的往返。
因此，我们来到了现在。服务器并没有消失，但它们离得很远，而且可能崩溃；CDN 将您的内容缓存在靠近用户的区域，但仅限于静态内容；而无服务器意味着更少的 DevOps 和（可能）更低的成本，但冷启动导致更高的延迟。
生活在边缘
边缘计算的魅力在于它将 CDN（靠近用户）和无服务器（运行函数）的最佳部分结合在一起。
使用边缘计算，您可以在靠近用户的环境中执行自定义代码。这带来了很多好处。
性能提升
这是您的用户唯一关心的事情。您的网站加载速度快吗？它会挂起吗？使用它令人沮丧吗？
由于网站或应用程序是从靠近用户的边缘服务器提供服务的，因此它将比从集中式服务器提供服务的速度更快。
但性能优势并不止于此。由于计算是在边缘执行的，而不是由用户的浏览器执行的。
- 应用程序对最终用户的机器消耗的资源更少，因此 CPU 和内存的使用更少，浏览器挂起的可能性也更小。
- 发送到最终用户的有效负载更小，因此使用的带宽更少。
- 由于函数在受控环境中运行，因此函数和 API 的行为一致。
安全性提升
将计算从客户端/设备迁移到无服务器边缘，还可以减少对应用程序的潜在攻击媒介。正如 Deno DX 工程主管 Kitson Kelly 在 这句话中所说，“这意味着您立即减少了向最终用户公开的攻击面。”他说（为清晰起见，进行了缩写）
您的设备不需要向后端服务发出 API 调用。我认为我们所有人都不得不抵御这种攻击。但是，如果您将计算从设备上移开，并且您只发送 HTML 和 CSS，那么您就消除了这个问题。从您的网络中发送的唯一内容是您想要呈现给客户的内容。
此外，DDoS 攻击更加困难。任何攻击者都无法攻击一台服务器，他们需要攻击数十台、数百台，甚至可能是全球数千台服务器。即使他们成功地使 10 台服务器脱机，也可能还有 20 台可用服务器可以将流量重新路由到那里。
开发者体验提升
现在，编写边缘代码比它需要的那样复杂。在很大程度上，这是由于边缘开发的混合性质。大多数实施它的框架不是边缘优先的，因此开发人员必须选择是否在边缘或浏览器中渲染任何给定的函数或页面。
这使得边缘开发更加复杂。但更新的框架，例如 Fresh，默认情况下不会向客户端提供任何 JavaScript，通过采用服务器端渲染和岛屿架构，简化了针对边缘的优化。使用 Fresh 和我们的全球分布式 JavaScript 无服务器边缘网络 Deno Deploy 的开发人员可以获得边缘和延迟优化的优势，例如 实现完美的 Lighthouse 得分。
边缘计算是互联网的下一个迭代。从 IBM 360/91 到伯纳斯-李的 NeXT 机器，从 Akamai 的 CDN 到亚马逊的数据中心，再到无服务器，最后到边缘计算。每个阶段都建立在最后一个阶段的基础上，汲取经验教训并纠正错误。边缘计算是使网络成为用户和开发人员更快、更安全的地方的下一阶段。