层感知的边缘微服务部署与请求调度策略
在基于容器的微服务被广泛应用于边缘计算的前提下，运行过程中以容器镜像的形式封装的微服务需要频繁地被从远程仓库下载到本地边缘服务器，这会产生大量下载流量和本地存储方面的开销。鉴于边缘服务器资源有限，最大限度地减少以上开销以增强微服务性能至关重要。其中，基于容器的微服务所具有的分层结构性质尚未得到有效利用，即不同微服务在同一边缘服务器中放置的基础层可以被共享。本文提出了层感知的边缘微服务放置和请求调度问题，即如何通过合理利用同一服务器的镜像之间的层共享特性，有效地增加微服务的放置数量和服务吞吐量。我们将该问题抽象化为具有近似子模性的优化问题，并证明该问题具有NP难的性质，并进一步设计了具有合理近似比的迭代贪心算法。大量实验验证了该算法的有效性，与当前最先进的微服务放置策略相比，迭代贪心算法放置的微服务数量可以增加27.61%，微服务吞吐量可以提高73.13%。
该结果“Layer Aware Microservice Placement and Request Scheduling at the Edge”发表在IEEE Infocom 2021，是实验室分布式系统组在微服务部署领域的研究成果。
- 论文原文：
- https://ieeexplore.ieee.org/document/9488779
背景与动机
通过在用户附近提供服务，边缘计算可以快速并按需应对飞速增长的服务和用户的需求。而针对资源受限的边缘设备，提供轻量级和易于部署的服务是一个必然的趋势。因此，基于容器的微服务被认为是一种解决问题的有效方式。与虚拟机（VM）不同，容器与底层主机共享操作系统内核，从而以更低的开销实现更快的服务启动。正因如此，微服务自然更适合边缘计算中的服务开发和运营，因此受到了学术界和工业界的广泛关注。微服务放置是微服务编排中的主要任务之一。当前，人们已经针对与其相关的不同目标进行了广泛的研究，例如，更好的资源效用、更低的服务成本或更快的微服务启动，提出了许多不同的近似算法，例如贪心策略、启发式算法和机器学习等。然而，现有的微服务放置工作本质上将容器视为具有较小资源需求的轻量级虚拟机。实际上，基于容器的微服务有两个根本上不同于虚拟机放置的特性。
第一个特性是，一旦将虚拟机放置在边缘服务器上，传统的基于虚拟机的服务就会在数小时、数天甚至数月的时间内持续提供某些功能。因此，现有的放置研究通常侧重于提高资源效用或最小化资源消耗。但是，事实上，微服务通常是短暂的，需要根据实时服务需求动态激活和停用。例如，谷歌每秒启动7000多个微服务，其中27%的生命周期短于5分钟，11%甚至短于1分钟。因此，基于容器的微服务放置需要经常性地被重新做出决策。此外，必须首先及时从远程仓库下载相应的容器镜像到本地磁盘以进行微服务放置。当微服务镜像较大时，频繁的下载会导致大量的流量开销，导致下载时延较长。这严重阻碍了微服务的启动速度，成为微服务编排的主要瓶颈。
另一个特性是基于容器的微服务与虚拟机具有完全不同的结构。容器镜像采用分层结构，将运行时工具、系统工具、libs、系统依赖等所需项目打包在不同的独立层中。因此，可以按层下载和存储微服务镜像。不同的镜像可能共享几个共同的基础层。最近在其他论文中的一项调查更是表明，57个代表性镜像可以共享19个基础层，Docker等主流容器产品支持放置在同一服务器上的镜像之间的层共享。通过这个性质，多个不同的微服务只需要从仓库下载一份共享层，这点特别有利于资源有限的边缘服务器。
因为更加靠近用户，在边缘启用微服务可以实现低延迟和快速响应。因此，在边缘满足用户请求自然比在云中更有利，用户能够获得更好的体验质量。鉴于上述基于容器的微服务特性，在边缘放置微服务主要存在两个困难：（1）如何在下载流量和存储方面最大限度地减少与放置相关的开销；(2)如何将分层结构恰当地应用到放置中。在本文中，我们首次研究了层感知的微服务放置与请求调度 (LA-MPRS) 问题，其目标是最大化边缘吞吐量，即边缘服务器所满足的请求数量。这被证明是一个具有挑战性的问题，因为微服务放置和请求调度问题通常被表述为整数线性规划 (ILP) 问题。由于与放置决策高度相关分层结构的存在，这个问题被进一步复杂化。之后我们进一步设计了关于LA-MPRS问题的迭代贪心算法，在微服务放置与请求调度方面解决了以上困难。
设计与实现
层共享有利于提高资源有限边缘服务器的吞吐量。我们以四个常用的微服务Cassandra、JAVA、Python和gcc为例，他们都基于 Debian 的同一个非最新Linux分布层。将这四个微服务的镜像放置在同一个边缘服务器之上时，这个基于Debian的Linux基础层可以被所有镜像使用，因此在保证计算资源、通信资源充足时，考虑层共享结构，一方面可以避免重复多次下载，有效降低微服务放置的下载流量，另一方面可以减少重复放置基础层带来的存储容量开销。一旦微服务放置成功，它们就会投入运行以处理用户请求。无法在本地处理的请求会被卸载到另一个放置有该微服务的边缘服务器或云端进行处理，最终达到最高的吞吐量。由于减少了从仓库下载到带宽有限的服务器的镜像总大小，层共享在一定程度上可以加速微服务启动。以上优势都是不考虑Cassandra、JAVA、Python和gcc的层共享性质，将他们的镜像分别视为一个整体所不能实现的。上面的例子告诉我们层共享确实有利于降低微服务放置的下载流量和存储开销。同时，请求调度应与层感知微服务放置一起考虑，以提高资源受限边缘服务器的服务提供能力。
图1 （a）存储资源容量（b）启动时间阈值 （c）计算资源容量（d）通信资源容量对边缘吞吐量和服务实例数量的影响
考虑到层共享，我们研究了层感知的边缘微服务放置与请求调度（LA-MPRS）问题，以在资源受限的边缘实现最大吞吐量，首先将LA-MPRS问题表述为 ILP 形式，并证明了该问题的NP难和近似子模性。为了解决计算复杂的问题，我们进一步设计了一种具有合理近似比的迭代贪婪算法，本着逐个迭代添加微服务实例的原则，在不违反容量约束的情况下贪心地最大化吞吐量。这样的设计基于这样一个事实：对于给定的放置决策，我们总是可以通过遍历有限多种可能性来找到添加微服务实例的最佳放置决策。近似比的结果证明也表示了放置决策的合理性。为了验证算法的有效性，我们考虑使用从Docker Hub中频繁下载的100种容器来提供不同类型的微服务，镜像大小范围为109~1045MB，层数范围为6~13。一些基础层可以在微服务之间共享，平均占到整个镜像为12%~51%范围内。微服务请求根据来自IBM Docker Registry Trace Player的边缘服务器真实数据，范围为7~135RPS。每个微服务所需的计算资源和请求大小根据微服务类型分别设置在0.002~0.05GHz和863~3561KB范围内。实验结果（图1）表明，基于层共享的迭代贪心算法与现有解决方案相比，可增加27.61%的微服务数量，提高73.13%的边缘吞吐量。
