本文探讨了移动边缘云（MEC）在减少云应用程序延迟方面的效果。尽管MEC理论上能提供低延迟和高带宽，但实验表明，当前云微服务应用部署在MEC上并未显著降低服务响应时间。作者通过分析发现，问题源于处理用户请求时服务间的大量事务，导致响应时间增加。为解决这个问题，提出了针对应用层和网络协议层的改进建议，以帮助云应用更好地适应MEC环境。
目录
2.3、云应用应该具备什么样的体系结构和特性，以使他们能够适应MEC？
一、论文信息
本文DOI：https://doi.org/10.1145/3318216.3363298
出于计算速度和存储能力的需要，边缘云产生了。从理论上来看，它可以比单独使用远程式的集中云提供更低的计算延迟和较好的存储能力，但是作者通过模拟边缘云的基础设施，并且使用Web Serving和Sock Shop两个应用程序，结合边缘云和远程集中云不同的部署方式进行实验。实验结果表明了这些部署在边缘云上的应用程序并没有减少服务的响应时间。于是作者随后写了一个分析器来分析响应时间并未减少的原因，最后根据原因提出了基于应用层和网络协议层的不同的解决方法。
1.1、摘要原文
Mobile Edge Clouds (MECs) are distributed platforms in which distant data-centers are complemented with computing and storage capacity located at the edge of the network. Their wide resource distribution enables MECs to fulfill the need of low latency and high bandwidth to offer an improved user experience.
As modern cloud applications are increasingly architected as collections of small, independently deployable services, they can be flexibly deployed in various configurations that combines resources from both centralized datacenters and edge locations. In principle, such applications should therefore be well-placed to exploit the advantages of MECs so as to reduce service response times.
In this paper, we quantify the benefits of deploying such cloud micro-service applications on MECs. Using two popular bench- marks, we show that, against conventional wisdom, end-to-end latency does not improve significantly even when most application services are deployed in the edge location. We developed a profiler to better understand this phenomenon, allowing us to develop recommendations for adapting applications to MECs. Further, by quantifying the gains of those recommendations, we show that the performance of an application can be made to reach the ideal scenario, in which the latency between an edge datacenter and a remote datacenter has no impact on the application performance.
1.2、摘要译文
移动边缘云(MECs)是一个分布式平台，在这个平台中，远程数据中心与位于网络边缘的计算和存储能力相辅相成。它们广泛的资源分布使MECs能够满足低延迟和高带宽的需求，从而提供改进的用户体验。
随着现代云应用越来越多地被设计为小型、独立可部署服务的集合，它们可以灵活地部署在各种配置中，这些配置组合了来自集中数据中心和边缘位置的资源。因此，原则上这些应用程序应该能够充分利用MECs的优点，从而减少服务响应时间。
在本文中，我们量化了在MECs上部署此类云微服务应用程序的好处。通过使用两个流行的基准，我们表明，与传统观点相反，即使大多数应用程序服务部署在边缘位置，端到端延迟也不会显著改善。我们开发了一个分析器来更好地理解这一现象，允许我们开发适应MECs的应用程序的建议。此外，通过量化这些建议的收益，我们表明应用程序的性能可以达到理想的场景，其中边缘数据中心和远程数据中心之间的延迟对应用程序性能没有影响。
1.3、结论原文
MECs are recognized as a key enabling driver of fifth generation mobile network technology (5G) that will make it possible to meet end- user expectations relating to performance, scalability and agility. Various mission-critical application types that are poorly served by current cloud infrastructure could run well on MECs.
Learning from the historical role of non-cloud-native legacy applications in traditional clouds, we argue that MECs also provide benefits to non-MEC-native applications. Therefore, in this work, we conducted empirical studies to explore and quantify the benefits of deploying cloud-native applications on MECs. We deployed two popular microservice benchmarks in different scenarios using resources from edge locations and the remote centralized cloud. Disappointingly, our results showed that current cloud-native applications derive little benefit from deployment on MECs in terms of latency reduction, and may even suffer from increased latency when deployed in this way. We developed a profiler to better understand the causes of these problems, revealing that they originate from the large numbers of transactions between application services when processing end-user requests. The number of transactions multiplied by the network delay between the edge and the remote centralized cloud causes response times to increase dramatically.
We subsequently identified some ways of modifying the engineering of cloud-native applications that could enable them to derive benefits from deployment on MECs. We showed that such changes can bring the performance of a cloud native application to that expected in an ideal scenario, i.e., in which the latency between the edge location and the remote datacenter has no impact on the application performance. Our paper paves the way to a more rapid adoption of MECs, by enabling a broad class of applications microservice-based cloud applications to readily take advantage of MECs.
The study is limited to one edge site and one centralized data centers. However, if applications are deployed in distinct edge sites, the overall result will be relevant those of the Ideal scenario plus the delay of data synchronization among edge sites. As near future work, we plan to verify the measurement for this scenario in which many aspects are considered such as database sharding, load balancing, and methods to generate workloads that is able to reflect the interaction of local end-users with applications deployed at the local edge sites. Also, we plan to further investigate the application- and protocol-level improvements discussed herein, with the aim of quantifying the gains and costs associated with each approach. In this way, we will draw up a blueprint for porting cloud-native applications to MECs.
1.4、结论译文
MECs被认为是第五代移动网络技术(5G)的关键驱动，这将使其有可能满足终端用户在性能、可伸缩性和敏捷性方面的期望。当前云基础设施不能很好地提供服务的各种关键任务应用程序类型可以在MECs上很好地运行。
从传统云中的非云原生遗留应用程序的历史角色中，我们认为MECs也为非云原生应用程序提供了好处。因此，在本文中，我们进行了实证研究，以探索和量化在MECs上部署云本地应用程序的好处。我们使用来自边缘位置和远程集中式云的资源，在不同的场景中部署了两个流行的微服务基准。令人失望的是，我们的结果显示，当前的云原生应用程序从在MECs上部署中获得的延迟减少益处很少，甚至可能在以这种方式部署时出现延迟增加的问题。我们开发了一个分析器来更好地理解这些问题的原因，揭示出这些问题源于处理最终用户请求时应用程序服务之间的大量事务。事务数乘以边缘和远程集中式云之间的网络延迟，导致响应时间急剧增加。
随后，我们确定了一些修改云本地应用程序工程的方法，使它们能够从MECs上的部署中获益。我们展示了这样的更改可以将云本地应用程序的性能提升到理想场景中所期望的水平，即边界位置和远程数据中心之间的延迟对应用程序性能没有影响。我们的论文为更快速地采用MECs铺平了道路，它使基于微服务的广泛应用程序能够很容易地利用MECs。
研究仅限于一个边缘站点和一个集中的数据中心。但是，如果应用程序部署在不同的边缘站点，那么总体结果将与理想场景的结果相关，并且会延迟边缘站点之间的数据同步。作为近期的工作，我们计划验证此场景的度量，其中考虑了许多方面，如数据库分片、负载平衡和生成工作负载的方法，这些工作负载能够反映本地终端用户与部署在本地边缘站点上的应用程序之间的交互。此外，我们计划进一步研究本文讨论的应用程序和协议级别的改进，目的是量化与每种方法相关的收益和成本。通过这种方式，我们将为将云本地应用程序移植到MECs绘制蓝图。
二、文章内容
2.1文章背景
一般来说，云应用程序的用户对服务的延迟非常敏感，服务响应用户请求时间越长，用户切换到其他服务的风险就越大。
而且，现代云应用程序的架构越来越像微服务（micro-service）集合，可以以各种形式部署，根据需要组合数据中心和边缘位置的资源。
从理论上来说，移动边缘云（MEC：Mobile Edge Cloud）的优点之一是比单独使用集中式的云具有更低延迟的计算和存储能力，因此数据中心和边缘位置结合的部署方式应该可以减少一定的延迟，但是在实际使用中，延迟时间似乎并未减少。所以作者通过本文量化MEC可以为基于微服务的云应用程序带来的好处，主要解决以下两个问题：
-
云应用程序能够在MEC上减少延迟吗？
-
云应用应该具备什么样的体系结构和特性，以使他们能够适应MEC？
2.2、云应用程序能够在MEC上减少延迟吗？
2.2.1、实验设计
作者本阶段主要通过实验来验证云应用程序是否能够在MEC上减少延迟，实验配置和设计如下图。
本次实验主要以一个远程云和一个边缘云为主，其他不在本次实验考虑范围之内，并且用了两个常规的应用程序测试样例，一个以Web服务为主，一个以电商服务为主。作者经过实验判定终端用户至远程云的RTT为40ms，到边缘云的RTT为10ms，终端用户、边缘云、远程云如下图示意。
应用示例可以主要可以分为用户服务和数据库服务，作者又定义了几个不同部署的场景，从传统部署的全远程云至理想化部署的全边缘云共五种应用场景，部署的具体情况如下图所示。
2.2.2、Web Serving的实验结果分析
作者使用了Faban框架，可以生成各种类型的操作请求，并统计请求结果生成报告。在本次实验中，用户的并发数量为7，负载的时间跨度为300s。
Faban生成的操作类型如下表所示（只有访问主页没有写操作，其余操作类型均包含将新数据写入数据库的操作），实验结果如下图所示，因为Web Serving中没有密集通信的用户服务，所以Limited Edge Deployment这个场景没有进行实验。
下表可以更直观的看出各类请求与仅远程云的时间差比例，计算公式为（当前场景的时间-仅远程云场景的时间）/仅远程云场景的时间。Ideal Deployment场景很明显时间是少于Cloud-Only Deployment的，但是在实际情况中，理想场景的部署很难实现。除此之外，针对于Mixed Deployment和Mostly Edge Deployment来说，仅有没有写操作的访问用户主页所有时间较少，其余均有所增加。而且针对于各类操作来说，Mixed Deployment场景的时间均是最多的，因为在这个场景下，所有写操作的数据库均被部署在了远程云上，加重了写入的负担。
因此可以得出结论，在MEC上部署部分云应用程序微服务并不会减少响应时间，反而增加了延迟。
2.2.3、Sock Shop的实验结果分析
对于Sock Shop，作者使用了Sock Shop自带的负载测试，并且设定了两种请求的模式，一种是读写混合的请求，另一种是只读的请求（分为Get Category和Get Basket）。读写混合类型的请求共1000个，同时并发用户数目为10个。只读类型的两种请求各1000个，同时并发用户数目为10个。
针对于混合类型的请求结果来说，Cloud-Only Deployment的请求响应时间为62ms，Limited Edge Deployment和Mixed Deployment的响应时间是它的3倍，Mostly Edge Deployment的请求响应时间为54ms，Ideal Deployment的请求响应时间为27ms。所以针对于混合类型的请求来说，Sock Shop也并没有在MEC上显示出比较明显的优势。
而针对于只读类型的请求结果来说，如下图所示，Mostly Edge Deployment和Ideal Deployment展现出了明显的优势。Mostly Edge Deployment的只读数据库服务部署在边缘云上，而Ideal Deployment所有的数据库服务均在边缘云上，因此它们所展现出来的性能应该是相似的。
对于Limited Edge Deployment和Mixed Deployment两个场景，因为Get Basket和Get Category两个只读操作需要调用部署在边缘云上的用户服务，例如front-end、category、cart等，再调用远程云上的categoryDB和cartDB数据库服务，因此所需时间会比单纯的使用Cloud-Only Deployment要长。所以，针对于只读类型的请求来说，Sock Shop也没有在MEC上显示出比较明显的优势。
综上所述，无论是使用Web Serving还是Sock Shop来测试，无论是使用了读写混合请求，还是只读请求，针对于作者所部署的物种场景，只有Ideal Deployment表现出了MEC能够减少服务响应请求延迟的优势，而这种部署场景又很难在现实生活中实现，因此对于“云应用程序能够使用MEC的优势来减少延迟”这一问题，答案是否定的。
2.3、云应用应该具备什么样的体系结构和特性，以使他们能够适应MEC？
在上一小节作者通过实验得出了结论：云应用程序并不能够使用MEC的优势来减少服务响应请求的延迟，因此作者接下来分析了不能够减少延迟的原因。
作者首先定义了一个概念，turns：是指两个主机之间通信方向的改变，与客户机进程被阻塞，等待从服务器进程返回数据的时间有关。如果服务器请求所需的turns越多，那么阻塞时间就越大，用户需要等待的响应时间就越长。下图是计算turns的示意图。
作者发现，turns的数目与云应用程序所部属的场景无关，但是如果两个主机分别部署在不同的网络层，延迟的时间会随着网络层之间的距离线性增加，因此当用户服务和数据库服务分别部署在边缘云和远程云时，延迟会明显增加，这也是上一小节Sock Shop只读请求实验中Limited Edge Deployment和Mixed Deployment时间会比Cloud-Only Deployment长的原因。
因为turns的数目基本上是一定的，所以作者通过实验获取了Web Serving和Sock Shop各个服务之间的turns，如下图所示。
turns的数目虽然是一定的，但是如果减少turns的数目，在相同部署的情况下则一定可以减少延迟的时间，这个可以用
来解释。所以可以从两个思路出发，一个是从实现的角度减少turns的数目，即应用层，另一个是从传输协议的角度减少不必要的握手turns，即网络协议层。
- 应用层：使用Query join/lookup 绑定几个查询来缓解
基于微服务的云应用程序通常具有用于特定服务的私有数据库，例如Sock Shop中order service对应orderDB。如果用户服务和数据库服务在不同的应用层，当每次查询某一个东西时，用户服务都要和数据库服务之间发送请求及响应，当当前查询完成开始新一轮查询时，用户服务依旧需要和数据库服务之间发送请求及响应，这样在无形之中增加了turns的数目，因此可以在某一次查询中绑定多个查询存储在本地，以减少后续发送请求和响应的次数，也就减少了turns的数目。
- 应用层：将本地目标数据缓存到与用户服务相同的位置
在用户服务和远程数据库服务之间切断尽可能多的事务，可以改善应用程序的总体响应时间。在开发过程中可以将本地目标数据缓存到与用户服务相同的位置，例如针对于电商购物网站来说，用户可以先选择自己所在地区，系统将距离用户较近的商户存储在边缘云上，而不是将所有商户保存在远程云上，这样可以减少一定的响应时间。
- 应用层：缓存、并发写入新数据
针对于Mostly Edge Deployment场景中服务相应时间为减少是因为写操作在远程云上，为了减少数据写入时间，可以并发的将写操作的新数据写入传冲区，每当缓冲区填满或需要调用缓冲区刷新事件时，再将缓冲区的数据写入数据库。
但是这种方法难以应对一些灾难性的事件，例如服务器崩溃等，这有可能出现数据丢失的风险，因此在安全性与便利性之间需要权衡，可以将一些不是很重要的数据写操作采取这种方法。
- 应用层：并行执行
在一个请求发生后，可能会对多个用户服务和数据库服务进行调用，这些调用往往是按照顺序进行的，因此可以将顺序执行改为并行执行以缩短服务响应时间。
- 网络协议层：使用QUIC协议（Quick Internet Connections）
QUIC（快速UDP互联网连接）协议是一种新的默认加密的互联网通信协议，它提供了许多改进，旨在加速HTTP通信，同时使其变得更加安全，其最终目的是在web上代替TCP和TLS协议。
对于HTTP协议来说，可以允许在一个持久的TCP链接中流水线处理多个请求，而无需等待响应，这样减少了跨网络所需的TCP握手和数据包的数量，但是可能会出现拥堵的情况，使用QUIC协议可以避免这一点。
详情可见：https://www.cnblogs.com/imteck4713/p/11777310.html
三、我的总结
本文针对于边缘云的理论优点再结合实际使用情况提出了疑问，发现边缘云并没有像我们预想的那样减少延迟，反而有可能增加响应时间，因此作者部署了5个实验场景进行实验证实这一问题的存在，并分析原因，最后提出解决方案。
从解决方案的角度来说，前几种基于应用层的均可以在开发过程中解决，而科研所需要的解决的应该类似于网络协议层的问题，但是目前也有了能够解决问题的网络协议，因此当做一篇科普文章看看即可，想要了解QUIC网络协议的，也放了一个简单易懂的链接。
493
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
