边缘计算将推动 CDN 进入新时代 由 边缘计算社区发布于 2019-08-29 15:43:01CDN(内容分发网络)属于边缘应用程序,后者则是CDN 服务的一个超集。我们正生活在一个超级连接的世界当中,所有的东西都可以被推至云端。将内容放在一个地方,站在管理层的角度这种想法可能是有用的,但是现在可以说是多余的。如今用户和数据已经变得无处不在。这种发展趋势正使得客户的期望值不断飙升。人们对高质量服务的期望值越来越高,与此同时客户的耐心也正变得越来越低。过去,人们可以耐心地等待 10 个小时来下载内容,但是现在这显然是不可能的事情。如今虽然我们都有着很高的期望值并且对性能也有着很高的要求,然而在另一方面顾虑也是存在的。互联网是一个很神奇的地方,它们有着不可预测的非对称模式、缓冲膨胀以及一系列与性能相关的问题。此外,互联网正在以越来越快的速度不断增长。到2020 年,在互联网上每人每天的流量预计将达到1.5 吉字节（兆字节的1024倍）。未来,由物联网生成的数据将远远超过这一数据量。例如,实现连网的飞机每天可产生大约5 太字节的数据。这种呈螺旋式增长的数据量需要一种新的数据管理方法,迫使我们重新思考交付应用程序的方式。为什么呢?因为所有这些信息都无法由单个云或内部数据中心处理。延迟始终是个问题。例如,在虚拟现实(VR)中,延迟超过7 毫秒就会引起晕动病。当需要实时做出决策时,我们会面临无法将数据发送到云端的问题。不过不要紧,我们可以使用边缘计算和多CDN设计来解决这一问题。引入边缘计算和多CDN设计 云部署、全物视频(all-things-video)、物联网和边缘计算正在为CDN 和多CDN 设计带来契机。通常,多CDN 为一种包含了多个CDN 提供商的实现模式。利用不同的计量指标可实现流量定向,从而实现流量负载在不同提供商之间平衡或进行失效备援。边缘计算将操作尽可能地移动到了源头。这是物理世界与数字世界互动的关键所在。从逻辑上讲,边缘计算的去中心化方法不会替代集中化方法。它们之间的关系是相互补充的关系,应用程序可以根据它们在网络中的位置以最佳方式运行。例如,在物联网中,节省电池寿命至关重要。假设一个物联网设备以 10ms 往返时延(RTT)处理事务,而不是100ms RTT,那么它们的电池寿命便可延长10 倍。 互联网是性能瓶颈 互联网的设计原则是每个人都可以与其他任何人进行对话,因此它们提供的是通用连接,无论是否需要。虽然网络地址转换(NAT)会带来一些设计变化,但是无论在哪里,互联网的角色在连接方面基本保持不变。使用这种类型的连接模型,距离是应用程序性能的重要决定因素。无论缓冲区有多大或怎么优化设备性能,地球另一侧的用户都会受到影响。由于数据包在实际数据传输之前会来回传递,因此需要经历较长的 RTT。尽管釆取了缓存和流量重新定向技术,但是到目前为止取得的成功只是有限的。 应用程序交付原则 传输控制协议(TCP)的启用时间可以追溯到20 世纪70 年代后期。背景是假设所有服务都在局域网(LAN)上并且没有丢包现象。在它们被设计时,还没有出现实时流量,例如对延迟和抖动非常敏感的语音和视频。TCP的设计初衷是为了易用性和可靠性,而不是为了提高性能。用户实际上需要优化TCP 堆栈。这就是CDN 非常擅长执行此类任务的原因。例如,如果收到了一个来自移动电话的连接,那么CDN 在一开始就会假设存在高抖动和丢包的情况。这使得它们能够正确地调整TCP 窗口大小,以准确地匹配网络条件。那么我们应当如何提升它们的性能,选择哪些选项设置呢?在一般情况下,许多人都希望能够降低延迟。但是对于视频流等应用程序,我们无法知道延迟是否是视频缓冲造成的。人们只能假设较少的缓冲可以缓解延迟现象。在这种情况下,基于吞吐量的测量远比更高的性能指标要合理,因为它们能够告诉我们对象的加载速度。我们还要考虑页面加载时间。在网络层中,人们开发出了首字节时间(TTFB)和 ping。但是由于所有东西都被打在一个数据包里,因此这些机制并没有多好的用户体验。ping 也不会显示带宽问题。如果一旦数据包丢包率超过 5%,并且用户正在测算TTFB(即第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 运行时引擎,其只运行客户的代码。用户还可以选择使用谷歌V8 开源高性能 Java Script 和WebAssembly 引擎。尽管如此,我们需要面对一个现实,那就是如果持续建造大量的PoP 将会出现收益递减的情况。如果涉及到诸如移动设备之类的应用程序时,采用以PoP 为主体的解决方案会导致失败。所以我们需要找到其他的解决方案。在即将到来的时代里,我们将会看到一个大多数应用程序开始向全球性应用程序转变的趋势,这意味着边缘应用程序的崛起。无论用户处于什么位置,将所有应用程序放在某个地方必然会变得没有意义。本文作者Matt Conran 拥有超过19 年的网络行业从业经验,曾经服务于多个初创企业和政府机构。此外,他还作为高级架构师参与了全球某大型服务提供商和数据中心网络的建设工作。 作者：Matt Conran 编译：陈琳华转发扩散一起促进边缘计算领域知识传播推荐阅读
