CN114731296A - 用于分布式边缘云计算的方法和系统 - Google Patents

Abstract

公开了边缘云计算设备的实施例。在实施例中，边缘云计算设备包括边缘节点激活模块，该边缘节点激活模块被配置为从在边缘云计算设备中运行的应用接收请求，并确定服务于接收的请求所需的一个或多个微服务的类型。边缘节点激活模块被配置为当所确定的类型对应于边缘云计算设备中本地托管的一个或多个微服务时，在边缘云计算设备中本地处理请求。

Description

用于分布式边缘云计算的方法和系统

技术领域

本发明总体上涉及云计算。特别地，本公开涉及用于分布式边缘云计算的方法和系统。

背景技术

通常，一些最受欢迎的消费者和企业应用和解决方案托管在通常称为“云”的数据中心内。云计算对于使能像Facebook^®、YouTube^®、Instagram^®、DropBox^®等之类的应用至关重要。底层架构对应于客户端-服务器架构，其中某些节点或计算设备充当“服务器”，并且其他节点或计算设备充当“客户端”。今天，绝大多数计算设备或节点以客户端-服务器模式操作，其中大多数服务器位于由分散在世界各地的服务器群组成的数据中心内。这样的固定且分层的客户端-服务器架构对于托管向大量客户端设备提供对来自远程服务器的内容和信息的访问的应用可能是高效的。通常，解决方案的后端托管在处理计算密集型任务的服务器上，并且解决方案的客户端应用软件（前端）托管在“边缘设备”上，其用于更简单的功能，诸如输入命令、高速缓存内容和为最终用户呈现信息。

该架构的优点之一是借助虚拟化和协调技术，在许多应用之间共享的通用服务器上快速且低成本地部署（计算和/或存储密集型）应用。然而，在过去的十年中，各种趋势已经见证了使分层客户端-服务器架构不太高效。当前分层架构中的中央云资源和网络连接性是未来增长的潜在瓶颈。将数据从数千亿个客户端设备发送到数千万个集中式云服务器导致带宽和能源的浪费并具有严重的社会和经济影响。

中央云架构的又一个缺点是，开发者依赖云服务提供商，云服务提供商具有对其服务器中存储或处理的应用和数据的访问权。因此，今天，少数几个非常大的公司对绝大多数的消费者和企业数据进行控制。此外，尽管采取了所有复杂的安全措施，但在第三方资源上存储数据和托管应用使信息所有者暴露于多重风险。云资源为对于数百万开发者和应用服务提供商的容易访问进行设计，这进而增加了漏洞和安全漏洞。在某些情况下，这导致了对消费者和企业数据隐私和安全的严重滥用。

发明内容

公开了实现有效和可行的方法以解决至少上述突出的挑战和缺点的系统和方法。在实施例中，该系统通过将任何计算设备或边缘节点转变成云服务器来实现云的去中心化。通过将边缘计算设备转变成云服务器，可能的是减少数字中间人和第三方信任元件的作用，因为许多应用不必要中央托管服务。这样，创建了物理“边缘云结构”，其潜在地比当前的“中央云”结构大几个数量级。

公开了边缘云计算设备的实施例。在实施例中，边缘云计算设备包括边缘节点激活模块，该边缘节点激活模块被配置为从在边缘云计算设备中运行的应用接收请求，并确定服务于接收的请求所需的一个或多个微服务的类型。边缘节点激活模块进一步被配置为当所确定的类型对应于边缘云计算设备中本地托管的一个或多个微服务时，在边缘云计算设备中本地处理请求。在实施例中，边缘节点激活模块进一步被配置为提供微服务运行时环境来执行本地托管的一个或多个微服务。在实施例中，边缘节点激活模块进一步被配置为提供本地托管的API网关，以向本地托管的一个或多个微服务发送请求。一个或多个微服务被配置为服务该请求并向应用发送回响应。

在实施例中，边缘节点激活模块进一步被配置为当服务于接收的请求所需的一个或多个微服务的确定类型对应于中央云计算设备中全局托管的一个或多个微服务时，向中央云计算设备中托管的API网关发送与从应用接收的请求相对应的http/https请求。边缘节点激活模块进一步被配置为从中央云计算设备中托管的API网关接收对http/https请求的http/https响应，并且其中http/https请求由中央云计算设备中全局托管的一个或多个微服务服务。在实施例中，边缘节点激活模块进一步被配置为提供本地托管的API网关，以将http/https请求发送到托管在中央云计算设备中的API网关。在实施例中，边缘节点激活模块进一步被配置为当服务于接收的请求所需的一个或多个微服务的确定类型对应于另一边缘云计算设备中托管的一个或多个微服务时，将请求直接发送到另一边缘云计算设备中托管的一个或多个微服务。在实施例中，边缘节点激活模块进一步被配置为实现边车（sidecar）模式以形成对应于本地托管在边缘云计算设备中的一个或多个微服务和托管在另一个边缘云计算设备中的一个或多个微服务的服务网格。

在实施例中，边缘节点激活模块进一步被配置为基于第一组参数发现一个或多个其他边缘云计算设备，以在它们之间建立连接，并提供微服务运行时环境，以执行与在一个或多个边缘云计算设备之间建立的连接相关联的本地托管的一个或多个微服务。第一组参数包括与一个或多个边缘云计算设备中的每一个相关联的用户账户、与一个或多个边缘云计算设备相关联的网络以及一个或多个边缘云计算设备的邻近度。在实施例中，边缘节点激活模块进一步被配置为发现由一个或多个边缘云计算设备支持的一个或多个微服务。

在实施例中，边缘节点激活模块进一步被配置为与一个或多个边缘云计算设备动态形成一个或多个集群，并在微服务级别上直接或通过跨一个或多个集群上的其他边缘云计算设备与一个或多个边缘云计算设备通信。在实施例中，边缘节点激活模块进一步被配置为通过公共嵌入式网络服务器（web server）向一个或多个边缘云计算设备暴露本地托管的一个或多个微服务服务。在实施例中，边缘节点激活模块包括嵌入其中的网络服务器，其中网络服务器被配置为基于与边缘云计算设备相关联的操作系统使用特定语言来提供容器管理API。

还公开了具有实现本文所述各种技术的指令的计算设备和计算机可读介质。示例计算机可读介质可以包括有形的、非暂时性的计算机可读存储介质，其具有可由处理器执行的计算机可执行指令，该指令在由处理器执行时使得处理器实行本文提供的各种方法和途径的任何组合。示例计算设备可以包括服务器或客户端设备，该服务器或客户端设备包括处理器、存储器、客户端应用和/或被配置为实行本文描述的方法的网络服务。

前述概述仅为说明性的，并且不旨在以任何方式进行限制。除了上述说明性的方面、实施例和特征之外，通过参考附图和以下详细描述，另外的方面、实施例和特征将变得清楚。

附图说明

图1示出了使用微服务的示例云架构100。

图2示出了使用微服务的云架构200的另一个示例。

图3示出了边缘云计算网络的示例性实施例300。

图4图示了根据实施例的边缘云架构400的基本构建块。

图5示出了根据实施例的边缘云计算设备500。

图6示出了根据实施例的示例性后端微服务分布600。

图7示出了根据实施例的示例性边缘云计算架构700。

图8示出了根据实施例的边缘云架构800中属于同一用户ID的两个边缘云计算设备的发现、连接和通信的示例性实施例。

图9示出了根据实施例在边车模式中使用无服务器微服务实现的示例性边缘云架构900。

图10示出了根据实施例的用于利用本地和全局托管的微服务的应用的示例性无服务器微服务1000。

图11示出了提供云计算基础设施的方法1100的示例性实施例。

图12示出了提供云计算基础设施的方法1200的另一实施例。

附图的详细描述

呈现以下详细描述以使得任何本领域技术人员能够制造和使用本发明。出于解释的目的，阐述了具体细节以提供对本发明的透彻理解。然而，对于本领域技术人员而言将清楚的是这些具体细节并不是实现本发明所必需的。特定应用的描述仅作为代表性示例提供。对于具有高的本领域技术的人员来说，对优选实施例的各种修改将容易地清楚，并且在不脱离本发明的范围的情况下，本文限定的一般原理可以应用于其他实施例和应用。本发明不旨在被限制于所示的实施例，而是符合与本文公开的原理和特征相一致的最宽可能的范围。

云计算架构的最新演进是转向微服务，该微服务将单片后端解决方案分解成在API网关后面时被动态实例化（无服务器）的微服务集合。这样的演进在微服务到微服务通信和集群管理中、尤其是在云计算环境的情境下引入了新的复杂度。例如，图1示出了使用微服务的示例云架构100。如所示，计算设备（客户端设备或节点）102运行向API网关108发送http/https请求106的客户端应用104。API网关108从中央云计算设备114中托管的云后端112发送http/https响应110。云后端112中还托管有全局托管的微服务116、118和120的集合。http/https响应110可以对应于响应于http/https请求106而启动的微服务之一（例如120）。这样的架构通常包括计算设备（例如102）上的客户端应用（例如104）和中央云功能的集合，以支持托管解决方案的后端，该解决方案的后端通常由可通过API网关（例如108）到达的一系列微服务（例如116、118、120）组成。在这样的场景中，每个http请求从“客户端设备”发送到中央云内的服务器（例如114），如同在典型的服务器-客户端架构的情况下。

图2中示出了用于客户端至客户端通信的云架构200的又一个示例。考虑运行客户端应用204的第一客户端设备202希望向运行客户端应用232的第二客户端设备230发送信息的场景。客户端应用204发送http请求206，该http请求206在中央云212中托管的API网关208处结束。https请求206对应于中央云212上托管的适当的微服务（例如，216、218、220），该微服务响应于请求210而被启动。启动的微服务（例如216）向推送通知服务222发送触发214，以将可从第一客户端设备（228）获得的信息传送给第二客户端设备230。接下来，在第二客户端设备230中运行的客户端应用232以（获取信息）请求224响应API网关208，该API网关208再次由中央云上托管的微服务（例如216）服务。接下来，服务微服务（例如216）将信息从第一客户端设备（226）发送到第二客户端设备230。因此，即使两个客户端设备（第一和第二客户端设备）处于紧密的邻近度并且在同一本地网络上，所有的通信和数据也将需要通过可能在数百英里之外的数据中心内的服务器，这可能是次优的和不合期望的。

解决该问题的有效且可行的方法是使得任何给定的计算设备充当云服务器。使得计算设备能够充当云服务器，可能潜在地减少对应用不必要的第三方云服务的依赖。此外，该方法还可以通过将微服务从后端动态移动到计算设备（现在充当服务器）来允许基于微服务的解决方案更灵活。在中央云内执行的许多功能可以在“充当”或“配置”为服务器的边缘设备上执行。一旦计算设备被配置为充当服务器，就可以提供比现有的中央云大几个数量级的去中心化边缘云计算（架构）。这样的架构存在包括以下各项的许多益处：降低云托管成本，降低通信带宽和网络效率，降低能耗和碳排放，减少时延，减少应用开发时间，拥抱微服务趋势的优势，增加数据隐私性，以及为消费者和企业提供对其数据行使更好控制。

在实施例中，实现此目的的第一步骤是移除服务器仅能存在于数据中心内的约束。这是基本约束，它限定了当今互联网的主要固定和分层客户端-服务器基础设施。本文公开了一种替代的架构，该架构遵循实用的方法，通过基于应用的实时需求使得任何计算设备能够充当客户端和/或服务器。

如较早前提及的，各种趋势已经见证了使现有的分层客户端-服务器架构不太高效。例如，第一个趋势是计算设备和嵌入式计算在所有事物中的爆炸式增长，以及边缘设备的不断增加的能力。例如，与在仅十年前的功能强大的服务器中相比，存在今天的智能电话中可用的更多的计算能力、内存和存储。例如，第二个趋势是在这些（边缘）设备上生成的巨大量的数据。随着移动设备上社交媒体的出现，设备上生成了数量级更多的个人多媒体内容（照片、视频、传感器数据等），而不是托管在云中中央服务器上的主要工作室和广播公司的优质内容。如今，在（边缘）设备上生成的大部分数据被发送回到中央云进行处理并且促进共享。第三个趋势是在微服务集合中分解解决方案以及部署的自动化，这使后端解决方案动态得多（无服务器），其具有紧密配合体量或甚至地理上的需求的可扩展性。

作为示例，目前人们家中存在超过8千万个索尼PlayStation 4（PS 4™）控制台。这表示超过6亿个处理器内核和大约40000千兆字节（petabytes）的存储。相比之下，这表示总计比整个Amazon Web Services（AWS^®）基础设施大得多的计算、存储和内存资源。存在数十亿个PC、机顶盒、游戏控制台、流媒体播放器、路由器、智能电话、平板设备和其他计算设备，它们可以潜在地充当云服务器并且共同具有比现有“中央云”多几个数量级的计算能力。本公开提供了创建由数十亿边缘云计算设备（或节点或边缘节点）组成的云结构的系统和方法，该云结构比现有的中央云大几个数量级。

去中心化云架构的公开的实施例不需要创建具有专用硬件的新网络节点。取而代之，公开的架构使得诸如PC、平板设备、机顶盒（STB）或者甚至家庭路由器之类的现有计算设备能够在可信时充当在云网络边缘的云服务器节点。公开的方法不需要对这些设备的低级别设计的任何改变。所有需要的是运行在现有操作系统顶上的可下载应用（例如边缘节点激活模块），而无需对现有设备的硬件或OS内核的任何改变。除了为开发者提供强大的武器库以去中心化现有的云基础设施之外，公开的架构为消费者提供了对其个人数据的更多控制。此外，除了其他事物之外，公开的方法尤其最小化应用和服务的托管和交付成本、改进网络性能并最小化时延。

公开了边缘云计算平台的实施例。公开的云平台加速了作为云计算中的下一革命的去中心化。云去中心化中的首要步骤是移除服务器仅能存在于数据中心内的约束。这是基本的约束，它限定了当今互联网的主要客户-服务器基础设施。本公开提供了通过基于应用的实时需求使得任何计算设备能够充当客户端或服务器来实现此的替代架构/平台和实用的方法。还公开的是使用边缘节点激活模块和一个或多个后端服务来创建边缘云结构的云平台。

公开的架构和平台的益处和优点包括降低云托管成本、降低通信带宽、增加网络效率、降低能耗和碳排放、降低时延、增加隐私性以及对消费者和企业数据的更好控制。

公开了在通信网络中提供边缘云计算基础设施的方法的实施例。通信网络包括与至少一个服务器计算设备通信的一个或多个边缘云计算设备。在实施例中，该方法包括由第一边缘云计算设备确定对应于来自在第一边缘云计算设备中运行的应用的请求的一个或多个微服务的类型。该方法进一步包括当确定类型对应于第一边缘云计算设备中本地托管的一个或多个微服务时，由第一边缘云计算设备在第一边缘云计算设备中本地处理该请求。该方法进一步包括由第一边缘云计算设备提供微服务运行时环境来执行本地托管的一个或多个微服务。

在实施例中，该方法进一步包括由第一边缘云计算设备提供本地托管的API网关，以向本地托管的一个或多个微服务发送请求。在实施例中，该方法进一步包括当一个或多个微服务的确定类型对应于中央云计算设备中全局托管的一个或多个微服务时，由第一边缘云计算设备向中央云计算设备中托管的API网关发送对应于来自应用的请求的http/https请求。该方法进一步包括由第一边缘云计算设备从中央云计算设备中托管的API网关接收对http/https请求的http/https响应，并且其中http/https请求由中央云计算设备中全局托管的一个或多个微服务来服务。在实施例中，该方法进一步包括由第一边缘云计算设备提供本地托管的API网关，以将http/https请求发送到中央云计算设备中托管的API网关。在实施例中，该方法进一步包括当来自应用的请求的确定类型对应于对第二边缘云计算设备的数据请求时，由第一边缘云计算设备将来自本地托管的一个或多个微服务的数据请求直接发送到第二边缘云计算设备中托管的一个或多个微服务。在又一实施例中，该方法进一步包括由第一边缘云计算设备提供边车模式以形成服务网格来支持在第一边缘云计算设备中运行的应用。该方法进一步包括由第一边缘云计算设备通过公共嵌入式网络服务器向一个或多个边缘云计算设备暴露本地托管的一个或多个微服务服务。在实施例中，该方法进一步包括由第一边缘云计算设备基于与边缘云计算设备相关联的操作系统使用特定语言来提供容器管理API。

在实施例中，该方法进一步包括由第一边缘云计算设备发现一个或多个其他边缘云计算设备，以在它们之间建立连接，并由第一边缘云计算设备提供微服务运行时环境，以执行与在一个或多个边缘云计算设备之间建立的连接相关联的本地托管的一个或多个微服务。在实施例中，该方法进一步包括由第一边缘云计算设备发现托管在发现的一个或多个其他边缘云计算设备中的一个或多个微服务，并且由第一边缘云计算设备在本地托管的一个或多个微服务和一个或多个边缘云计算设备中的发现的一个或多个微服务之间建立直接微服务级别连接。在实施例中，该方法进一步包括由第一边缘云计算设备加载和执行服务来自应用的请求所需的一个或多个微服务。该方法还包括一旦已经服务了来自应用的请求，就由第一边缘云计算设备停止所加载的一个或多个微服务。

图3描绘了边缘云计算网络300的实施例。在现有的“中央云”模型中，随着更多设备被添加或更多内容由设备生成，数据中心内必须添加更多服务器来支持它们。利用如图3中所示的分布式边缘云计算网络300，可以创建随着边缘设备的数量而扩展的云结构。随着边缘设备数量和边缘设备生成的内容增长，这减少了数据中心内对于附加服务器的需求。

在正在进行的描述中，“边缘设备”可互换地称为“节点”或“边缘节点”或“边缘计算设备”或“边缘云计算设备”。因此，“云”容量随着边缘云计算设备数量增长而增加。此外，假定大多数数据在边缘产生，应用的传输成本和时延被最小化。在公开的方法中，大多数处理在边缘执行，通信尽可能保持在本地，并且边缘云计算设备协作并共享计算和其他资源。出于正在进行的描述的目的，“中央云”或“中央云计算设备”指代数据中心内的一个或多个服务器，它们仍然是有价值的资源，因为它们对于需要中央存储或处理的许多应用可能是不可或缺的。然而，在提出的边缘云平台和架构中，中央云将不再是瓶颈或“必要的”信任元件，并且不需要与边缘节点成比例地增长。可以注意的是，数据中心资源可能需要增加，但是以合理的速度来仅适应中央处理的需求。所有其他可能的任务和功能都可以移交给边缘节点，今天大部分数据都是在所述边缘节点处生成的。

如图3中所示，边缘云计算网络300包括多个边缘云计算设备，诸如膝上型计算机302、平板PC 304、中央“云”306、汽车信息娱乐系统308、安全相机310、服务器计算设备312、移动设备314和游戏控制台316。在示例性实施例中，每个边缘云计算设备可以被配置为根据边缘云计算网络300的需要充当客户端或服务器。此外，图3以虚线示出了边缘云计算设备之间的连接或通信路径。如本领域技术人员将领会的，该架构不遵循常规的客户端-服务器模式，在常规的客户端-服务器模式中，一个或多个设备被指定为总是充当“服务器”并且其他设备总是充当“客户端”。

在边缘云计算网络300的提出的架构中，操作系统和网络中存在碎片，这可能是使提出的架构可行的挑战。例如，每个边缘云计算设备可以使用不同的操作系统，诸如Linux^®、android、iOS^®、macOS^®、Windows^®、Fedora™等之类的多个变体。此外，边缘云计算设备可以被配置为使用不同的联网技术来操作，所述不同的联网技术诸如是固定（以太网、光纤、xDSL、DOCSIS^®、USB等）、移动WAN（2G、3G、4G等）、无线LAN（WiFi^®等）、无线PAN（蓝牙^®、WiGig、ZWave^®、ZigBee^®、IrDA等）以及机器网络（SigFox^®、LoRa^®、RPMA等）。为了应对该挑战，提出的云架构包括边缘云计算设备（例如，314 ），边缘云计算设备（例如，314 ）当被“激活”时被配置为跨许碎片化的操作系统和网络技术与其他边缘云计算设备连接、通信和协作。

在本公开的另一方面，网络资源的可用性可能是边缘云计算网络300中的挑战。因此，一旦边缘云计算设备（例如312、314）充当服务器，它们就可以使用上行链路网络资源与其他边缘节点连接和通信。尽管网络连接性逐渐变得对称，但通常与上行链路资源相比，存在更多可用的下行链路资源。作为说明性示例，与将视频从源节点（直接）流式传输到目的地节点相比，将视频从边缘节点发布到中央云以供三个其他边缘节点消费直接需要不同的上行链路/下行链路资源。在集中式云网络中，存在上行链路的一个实例和下行链路的三个实例，并且在提出的去中心化边缘云计算网络300中，存在上行链路的三个实例（假设都不在防火墙后面）。因此，网络资源的可用性将是分布式边缘云平台可行的重要方面。该问题的解决方案将关于“精英管理（meritocracy）”原理进行解释。

在本公开的又一方面，与数据中心内的服务器不同，大多数边缘节点本质上可能是非持久性的。可能存在对其可用性和可靠性的较少控制，尤其是在电池供电的移动设备的情况下。提出的边缘云计算架构通过下面解释的“微服务”方法克服了该挑战。在实施例中，当构建持久节点必要的某些应用时，考虑边缘节点的非持久性质。持久节点总是可以使用其他协作边缘节点来提供，或者在最坏的情况下，可以使用中央云。

需要克服的又一个挑战是分发管理。在数据中心内，分发管理基于诸如CPU负载、内存约束和IO之类的更简单的标准应对资源可用性。分发管理的范围是运行解决方案（后端）的特定数据中心。在边缘云的情况下，用于分发管理的标准多样化得多，并且包括功率可用性和功耗、可靠性以及设备功能。如稍后讨论的，在边缘云计算架构的情况下，分发范围扩展到网络、邻近度和账户，因为大多数设备属于特定用户。

现有的中央云架构可能是高效的，其中信息在中央位置/设备中生成和/或存储，并且大多数边缘节点用于从万维网接收信息（通过一系列可通过http到达的专用服务器）。然而，由于社交媒体、用户生成内容、物联网（IoT）和机器生成数据的快速增长，边缘节点正在生成当今的大多数数据。因此，一个关键的考虑因素是最适合用于数据生成和使用中的基本变换的（一个或多个）架构，如正在进行的公开中所提出的。

对于去中心化边缘云，包括“中央云”（例如，图3中的306）的所有节点可以充当云服务器，并且不存在指定的永久信任元件。边缘节点或边缘云计算设备被配置为在除非必要不诉诸于第三方信任（中央）元件的情况下直接通信、协作和直接共享资源。通过该方法，中央云资源仅在需要时使用，例如，当存在对于全局存储、归档、集中式数据库更新、集中式注册等的需要时。可以由边缘节点处理的任何其他功能可以被指派给它们，例如，设备之间的消息传递，或者机器之间的控制信号握手，或者在小型集群内的节点之间传输数据。

此外，软件行业中的正在进行的趋势使提出的去中心化非常可行。在过去，管理由大量组件组成的软件解决方案的复杂度导致了单片的解决方案。然而，虚拟化技术向像Docker^® & CoreOS^®之类的更轻型容器管理平台的演进、按需IT的消费化以及丰富通信（API）的易用性已经显著降低了复杂度。好的软件设计实践是将解决方案开发为单个目的、限定明确的组件的许多实例的集合，其在下文中称为“微服务”。

这样设计云系统的结果是：更精细地利用基础设施资源以紧密遵循需求曲线、简化复杂属性（会话、租用）的设计，更好地在数据中心内或数据中心之间分发和利用计算资源，以及进一步将解决方案的客户端从单片分解为微服务架构，以便更快的应用开发时间和更容易的软件升级和维护。为了在提出的架构中实现软件解决方案的更高效率，使用短暂微服务（也称为“无-服务器”或“无服务器”架构）的编程被实现，其中基于对微服务本身进行的API调用来实例化（启动和运行）微服务。

在示例性实施例中，通过识别和暴露计算资源并且在可用时以机会方式利用计算资源，将云扩展至边缘。此外，向基于可用性、策略和上下文（包括社交和其他应用级别事件）部署短暂微服务的方式添加分析，使能在边缘云计算网络300上优化部署应用。公开的架构假设现有的边缘云计算设备可以容易地转变成边缘云服务器（或边缘云服务器计算设备）。在描述的范围内设想开发者应当能够以尽可能少的努力构建应用（由边缘云支持）。给定边缘云计算设备的异构性质，公开的方法基于设备能力指派功能角色。为了使开发者开发应用容易，实现并遵循与中央云类似的API语义，例如Amazon Web Services^®（AWS）或Microsoft Azure^®。此外，实现了在边缘节点上运行微服务的轻型容器和现有容器技术的语义，诸如例如Docker^®或CoreOS^®。

在公开的方法中，边缘节点或边缘云计算设备被配置为展示成为潜在边缘云服务器或边缘云服务器计算设备的多个能力。所述多个能力包括发现其他边缘节点或边缘云计算设备的存在的能力，而不管与它们相关联的操作系统（OS）或网络。所述多个能力还包括发现其他节点的能力和行为（例如，硬件规格、OS、持久性等）的能力。所述多个能力进一步包括发现由其他边缘节点或边缘云计算设备支持的一个或多个微服务以及连同其他边缘节点或边缘云计算设备一起尤其是在网络、邻近度和用户账户周围动态形成集群的能力。

在另一个实施例中，所述多个能力进一步包括直接或通过跨不同群集中的其他节点与微服务级别的其他节点进行通信以及与它们选择共享数据、服务和/或资源的其他节点进行连接的能力。在仍另外的实施例中，所述多个能力进一步包括基于资源和能力适应所指派的功能和角色以及本地处理和分析数据的能力。此外，所述多个能力进一步包括成为与中央云一样安全和可信的能力。

在实施例中，展示多个能力的边缘节点或边缘云计算设备的配置通过平台不可知的方法实现。在实施例中，提供了可下载的应用级别软件（例如，边缘节点激活模块），其将任何边缘云计算设备转变成边缘云服务器，并因此构建端到端边缘云平台。本领域技术人员应当注意，提出的方法不需要对设备硬件、OS内核或驱动程序的改变，并且在大多数调制解调器硬件（PC、STB、路由器、平板设备、智能电话等）上工作。还应当注意的是，提出的软件级别应用具有非常小的内存占用，并支持可以跨边缘云计算设备容易地加载、运行和停止的微服务。

此外，公开的方法支持多租户、多应用和微服务，其中单个软件实例支持多个客户。公开的云平台具有在“中央云”（例如，图3中的306）上托管的轻型但高度可扩展的后端（服务），并且使用引导机制来注册节点或其他边缘云计算设备。公开的云平台提供了在同一网络、邻近度和（用户）账户内创建边缘节点的动态集群以及管理集群间和集群内节点的移动性特性（出现和消失）的能力。

在实施例中，边缘云计算网络300直接或通过中间节点管理边缘节点或边缘云计算设备之间的通信，并基于来自边缘节点的需求动态实例化后端资源或服务。此外，边缘云计算网络300通过动态拉动协作边缘节点和/或资源来创建有效的持久性。

为了利用边缘节点的能力并创建大规模去中心化边缘云，公开的方法考虑并实现了边缘云架构中的各种原理。通过公开的方法实现的去中心化的第一原理是“精英管理”。所有节点都具有参与边缘云计算网络300的平等机会。节点基于它们的能力可以承担任何角色。由节点所有者使能的功能存储在节点配置文件中。例如，具有大存储的节点可以成为“高速缓存节点”或“备份存储节点”，具有良好网络连接性的节点可以成为“代理节点”，并且持久节点可以成为节点集群的知识（例如，设备和能力/角色配置文件）的持有者，等等。精英管理避免了为中心元件提供预定义角色的需要，这导致了节点的层次结构。

在实施例中，诸如“透明度”之类的精英管理工作所必要的其他原理也在公开的方法中实现。例如，节点应当以透明的方式说出关于其配置文件的真相，否则精英管理的原理不能有效地应用。公开的架构移除了撒谎的动机（例如，不提供任何节点特定的特权或权利）。即使当不存在撒谎的明显动机（例如，提供虚假信息、误导信息或假信息）时，公开的架构也实现一种机制来将对其配置文件撒谎以损害边缘云计算网络100中的集群的操作的节点列入黑名单。此外，精英管理可能随时间而改变，并且节点可能升级或降级其能力和配置。公开的架构实时适应对节点的任何这样的改变。

关于“精英管理”原理的一个重要考虑因素是中央云资源在提出的架构中的价值。中央云架构可以被视为边缘云计算架构的特例，其中边缘节点仅用作客户端。因此，为了加快开发速度而同时牺牲托管成本、时延和隐私，可能合期望的是中断现有的不良实践或退回到中央云上现成可用的资源。为了使精英管理原理有效工作，所有节点都被视为对其他节点的潜在“服务器”，并且所有请求都需要保持在节点处于活动的群集的本地。

由公开的方法实现的去中心化的第二个原理是“分布式发现”。边缘云计算网络100中的节点需要发现其他节点。在正在进行的公开中，发现旨在是基于范围的“过滤搜索”操作。范围的说明性和非限制性示例包括用户账户（在同一账户ID下注册的节点）、网络（作为同一链路本地集群网络的成员的节点）、邻近度（报告它们自己物理上存在于地理位置或地理空间查询所限定的区域内的节点）。在实施例中，发现过程使用这些或其他范围的任何组合，而没有专用的中央节点，例如充当存在服务器的中央节点。如果节点位于防火墙后面并且从外部不可到达，则它应当依赖于任何可到达的节点来变得可被发现。除非绝对必要，否则节点不应当依赖于中央实体。在实施例中，发现过程包括关于如何与设备连接和通信的信息、边缘节点可以采用的重要特性、角色和人物角色。各角色可以包括高速缓存节点（具有备用存储的节点）、代理节点（与互联网的良好连接性）、CPU资源（具有运行微服务的备用CPU的节点）等。

通过公开的方法实现的去中心化的第三个原理是“聚类”。人类和机器以集群进行通信。人类学家罗伯特·邓巴（Robert Dunbar）提出，人类可以与之具有稳定关系的人的认知极限是150。换言之，人类在受约束的集群中进行通信。附加地，人类很少定期或频繁地与紧密关系圈中的每个人通信。事实上，日常通信可能限于少数非常紧密的关系。因此，在为集群内的节点指派角色和责任时，为边缘云计算架构提出的通信框架考虑到这一点是合乎逻辑的。

然而，上述通信特性不限于人类。机器之间的通信非常相似，并且在任何给定的时刻，大多数通信经常是在集群中非常小的一组节点之间进行的。因此，可以优化所有通信，使其尽可能发生在集群本地。为了移除任何节点必须与每个其他节点握手的要求，在提出的架构中，群集中的一个节点（超级节点）被给予作为群的知识持有者的特殊角色。超级节点被指派了为/向全局发现或其他集群中的节点传达该知识的角色。提出的方法允许节点基于较早前描述的三个给定范围动态形成它们自己的自组织集群。节点经由其他节点基于一系列节点特性和规则的选举或选择来动态承担角色。通过这样做，节点动态形成边缘云的结构（即软件限定的云基础设施）。随着节点进入和退出集群，角色被动态重新指派。

节点主要在（受约束的）群集中通信。因此，边缘云中的公开的通信框架在向群集内的节点指派角色和责任时考虑到了这一点。第一活动节点（或第一边缘云计算设备）基于给定的范围形成集群。当节点被“激活”时，它首先寻找“超级节点”（在正在进行的描述中也被称为“超级边缘云计算设备”）。超级节点监督全局发现并且持有边缘云的知识。如果没有找到超级节点，则第一节点（或第一边缘云计算设备）声明或指定其自身为超级节点。如果通信网络可用，则超级节点向全局发现通知它的存在，并接收限定范围内的节点列表。为了维持效率，超级节点通知其范围内的其他节点。随后，可以标识更好的超级节点，并且该更好的超级节点可以向它们通知全局发现其存在，并且然后充当超级节点。

一旦超级节点已经创建了集群，进入集群的后续节点就被配置为发现现有超级节点，将它们自身注册到超级节点，并接收其范围内的节点列表。新节点向其范围内的其他节点通知它们的存在。公开的边缘云实现该引导模型以避免过载任何节点，无论是全局的还是本地的，并且因此减少了流量和聊天，并创建了轻型和可扩展的架构。给定节点的潜在移动性，存在通知是节点自身的功能，以及决定它想要通知哪些其他节点的责任。因此，公开的边缘云架构没有在公开的边缘云计算网络中实现单个全局存在服务器或注册点。类似地，公开的架构在节点之间的基础设施级别没有“保持活动”机制。在实施例中，如果在某些场景下需要，则这样的机制可以移交给微服务。

通过公开的方法实现的去中心化的第四个原理是“微服务到微服务通信”。为了创建分布式边缘云结构，边缘云计算设备或节点上的应用可以在除非绝对必要否则没有第三方信任元件的情况下直接通信。这可以允许设备在网络级别将边缘节点连接在一起。然而，在物理网络级别连接设备或边缘节点是不够的。运行在边缘节点上的微服务需要直接通信。在实施例中，边缘节点中的边缘节点激活模块提供了光容器，该光容器使能在边缘节点上部署和托管微服务，以利用所形成的边缘“云结构”来直接与其他微服务通信，从而创建“服务网格”。此外，边缘节点被配置为在边缘云计算网络100中的任何其他边缘节点上加载、启动和停止微服务。该配置确保了跨公开的云平台上的微服务管理保持分布式，而不需要中央实体。

在实施例中，边缘节点上使能的微服务通过公共嵌入式网络服务器暴露其服务。每个服务的API端点都从边缘群集中的所有其他边缘节点可访问。在实施例中，边缘云使能微服务跨边缘节点的无缝可达性，以直接或经由稍后更详细描述的“边车模式”形成服务网格。在可以运行容器守护进程（daemons）（例如Linux）的环境中，公开的边缘云平台提供了用于管理边缘节点的自组织集群的功能。在不能运行容器守护进程（例如，智能电话）的环境中，公开的边缘云平台提供了附加的“轻型”容器能力，其具有下载、部署和操作微服务的能力。

公开的方法实现的去中心化的第五个原理是“动态资源实例化”。为了使去中心化高效，合期望的是与节点加入集群、离开集群或取得指派的资源相关联的开销非常小。出于正在进行的描述的目的，由公开的边缘云架构实现的解决方案被称为“动态资源实例化”。根据该原理，基于网络条件和来自一个或多个集群内的边缘节点的需求，信令和数据资源被动态部署（通过后端服务），从而消除了保留计算资源的需要。这通过动态部署仅在需要时被实例化的端点（例如，SEP、BEP）来增加效率并降低成本。公开的云平台帮助边缘节点有机会设立隧穿以增加信令和数据带宽效率。基于在网络拓扑基础上的参数和在边缘节点上运行的应用的需求来部署资源。在实施例中，参数包括上线时间（time to go-live）、并发连接数和通信协议（HTTP、SSH、Web套接字或UDP隧穿）。如果期望，则可以将端点部署在给定群集的最紧密邻近度内的可用计算资源上。

通过公开的方法实现的去中心化的第六个原理是“协作”。为了利用去中心化边缘云网络中边缘节点的集体力量，期望的是边缘节点协作并共享资源。合期望的是去中心化云资源的共享像在中央云的情况下一样无缝。作为第一步骤，公开的云架构能够使用所有边缘云计算设备的集体资源。例如，视频以HD格式被记录在移动电话314上，并且记录的内容被无缝地存储在膝上型计算机302上或者甚至是连接的存储加密狗上。作为下一步骤，公开的架构使能与朋友和家人共享资源。例如，允许家庭成员共享网络附接存储（NAS）作为家庭资源。在实施例中，公开的架构还提供了向陌生人租赁计算资源以及创建甚至更大的边缘云的能力。这样，从大量边缘节点创建云结构，所述大量边缘节点比中心云大几个数量级。

可以注意到，公开的方法不旨在将边缘云与协作紧密结合。边缘云提供了利用跨边缘节点的协作和资源共享的机会。然而，即使没有协作，边缘云也可以提供上述许多益处。作为基本步骤，在任何边缘设备上构建的任何应用都优先使用其本地资源（而不是中央或全局资源）来托管微服务，以基于应用的要求为其集群中的其他节点服务。例如，Jack的设备应当用作托管Jack的应用程序的服务器。然而，在协作的情况下，该方法可以进一步扩展以使用其他节点上的资源。例如，Jill的电话可以为Jack的应用运行微服务，即使他们不在活动会话中，或者Jack可以在他的设备上为Jill的视频提供备用存储，或者Jill可以使用Jack的光纤连接，而不是她当时不良的蜂窝连接。换言之，协作可以显著改进效率和扩展性，但是对使边缘云有用而言可能不是必要的。

通过公开的方法实现的去中心化的第七个原理是“基础设施独立性”。如较早前所述，对于云去中心化，合期望的是公开的云平台对于操作系统、网络（类型和技术）和位置是不可知的。由于各种原因，已经存在对节点之间的去中心化通信标准化的许多失败的行业尝试。因此，提出的去中心化云平台独立于操作系统和网络的演进。换言之，公开的云平台在应用层的现有操作系统和网络标准顶上操作。该原理确保了公开的云平台在具有最小的依赖性或没有依赖性的情况下被长期部署和维护。公开的云平台还避免了遗留协议、模块、库、数据等的问题。

图4图示了根据分布式边缘云平台400的实施例的边缘云计算架构的基本构建块。基于上述原理，设计和开发了公开的分布式边缘云平台400。设想通过配置每个边缘云计算设备充当边缘云服务器来使能边缘云是一种实用的方式。如较早前所述，这样的配置是以对硬件平台、操作系统和底层网络技术不可知的完全分布式的方式执行的。公开的云平台、微服务、边缘节点（或边缘云计算设备）和云集群被配置为在任何操作系统上运行，并通过任何网络进行通信。此外，公开的云平台和分布式云服务独立于任何基础设施。

如图4中所示，分布式边缘云平台400是端到端系统，其包括作为其基本构建模块的中央和边缘元件。中心元件包括由服务器计算设备提供的后端服务模块402，并且边缘元件包括边缘节点激活模块426和一个或多个微服务（例如，如稍后关于图5所述的518、520、522）。本领域技术人员将领会，公开的架构旨在是分布式的，并且元件（中央或边缘）可以驻留在任何可到达的边缘云计算设备（例如，302、304、306、312）上的任何地方。

参考分布式边缘云平台400的中心元件，后端服务模块402托管在通过互联网可到达的服务器上，并提供必要的服务以支持跨边缘云上的边缘节点或边缘云计算设备。出于正在进行的描述的目的，边缘云被限定为节点（例如302、304）的集合，每个节点基于特定设备的上下文或能力范围具有全局唯一的ID。在实施例中，给定节点可以是多个集群的成员（例如，参见图7中的节点730）。例如，第一群集可以对应于用户帐户群集，它是属于注册它们的用户的节点群集。第二集群可以对应于网络集群（例如726），该网络集群是其物理上连接到的链路本地网络集群。第三集群可以对应于邻近集群（例如，736），其是特定周围区域内的节点集群。

在实施例中，后端服务模块402被配置为提供包括发现服务406、信令服务408、身份服务410的一个或多个后端服务。信令服务408进一步提供诸如信令端点（SEP）412和承载端点（BEP）414的资源。在实施例中，一个或多个后端服务进一步包括服务器令牌服务416和注册服务418。服务器令牌服务416可以与服务的安全令牌认证/授权功能相关联。后端服务模块402使用云网络服务420来托管，诸如但不限于服务器计算设备（例如312）中或云306中的Amazon Web Services^®（AWS）。

在实施例中，发现服务406和信令服务408的碎片或部分既在后端服务器（例如312）上又在边缘节点（例如302）上实现。例如，每个集群中的网络代理（或节点）是信令服务408的部分，并且每个集群中的超级节点（或超级边缘云计算设备）是发现服务406的部分。如本领域技术人员可以领会的，公开的云架构偏离了“边缘上的云客户端中的服务”的现有概念。其价值来自从中央云（例如306）一直到边缘节点的整个范围上的服务分布（如稍后关于图7所解释的）。

发现服务406被配置为持有和提供知识，以形成一个或多个集群、集群的总体状态以及集群内的节点。一旦形成集群，任何新节点就向超级节点注册，该超级节点随后经由超级节点通知发现服务406。为了减少可扩展性的流量，从超级节点到发现服务406的更新以机会方式发生，并且仅当一个或多个集群中发生改变时才发生。

在实施例中，发现服务406被配置为对超级节点执行可达性测试。当超级节点注册它自己时，发现服务406测试可达性。超级节点可能在防火墙后面，并且虽然它可以发起对发现服务406的调用，但是发现服务或其他外部节点可能不能模仿对超级节点的调用。在这样的情况下，发现服务406将请求信令服务408为集群动态部署信令端点（SEP）（例如412）。随后，发现服务406将SEP地址返回给超级节点。

在又一实施例中，发现服务406被配置为存储节点和集群配置文件的完整清单。该清单包括所有节点上的计算资源、每个节点的状态、每个节点的位置以及每个节点上可用的服务的详细信息。该清单进一步包括到达每个节点和集群的端到端网络拓扑、集群的可达性和资源的可用性以及其他相关信息。换言之，发现服务406对跨边缘云计算网络300上的所有资源具有完全可见性，并且可以供应该信息以实时地在网络内的任何可用资源上动态部署服务。在实施例中，公开的架构使用标准的amazon语义来使得对于开发者而言更容易以与在中央云资源的情况下类似的方式暴露资源。

在实施例中，身份服务410对应于第三方身份软件即服务（SaaS），例如基于OAuth2.0，其驻留在公共云中，并创建和维护节点的认证配置文件。在实施例中，公开的云平台使用身份服务410（连同服务器令牌服务416）借助于一个或多个令牌持有者的令牌生成和管理来进行节点授权。令牌持有者可以是边缘节点激活模块（例如426、508）、使用边缘节点激活模块的微服务（例如518、520、522）、使用边缘节点激活模块的应用开发者以及应用的终端用户。公开的云平台使用令牌来验证凭证、令牌持有者的合法性，并授权对后端服务模块402提供的一个或多个后端服务的访问。在实施例中，通过使用Jason Web令牌（JWT）和用于验证令牌持有者身份的标准“声明”的子集来执行授权。

在实施例中，信令端点（SEP）412和承载端点（BEP）414均是基于从例如发现服务406或信令服务408接收的请求而动态和按需部署的资源。因此，不需要预留计算资源。通过仅在需要时部署端点，这增加了效率并降低了成本。SEP用于信令通信，而BEP用于数据通信，并且它们联合帮助节点有机会设立隧穿来增加信令和数据带宽效率。基于参数部署SEP和BEP，所述参数诸如但不限于上线时间、并发连接数和通信协议（HTTP、SSH、Web套接字或UDP隧穿）。如果期望，则端点可以部署在群集的最紧密邻近度内的可用计算资源上。

在实施例中，服务器令牌服务416是基于OAuth2.0的SaaS解决方案。在实施例中，服务器令牌服务416向向其他服务发出请求的服务提供令牌。在实施例中，服务器令牌服务416驻留在公共云中，并根据系统图发布服务令牌。此外，服务器令牌服务416实现“客户端_凭证”和“刷新_令牌”流。当微服务需要调用另一个微服务时，它要么已经具有有效的令牌并且因此可以直接发出请求，要么它请求包括许可（或范围）列表的令牌。在实施例中，接收服务将验证令牌签名和范围，以便满足传入/接收的请求。在实施例中，这样的服务对服务令牌是短暂的。

在实施例中，注册服务418（也称为IT储存库）是SaaS解决方案，其驻留于公共云中，并维护所有后端微服务及其所属集群的列表。主要用于管理目的，注册服务418维护集群知识，并允许集群出于配置目的进行自我管理。在实施例中，注册服务418提供地理定位的集群列表（或如稍后关于图6描述的配置），其他服务（例如，发现服务406）可以使用该地理定位的集群列表来标识信令服务408，以在需要时调用SEP 412或BEP 414。

现在转向分布式边缘云平台的边缘元件，边缘云计算设备404包括边缘节点激活模块426。如较早前所述，边缘节点激活模块426位于OS层428顶上，并提供微服务运行时环境，用于使用微服务运行时环境模块424来执行一个或多个微服务。一个或多个第三方应用422也被托管在由边缘节点激活模块426服务的边缘云计算设备404中。在实施例中，开发者可以使用由边缘节点激活模块426提供的容器管理器来开发他们自己的微服务，所述微服务可以被托管在边缘设备或节点上。

在实施例中，边缘节点激活模块426被配置为将任何边缘设备（或边缘云计算设备）转变成云服务器，并将云计算基础设施扩展至该新边缘。边缘设备可以是具有基本计算能力的任何设备，诸如膝上型计算机（例如302）、机顶盒、住宅和IoT网关、连接TV的游戏控制台、汽车信息娱乐系统（例如308）、智能电话（例如314）等。任何边缘设备可以下载边缘节点激活模块426并执行它以“成为”云服务器。出于正在进行的描述的目的，已经执行边缘节点激活模块426的任何边缘设备被称为“节点”。这样的节点具有旨在用于公开的边缘云平台和架构的一个或多个特性。所述一个或多个特性包括独立于OS和网络动态发现彼此（或其他节点）的能力，并且包括向彼此暴露计算和可用能力和功能的能力。所述一个或多个特性进一步包括形成和组织成集群（边缘集群）以及即使在没有互联网可用性的情况下在集群内和跨集群通信的能力。

公开的边缘云平台通过根据如上述第三聚类原理形成集群节点来操作。一个或多个集群由第一活动节点（或第一边缘云计算设备）基于特定范围形成。当节点（例如，第一边缘云计算设备）被激活（利用边缘节点激活模块426使能）时，它首先寻找监督全局发现并持有边缘云知识的超级节点。如果没有找到超级节点，则第一个节点声明它自己是超级节点。如果互联网可用，则超级节点向全局发现通知它的存在，并接收限定范围内的节点列表。为了维持效率，超级节点通知其范围内的其他节点。

超级节点创建集群后，进入集群的后续节点发现现有超级节点，将它们自身注册到超级节点，并接收它们范围内的节点列表。新节点通知其存在范围内的其他节点。该引导模型被公开的云架构用来避免使无论是全局的还是本地的任何节点过载，并因此减少流量和聊天。给定节点的潜在非持久性，存在通知旨在作为节点自身的功能，以及决定它想要通知哪些其他节点的责任。

如上面解释的，边缘节点激活模块426可以驻留在任何边缘云计算设备或服务器上，并且可以使其对于各种硬件平台和操作系统可用。在实施例中，边缘节点激活模块426对应于应用级别的软件，并且因此可以在许多类型的边缘云计算设备上下载。后端服务模块402提供托管在中央云（例如306）或具有足够计算和存储器的任何可到达且可靠的计算资源上的一个或多个后端服务，并提供必要的服务来支持边缘节点。

图5示出了根据实施例的边缘云计算设备500。如所示的，边缘云计算设备500包括耦合到存储器504的处理器502。存储器对应于具有实现本文描述的各种技术的指令的非暂时性计算机可读介质。示例计算机可读介质可以包括有形的、非暂时性的计算机可读存储介质，其具有由处理器502可执行的计算机可执行指令，所述指令在由处理器执行时，使得处理器实行本文提供的各种方法和途径的任何组合。尽管未示出，但是可以领会，所有边缘云计算设备（302、304、308、310、312、314、316、404）和中央云（例如306）至少包括处理器（例如502）、存储器（例如504）和/或存储在存储器中的各种其他应用或模块，所述应用或模块当由（一个或多个）处理器执行时，实行本文描述的方法和途径。

存储器504包括OS层506和边缘节点激活模块508。边缘节点激活模块508进一步包括具有API网关的网络模块510。边缘节点激活模块508还包括容器管理器微服务（

）图像储存库512、HTTP请求包装器（库）514和嵌入式网络服务器516。如较早前解释的，边缘节点激活模块508被配置为向一个或多个边缘节点暴露一个或多个微服务。在实施例中，边缘节点激活模块508被配置为启动/停止、下载、部署边缘云中的任何服务，并使用API网关暴露服务。为此，边缘节点激活模块508被配置为发现一个或多个群集中（在一个或多个群集内或跨一个或多个群集）的其他边缘节点、与所述其他边缘节点连接和通信。存储器504还包括一个或多个微服务（

），如图5中的518、520和522所描绘。微服务522被示为用户界面（UI）应用程序524的一部分。存储器504还包括其中没有微服务的其他UI应用程序526。所有微服务（518、520和522）和UI应用（524和526）都通过如图5中528所描绘的第三方暴露的API可访问。

在实施例中，边缘节点激活模块508对应于软件库和对应API的集合。旨在开发者也可以使用软件库和API来高效地解决新的超连接和高度移动的分布式边缘计算世界中联网节点的基本挑战。边缘节点激活模块308可以在异构环境中交付，而不管与任何边缘云计算设备相关联的OS、制造商和连接的网络。此外，边缘节点激活模块508可以在任何PC、服务器、移动设备、固定网关、自主汽车网关、连接的TV上或者甚至在云中运行（被执行），这取决于应用使用情况。如较早前所述，一旦边缘节点激活模块508被加载到边缘设备上，它就成为边缘云节点。

如图5中所示，边缘节点激活模块508驻留于操作系统层506和终端用户应用（例如，524，526）之间。存在几个微服务（例如518、520、522）从边缘节点500可获得，并且边缘节点激活模块508为第三方提供开发他们自己的微服务的能力。边缘节点激活模块508还提供微服务运行时环境。如较早前所述，通过并入边缘节点激活模块508，计算设备被变换成智能网络节点或边缘节点，它们可以形成一个或多个集群。边缘节点激活模块508消除了分布式边缘云节点之间联网的复杂度，从而使得开发者能够专注于他们在微服务模型中、甚至在小型移动设备（例如314）上的解决方案。

取决于物理硬件能力、OS、附接的网络连接性、每个节点上运行的微服务类型和使用/隐私策略设置，将群集中的节点配置为承担特定角色或角色组合。一些角色是通过选举过程指派的，在任何给定时间考虑集群内的其他节点，而其他角色是通过选择过程指派的。如较早前所述，集群中最重要的角色之一是超级节点（或超级边缘云计算设备），所有成员节点都对其选举节点。在单节点集群的平凡情况下，节点充当其自己的超级节点。超级节点被配置为关于集群及其所有成员节点的信息的承载者。这是集群的“单个真实源”。超级节点被配置为维护与其他节点、部署在每个节点上的微服务以及来自边缘节点激活模块508的操作的历史产物相关的信息。超级节点被配置为将诸如链路本地代理和链路本地高速缓存之类的角色指派给集群中的其他节点。在群集节点驻留于防火墙后面的情况下，链路本地代理节点支持通信。另一方面，可以为具有大量物理存储的节点指派群集的链路本地高速缓存角色。

对于每个节点，边缘节点激活模块508支持唯一用户和多个微服务和应用提供商（以其他方式称为“租户”）。换言之，即使用户已经在移动设备上加载了多个应用，所有这些应用都采用边缘节点激活模块508，功能和能力也与该用户相关（并且被授权给该用户）。在实施例中，边缘节点激活模块508在物理和微服务级别提供边缘设备之间的发现、连接和通信。例如，边缘节点激活模块508通过对（一个或多个）本地和全局网络中具有边缘节点激活模块实例的所有节点进行自动发现和自动路由来提供节点和服务发现。类似地，边缘节点激活模块508提供自组织边缘节点云中的节点和服务连接，形成自组织集群。在实施例中，边缘节点激活模块508被配置为提供光容器，以通过（远程/本地）加载、运行和管理微服务实例来管理一个或多个微服务。如较早前所述，边缘节点激活模块508包括用于提供微服务运行时环境的边缘网络服务器。

如较早前所述，具有边缘节点激活模块508的节点被配置为发现彼此、与彼此连接和通信。在实施例中，发现是“过滤搜索”操作，基于对应于用户帐户的一个或多个范围，即在同一帐户ID下注册的节点。在实施例中，边缘节点激活模块508通过第三方身份SaaS提供商（用作后端服务模块402提供的身份服务410）采用基于OAuth 2.0的OpenID标准。该范围也可以对应于网络，诸如作为同一链路本地集群网络成员的节点。在这种情况下，链路本地标识符是通过将公共IP地址和链路本地网络地址组合而形成的。范围也可以对应于邻近度，诸如报告它们自己物理上存在于地理位置或地理空间查询所限定的区域内的节点。由边缘节点激活模块508执行的发现过程可以使用上述范围的任何组合。这些节点中的每一个上和跨集群的微服务可以使用边缘云，经由API彼此调用来形成它们自己的服务网格。此外，节点和在节点上运行的微服务具有唯一的标识符，诸如特定节点上的特定微服务（例如，驱动器）可唯一地、本地和全局寻址。

此外，边缘节点激活模块508提供微服务运行时环境（轻型容器），以通过公共嵌入式网络服务器暴露与微服务相关联的服务。通过作为网络模块510的部分的API网关，从边缘群集中的所有其他节点可访问每个服务的API端点。边缘节点激活模块508以两个不同的方式补偿容器守护进程（或Docker^®）。在可以运行容器守护进程的环境（例如Linux^®）中，边缘节点激活模块508提供管理如较早前所述的边缘节点的自组织集群的功能。在不能运行容器守护进程（例如，智能电话）的环境中，边缘节点激活模块508提供附加的“轻型”容器能力，其具有下载、部署和操作微服务的能力。嵌入式网络服务器（例如516）提供具有一个或多个约束的容器管理（例如Docker^®）API的子集。所述一个或多个约束包括使用基于底层OS的特定语言（android使用java，iOS^®使用objective c等）。所述一个或多个约束进一步包括运行在“轻型”容器环境（由边缘节点激活模块508提供）上的微服务对边缘节点激活模块508提供的网络服务器的使用，以优化底层平台上有限资源的使用。

边缘节点激活模块508允许开发者在任何节点上构建和托管微服务。公开的云架构还利用边缘节点激活模块508提供各种微服务，以加速应用开发并使得开发者能够立即利用分布式边缘云平台。例如，在驱动器微服务的情况下，可以经由流行的API提供对边缘节点上可用存储的抽象访问和分布式文件管理。在另一说明性示例中，提供了波束微服务，其以对等、一对一和一对多的方式将内容从一个节点波束传送到（一个或多个）节点和/或（一个或多个）服务。

在实施例中，边节点激活模块508实现边车模式，该边车模式允许将应用分解成使用不同技术构建的组件。使用边车模式，应用的任何组件都可以独立构建和部署。由于边车与应用的邻近度而减少时延，并且可以在不改变应用本身的情况下添加组件和功能。边车模式抽象了应对服务网格的许多复杂度。这在公开的边缘云计算架构中是可能的，因为这些复杂度中的许多独立于跨边缘云部署的微服务类型。然而，边车模式可能不隐藏网络的分布式性质。作为示例，可以使用边车模式构建API网关或安全令牌管理。在实施例中，API网关是边缘节点激活模块508内的网络模块510的部分。API网关使每个服务的API端点都从集群中的所有其他节点可访问。通过提供该API网关，边缘节点激活模块508提供了对应对不同集群中的其他微服务的复杂度进行抽象的功能。

在边缘节点，安全性成为微服务如何通信的关键方面。像防火墙和网络分区之类的某些元件在中央云内非常常见，但在边缘上通常可能不存在。因此，处理多个级别的安全性可能是必要的。例如，在链路本地群集上，不可能使用https，因为群集中的节点没有域名。因此，同一链路本地网络内的节点之间的通信被加密。此外，每个微服务的API都经由令牌被保护。通常，边缘节点激活模块508运行在不可信网络环境中。因此，不能假设防火墙保护运行在边缘节点上的微服务。在实施例中，应对具有有效且未过期的令牌是由边车模式抽象的。由于存在可以管理来自其他节点的数据的一些特殊节点（例如，高速缓存节点或链路本地代理节点），所以可能需要对用户有效载荷进行加密，使得它仅对授权方可见。在实施例中，获取密钥、加密和解密用户有效载荷也由边车抽象。

对于邻近度和用户账户集群，路由至适当节点是复杂的操作，其需要应对超级节点和链路本地代理节点。在实施例中，边车对微服务的开发者隐藏了该复杂度，并且开发者仅需要调用集群内的适当微服务。分布式系统需要重试机制来确保容错。在实施例中，边车处理重试调用和重试策略。开发者可以专注于开发他们的微服务，而不是分布式系统的复杂度。类似于后端技术，像帮助开发者处理服务网格的Istio，边缘节点激活模块508在边缘处理服务网格，并应对使用边缘设备作为服务器的所有约束。

图6示出了根据实施例的示例性后端微服务分布600。在实施例中，使用如图6中所示的基于微服务的架构来设计和部署边缘云计算平台的后端系统。参考图6，每个元件由链接到地理分布式数据存储614的微服务604、606、608、610和612的地理部署集群的组602组成。在实施例中，为了确保相同或不同集群中的一个或多个微服务具有相同的视图，发现服务（例如406）、注册服务（例如418）、服务器令牌服务（例如416）和身份服务（例如410）的数据存储（例如612）需要以一致的方式同步。

在实施例中，对于信令服务，SEP（例如412）和BEP（例如414），每个微服务集群是地理独立的。信令服务（例如408）用于提供API来启动SEP（例如412）和BEP（例如414）组件。信令服务408保持对信令服务408的集群中的现有BEP 414和SEP 412的跟踪，并提供适当地负载平衡BEP和SEP所需的信息。为了基于BEP和SEP所需的位置提供最优时延，信令服务408是独立地理分布的。在实施例中，微服务的地理部署集群可以对应于边缘云计算设备的相应集群。换言之，对于最佳情况场景，集群中的边缘云计算设备中托管的微服务可以形成对集群中的边缘节点可用的微服务集群。在实施例中，微服务的地理部署集群可以对应于边缘云计算设备的多个集群。换言之，对于下一个最佳场景，不同集群（例如，2个集群）中的边缘云计算设备中托管的微服务可以形成对边缘节点可用的微服务集群，（2个）集群。

图7示出了根据实施例的示例性边缘云架构700。如较早前所述，去中心化云的价值来自从中央云（例如306）一直到边缘节点的整个范围内的服务分布。图7示出了后端服务模块702，该后端服务模块702被配置为提供包括发现服务704、信令服务706、身份服务712、服务器令牌服务714和注册服务716的一个或多个后端服务。信令服务706被配置为提供信令端点（SEP）708和承载端点（BEP）710。一个或多个后端服务被托管在云网络服务718上。公开的云架构允许后端服务模块702和云中的一个或多个节点之间的协作，以形成一个或多个集群。

例如，图7示出了3个集群：网络集群1 （726）、网络集群2 （732）和邻近集群3（736）。网络集群1（726）包括3个节点：作为超级节点的节点1（720）、节点2（722）和作为网络代理节点的节点3（724）。网络群集2（732）包括2个节点：作为超级节点和网络代理节点728的节点5和作为高速缓存代理节点730的节点6。邻近集群3（736）包括2个节点：作为高速缓存代理节点730的节点6和节点4（734）。如较早前所述，这些节点中的每一个包括边缘节点激活模块（例如，426、508）、一个或多个微服务（例如，518、520）以及一个或多个第三方应用程序（例如，422、524、526）。上面提及的集群是基于如较早前所述的一个或多个范围形成的。例如，网络集群1和2（722和728）是基于作为范围的网络形成的，并且邻近群集3是基于作为范围的邻近度而形成的。此外，如图7中所示，给定节点可以是2个集群的部分，例如，作为高速缓存代理节点726的节点6是网络集群2（728）和邻近集群3（732）的一部分。基于较早前解释的考虑因素，各种角色被指派给各种节点。

信令（SEP）和承载（BEP）端点的机制可以经由图8中所描绘的示例进行最佳说明。图8示出了对属于同一用户ID的两个边缘云计算设备进行发现、连接和通信的系统800的示例性实施例。类似于图7，图8描绘了被配置为提供一个或多个后端服务的后端服务模块802，所述一个或多个后端服务包括云网络服务818上托管的发现服务804、信令服务806、身份服务812、服务器令牌服务814、注册服务816。信令服务806被配置为动态部署诸如信令端点（SEP）808和承载端点（BEP）810之类的资源。

图8还示出了2个集群：网络集群1（826）和网络集群2（832）。网络集群1（826）包括3个节点：作为超级节点的节点1（820）、节点2（822）和作为网络代理节点的节点3（824）。网络群集2（832）包括2个节点：作为超级节点和网络代理节点828的节点5和作为高速缓存代理节点830的节点6。

出于正在进行的描述的目的，假设两个节点（网络集群1中示出为822的节点2和网络集群2中示出为830的节点6）属于同一用户（账户），并且已经向其相应的链路本地网络集群注册。应当注意的是，这两个节点尽管属于相同的用户帐户，但却是两个不同集群的部分。公开的边缘架构提供了SEP 808作为节点6（830）的可到达端点，它可以使用该可到达端点来与节点2（822）通信，就好像它是可直接访问的一样。使用SEP 808以集群间的方式执行这两个节点之间的通信。在建立信令之后，为两个节点822和830之间的大部分交换提供BEP810。分离信令和承载信道的灵活性允许创建不限于基于HTTP的服务交付的“服务特定”的BEP。

如较早前所述，节点间的发现、连接和通信过程包括向超级模块（例如820）发送用于属于某一范围（例如网络）的节点的发现请求（由新节点）的第一步骤。该过程进一步包括从超级节点获得与适当的信令信息一起的节点列表的步骤。该过程进一步包括经由SEP向（不同集群中的）远程节点发送请求（例如806）。该过程还包括让远程节点请求BEP（例如810）以提供服务。该过程以连接和通信的步骤结束，以通过所提供的BEP来消费服务。

如较早前所述，边缘节点激活模块426的主要优势之一是使用微服务概念和架构在典型客户端设备上开发前端应用的能力。转向微服务是由三个主要趋势触发的。首先，微服务实现并且暴露RESTful API（基于HTTP REST）。一组易于使用的API可以隐藏内部复杂度，并促进系统内微服务之间的通信。其次，可能的是通过使用由管道基础设施（例如Jenkins）控制的部署脚本（例如Ansible）自动部署微服务，来构建由潜在的大量系统元件组成的复杂系统。此外，通过提供决定在哪里发生部署的能力，自动化部署可以帮助构建灵活的系统。第三，通过简单的API请求IT资源（诸如CPU、存储和网络）并且以接近实时的方式取得这些资源的能力使大型且可扩展系统的创建更可行。

然而，过渡到微服务和边缘云可能需要开发团队更紧密地工作，因为它将不同的知识和专业技术融合在一起。例如，它可能需要后端开发者的技能。为了支持数十亿的小型客户端（例如IoT），在中央云上存在巨大的负担。一方面，太多的资源可能处于闲置状态，等待来自边缘上客户端的信号。另一方面，有时满足应用的性能需求可能是不可行的。例如，在美国部署后端系统来支持欧洲的客户端可能不满足许多应用的时延约束。因此，后端开发者需要更好地利用客户端资源来帮助支持这些新需求。他们可能被迫卸载许多更接近应用的功能，即使这需要在运行应用的“客户端”设备中部署部分后端系统。

过渡实现所需的又一个专业技术是IT/DevOps的专业技术。长期以来，IT团队一直负责确定和管理部署解决方案的基础设施。他们必须考虑许多约束和参数，诸如部署和运营成本、可扩展性和弹性。对于大多数应用，云基础设施的范围是单个数据中心，并且主要任务是解决计算和网络资源约束。为了支持在边缘的设备和数据的爆炸式增长，范围应当扩展到在正确的时间和正确的位置部署IT资源（通常超出数据中心的范围）。需要考虑诸如邻近度、帐户和链路本地存在之类的新的范围，以确保高效的部署和操作。

过渡实现所需的又一专业技术是前端开发者的专业技术：用于执行简单任务的前端应用，所述简单任务诸如是向后端输入和发送信息和/或呈现来自后端的信息。大多数复杂的功能通常都被移交给后端服务器。然而，给定在边缘生成的数据的爆炸式增长，许多新功能必须在“客户端设备”上得到支持，诸如高速缓存、增强现实（AR）、图像识别、授权和认证。因此，前端应用变得更大并且更复杂（例如，iOS^®上的Facebook^®应用程序在不到2年的时间里大小增加了两倍，超过300兆字节）。因此，存在从单片前端应用程序设计过渡到微服务架构并且将前端应用程序子系统分解成微服务的机会。然后，该应用程序可以无缝地调用设备上本地的微服务连同后端上运行（托管在中央云上）的微服务。

基于微服务的系统的许多结果之一是在多租户和单租户之间的选择。公共云的主要益处是多租户，其中多个应用可以共享公共云资源和部署在其上的微服务。然而，出于诸如安全性或数据隐私之类的多种原因，某些应用可能必须部署需要保持为单租户的微服务。因此，可以选择微服务是多租户还是单租户的混合方法可能是更好的方法。

又一个重要方面是微服务是单用户还是多用户。第一眼看，多用户微服务可能似乎是更合期望的。然而，情况可能并不总是如此。例如，如果微服务总是服务于一个“客户端设备”或一对“客户端设备”内的单个用户，其中仅有一个充当客户端并且另一个充当服务器，则多用户平台可能是低效的。因此，可以选择微服务是多用户还是单用户的混合方法可能是更好的方法。

随着系统复杂度增加，混合方法在这两个方面的优势变得至关重要。在实施例中，边缘节点激活模块（例如426）可以从头开始开发，以提供实现混合方法的灵活性和容易性，从而使后端、前端和DevOps有益处。益处可以包括开发的简单性、灵活性、重复部署能力和可扩展性，如将关于图9和图10描述的。

图9示出了根据实施例在边车模式中使用无服务器微服务实现的示例性边缘云架构900。如所示的，架构900包括运行第三方应用或客户端应用904的客户端设备902。客户端设备902包括边缘节点激活模块922和一个或多个本地托管的微服务926、928和930。边缘节点激活模块922包括API网关924，API网关924与托管在中央912中或云计算设备914中的API网关908通信。在实施例中，边缘节点激活模块922从客户端应用904接收请求，并确定服务于该请求所需的一个或多个微服务的类型。如果该请求可以由本地托管的微服务（例如926、928、930）来服务，则API网关924将该请求发送给被实例化或启动的适当的微服务。本地托管的微服务可以从远程设备加载，或者可以基于来自客户端应用904的需求被动态实例化（在运行时）。启动的微服务（例如926）服务于该请求，并通过API网关924将响应发送回到客户端应用904。

然而，如果服务于请求所需的微服务的确定类型具有全局性质或对应于全局托管的微服务，则API网关924向API网关908发送http/https请求906。API网关908启动适当的微服务（例如916、918、920），该适当的微服务被全局或集中托管在中央云912上以服务于http/https请求906。API网关908向API网关924发送http/https响应910。与图1相反，客户端应用904可以利用由边缘节点激活模块922暴露的本地托管的微服务以及还有由API网关908暴露的全局托管的微服务。

在实施例中，在合理的情况下，后端开发者可以容易地从多用户微服务过渡到驻留于距应用最近的资源上、即驻留于运行前端应用的同一资源上的单用户微服务。在实施例中，资源随着应用的存在而存在，并且仅当应用通过边缘节点激活模块提供的API网关发出请求时，微服务才存在。这降低了开发多用户微服务的复杂度，并且将无服务器微服务模型带到了中央云之外的所有种类的边缘资源。只要无服务器微服务（例如926）暴露它们的RESTful API，微服务就可以跨域使用。

另一方面，IT/DevOps将在中央云内管理较少数量的微服务，这有助于降低复杂度和运营成本。当微服务更靠近所需的应用时（例如在客户端设备902上），实现了具有最小或甚至没有托管成本的水平可扩展性。复杂度也降低了，因为不存在对于不同的基础设施知识的需要，因为边缘处的资源看起来与中央云上的资源相同（尽管具有不同的约束）。

此外，前端应用开发者可以遵循后端开发方法，并将前端应用的复杂度分解为无服务器微服务和如图9中图示的边车模式。利用边缘节点激活模块（例如，426、508、922）开发应用为开发者提供了如下灵活性：决定应用在哪里是活动的，以及决定什么微服务需要在节点群集内的哪里运行：在中央云上、在本地设备上或群集内的另一设备上。因此，开发者具有更多的选项将客户端应用（通常编写为单片块）分解成微服务，并享受后端开发中常见的微服务架构的所有益处：可扩展性、灵活性、技术选择、对其他模块或功能的独立影响、部署容易等。

图10示出了根据实施例的用于利用本地和全局托管的微服务的应用的示例性无服务器微服务1000。与图1和图2中所示的中央云方法相比，客户端应用不仅可以向中央云内的API网关发出请求，而且还可以本地向同一设备发出请求。换言之，应用可以利用本地托管的微服务来实现本地功能，并利用中央云上的全局托管的微服务来实现不能在本地托管的那些功能。该概念可以扩展到多个设备和边缘节点，如图10中所示的客户端到客户端通信的示例。

如所示的，架构1000包括分别运行第三方应用或客户端应用1004和1040的两个客户端设备1002和1038。客户端设备1002和1038分别包括边缘节点激活模块1022和1042。每个客户端设备本地托管一个或多个微服务。例如，客户端设备1002托管微服务1026、1028和1030。同样，客户端设备1038托管微服务1046、1048和1050。边缘节点激活模块1022包括API网关1024，该API网关1024被配置为与中央1012内托管的API网关1008通信。在实施例中，边缘节点激活模块1022从客户端应用1004接收请求1020，并确定服务于该请求所需的一个或多个微服务的类型。如果确定的类型对应于一个或多个本地托管的微服务（例如1026、1028、1030），则API网关1024将服务请求1032发送给被实例化或启动的适当微服务。在实施例中，本地托管的微服务可以从远程设备加载，或者可以基于来自客户端应用1004的需求来实例化。微服务（例如1026）服务于该请求，并通过API网关1024将响应发送回到客户端应用1004。

然而，如果服务于该请求所需的微服务的确定类型具有全局性质或对应于全局托管的微服务，则API网关1024向API网关1008发送http/https请求1006。API网关1008启动适当的微服务（例如1014、1016、1018），该适当的微服务被全局或集中托管在中央云1012上以服务于该请求。API网关1008向API网关1024发送http/https响应1010。在实施例中，边缘节点激活模块1022确定服务于请求1020所需的一个或多个微服务的类型对应于另一客户端设备（例如1038）上托管的微服务。边缘节点激活模块1022使能与API网关1042的直接通信。在又一实施例中，边缘节点激活模块1022使能1030和1046之间的直接微服务到微服务通信。例如，微服务1030向微服务1046发送数据请求1034。微服务1046服务于该数据请求，并向微服务1030发送响应1036。与图2中所示的中央云方法相反，其中边缘设备仅充当客户端，如上所述，客户端到客户端的通信可以直接发生在边缘设备/客户端设备之间（或者通过中央云内的服务器）。这给予开发者优化部署的所有方面的机会，部署的所有方面诸如是云托管成本、时延、带宽使用、数据隐私以及微服务架构为典型后端功能带来的所有其他益处。

因此，边缘节点激活模块的公开实施例通过使用相同的模型和API将按需IT资源的概念无缝地扩展到边缘，使开发者有益处。它通过添加新的集群范围进一步扩展了集群的概念：用户帐户、邻近度和网络。它进一步扩展了服务网格的概念，通过在边缘提供边车模式来处理API网关、安全性和路由，以便与其他微服务进行通信，无论是在本地边缘还是在中央云内。

在实施例中，开发具有边缘节点激活模块（例如，426、508、922、1022）的应用使得开发者具有更多选项、简单性和灵活性。解决方案开发者可以基于解决方案业务逻辑来做出数据驻留在哪里的决定。因此，本文公开的是一种实用的方法，用于构建边缘云，该边缘云通过利用当前未使用或严重未充分利用的边缘资源，具有更多数量级的处理能力、存储和存储器。这可以创建数量级更大、更便宜、更快的云结构，并可以为所有消费者和企业应用提供更好的数据隐私。

图11示出了提供云计算基础设施或平台的方法1100的示例性实施例。参考图1-10，边缘云计算基础设施在通信网络（例如，边缘云计算网络300）中实现，该通信网络包括与服务器计算设备（例如，312）通信的一个或多个边缘云计算设备（例如，302、304）。该方法包括如在步骤1102中由第一边缘云计算设备（例如404、500）、边缘节点激活模块（例如422、508）执行。在实施例中，边缘节点激活模块是由第一边缘云计算设备可下载的软件级别的应用。该方法进一步包括如在步骤1104中由第一边缘云计算设备动态发现独立于与其他边缘云计算设备相关联的操作系统和网络的其他边缘云计算设备（例如310）。该方法进一步包括如在步骤1106中，由第一边缘云计算设备暴露所发现的其他边缘云计算设备（例如310）的资源可用性、能力和功能。该方法进一步包括如在步骤1108中由第一边缘云计算设备形成和组织所发现的其他边缘云计算设备的一个或多个集群（例如722、732）。该方法还包括在步骤1110中由第一边缘云计算设备在一个或多个集群内以及跨一个或多个集群进行通信。

在实施例中，该方法进一步包括，在执行边缘节点激活模块（例如，422）之后，由第一边缘云计算设备搜索超级边缘云计算设备（或超级节点）。如较早前所述，超级边缘云计算设备被配置为管理全局发现。该方法进一步包括在搜索期间没有找到超级边缘云计算设备的情况下，由第一边缘云计算设备指定其自身为超级边缘云计算设备。在另一个实施例中，该方法包括由第一边缘云计算设备传送其存在的全局发现，以及由第一边缘云计算设备接收在第一边缘云计算设备的范围内的一个或多个边缘云计算设备的列表。

在又一实施例中，该方法进一步包括由第一边缘云计算设备从随后进入一个或多个集群中的一个或多个边缘云计算设备接收注册请求。该方法还包括由第一边缘云计算设备向注册的一个或多个边缘云计算设备传输在第一边缘云计算设备的范围内的一个或多个其他边缘云计算设备的列表。

图12示出了提供云计算基础设施或平台的方法1200的示例性实施例。参考图1-11，边缘云计算基础设施在通信网络（例如，边缘云计算网络300）中实现，该通信网络包括与服务器计算设备（例如，312）通信的一个或多个边缘云计算设备（例如，302、304、500、902、1002）。该方法由第一边缘云计算设备（例如902、1002）执行，并且包括如在步骤1202中确定对应于来自在第一边缘云计算设备中运行的客户端应用（例如904、1004）的请求的微服务类型。该方法进一步包括如在步骤1204中确定微服务的类型是否是全局的。换言之，来自客户端应用的请求仅可以由全局或集中托管的微服务（例如916、918、920、1014、1016）来服务。关于在步骤1204的肯定确定，如在步骤1206中，第一边缘云计算设备向中央云（912，1012）中的API网关（例如908，1008）发送http/https请求（例如906，1006）。该方法如在步骤1208中进一步包括启动全局托管的微服务（例如916、1014）并向第一边缘云计算设备返回响应（例如http/https响应910、1010）。

关于在步骤1204的否定确定，该方法如在步骤1210中进一步包括与来自客户端应用的请求相对应的微服务类型是否为本地的确定。如果是，则该方法如在步骤1212中进一步包括通过启动本地托管的微服务（例如1026、926）来处理请求。如果不是，则该方法如在步骤1214中包括将请求直接发送到另一（第二）边缘云计算设备（例如1038）中托管的微服务。该方法进一步包括启动在另一（第二）边缘云计算设备（1038）中托管的微服务（例如1046）并返回对该请求的响应。

如本文所述，边缘节点激活模块使得边缘云计算设备或客户端设备能够在本地动态创建或实例化微服务。边缘节点激活模块还发现给定集群中或跨集群存在的其他边缘节点，并暴露在发现的边缘节点中托管的一个或多个微服务。这样，任何边缘节点都可以充当“服务器”或“客户端”，并且来自客户端应用的给定请求可以根据服务请求的需求（类型）被本地或全局服务或者由其他边缘节点服务。

公开了服务器计算设备的实施例。服务器计算设备被配置用于在通信网络中操作，该通信网络包括与服务器计算设备通信的一个或多个边缘云计算设备。在实施例中，服务器计算设备包括后端服务模块，该后端服务模块被配置为提供一个或多个后端服务来支持一个或多个边缘云计算设备。一个或多个后端服务包括发现服务，该发现服务被配置为提供知识以形成一个或多个边缘云计算设备的一个或多个集群，其中一个或多个集群中的每一个包括至少一个超级边缘云计算设备。后端服务进一步包括信令服务，该信令服务被配置为在接收到来自发现服务的请求时为一个或多个集群动态部署信令端点（SEP）和承载端点（BEP）。后端服务进一步包括服务器令牌服务，该服务器令牌服务被配置为向一个或多个集群中的第一边缘云计算设备中的微服务递送令牌，向一个或多个集群中的第二边缘云计算设备中的另一微服务发出请求。

在实施例中，一个或多个后端服务进一步包括身份服务，该身份服务被配置为创建和维护一个或多个边缘云计算设备的认证配置文件。在实施例中，一个或多个后端服务进一步包括注册服务，该注册服务被配置为维护一个或多个集群中提供的所有微服务以及相关联的集群信息的列表。在实施例中，注册服务进一步被配置为维护一个或多个集群的集群知识，以允许一个或多个集群出于配置目的而被自我管理。在实施例中，注册服务进一步被配置为提供将由一个或多个后端服务使用的集群的地理定位列表和相关联的配置细节。

在实施例中，形成一个或多个集群的知识包括一个或多个集群的配置文件、与形成一个或多个集群的一个或多个边缘云计算设备相关联的计算资源的细节、形成一个或多个集群的一个或多个边缘云计算设备的状态和/或位置、形成一个或多个集群的一个或多个边缘云计算设备上可用的一个或多个微服务、到达形成一个或多个集群的每个边缘云计算设备的端到端网络拓扑以及一个或多个集群的可达性。在实施例中，发现服务进一步被配置为提供与通信网络中可用的资源相关联的信息，以实时地在通信网络内的任何可用的边缘云计算设备上动态部署一个或多个微服务。在实施例中，身份服务被配置为生成和维护用于以下各项的一个或多个的令牌：每个边缘云计算设备中的边缘节点激活模块、使用边缘节点激活模块的微服务、使用边缘节点激活模块的应用开发者以及边缘节点激活模块支持的应用的终端用户。

公开了边缘云计算设备的实施例。在实施例中，边缘云计算设备包括边缘节点激活模块，该边缘节点激活模块被配置为基于第一组参数发现一个或多个其他边缘云计算设备，以在它们之间建立连接。边缘节点激活模块进一步被配置为提供微服务运行时环境，以执行与在一个或多个边缘云计算设备之间建立的连接相关联的一个或多个微服务。在实施例中，边缘节点激活模块被配置为发现一个或多个边缘云计算设备的存在，而不管与一个或多个边缘云计算设备相关联的操作系统和/或网络类型。边缘节点激活模块进一步被配置为发现与一个或多个边缘云计算设备相关联的能力和行为，并发现由一个或多个边缘云计算设备支持的一个或多个微服务。在实施例中，第一组参数包括与一个或多个边缘云计算设备中的每一个相关联的用户账户、与一个或多个边缘云计算设备相关联的网络以及一个或多个边缘云计算设备的邻近度。

所述边缘节点激活模块进一步被配置为与一个或多个边缘云计算设备动态形成一个或多个集群，并在微服务级别上直接或通过跨一个或多个集群上的其他边缘云计算设备与一个或多个边缘云计算设备通信。在实施例中，边缘节点激活模块进一步被配置为如果发现的一个或多个边缘云计算设备选择共享数据、服务和/或资源，则与发现的一个或多个边缘云计算设备连接。边缘节点激活模块进一步被配置为通过公共嵌入式网络服务器暴露一个或多个微服务服务。在实施例中，通过API网关从集群中的一个或多个边缘云计算设备可访问每个微服务的一个或多个API端点。边缘节点激活模块进一步被配置为至少部分基于与一个或多个边缘云计算设备相关联的相应计算环境来提供灵活的容器能力。相应的计算环境运行容器守护进程来下载、部署和操作一个或多个微服务。

在实施例中，计算环境运行容器守护进程，以管理一个或多个边缘云计算设备的自组织集群。边缘节点激活模块进一步包括嵌入其中的网络服务器。网络服务器被配置为基于与边缘云计算设备相关联的操作系统使用特定语言来提供容器管理API。边缘节点激活模块进一步包括一个或多个软件库和对应的API。

公开了服务器计算设备的实施例。实施例涉及包括与服务器计算设备通信的一个或多个边缘云计算设备的通信网络。在实施例中，服务器计算设备包括后端服务模块，该后端服务模块被配置为提供一个或多个服务来支持一个或多个边缘云计算设备。一个或多个后端服务包括发现服务，该发现服务被配置为提供知识以形成一个或多个边缘云计算设备的一个或多个集群。一个或多个集群中的每一个包括至少一个超级边缘云计算设备（或超级节点）。一个或多个后端服务进一步包括信令服务，该信令服务被配置为在接收到来自发现服务的请求时为一个或多个集群动态部署信令端点（SEP）和承载端点（BEP）。一个或多个后端服务进一步包括被配置为创建和维护一个或多个边缘云计算设备的认证配置文件的身份服务。

一旦形成第一集群，发现服务就被配置为允许不是第一集群的部分的新边缘云计算设备向对应于第一集群的超级边缘云计算设备注册。在实施例中，发现服务进一步被配置为允许每个超级边缘云计算设备注册它自己。在实施例中，形成一个或多个集群的知识包括一个或多个集群的配置文件、与形成一个或多个集群的一个或多个边缘云计算设备相关联的计算资源的细节、形成一个或多个集群的一个或多个边缘云计算设备的状态和位置、形成一个或多个集群的一个或多个边缘云计算设备上可用的一个或多个服务、到达形成一个或多个集群的每个边缘云计算设备的端到端网络拓扑以及一个或多个集群的可达性。

在另一实施例中，发现服务进一步被配置为提供与通信网络中可用的资源相关联的信息，以实时地在通信网络内的任何可用的边缘云计算设备上动态部署一个或多个服务。在又一实施例中，信令服务被配置为基于对于一个或多个集群内的计算资源的需求来动态部署信令端点（SEP）和承载端点（BEP）。

在仍另外的实施例中，信令端点（SEP）用于信令通信，并且承载端点（BEP）用于数据通信。信令端点（SEP）和承载端点（BEP）的动态部署增加了一个或多个集群中的一个或多个边缘云计算设备的信令带宽和数据带宽。信令服务进一步被配置为基于一个或多个参数来动态部署信令端点（SEP）和承载端点（BEP）。一个或多个参数包括一个或多个服务的上线时间、一个或多个集群中的并发连接数以及与一个或多个集群中的一个或多个边缘云计算设备相关联的一个或多个通信协议。

在实施例中，信令服务进一步被配置为在一个或多个集群的最近邻近度内的可用边缘云计算设备上动态部署信令端点（SEP）和承载端点（BEP）。身份服务被配置为生成和维护用于以下各项的一个或多个的令牌：每个边缘云计算设备中的边缘节点激活模块、使用边缘节点激活模块的微服务、使用边缘节点激活模块的应用开发者以及由边缘节点激活模块支持的应用的终端用户。在又一实施例中，身份服务被配置为验证令牌持有者的凭证和合法性，并授权令牌持有者访问由后端服务模块提供的一个或多个服务。

公开了提供边缘云计算基础设施（或平台）的方法的实施例。该方法在通信网络中实现，该通信网络包括与服务器计算设备或中央云通信的一个或多个边缘云计算设备。该方法包括由第一边缘云计算设备执行边缘节点激活模块。该方法进一步包括由第一边缘云计算设备动态发现独立于与其他边缘云计算设备相关联的操作系统和网络的其他边缘云计算设备。该方法进一步包括由第一边缘云计算设备暴露所发现的其他边缘云计算设备的资源可用性、能力和功能。该方法进一步包括由第一边缘云计算设备形成和组织所发现的其他边缘云计算设备的一个或多个集群。该方法还包括由第一边缘云计算设备在一个或多个集群内以及跨一个或多个集群进行通信。

在实施例中，该方法包括，在执行边缘节点激活模块之后，由第一边缘云计算设备搜索超级边缘云计算设备（在正在进行的描述中也称为“超级节点”）。超级边缘云计算设备被配置为管理节点或边缘云计算设备的全局发现。

在搜索期间未找到超级边缘云计算设备的情况下，该方法进一步包括由第一边缘云计算设备将其自身指定为超级边缘云计算设备。该方法进一步包括由第一边缘云计算设备传送其存在的全局发现，以及由第一边缘云计算设备接收在第一边缘云计算设备的范围内的一个或多个边缘云计算设备的列表。

该方法进一步包括由第一边缘云计算设备接收来自随后进入一个或多个集群中的一个或多个边缘云计算设备的注册请求，并由第一边缘云计算设备向已注册的一个或多个边缘云计算设备传输第一边缘云计算设备范围内和/或已注册的一个或多个边缘云计算设备范围内的一个或多个其他边缘云计算设备的列表。

如本文权利要求书和说明书中使用的术语“包括”、“包含”和“具有”应被视为指示可以包括其他未指定元件的开放组。术语“一”、“一个”以及单词的单数形式应被理解为包括相同单词的复数形式，使得所述术语意味着提供了一个或多个某物。术语“一个”或“单个”可以用于指示某事物中的一个且仅一个是意图的。类似地，当意图特定数量的事物时，可以使用诸如“二”的其他特定的整数值。术语“优选地”、“优选的”、“优选”、“可选地”、“可以”以及类似的术语用于指示所涉及的项目、条件或步骤是本发明的可选（非必需）特征。

已参照各种特定和优选的实施例和技术对本发明进行了描述。然而，应当理解，可以进行许多变化和修改，而仍然在本发明的精神和范围内。对于本领域普通技术人员而言将清楚的是，除了在本文具体描述的方法、设备、设备元件、材料、程序和技术之外的方法、设备、设备元件、材料、程序和技术可以应用于如在本文广泛公开的本发明的实践，而无需诉诸于过度的实验。本文描述的方法、设备、设备元件、材料、程序和技术的所有本领域已知的功能等同物都旨在被本发明所涵盖。每当公开一个范围时，所有的子范围和个体值都旨在被涵盖。本发明不受公开的实施例限制，所述公开的实施例包括附图中所示的或说明书中举例说明的任何实施例，所述实施例是作为示例而非限制给出的。

虽然已关于有限数量的实施例对本发明进行了描述，但受益于本公开内容的本领域技术人员将领会，可以设计不脱离如本文公开的本发明的范围的其他实施例。因此，本发明的范围应当仅由所附权利要求书来限定。贯穿本申请的所有参考文献，例如包括授权或授予的专利或等同物的专利文件、专利申请公开和非专利文献文件或其它来源材料，特此在本文通过引用以其整体并入——就像通过引用单独并入一样——达到每个参考文献至少部分与本申请中的公开内容一致的程度（例如，部分不一致的参考文献除了参考文献的部分不一致部分之外都通过引用并入）。

Claims (37)

1.一种边缘云计算设备，包括：

边缘节点激活模块，被配置为：

从在边缘云计算设备中运行的应用接收请求；

确定服务于接收的请求所需的一个或多个微服务的类型；以及

当确定的类型对应于在边缘云计算设备中本地托管的一个或多个微服务时，在边缘云计算设备中本地处理所述请求。

2.根据权利要求1所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为提供微服务运行时环境，以执行本地托管的一个或多个微服务。

3.根据权利要求1所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为提供本地托管的API网关，以向本地托管的一个或多个微服务发送所述请求。

4.根据权利要求1所述的边缘云计算设备，其中，所述一个或多个微服务被配置为服务于所述请求并且向所述应用发送回响应。

5.根据权利要求1所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为当服务于接收的请求所需的一个或多个微服务的确定类型对应于中央云计算设备中全局托管的一个或多个微服务时，向中央云计算设备中托管的API网关发送对应于来自所述应用的接收的请求的http/https请求。

6.根据权利要求5所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为从中央云计算设备中托管的API网关接收针对所述http/https请求的http/https响应，并且其中所述http/https请求由中央云计算设备中全局托管的一个或多个微服务服务。

7.根据权利要求5所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为提供本地托管的API网关，以将所述http/https请求发送到在中央云计算设备中托管的API网关。

8.根据权利要求1所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为当服务于接收的请求所需的一个或多个微服务的确定类型对应于在另一边缘云计算设备中托管的一个或多个微服务时，将所述请求直接发送到在所述另一边缘云计算设备中托管的一个或多个微服务。

9.根据权利要求8所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为实现边车模式以形成对应于本地托管在所述边缘云计算设备中的一个或多个微服务和托管在所述另一边缘云计算设备中的一个或多个微服务的服务网格。

10. 根据权利要求1所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为：

基于第一组参数发现一个或多个其他边缘云计算设备，以在它们之间建立连接；以及

提供微服务运行时环境来执行与在一个或多个边缘云计算设备之间建立的连接相关联的本地托管的一个或多个微服务。

11.根据权利要求10所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为发现由所述一个或多个边缘云计算设备支持的一个或多个微服务。

12.根据权利要求10所述的边缘云计算设备，其中，所述第一组参数包括：与所述一个或多个边缘云计算设备中的每一个相关联的用户账户、与所述一个或多个边缘云计算设备相关联的网络以及所述一个或多个边缘云计算设备的邻近度。

13. 根据权利要求10所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为：

与所述一个或多个边缘云计算设备动态形成一个或多个集群；以及

在微服务级别直接或通过跨所述一个或多个集群的其他边缘云计算设备与所述一个或多个边缘云计算设备通信。

14.根据权利要求1所述的边缘云计算设备，其中，所述边缘节点激活模块进一步被配置为通过公共嵌入式网络服务器向一个或多个边缘云计算设备暴露本地托管的一个或多个微服务服务。

15.根据权利要求1所述的边缘云计算设备，其中，所述边缘节点激活模块包括嵌入其中的网络服务器，其中所述网络服务器被配置为基于与所述边缘云计算设备相关联的操作系统使用特定语言来提供容器管理API。

16.一种被配置用于在通信网络中操作的服务器计算设备，所述通信网络包括与所述服务器计算设备通信的一个或多个边缘云计算设备，所述服务器计算设备包括：

后端服务模块，被配置用于提供一个或多个后端服务以支持所述一个或多个边缘云计算设备，其中所述一个或多个后端服务包括：

发现服务，被配置用于提供知识以形成所述一个或多个边缘云计算设备的一个或多个集群，其中所述一个或多个集群中的每一个包括至少一个超级边缘云计算设备；

信令服务，被配置为在接收到来自所述发现服务的请求时，为所述一个或多个集群动态部署信令端点（SEP）和承载端点（BEP）；以及

服务器令牌服务，被配置为向所述一个或多个集群中的第一边缘云计算设备中的微服务递送令牌，向所述一个或多个集群中的第二边缘云计算设备中的另一微服务发出请求。

17.根据权利要求16所述的服务器计算设备，其中，所述一个或多个后端服务进一步包括身份服务，所述身份服务被配置为创建和维护所述一个或多个边缘云计算设备的认证配置文件。

18.根据权利要求16所述的服务器计算设备，其中，所述一个或多个后端服务进一步包括注册服务，所述注册服务被配置为维护在所述一个或多个集群中提供的所有微服务以及相关联的集群信息的列表。

19.根据权利要求18所述的服务器计算设备，其中，所述注册服务进一步被配置为维护所述一个或多个集群的集群知识，以允许所述一个或多个集群出于配置目的而被自我管理。

20.根据权利要求18所述的服务器计算设备，其中，所述注册服务进一步被配置为提供将由所述一个或多个后端服务使用的集群和相关联配置细节的地理定位列表。

21.根据权利要求16所述的服务器计算设备，其中，形成一个或多个集群的知识包括：

所述一个或多个集群的配置文件、与形成所述一个或多个集群的一个或多个边缘云计算设备相关联的计算资源的细节、形成所述一个或多个集群的一个或多个边缘云计算设备的状态和/或位置、形成所述一个或多个集群的一个或多个边缘云计算设备上可用的一个或多个微服务、到达形成所述一个或多个集群的每个边缘云计算设备的端到端网络拓扑以及所述一个或多个集群的可达性。

22.根据权利要求16所述的服务器计算设备，其中，所述发现服务进一步被配置为提供与所述通信网络中可用的资源相关联的信息，以实时地在所述通信网络内的任何可用的边缘云计算设备上动态部署所述一个或多个微服务。

23.根据权利要求17所述的服务器计算设备，其中，所述身份服务被配置为生成和维护用于以下各项中的一个或多个的令牌：每个边缘云计算设备中的边缘节点激活模块、使用所述边缘节点激活模块的微服务、使用所述边缘节点激活模块的应用开发者以及由所述边缘节点激活模块支持的应用的终端用户。

24. 一种在通信网络中提供边缘云计算基础设施的方法，所述通信网络包括与至少一个服务器计算设备通信的一个或多个边缘云计算设备，所述方法包括：

由第一边缘云计算设备确定对应于来自在第一边缘云计算设备中运行的应用的请求的一个或多个微服务的类型；以及

当确定的类型对应于在第一边缘云计算设备中本地托管的一个或多个微服务时，由第一边缘云计算设备在第一边缘云计算设备中本地处理所述请求。

25.根据权利要求24所述的方法，进一步包括：

由第一边缘云计算设备提供微服务运行时环境，以执行本地托管的一个或多个微服务。

26.根据权利要求24所述的方法，进一步包括：

由第一边缘云计算设备提供本地托管的API网关，以将所述请求发送到所述本地托管的一个或多个微服务。

27.根据权利要求24所述的方法，进一步包括：

当一个或多个微服务的确定类型对应于中央云计算设备中全局托管的一个或多个微服务时，由第一边缘云计算设备向中央云计算设备中托管的API网关发送对应于来自所述应用的请求的http/https请求。

28.根据权利要求27所述的方法，进一步包括：

由第一边缘云计算设备从中央云计算设备中托管的API网关接收针对所述http/https请求的http/https响应，并且其中所述http/https请求由中央云计算设备中全局托管的一个或多个微服务服务。

29.根据权利要求27所述的方法，进一步包括：

由第一边缘云计算设备提供本地托管的API网关，以将所述http/https请求发送到在中央云计算设备中托管的API网关。

30.根据权利要求24所述的方法，进一步包括：

当来自所述应用的请求的确定类型对应于第二边缘云计算设备的数据请求时，由第一边缘云计算设备将来自本地托管的一个或多个微服务的数据请求直接发送到第二边缘云计算设备中托管的一个或多个微服务。

31.根据权利要求24所述的方法，进一步包括：

由第一边缘云计算设备提供边车模式，以形成服务网格来支持在第一边缘云计算设备中运行的应用。

32.根据权利要求24所述的方法，进一步包括：

由第一边缘云计算设备通过公共嵌入式网络服务器向一个或多个边缘云计算设备暴露本地托管的一个或多个微服务服务。

33.根据权利要求24所述的方法，进一步包括：

由第一边缘云计算设备使用基于与所述边缘云计算设备相关联的操作系统的特定语言来提供容器管理API。

34. 根据权利要求24所述的方法，进一步包括：

由第一边缘云计算设备发现一个或多个其他边缘云计算设备，以在它们之间建立连接；以及

由第一边缘云计算设备提供微服务运行时环境，以执行与在一个或多个边缘云计算设备之间建立的连接相关联的本地托管的一个或多个微服务。

35. 根据权利要求34所述的方法，进一步包括：

由第一边缘云计算设备发现在发现的一个或多个其他边缘云计算设备中托管的一个或多个微服务；以及

由第一边缘云计算设备在本地托管的一个或多个微服务和在所述一个或多个边缘云计算设备中发现的一个或多个微服务之间建立直接微服务级别连接。

36.根据权利要求24所述的方法，进一步包括：

由第一边缘云计算设备加载并执行服务于来自所述应用的请求所需的一个或多个微服务。

37.根据权利要求36所述的方法，其中，进一步包括：

一旦来自所述应用的请求已被服务，第一边缘云计算设备就停止所加载的一个或多个微服务。

Images