行业新闻与博客

CDN 是边缘应用程序，边缘应用程序是 CDN 正在执行的操作的超集。

我们生活在一个超级连接的世界，现在任何东西都可以推向云端。将内容放在一个地方的想法，从管理层的角度来看可能是有用的，现在是多余的。今天，用户和数据无处不在。

由于这种演变，客户的期望值飙升。现在人们对高质量服务的期望越来越高，客户的耐心也越来越低。在过去，人们可以耐心地等待 10 个小时来下载内容。但这肯定不是目前的情况。如今我们有很高的期望和高性能要求，但另一方面也存在顾虑。互联网是一个奇怪的地方，具有不可预测的非对称模式，缓冲膨胀以及我在 Network Insight 上撰写的其他与性能相关的问题列表。

此外，互联网正在以加速的速度增长。到 2020年，互联网每人每天的流量预计将达到 1.5 千兆字节。在未来的时代，由物体驱动的物联网（IoT）世界也将远远取代这些数据。例如，连接的飞机每天将产生大约 5 太字节的数据。这种螺旋式的数量需要一种新的数据管理方法，并迫使我们重新思考如何交付应用程序。

为什么？因为所有这些信息都无法由单个云或内部部署位置处理。延迟始终是个问题。例如，在虚拟现实（VR）中，超过 7 毫秒的任何东西都会引起晕动病。当需要实时做出决策时，您无法将数据发送到云。但是，您可以使用边缘计算和多 CDN 设计。

引入边缘计算和多 CDN

云采用率，全事物视频，物联网和边缘计算正在为 CDN 和多 CDN 设计带来生机。通常，多 CDN 是包含多个 CDN 供应商的实现模式。通过使用不同的度量来执行流量方向，从而可以在不同供应商之间对流量进行负载平衡或失败。

边缘计算将动作尽可能地移动到源。这是物理世界与数字世界互动的关键。从逻辑上讲，边缘计算的分散方法不会接管集中式方法。它们将相互补充，以便应用程序可以在其峰值级别运行，具体取决于它在网络中的位置。

例如，在物联网中，节省电池寿命至关重要。假设一个物联网设备可以在 10ms 往返时间（RTT）内进行交易，而不是 100ms RTT。因此，它可以使用 10 倍的电池。

互联网，性能瓶颈

互联网的设计原则是每个人都可以与每个人交谈，从而提供通用的连接，无论是否需要。网络地址转换（NAT）是最大的设计变更。然而，无论位置如何，互联网的角色在连接方面基本保持不变。

使用这种类型的连接模型，距离是应用程序性能的重要决定因素。无论缓冲区大小或其他设备优化如何，地球另一侧的用户都将受到影响。由于数据包在实际数据传输之前来回传递，因此经历了长 RTT。尽管正在使用缓存和流量重定向，但到目前为止已经取得了有限的成功。

申请交付的原则

当传输控制协议（TCP）启动时，它认为它回到了 20 世纪 70年代后期。它假定所有服务都在局域网（LAN）上，并且没有丢包。然后它从那里开始向后工作。回到设计时，我们没有实时流量，例如语音和视频，这是延迟和抖动敏感的。

理想情况下，TCP 的设计是为了易用性和可靠性，而不是为了提高性能。您实际上需要优化 TCP 堆栈。这就是 CDN 非常擅长执行此类任务的原因。例如，如果从移动电话接收到连接，则 CDN 将首先假设存在高抖动和丢包。这允许他们正确地调整 TCP 窗口的大小，以准确匹配网络条件。

你如何放大表现，你有什么选择？从一般意义上讲，许多人都希望降低延迟。但是，对于视频流等应用程序，延迟不会告诉您视频是否要缓冲。人们只能假设较低的延迟会导致较少的缓冲。在这种情况下，基于吞吐量的测量是一个更好的性能指标，因为它将告诉您对象加载的速度。

我们还要考虑页面加载时间。在网络级别，是第一个字节（TTFB）和 ping 的时间。但是，这些机制并没有告诉您很多用户体验，因为所有内容都适合一个数据包。使用 ping 不会通知您带宽问题。

如果一旦数据包丢失超过 5％，并且您正在测量第一个字节（即第 4 个数据包）的时间，网页会变慢 25％ - 您究竟能学到什么？TTFB 与堆栈上一层的互联网控制消息协议（ICMP）请求相当。如果有什么东西被破坏，那就好了，但如果有不好的问题则不行。

当您检查 TTFB 测量的历史时，您会发现由于缺乏真实用户监控（RUM）测量而部署它。以前，TTFB 在估算某物的加载速度方面表现不错，但我们不必再近似，因为我们可以用 RUM 测量它。RUM 是来自最终用户的测量值。一个示例可以是从提供给实际用户的网页生成的度量。

最后，TTFB，ping 和页面加载时间不是复杂的测量。我们应该尽可能多地选择 RUM 时间测量。这提供了更准确的用户体验图。这是过去十年来变得至关重要的事情。

现在我们生活在一个 RUM 世界中，这让我们可以根据对业务用户的重要性来构建我们的网络。所有 CDN 都应针对 RUM 测量。为此，他们可能需要与交通管理系统集成，以智能地衡量最终用户真正看到的内容。

需要多 CDN

首先，选择多 CDN 环境的原因是可用性和性能。没有任何一个 CDN 可以成为世界上每个人和世界各地最快的 CDN。由于互联网的连接模式，这是不可能的。但是，将两个甚至更多 CDN 提供商中的最佳组合在一起将提高性能。

与单个 CDN 相比，多 CDN 将提供更快的性能和更高的可用性。一个好的设计是运行两个可用区域。更好的设计是使用单个 CDN 提供程序运行两个可用区。但是，优越的设计是在多 CDN 环境中运行两个可用区域。

边缘应用程序将成为新的常态

不久之前，从重型物理单片架构到敏捷云的过渡。但真正发生的是从物理设备到基于虚拟云的设备的过渡。也许现在是我们应该问的时间，这是我们真正想要的未来吗？

引入边缘应用程序的主要问题之一是心态。要让自己或同行相信，您花费的所有时间和投资的基础设施并不是您业务的最佳前进方式。 

尽管云已经引起了巨大轰动，但仅仅因为您迁移到云并不意味着您的应用程序运行得更快。实际上，您所做的只是抽象体系结构的物理部分并向其他人管理它。然而，云为边缘应用对话打开了大门。我们已经迈出了迈向云的第一步，现在是时候进行第二步了。

基本上，当您考虑边缘应用程序时：它的简单性是可编程的 CDN。CDN 是边缘应用程序，边缘应用程序是 CDN 正在执行的操作的超集。边缘应用程序表示边缘的云计算。它是将应用程序分布得更靠近源的范例，以实现更低的延迟，额外的弹性和简化的基础架构，您仍然可以拥有控制权和隐私权。

从体系结构的角度来看，边缘应用程序比部署集中式应用程序提供了更多的弹性。在当今充满期望的世界中，弹性是业务连续性的必要条件。边缘应用程序允许您将基础架构折叠为更便宜，更简单且更注重应用程序的架构。广泛的基础设施越少，您就越有时间专注于对您的业务至关重要的事情 - 客户。

边缘架构的一个例子

边缘体系结构的一个例子是在每个 PoP 中，每个应用程序都有自己独立的 JavaScript（JS）环境。JavaScript 非常适合安全隔离，性能可以保证扩展。JavaScript 是一个专用的隔离实例，它在边缘执行代码。

最有可能的是，每个 JavaScript 都有自己的虚拟机（VM）。VM 正在执行的唯一操作是 JavaScript 运行时引擎，它运行的唯一操作是客户的代码。可以使用 Google V8 开源高性能 JavaScript 和 WebAssembly 引擎。

让我们面对现实，如果你继续建造更多的 PoP，你将会达到收益递减规律。当涉及到诸如移动设备之类的应用程序时，在投入 PoP 以形成解决方案时，你真的会被淘汰出局。所以我们需要找到另一种解决方案。

非常感谢您对亚洲注册的支持与信任！

禁止转载