关于边缘计算:从静态动态到全站看阿里云全站加速的技术演进

7次阅读

共计 3800 个字符,预计需要花费 10 分钟才能阅读完成。

所谓的抄近道,走的人多了,也就堵了。网络高速路亦是如此。

作者|原丘
编辑|IMMENSE

01 源起:“减速”的经典架构

CDN 并不是互联网诞生之初就存在的。

当没有 CDN 减速时,大量的用户申请须要穿梭互联网骨干网能力取得源站的内容。

上世纪 80 年代,互联网技术开始民用,人们次要通过拨号来拜访网络,因为用户少、带宽小,并没有对骨干网和服务器带来压力。

随着互联网高速倒退,应用互联网的用户数量呈现井喷式增长,加之宽带接入网的呈现,内容源服务器和骨干网络的压力越来越大。

因为网络距离远以及骨干网的网络拥塞问题,端到端的申请时延会十分长,无奈及时响应用户的拜访需要,这会重大影响用户体验。

在晚期 CDN 架构设计中,外围的指标,是通过内容的散发来实现 ” 减速 ”,实质逻辑就是将文件从源站“搬”到离用户近的中央,缩短内容传输的物理间隔来实现所谓的 ” 减速 ” 成果。

那么基于这个前提和背景,技术上的重点,就是怎么让尽可能少的流量穿过边缘集群回到源站,即尽可能的进步内容的命中率。

事实上,业界的厂商根本也都是在这个方面注入了最多的技术投入,尽量将拜访终结在边缘,其次在上游减少缓存层(很多厂商叫做两头源),来 ” 拦挡 ” 回源流量。

所以,经典的 CDN 动态减速,节点架构依照分层的设计就牵强附会了,即从边缘 -> 一级父层 ->…->N 级父 -> 源站。

应用 CDN 之后,因为大量申请在边缘就能够找到其所需的内容,因而穿梭互联网骨干网的流量大幅缩小。

这样,既无效加重了骨干网的流量压力,也节俭了 SP(Service Provider,服务提供商)的带宽老本,促成了互联网业务的疾速倒退。

02 有余:动静场景下的失控

然而,在局部场景下,CDN 经典技术架构并不是万能的。

以电商、社交互动媒体、博客为代表的互联网业务,存在大量不能缓存、须要实时回源的动静内容减速场景。

比方:电商平台波及了用户注册、登录、在线领取、秒杀等须要动静减速的场景。

从流量上来说,一个域名全网的流量,随着层级的深刻,流量逐级缩小,最终从几个节点回到源站,面对一些内容热度比拟高的状况,回源量会更少。

从宏观来讲,个别的逻辑是把内容送到离客户最近的边缘节点。那么,对于后续的父层节点来说(Parent Node),仍然遵循同样的逻辑,即:一级父离 edge 尽量近,二级父离一级父尽量近。

最终出现的状态就是 CDN 的节点集中在离客户端比拟近的中央。

基于此,会呈现一种不可避免的状况,文件没有在 CDN 的网内节点命中,必须要回源,这就会经验一个比拟长的非 CDN 可控的公网链路回源。

从品质的角度来看,回源引起的品质劣化对整体域名品质的影响权重不肯定很高。

举个直观的例子,如果客户域名的 CDN 命中率是 95%,即回源流量占比仅为 5%,那么即便这部分流量呈现响应工夫异样,那么整体也只影响 5% 左右流量。

基于下面的论证,如果是一个须要 100% 回源的流量,比方登录,提交表单,举荐列表,领取等场景下的流量。当把流量切到 CDN 动态减速平台,那么面对节点高度集中在边缘,通过一个长距离不可控的公网链路回源,整体的品质将很容易失控。

03 思考:动静减速的外围

对于纯动静的流量,外围的问题比拟明确:

当客户流量接入到 CDN 边缘节点之后,须要逾越一个很长的物理间隔将申请送到客户源站,CDN 怎么承诺提供一个低提早,高稳固的服务质量,就是一个外围的课题。

从边缘的接入角度来看,用户的动静流量根本都是 https 接入,那么基于 CDN 宽泛散布的边缘节点来说,能够将客户端拜访的 TCP 握手和 SSL 握手,卸载到 CDN 边缘节点,从而让原本须要长距离跟源站进行屡次握手交互的操作,失去了极大的性能改善。

从节点内的传输的角度来看,要想做到最优的提早,就须要利用最短最优的链路,同时在这个链路上配合最高效的传输。

“所谓“修好路,跑好车”,这两项能力必须同时满足,能力施展最优的减速成果。”

再好的链路,如果两头传输随同额定的交互开销,例如过多的 tcp 握手,ssl 握手等,也很难接受住负向影响。

咱们把这两项能力称为“选路能力”和“传输能力”,核心技术点就是:传输优化与动静选路。

04“修好路”:核心技术之传输优化

对于低提早来说,动静流量往往都是小文件内容为主,即一次网络交互就实现,所以传统的 CDN 基于大文件下载的 TCP 优化,难以施展很大的作用。

其根本原因在于:

目前 TCP 优化少数都是基于多包的统计和测量等形式,来探测网络的最小提早和最大窗口等维度的数据,来调整收发包数量和频率。那么一次网络交互的场景(典型的动静业务场景,例如弹幕、交易领取、登录等),就显著不实用。

所以对于动静流量的减速,首包 (根本就等于响应工夫) 就是一个外围指标。不像大文件场景,因为下载时长可能很多都是秒级以上,首包的多少,占比总的实现工夫比例不是很高。

对于动静流量,首包根本就是全副。它的工夫量级简直等于一次 tcp 握手的工夫,那么在传输过程中有额定的长链路握手开销,由此带来的影响是微小的。

对于动静流量两项外围能力中的“传输能力”,外围其实是 0rtt 能力,所谓的 0rtt 指的是,CDN 节点内除了必须产生的一次传输有效载荷行为外,不会呈现网络上的额定往返(即所谓“0”)。

在这项能力方面,阿里云的全站减速,通过多年的打磨,构建了一个用户态的利用网络,让 CDN 边缘和源站之间得以实现运行时零握手开销的传输管道。

05“跑好车”:核心技术之动静选路

对于选路零碎,基于阿里云全站减速 DCDN 多年的业务教训和演进,在此文次要抛出一些观点,来供读者进一步的思考。

后面谈到,在 CDN 的默认架构下,回源波及很长的公网链路,这段链路可能要逾越不通的省份,国家,甚至大洲,又或者是须要穿过不同品种的运营商网络。

而在广域网的路由中,有很多简单的地区和商业下面的定制策略,绕路之类的状况是经常出现的。

一种卓有成效的计划就是基于 CDN 宽泛散布的节点,通过节点间的探测,配合 CDN 节点与各运营商的宽泛连通性,结构“门路切割”来尽量躲避穿梭长链路可能存在的问题。

所谓的“门路切割”就是构建多段 TCP 来疏导数据,在路由层面尽量依照预期的链路来走。

对于选路来说,区别于通用的三层路由选路。

因为动静业务流量是一种具体的场景,在选路时会额定的关注节点间。节点到用户源站层面上,业务特色、HTTP 和 HTTPS 流量特色、TCP 和 UDP 差别、长连贯和短连贯等方面,对于业务流量会有一些奥妙的影响。

所以,对于网络 (如下图) 的最优门路计算,相干的算法能够参考的较多。

“最优路经计算,其外围的问题,在于如何构图,即图的边到底,通过哪些维度来度量与归一化,是十分重要的课题。”

除了构图中对于“边”的度量和定义,还要关注“节点”的维度。学术界的经典最优选路的算法,并不思考链路或者节点容量的问题。

那么,如果依照最优门路相干算法的运行后果,会导致流量汇聚到某条链路或者节点,产生反向作用,导致链路品质上的劣化。

一个形象的比喻就是:所谓的抄近道,走的人多了,也就堵了。

传统的经典算法,一旦波及到链路容量限度,就不能失常运行,须要有新的模型来解决这类问题。

另外一个选路层面须要思考的问题,就是:经典的门路算法是无状态的。

意思是说,每两次选路的过程之间是没有关联的,这就会导致每次选路的后果可能差别很大,流量在网络内疯狂震荡,对于零碎的稳定性和解决能力有很大挑战和危险。

最初一个在“选路”层面重点思考的问题就是,分分明哪些是节点层面应该做好的,哪些应该选路层面去做好的。

在 SDN 的畛域中,节点层面被定义为数据面,选路层面定义为管制面。换句话说,所谓的管制面要管制哪些,能管制哪些?

对于业界常见的计划来说,选路根本都是中心化的,那么人造来说,节点到核心的交互就不能太频繁。

选路层面都须要通过收集和汇聚数据的过程,决策和策略必然产生提早。

比方 10 分钟实现一个周期的工作解决和下发,那么零碎肯定是留有足够的 buffer 的。这个 buffer 外围个别体现两点,一是留有肯定的余量,二是带有肯定的预测。

用一句话来讲,选路零碎每次计算结果,其实对节点数据面来说,有一个隐含 SLA(服务水平协定)的。

比方在某个选路零碎中,以后给的后果是保障的将来 10 分钟内,在流量不超过 xx 的阈值下,提早能够管制 xx 毫秒的概率是 99.9%,那么对于一些秒级的链路闪断或者品质好转,就须要节点数据面有本人的容灾和兜底策略,这部分是核心式选路零碎的交互时间尺度内,难以提供无效反对的。

独自站在选路的视角来看将来的演进,传统的基于分场景,人为指定策略的探测模式(探测实质是一种旁路采样,从统计学上来讲就是心愿结构一种抽样来最大化的反映整体或者理论业务流),而后基于此进行构图和算路的架构,在系统优化和迭代方面,针对业务的贴合度,或多或少存在肯定的 GAP。

然而,在理论业务倒退过程中,面对同时混合了动、动态两种流量场景的全站业务,相应的技术架构就须要有更多的兼顾和综合视角的思考,无论是“传输”还是“选路”。

动静减速业务的技术演进,从历史的角度看,根本都是立足于动态 CDN 架构在特定场景下的问题,一直迭代和演进,走出了一套有差异化的架构和技术栈。

「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实际技术文章,在这里与音视频畛域一流工程师交换切磋。公众号后盾回复【技术】可退出阿里云视频云产品技术交换群,和业内大咖一起探讨音视频技术,获取更多行业最新信息。

正文完
 0