阿里云高级技术专家丁玉杰：全协议边缘高速公路的构建与演进

在4月15日的2021 GIDC全球互联网数据大会上，阿里云高级技术专家丁玉杰为进行了“全协议边缘高速公路的构建与演进”主题演讲，分享了阿里云边缘计算和全站加速的具体实践和技术思考。

边缘计算的概述

众所周知，中心云的特点比较明显，包括节点资源较为集中、资源规模较大、离终端距离较远等等。一些网民的端侧跟中心云的距离是非常远的，物理传输距离较长，在一些短延时的应用如实时音视频通话、视频会议等场景之下，中心云在传输层面不能满足低延时和高可用的需要。

边缘网络是在端到中心云的传输链路中间构建了一个大网，同时这个网络的规模比较大巨大，覆盖了这两者之间非常广的链路空间，给传输优化带来了极大的可能。另外，从客户端访问边缘网络，也可以很好的减少回到中心云的带宽成本。

云边协同的大网

在边缘计算大背景下，边缘网络是中心云网络的延伸和补充，接下来着重讨论边缘组网作为传输和加速方面的意义和技术布局。

如下图的框架所示，左边是终端访问中心云，会经过MEC、边缘节点等一系列进程，这里网络的层次相当于是更丰富。整个过程中需要解决节点接入、边缘组网、回云加速等不同层面的问题。

现在大家都在谈SD-WAN，谈控制面和数据面，那么到底控制面需要做什么？数据面需要做什么？很多厂商和专家认知里可能有一定的差异。有的人把控制面的一些事情往下放，有的人把数据面上的东西往控制面提。这些有很大一部分决策，跟业务场景，数据量，以及成本取舍等，都有很大的关系。

边缘网络控制面

在边缘组网的情况下，海量边缘节点组建成的网络拓扑规模巨大，流量管控和算法层面，会面临很大的挑战，阿里云是如何解决问题的，丁玉杰在现场进行了解答。

首先，边缘网络控制面，边缘网络的节点数量比较多，一般的理论层面都是先抽象成一个路径问题。这个路径问题很多人也会归类到运输规划问题。在一般路径模型的假设下，问题就是要求从端侧到中心云之间的网中，去求解一个最优或者最短路径的问题。实际上在很多的理论领域，不少的算法都在探讨，而传统的关于最优路径方面的算法，边缘场景的状况下不太适用，核心是因为它巨大的规模以及流量。一些论文讲过类似的问题和方案，但是在大规模下的工程实践，相关的指导性理论不是很多。

举一些典型的场景，比如节点规模太大，当面对几十万的节点矩阵的时候，计算性能可能会不够，比如希望两分钟迭代一次最优的结果；每一个节点都是有成本的约束和带宽以及算力的约束，只关注RT和丢包率的维度，可想而知最后可能导致某一个的链路，就是大家都认为是最优的时候，可能会造成拥堵。

还有，例如传统上每一轮全网的最优路由迭代之后，下一轮计算往往容易导致状态的软相关，这种情况下非常容易导致网络流量的剧烈波动，包括计算出来的节点和流量数据，流量在节点间的震荡，会对服务器的稳定性产生比较大的影响(例如过多的新建连接等)。系统在全局上需要保证流量的稳定度，这个前提非常重要。

对于边缘网络来说，综合我们的实际经验和场景上的分析，处理这类问题，丁玉杰归纳了4个步骤作为参考：
第一个点是目标函数。目标函数的概念就是要定义流量调配核心的目标是什么，要做全局的流量最优还是处理时间最短还是处理成本最低？要把目标想清楚，揪出核心点。
第二个就是流量建模，衡量质量的链路指标是什么样？有多少的流量？成本是多少？这是一些互相有关联的变量，变量之间有着相互的一些约束，这些约束以及约束跟约束之间的关系，都要搞清楚。
第三个是仿真模拟，把模型建出来之后，需要在一些模拟环境下跑这个数据，跑出来你认为理论角度它应该是一个怎么样的结果。如果觉得结果满足你的预期，你就投入到生产环境，用生产的流量正常的跑。这个过程特别要注意做好故障避免和容灾考虑，万一出现了模型程序有Bug或者其他意外的情况，导致流量产生了异常，要有办法可以收敛和兜底，避免爆炸面的扩大。
第四是反馈学习，拿到生产环境肯定会跑出一些结果，需要反向的输入到模拟系统，看结果为什么和预期不符，需要做哪些调整。很难说这个跟预期不符，能很容易确定是有哪个或者哪些参数不当导致的，所以要不断的调试参数和算法，让他接近你的预期。当模型接近了预期，你还要回答未来这个指标是否还有调优空间，当你无法评估未来的优化空间，那么未来的优化和迭代就缺乏必要的指导性。所以需要构建这样的一套测试平台或者是流量模拟平台，快速且反复的迭代验证参数和算法。

控制面选择了最优的链路，相当于修了一个高速公路，你用这个链路的时候，是不是跑的足够快。你修的路再好，如果你的车很烂，也起不到很好的效果，甚至可以把选路的效果抵消。

边缘网络数据面

在控制面的选路与决策下构建出的高速链路，数据如何做到最快速稳定的进行传输，这是数据面的核心问题，丁玉杰分享了一些处理策略。

保证传输过程当中的效率最大化，这个是数据面要做的事情。公网传输的情况下，你的可能遇到一些问题，例如在长链路的情况下，RT比较高，比如中国和欧洲大概是200—300的RT。如果你中间这些链路之间只做了SD-WAN，主要集中在二三层封装和流控，在TCP传输层面视角，这种链路下丢包和拥塞反馈的时间会比较长。每一次包的来回确认，会在丢包和拥塞时，产生严重的降窗和比较忙的窗口恢复时间，结果就是你的速度跑不起来。

“我们在传输层面其实做了很多的事情。”丁玉杰介绍道。包括以下几个点：第一个是TCP的协议栈层面做了比较大的创新实践，还是基于上面提到的思路，同样建立了一套优化评价和数据体系，快速的迭代tcp/udp的拥塞算法和参数调优。最终在自研协议上做到了非常细腻的流控模型，针对5G，WIFI，弱网等不同QOS下实现了精准的优化。
另外一个是传输协议层面，在TCP/UCP层面之上和应用层之下都做了一些私有协议的研发。一方面实现了秒级包粒度的容灾切换，而传统的基于TCP的业务只能等待超时进行重连，即使配合主动探活，也很难做到秒级切换。在直播和长时间传输业务场景下，得到非常高的质量和稳定性。另外一方面实现了基于UDP内部0rtt管道化，除了控制流之外，中间的数据传输过程不会有任何额外的传输往返开销。另外就是在多级中转的模型下，tcp或者udp转发在中间链路出现故障时，会丢失状态，即起始节点难以确认数据经过多级转发之后的状态，难以进行重传等恢复策略，自研的传输协议框架，可以轻松解决这类问题，给业务提供了极高的可用性保障。

以上的工作和探索，让边缘计算的数据面传输，真正构建了端到云中心的高速传输管道，给客户带来了极佳的使用体验。

这里是把前面的两点做一个合并，简单的说就是三层，第一个是Overlay二层组网，具有十几万、几十万级的规模节点的二层组网能力。第二个是上层叠加了传输框架和协议架优化层面的一个传输层，再上层是一些业务场景，包括TCP加速和UDP加速等等。

典型加速业务场景及产品矩阵

在底层组网和传输协议层面构建的边缘传输大网底座上，边缘云已经沉淀了许多典型的加速业务场景。

以电商平台场景举例，处理高并发QPS场景下的边缘限流，原站HTTPS在边缘的卸载等。以新闻社交场景举例，很多时候大家用的是一些静态内容，如图片和内容以及视频，还有登陆和支付以及接口和推荐等动态内容，是一个混合的业务状态，所以这就需要全站加速来实现更好的效果。

整体来说，阿里云可以提供多场景一站式加速解决方案。一个是基础加速，包括点播、直播以及我们最近做的基于边缘网络的计算场景，上层包括全站加速和安全加速，最上层面向低延时、视频会议、音视频通信等视频场景的技术方案。

后续阿里云边缘计算会在“阿里云EdgePlus”公众号中分享更多最新的产品能力、解决方案和技术实践，欢迎大家一起探讨。

本文转自网络，原文链接：https://developer.aliyun.com/article/783729
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！