II摘要在过去的十年中，云计算已经发展成为大多数分布式应用程序的标准部署环境虽然云计算提供商不断将其覆盖范围扩展到全球不同的位置，但其云计算中心到最终用户的距离仍然经常转化为显著的延迟和网络利用率。随着虚拟/增强现实和自动驾驶车辆等新应用程序的出现，这些应用程序的延迟非常低，或者物联网会产生大量数据，目前的集中式云基础设施已无法支持其严格的要求。这已经将焦点转移到更分布式的替代方案，如雾计算。虽然这种基础设施的前提似乎是吉祥的，但标准的雾管理平台尚未出现。因此，大量的注意力集中在捕捉正确的设计要求，以提供这些房地。在本文中，我们的目标是设计积木，可以提供雾管理任务的基本功能 从保持局部性的基本雾原则出发，我们设计了一个懒惰的和局部感知的覆盖网络称为考拉，它提供了有效的分散管理，而不会引入额外的流量开销。为了捕获来自应用层的额外需求，我们将一个众所周知的基于微服务的应用程序，即Sharelatex移植到雾环境中。我们研究了其性能如何受到影响，以及管理层可以提供哪些功能，以促进其雾部署并提高其性能。基于我们的覆盖构建块和从应用程序的雾部署中检索到的需求，我们设计了一个服务发现机制，它满足这些需求，并将这些组件集成到一个单一的原型中。这个全栈原型支持基于真实用例场景对这些组件进行完整的端到端评估II确认阳光明媚的下午，坐在码头上，凝视着布列塔尼北部海岸的地平线，微风轻抚着我的头发，我拿着笔记本和羽毛笔。这就是我在新完成的手稿上写下注释的那一刻的想象当时我并不知道，写答辩状，就像我最近做的大多数有趣的活动一样，会是另一种分散我注意力的方式，让我无法处理更重要的任务，比如练习我在这个案子中的辩护陈述。拖延症，你为什么这么可爱？然而，这一次，它是甜蜜的。就像一部好电影的结尾，我期待着这一刻的到来，但现在我感到遗憾。就像在一部好电影的结尾，我想把这一刻献给所有让这段旅程成为可能的了不起的人。我要感谢陪审团的所有成员：Luciana Arantes，Noël de Palma，Sébastian Monet，Adrian Lebre和Etienne Rivère，感谢他们为今天的辩护日付出的时间和努力。我特别要感谢诺埃尔和塞巴斯蒂安接受阅读和审查我的手稿的额外任务也感谢Adrian对Discovery项目的支持，以及成为我的CSID委员会的一员。特别感谢Etienne在Louvain-la-Neuve接待我，以及您在撰写这些文章时的支持和奉献当然，我最深切的感谢我的两位伟大的导师，塞德里克和马林。与你共事是我的荣幸。我知道有时候要战胜自己的怀疑和无知需要超能力。但你的指导，动力，积极性，以及对我们工作和我的信任，绝对可以算作这样。谢谢你在我人生的每一步都陪伴着我，一直指引着我正确的方向。感谢Guillaume给我机会加入Myriads团队。作为最永久的非永久性，我很高兴能与团队的不同世代会面，分享我在工作中的许多快乐和沮丧时刻感谢大卫、云波、克莱门特、迈赫迪和亚斯米娜，感谢马修让我的工作变得快乐，感谢马修保护我免受技术问题的困扰。感谢我的亲密朋友们，让我的工作之余也变得快乐：马达和博格迪，感谢你们的支持和积极，让我觉得我可以永远依靠你们（即使在荷兰的某个地方迷路）;哈维尔，感谢你们所有的美好交谈，感谢你们在困难时刻的陪伴;阿米尔，感谢你们如此关心我，如此可靠（我永远不会忘记那一天）;尤尼斯，感谢你们收养了我，为我打开了你们的大门;当然，还有塞西尔，感谢你们提醒我要生活得轻松，并不断地激发我的自我完善。虽然经典作品永远是不可替代的，但我结交的新朋友变得不可或缺。我当然指的是急救队：洛伦佐，保罗和克里斯汀。乔瓦尼，我非常幸运在回雷恩的路上遇到你。保罗，我也很幸运你加入球队这么晚，否则我永远不会毕业。克丽丝我该从何说起我需要再一次写我到目前为止写的东西。我只能说很少有人会像你那样让我今天站在这里伊斯玛和安娜，不管我有多爱你们，叛国是不酷的！你只有一次机会弥补！IIIIV克里斯，马丁，妈妈和爸爸，言语永远不足以表达我是多么感激你不得不忍受我接受适当的教育，达到这一天。我深深地爱着你，我把这份工作献给你。我将离开这个实验室，很快也将离开雷恩，但我的一部分将永远留在这里，雷恩的一部分将永远与我同在目录1介绍11.1分布式系统11.2研究和工业11.3效用计算：网格和云21.4中央集权和权力下放31.5云的数量和限制31.6边缘和雾42艺术92.1分布式和分散式效用计算2.1.1Cloud92.1.2分布式云102.1.3去中心化云122.1.4积木块132.2覆盖网络132.2.1结构化覆盖142.2.2非结构化覆盖162.2.3混合覆盖182.2.4地方意识192.2.5减少维护开销212.3键值存储222.3.1值得注意的NoSQL数据存储2.4服务发现242.4.1面向服务架构（SOA）252.4.2微服务252.4.3值得注意的微服务发现机制2.5结论273为分散式云设计覆盖网络。293.1一.导言. 293.2雾管理303.3核心设计313.4减少维护323.5地方意识323.5.1本地感知邻居选择323.5.2邻近路由333.5.3地理布局343.6增强路由表353.7结论36vvi目录4Koala：分散云的懒惰和本地意识覆盖374.1导言。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .374.2协议。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384.2.1模型。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .384.2.2考拉：引擎盖下。. . . . . . . . . . . . . . . . . . . . . . . . . . . .384.2.3 PoP感知拓扑。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .404.2.4路由：贪婪，基于延迟，还是两者兼而有之？ . . . . . . . . . . . . . . . . . . .404.2.5加入. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .424.2.6懒惰的学习. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444.2.7复原力。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .444.2.8讨论：网络坐标。. . . . . . . . . . . . . . . . . . . . . .454.3评价。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .464.3.1长链接的数量和可扩展性。. . . . . . . . . . . . . . . . . . . .464.3.2懒惰学习和延迟意识。. . . . . . . . . . . . . . . . . . . .474.3.3对客户流失的。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .484.3.4拓扑意识：考拉口味。. . . . . . . . . . . . . . . . . . . . .494.3.5流量模式：应用程序链接。. . . . . . . . . . . . . . . . . . . . . .514.4与相关工作的。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .524.5结论。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535传统应用程序的核心/边缘部署555.1导言。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .555.2背景。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .565.2微服务. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .565.2.2用例应用：ShareLatex。. . . . . . . . . . . . . . . . . . . . . .575.3核心/边缘混合部署。. . . . . . . . . . . . . . . . . . . . . . . . . . . .595.3.1实现重定向。. . . . . . . . . . . . . . . . . . . . . . . . . .605.4评价。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .615.4.1集中式与 混合部署。. . . . . . . . . . . . . . . . . . . . .615.4.2重定向的。. . . . . . . . . . . . . . . . . . . . . . . . . . . .635.5与相关工作的。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .645.6结论。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .656一种局部感知的对象驱动服务发现机制676.1导言。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .676.2服务和对象。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .686.2.1作为数据的。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .696.2.2对象作为位置引用。. . . . . . . . . . . . . . . . . . . . . . . .696.3实现考拉原型。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .716.3.1体系结构概述。. . . . . . . . . . . . . . . . . . . . . . . . . . . .716.3.2内部状态。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .726.3.3协议。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .746.4与ShareLatex。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .786.4.1核心服务。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .786.4.2ShareLatex对象。. . . . . . . . . . . . . . . . . . . . . . . . . . . .786.4.3将Koala与ShareLatex。. . . . . . . . . . . . . . . . . . . . .796.4.4集成的微妙之处。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .796.4.5为什么请求重定向也会移动数据. . . . . . . . . . . . . . . . . .806.5评价。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .816.5.1移动项目. . . . . . . . . . . . . . . . . . . . . . . . . . . . .816.5.2工程分布。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .826.5.3间接费用。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84目录. vii6.6讨论856.6.1关于Koala856.6.2边缘应用指南866.7与相关工作的6.8结论877结论和今后的工作7.1调查结果摘要7.2概括907.3优势和局限性917.4未来的方向.91Bibliography参考书目93八、目录图目录1.1物联网对云的潜在影响[77]。................................................................................................42.1背景和相关工作的分层视图...................................................................................................92.2水母互联网模型112.3核心云、边缘云和雾122.4OpenFog参考架构（改编自[36]）132.5CAP定理233.1LOF30的标题3.2路由表条目的帕累托边界。.................................................................................................333.3考虑数据中心划分的方法.....................................................................................................354.1小型网络中的逻辑环（m=4），以及节点0的路由表。...................................................394.2图4.1所示为多环结构的例子4.3网络扩展到10万个节点时的延迟和跳数.............................................................................474.4α对延迟和跳数的影响..........................................................................................................474.5邻近链路对延迟和跳数的影响484.6客户流失对延迟和故障率的影响。.....................................................................................494.7大规模故障对延迟和故障率的影响。.................................................................................494.8考拉口味的比较.....................................................................................................................504.9应用程序链接的流量分布和影响.........................................................................................525.1四类微服务基于其复制对应用程序正确性的影响。.........................................................575.2ShareLatex微服务及其复制类别如图5.1所示。585.3我们的分配和安置。核心中的关键服务，边缘中的延迟敏感和频繁服务。.................595.4重定向场景。项目A不需要重定向，而B和C需要重定向到核心和另一个边缘。........ 605.5集中式与混合部署-扩展setup. ............................................................................................625.6混合部署对于最频繁的操作产生较低的延迟（第一行）。.............................................625.7使用重定向的影响。setup. .................................................................................................635.8重定向和用户接入点的影响.................................................................................................646.1对象（道路）“123”服务组由“道路列表”和“交通”服务组成并且其实例组分别由那些服务的实例2和5组成696.2在三个边缘位置中的一个中移动对象O将请求重定向到服务S1、S2、S3的不同实例。706.3总体结构716.4服务数据在Koala726.5Koala73中的对象数据6.6应用程序链接节点2-5与维瓦尔第坐标。........................................................................... 73IXx图列表6.7配置服务以与Koala74交互6.8使用Koala75配置对象重定向6.9节点2-5的对象访问记录....................................................................................................... 776.10 项目的服务组.........................................................................................................................796.11 在nginx中重定向对象请求.................................................................................................. 806.12 移动项目实验设置。.............................................................................................................816.13 移动项目结果。.....................................................................................................................826.14 项目分配实验设置。.............................................................................................................836.15 项目随时间的分布。.............................................................................................................846.16 头顶设置。.............................................................................................................................846.17 三个请求的开销结果.............................................................................................................85表的列表4.1交通分布515.1 ShareLatex服务，它们的类别和附加属性：关键（Cr.），延迟敏感（LS）、频繁（Fr.）....................................................................................................................................586.1项目、用户和理想站点布局的分布。.....................................................................................83Xi十二、表格一览表第1介绍1.1分布式系统第一台现代计算机体积庞大，价格昂贵，只有少数组织能够负担得起。由于数量稀少，缺乏连接手段，它们独立运作然后，在80年代中期，两个主要的多年来，微处理器的计算能力显著提高，而它们的成本和尺寸显著下降。同样，网络硬件和软件层的进步使数据交换速度非常快。最后是沟通。起初，这涉及建筑物或组织内的计算机，它们连接在局域网（LAN）中。这些小型网络开始逐渐互连，形成越来越大的网络，导致所谓的广域网（WAN）。最终，全世界的局域网和广域网的互连这是信息时代的开始，这是一个完全重塑工业和人们生活大多数方面的历史时期这种惊人的发展不仅仅是大型基础设施中处理器简单互连的结果。这种互联的真正力量在于这些众多的处理器相互协作以完成更大和更复杂的任务，否则在合理的时间内是不可能的。这种合作的需要，起源于计算机科学中最核心的领域之一，分布式系统。在他们的书中，[157]，Tanenbaum和Van Steen将分布式系统定义为：分布式系统是一个独立组件（计算机）的集合，在用户看来，它们是一个单一的连贯系统。虽然为用户提供了单个一致的界面，但在幕后，这些组件可以具有不同的角色并以各种方式进行交互在分布式系统中划分任务的两种最常见的方法是客户机-服务器和对等（P2P）模型。 在客户端-服务器模型中，任务在资源请求者（客户端）和资源提供者（服务器）之间共享这种模式的典型例子包括万维网（WWW）和电子邮件。 在P2P模型中，每个组件同时充当客户端和服务器，通过请求和提供资源。此模型的常见情况包括文件共享或IP语音（VoIP）系统。鉴于其解决未来将出现的复杂任务的潜力以及其解决当前需求的适用性，分布式系统一直是研究的主题，也是当今工业的一个组成部分1.2研究和工业中的分布式系统通常很难区分研究和工业在某一特定领域的发展中的贡献。贡献往往是交织在一起的，研究集中在大的方面。12第1章介绍图片，以及解决当前实际问题的行业研究由于早期阶段的研究集中在利用多个处理器的组合能力的潜力在创建通信标准方面，如OSI模型和互联网协议套件方面，投入了巨大的努力。随后又制定了促进同步和协作的附加议定书和框架。编程语言也丰富了构建分布式系统的工具，如远程过程调用（RPC），消息传递接口（MPI）或Map-Reduce模型。让多台机器并行执行某项任务从未如此简单。在这一点上，实现前所未有的计算性能是一个水平扩展处理器的问题很快，每秒执行千万亿次运算的超级计算机成为现实。这影响了许多其他领域的研究，如遗传学，气候，太空探索等。这种特殊的计算能力必须提供给需要它的教育或研究机构。行业从第一个聊天应用程序到现在的社交媒体，由于工业的发展，出现了大量的分布式系统。早期的公司通常提供客户端-服务器应用程序，其中客户端通常是用户机器，而服务器是位于内部的机器。随着公司获得越来越多的客户，他们的计算资源不断增加。很快服务器变成了机架，机架填满了机房，在某些情况下甚至变成了数据中心.对于大多数公司来说，存储、维护和升级这些机器是不可持续的。另一方面，新公司进入市场的壁垒开始很高，因为它们需要大量的初始投资才能具有竞争力。此外，对计算能力的需求并不是恒定的，因此公司很难规划其投资。在研究中，效用计算是一个明确的后续步骤。1.3效用计算：网格和云效用计算依赖于根据需要提供计算资源的想法，类似于其他公用事业，如电力或水。这意味着用户需要一种方法来将他们的应用程序或任务加载到分布式基础设施上，以便执行它们，并可能在完成后删除它们。考虑到应用程序和硬件的巨大异构性，这并不简单。这是虚拟化技术被证明是非常有用的时候虚拟化在硬件和软件之间创建了一个抽象层，消除了兼容性问题，同时为软件提供了几乎无限的硬件资源。用户可以将其完整的软件堆栈打包到虚拟环境中，例如虚拟机（VM）或容器，并根据需要分配尽可能多的资源。当执行终止时，可以在不影响系统其余部分的情况下处置这些环境在2004年左右，Foster、Kesselman和Tuecke三人在研究中引入了超级计算机中效用计算的概念，称为网格计算[54]。他们对网格的定义涉及到认证、数据存储、虚拟网络、安全供应、监控等详细概念这些进步为另一个著名的效用计算实现铺平了道路，云。云计算将网格概念带到了行业中。一些已经拥有数据中心的大公司，如亚马逊或谷歌，增加了他们的能力，并专门以按使用付费的模式向用户提供计算和存储资源事实上，云将业务模型与网格服务相关联，这使得计算能力几乎无限，1.4. 中央集权和地方分权3存储访问任何其他公司，以合理的价格.云计算不仅对IT行业产生了巨大的影响，而且最近已经成为各个行业领域老牌公司的事实上的计算平台，也是众多初创公司成功的核心当然，通过放弃他们的内部基础设施，公司减轻了维护它们及其相关成本的责任。然而，这些基础设施通常位于更靠近其客户端的位置，并分配了整体计算负载。通过在云中托管他们的服务，所有计算都集中在世界各地的少数几个鉴于大量公司转向云计算，集中化成为一个值得关注的现实问题。1.4集权与分权分布式系统是集中化和分散化交替的故事集中化提供了简单性、高效算法、易于管理和计费，但也提供了单点故障以及网络和计算资源的饱和另一方面，去中心化提供了鲁棒性和负载平衡，但代价是管理和计费的复杂性大大增加通常情况下，情况决定哪一个是最合适的过去，我们已经注意到这两种方法之间的转变第一个分布式系统是基于高度集中的客户机-服务器架构然而，这种架构的局限性在21世纪初的文件共享环境中得到了测试因此，出现了点对点架构，提供了一种更有效的分散式解决方案。然而，在接下来的十年里，网络、计算和存储领域发生了显著的进步，这使得客户端-服务器架构再次成为可行的解决方案总的来说，趋势表明，只要服务使用没有达到基础设施的极限，集中化是首选，否则就需要分散化，直到下一次技术突破。1.5云数量和限制云服务是2019年增长最快的市场之一，价值2143亿美元，预计到2022年将保持14%以上的稳定增长[60]。根据思科从2016年到2021年，全球每年的云流量将增加3.3倍（高达19.5 ZB），而存储在云中的数据将增加4倍（高达2.6 ZB）。虽然云计算的持续增长似乎远未达到稳定状态，但这种增长对当前基础设施的影响需要加以研究。端到端基础设施包括三个主要元素：网络中心、网络（链路、路由器、交换机）和用户机器或设备。鉴于云计算中心由直接受益于这种增长的云计算公司拥有事实上，思科然而，大规模的制冷机具有极高的能耗。到2030年，制冷剂的消费量将占全球消费量的13%，而2010年为1%[13]。这与2016年美国的能源消耗（17%）相似[6]。除非向绿色能源进行深刻的转变，否则能源中心的增长是不可持续的。关于网络，对云增长的反应不那么直接。不同的网段由不同的参与者拥有和管理，这就产生了几个问题。监管不足和网络公司之间的竞争动态可能导致次优4第1章介绍图1.1：物联网对云的潜在影响[77]。基础设施或配置[39]。此外，与集中式的数据中心投资不同，固定网络中的投资需要对基础设施进行毛细血管干预，这是昂贵的，并且具有许多技术细节（挖沟，政府许可）。这意味着它们在不同的公司和地点之间不可能是一致的。最后，网络的能源消耗与互联网中心一样陡峭，因此它遭受同样的不可持续性问题[13]。至于用户机器，特别是移动设备，它们是云增长的主要推动者之一。在过去的十年中，我们见证了智能移动设备的前所未有的增长，2017年达到50亿用户（占世界人口的65%）。这种增长的特点是计算能力、内存和网络能力的突破性进展，使这些设备能够支持全新的应用类别从虚拟现实和增强现实到自动驾驶汽车，机会似乎无穷无尽。然而，这些应用中的许多应用需要非常低的延迟来操作（低于15 ms [50]）。鉴于云流量的急剧增长以及网络无法维持这种增长，集中式云无法支持这些应用程序。除了对低延迟的需求外，移动应用程序还生成大量数据。根据思科的预测，到2021年，所有数据的15%将驻留在移动设备中，并且很有可能最终转移到数据中心。此外，随着物联网的出现，每年生成的数据量将飙升至850 ZB，其中90%是短暂的（需要处理，但不一定存储）。在集中式云中处理如此大量的数据是不现实的，因为流量的增长将是预测的20即使只存储这种处理的结果（10%），它仍然会超过其他服务产生的总流量，如图1.1所示。为了应对这些限制，应考虑边缘或雾计算等替代解决方案。1.6边缘和雾Edge和Fog都依赖于将计算和存储资源分布在整个网络上的想法这两个术语有时可以互换使用。然而，一般的看法是，Edge专注于在网络边缘尽可能接近用户地引入资源，而Fog更通用，并且设想在网络的边缘和核心之间的连续体中分配资源这些概念旨在解决集中式云的弱点它们最大限度地减少了对用户的延迟，同时大大减少了传播到中央数据中心的流量，1.6. 边缘和雾5网络核心。这不仅支持上述实时和物联网应用，还提供了更公平的资源分配，类似于互联网的初始结构这有助于当前的基础设施更好地处理云服务预期增加的流量。Fog和Edge的前提已经将这两个术语转化为技术爱好者的流行语这种兴趣也同样反映在研究中，特别是在过去五年中。相当多的研究集中在潜在的架构和算法，以实现这些承诺。他们中的许多人专注于特定领域的应用（医疗保健[154]，自动驾驶汽车[73]，智能城市[158]），而其他人则专注于特定的管理方面，如调度[5]，迁移[19]，负载平衡[83]，联盟[173]等。然而，值得注意的是，大多数与雾有关的研究往往是概念性的，很少有原型[124]。将这些想法实现为标准的通用Edge/Fog平台仍然是一个持续的过程，需要进一步的研究。迈向标准化的一步是将基础设施管理作为一个整体来对待，而不是从头开始为特定任务构建解决方案。首先，重要的是要解决所有管理任务共同的架构方面，如任务分配、可扩展性、通信原语、本地化、接口和服务质量（QoS）管理。这些方面的设计决策仍然必须符合边缘/雾架构关于最小化延迟和流量生成的前提一旦我们建立了一个框架，特定管理任务的实施就可以专注于政策而不是架构。目标在本论文中，我们通过不同的步骤，解决雾管理的架构方面，通过提供可用于实施特定的管理任务的构建块。我们的目标是从两个方向解决这个问题，即自下而上和自上而下。在自下而上的方法中，我们从基础设施开始分析管理，而在自上而下的方法中，我们关注应用程序的角度。具体而言，我们的目标如下：底向上从Fog的前提开始，我们的目标是确定高效基础设施管理的最关键要求基于这些要求，我们的目标是建立一个覆盖网络专门为雾环境，作为一个构建块，更高层次的管理任务。顶向下为了捕捉现实生活中的管理层处理的需求，我们的目标是部署一个现有的广泛使用的应用程序在雾环境。在没有真正的开源雾原生应用程序的情况下，我们的目标是确定架构方面和方法来适应云应用程序，以便能够在雾上部署。我们希望了解雾部署对于非雾原生应用程序的有效性以及如何改进它们。·····6第1章介绍在中间基于我们的覆盖网络和部署的应用程序，我们的目标是实现一个管理任务的例子，如服务发现，它建立在我们的覆盖和支持应用程序部署在真实情况下的用户场景。总体目标是在雾基础设施中提供一个完全集成的应用程序管理和部署原型贡献按照类似的目标组织，我们的贡献如下：下而上我们认为，为了符合雾原则，有效的管理需要简单，分散，保持本地性，减少不必要的流量，但仍提供快速的服务，并具有故障恢复能力我们介绍考拉，覆盖网络，提供了实现这些要求。 Koala是完全去中心化的，采用了简单的扁平结构，但它考虑了雾的基于中间层的拓扑结构。它使用不同的技术提供位置感知，包括邻近路由和邻近节点的发现。Koala通过删除任何维护程序来最大限度地减少管理流量。相反，它包括一个懒惰的机制，依赖于在应用程序流量上捎带维护信息因此，它的维护与它的使用有关。我们提供了一个基于模拟的评估我们的覆盖网络在各种条件下，使用数十万个节点，并将其与经典的覆盖。顶向下我们讨论了应用程序必须遵守的要求，以便在不重新实现的情况下启用雾部署我们提出了基于微服务的体系结构作为这些要求的潜在实现（与渗透计算方法相结合）。我们根据微服务的状态及其复制对应用程序部署的影响定义了微服务的分类这种分类对于决定如何以及在何处部署微服务至关重要。我们考虑一个著名的微服务应用程序的雾部署，即共享乳胶。基于我们的分类法和一些额外的标准，如关键性和使用情况，我们提出了一种方法来分割和复制不同位置的应用程序服务我们评估了这种部署如何影响某些应用程序用例，并确定了一些问题，如果应用程序设计时考虑到雾部署，这些问题可能会得到不同的处理。在我们的部署中，最常见的是微服务的状态在不同的实例中完全复制，或者以每个实例存储一组不同的存储对象的方式进行分片。我们观察到，在给定对象的情况下，找到最佳副本或定位正确的分片是这种部署中的常见要求，如果在应用程序外部处理，则有几个优点·········
我的内容管理
展开
