CN115941678A - 云边缘协同服务链部署方法及装置 - Google Patents
云边缘协同服务链部署方法及装置 Download PDFInfo
- Publication number
- CN115941678A CN115941678A CN202211192420.5A CN202211192420A CN115941678A CN 115941678 A CN115941678 A CN 115941678A CN 202211192420 A CN202211192420 A CN 202211192420A CN 115941678 A CN115941678 A CN 115941678A
- Authority
- CN
- China
- Prior art keywords
- service chain
- cloud
- edge
- deployment
- path
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请提供一种云边缘协同服务链部署方法及装置,方法包括:应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在云中心网络中的第一目标部署路径并在云中心网络中部署服务链请求;若服务链请求未部署在云中心网络中,且若基于边缘算法获知边缘系统当前满足服务链请求对应的资源需求,则判断边缘系统当前是否满足时延需求,若不满足,且若根据最优路径算法和时延需求生成该服务链请求在边缘系统中的第二目标部署路径,则基于该第二目标部署路径在边缘系统中部署服务链请求。本申请能够在高时延要求且资源受限的前提下实现在云端和边缘环境下的服务链的动态协同部署。
Description
技术领域
本申请涉及服务链部署技术领域,尤其涉及云边缘协同服务链部署方法及装置。
背景技术
根据用户的需求将一定数量的虚拟网络功能(VNF,Virtual Network Function)组合在一起即构成服务链(SFC,Service Function Chain),因其能够解决运营商提供网络服务成本高、部署困难的问题,因此非常适用于当前流量急剧增多的物联网(IoT,Internetof the Things)场景。物联网的很多场景往往对端到端时延有很高的要求。例如,自动驾驶对网络的时延需求为小于10ms,由此来保证汽车能够及时的进行操作。AR或VR设备等对网络的时延需求为小于20ms,由此来保证人的动作与画面的同步。因此需要通过优化服务链部署来为物联网设备的端到端时延提供一个严格的保障。
目前,若仅在云端部署服务链,虽然资源充足,但云端和边缘的链路时延高,无法保证实时性要求高的场景;若仅在边缘环境部署服务链,虽然能够免去云端和边缘的链路时延,但边缘环境的资源受限,无法保证服务链部署的可靠性。一类现有服务链部署方式可以采用假定虚拟网络功能时延固定不变的服务链部署算法,但该方式会对服务链的端到端时延的计算带来较大的误差;另一类现有服务链部署方式可以采用基于排队论的服务链部署算法,但由于基于排队论所计算出来的时延为数据包的平均时延,因此无法保证每一个数据包都能够在计算出来的时延中完成传输,并不适用于自动驾驶这类时延敏感的物联网场景;还有一类现有服务链部署方式可以采用云边缘环境下的服务链部署算法,但该类算法对于时延的考虑并不精确,产生的误差较大,不适用于物联网场景。也就是说,现有的服务链部署方式无法同时满足服务链部署资源要求和应用场景的高时延要求。
因此,如何在高时延要求且资源受限的前提下实现在云和边缘环境下的服务链部署是当前亟需解决的问题。
发明内容
鉴于此,本申请实施例提供了云边缘协同服务链部署方法及装置,以消除或改善现有技术中存在的一个或更多个缺陷。
本申请的一个方面提供了一种云边缘协同服务链部署方法,包括:
应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求;
若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
在本申请的一些实施例中,所述应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求,包括:
接收服务链请求,并获取该服务链请求对应的时延需求值;
基于网络演算方式确定该服务链请求部署在所述云中心网络的时延上限值;
判断所述云中心网络的时延上限值是否小于或等于所述时延需求值,若是,则将该服务链请求存储至一预设的云端服务链集合中;
针对所述云端服务链集合中的服务链请求,调用最优路径算法获取该服务链请求在所述云中心网络中的目标部署路径,将该目标部署路径确定为第一目标部署路径,并将基于该第一目标部署路径在所述云中心网络中部署所述服务链请求。
在本申请的一些实施例中,还包括:
若经判断获知所述云中心网络当前的时延上限值大于所述服务链请求的时延需求值,则将所述服务链请求存储至一预设的边缘服务链集合中。
在本申请的一些实施例中,所述若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求,包括:
获取所述服务链请求的服务链资源需求值以及属于所述服务链请求中的各个虚拟网络功能VNF的VNF资源需求值;
根据所述服务链资源需求值、VNF资源需求值和所述边缘系统中各个边缘节点当前的可用资源值,生成所述服务链请求在所述边缘系统中的初始部署方案;
判断所述服务链资源需求值是否小于或等于所述边缘系统当前的可用资源值,若是,则基于网络演算方式确定该服务链请求部署在所述边缘系统的第一时延上限值;
判断所述第一时延上限值是否小于或等于所述时延需求值,若否,则调取所述最优路径算法生成该服务链请求在所述边缘系统中的目标部署路径;
基于网络演算方式,应用所述部署路径重新确定所述服务链请求部署在所述边缘系统的第二时延上限值;
判断所述第二时延上限值是否小于或等于所述时延需求值,若是,则将所述服务链请求在所述边缘系统中的目标部署路径确认为第二目标部署路径,并基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
在本申请的一些实施例中,还包括:
若经判断获知所述第一时延上限值小于或等于所述时延需求值,则将所述初始部署方案作为第二目标部署路径,并基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
在本申请的一些实施例中,还包括:
若经判断获知所述服务链资源需求值大于所述边缘系统当前的可用资源值,或者,若经判断获知所述第二时延上限值仍然大于所述时延需求值则拒绝执行该服务链请求,则拒绝执行该服务链请求。
在本申请的一些实施例中,所述最优路径算法包括:
获取所述服务链请求在当前目标环境中的部署路径,其中,所述目标环境包括:所述云中心网络或所述边缘系统;
判断所述部署路径中的各个服务节点是否均满足所述服务链请求对应的资源需求,若是,则将该部署路径确定为最优路径;
若所述部署路径中的各个服务节点中存在不满足所述服务链请求对应的资源需求的服务节点,则在所述部署路径中将该不满足所述资源需求的服务节点删除,再将该部署路径确定为最优路径;
判断所述最优路径中的各个服务节点是否均满足预审的带宽限制,若是,则将该最优路径确定为目标部署路径。
本申请的另一个方面提供了一种云边缘协同服务链部署装置,包括:
云端部署模块,用于基于云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求;
边缘部署模块,用于若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
本申请的另一个方面提供了一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现所述的云边缘协同服务链部署方法。
本申请的另一个方面提供了一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现所述的云边缘协同服务链部署方法。
本申请提供的云边缘协同服务链部署方法,应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求;若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。通过将网络演算理论应用到云边缘协同的服务链部署中,如果满足服务链的时延需求,那么优先部署在云端以此来节约边缘的资源。而如果部署在云端的时延上限大于服务链的时延需求,那么将服务链部署在边缘节点上;能够保证所提供的确定时延的网络服务的可靠性,并能够在资源受限的情况下部署时延上限确定的服务链,能够有效提高服务链部署的时延精度;进而能够在高时延要求且资源受限的前提下实现在云端和边缘环境下的服务链的动态协同部署,能够为部署的服务链提供一个端到端时延的保障,并能够提高服务链在云端和边缘系统中的协同部署的有效性及可靠性,有效降低误差,提高服务链部署的有效性及可靠性,尤其适用于时延要求高的物联网场景。
本申请的附加优点、目的,以及特征将在下面的描述中将部分地加以阐述,且将对于本领域普通技术人员在研究下文后部分地变得明显,或者可以根据本申请的实践而获知。本申请的目的和其它优点可以通过在说明书以及附图中具体指出的结构实现到并获得。
本领域技术人员将会理解的是,能够用本申请实现的目的和优点不限于以上具体所述,并且根据以下详细说明将更清楚地理解本申请能够实现的上述和其他目的。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,并不构成对本申请的限定。附图中的部件不是成比例绘制的,而只是为了示出本申请的原理。为了便于示出和描述本申请的一些部分,附图中对应部分可能被放大,即,相对于依据本申请实际制造的示例性装置中的其它部件可能变得更大。在附图中:
图1为本申请一实施例中的云边缘协同服务链部署方法的总流程示意图。
图2为网络演算的曲线举例示意图。
图3为服务链端到端时延的构成举例示意图。
图4为本申请一实施例中的云边缘协同服务链部署方法中步骤100的具体流程示意图。
图5为本申请一实施例中的云边缘协同服务链部署方法中步骤200的具体流程示意图。
图6为本申请另一实施例中的云边缘协同服务链部署装置的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚明白,下面结合实施方式和附图,对本申请做进一步详细说明。在此,本申请的示意性实施方式及其说明用于解释本申请,但并不作为对本申请的限定。
在此,还需要说明的是,为了避免因不必要的细节而模糊了本申请,在附图中仅仅示出了与根据本申请的方案密切相关的结构和/或处理步骤,而省略了与本申请关系不大的其他细节。
应该强调,术语“包括/包含”在本文使用时指特征、要素、步骤或组件的存在,但并不排除一个或更多个其它特征、要素、步骤或组件的存在或附加。
在此,还需要说明的是,如果没有特殊说明,术语“连接”在本文不仅可以指直接连接,也可以表示存在中间物的间接连接。
在下文中,将参考附图描述本申请的实施例。在附图中,相同的附图标记代表相同或类似的部件,或者相同或类似的步骤。
近年来,随着物联网技术的迅速推进,使得现有的物联网设备的新应用场景急剧增多,如自动驾驶、智能医疗、智能制造等等。而随着物联网设备应用场景的增多,物联网设备所产生的流量也是随之急剧增多,由此对传统的网络基础设施提出了挑战。因为传统的网络基础设施都是基于专用硬件来进行搭建的。运营商基于此提供网络功能服务,成本高,并且部署困难,难以满足物联网对网络服务所提出的要求。因此,网络功能虚拟化(NFV,Network Function Virtualization)应运而生。网络功能虚拟化将网络服务与具体的硬件分开。因此,像NAT、防火墙、入侵检测、DNS和缓存这些的网络服务,能够以软件的形式交付,并部署在通用的硬件平台上。这就为网络服务的设计、部署和管理带来了很大灵活性和弹性。从而也解决了运营商提供网络服务成本高、部署困难的问题。
基于网络功能虚拟化所实现的网络功能,如NAT,防火墙等,被叫做虚拟网络功能(VNF,Virtual Network Function)。而根据用户的需求将一定数量的虚拟网络功能组合在一起就构成了服务链。而将组成服务链的各个虚拟网络功能放置到服务器当中去的任务就叫做服务链部署。不同的用户需要不同的网络服务,对网络服务的需求也不一样,如时延、计算能力等等。因此,怎么部署服务链是至关重要的。
物联网的很多场景往往对端到端时延有很高的要求。例如,自动驾驶对网络的时延需求为小于10ms,由此来保证汽车能够及时的进行操作。AR或VR设备等对网络的时延需求为小于20ms,由此来保证人的动作与画面的同步。因此需要为物联网设备的端到端时延提供一个严格的保障。若仅在云端部署服务链,虽然资源充足,但云端和边缘的链路时延高,无法保证实时性要求高的场景;若仅在边缘环境部署服务链,虽然能够免去云端和边缘的链路时延,但边缘环境的资源受限,无法保证服务链部署的可靠性。
目前在如何通过优化服务链的部署来为服务链提供端到端的时延保障方面有许多研究工作,但这些工作都没有解决提供严格的时延保障的问题。一类现有服务链部署方式可以采用假定VNF时延固定不变的SFC部署算法,在建模的过程中,假定数据包通过VNF的时延是固定不变的,这将会对服务链的端到端时延的计算带来较大的误差。每个VNF对资源的需求是不一样的,而VNF分配到的资源的多少又会影响到数据包的处理速率,从而影响到数据包通过VNF的时延。另一类现有服务链部署方式可以采用基于排队论的SFC部署算法,通过引入排队论来解决这一问题。然而基于排队论所计算出来的时延为数据包的平均时延。因此,其无法保证每一个数据包都能够在计算出来的时延中完成传输。显而易见,这对自动驾驶这种时延敏感的物联网场景是无法容忍的。还有学者率先将网络演算引入到了服务链的端到端时延的计算当中来。但该作者仅考虑了单条服务链的场景。另有学者考虑了在多条服务链之间的资源竞争的情况下基于网络演算推导出了服务链的端到端时延上限。但都仅仅只是推导了服务链的时延,并未结合服务链的部署。
现在也已经有一些研究者在研究在云边缘环境下的服务链部署。比如将SFC放置问题表述成两个子问题:图匹配问题和SFC映射问题。他提出了基于线性规划的方法来解决图匹配问题,然后设计了一种Hungarian-based放置算法来解决SFC映射问题。但该工作只考虑了计算资源而没有考虑时延。还有研究人员考虑了时延,但是他没有考虑云和边缘节点之间的高链路时延。还有学者基于时延波动,提出了一种动态的VNF动态重新调度方法。但该项工作只考虑了在边缘节点部署VNF,没有考虑云中心,这样当SFC请求数量增多的时候会因为边缘资源不足而出现部署失败,难以提供可靠性。另有学者综合考虑了云边缘环境下的时延和资源的消耗,但作者在计算时延的时候没有考虑VNF的计算时延,这样会带来较大的误差。
具体来说,现有的服务链部署方式可以概况为以下三类:
1)假定VNF时延固定不变的SFC部署算法:假定数据包通过VNF的时延是固定不变的,这将会对服务链的端到端时延的计算带来较大的误差。每个VNF对资源的需求是不一样的,而VNF分配到的资源的多少又会影响到数据包的处理速率,从而影响到数据包通过VNF的时延。
2)基于排队论的SFC部署算法:基于排队论所计算出来的时延为数据包的平均时延。因此,其无法保证每一个数据包都能够在计算出来的时延中完成传输。然而有些如自动驾驶这种时延敏感的物联网场景是无法容忍这类情况的。
3)云边缘环境下的SFC部署算法:该部分的算法工作,有些工作只考虑了计算资源而没有考虑时延;有些工作考虑了时延,但是没有考虑云和边缘节点之间的高链路时延;有些工作考虑了云边缘环境下的时延和资源的消耗,但在计算时延的时候没有考虑VNF的计算时延。总体来说,该部分工作对于时延的考虑不精确,产生的误差较大,不适用于物联网场景。
因此,如何在高时延要求且资源受限的前提下实现在云和边缘环境下的服务链部署是当前亟需解决的问题。
基于此,在本申请中,首次将网络演算理论应用到了云边缘协同的服务链部署中,意在为部署的服务链提供一个端到端时延的保障。而实现云边缘协同的服务链部署,我们遇到了两个挑战。挑战一在于云和边缘的链路时延高,如何保证提供的确定时延的网络服务的可靠性。挑战二在于边缘节点的资源有限,如何在资源受限的情况下去部署时延上限确定的服务链。
为了解决这些挑战,发明人首先对云边缘协同的服务链部署问题进行建模,由于引入了网络演算,而网络演算在进行服务链时延上限的推导时引入了非线性约束,因此问题最终被建模成混合整数非线性规划。我们首先证明了该问题是可以在多项式级时间复杂度内被验证的困难问题NP-hard,然后提出了启发式算法来解决以上两个挑战。
本申请首先运用网络演算理论计算服务链部署在云端的时延上限,如果满足服务链的时延需求,那么优先部署在云端以此来节约边缘的资源。而如果部署在云端的时延上限大于服务链的时延需求,那么采取第二种部署方法,将服务链部署在边缘节点上。
在本申请的一个或多个实施例中,所述云边缘协同部署是指云端及边缘协同部署,具体是指云中心网络和边缘系统之间的协同部署。所述云中心网络可以部署各个云端服务器。所述边缘系统由各个边缘节点组成,且边缘节点可以为服务器或具有数据处理功能的客户端设备。
在本申请的一个或多个实施例中,所述服务链也可以称为在服务功能链。服务链请求可以写为SFCs。
在本申请的一个或多个实施例中,部分参数说明如下:
G,是指部署在云中心网络的服务链的集合;
E、E’,是指部署在边缘节点的服务链的集合;
Fs、Fs’,是指属于服务链请求的VNF集合;
Rv,是指边缘系统当前的可用资源;
v,是指云中心网络或者边缘系统中服务器,该服务器在云中心网络中可以为云端服务器,在边缘系统中可以使边缘节点;
V、V’,是指边缘系统中的服务器的集合;
Rv,是指边缘节点集合中的各个边缘节点的可用资源;
lij,是指链路i和链路j构成的路径;
L,是指路径集合;
具体通过下述实施例进行详细说明。
本申请实施例提供一种云边缘协同服务链部署方法,参见图1,所述云边缘协同服务链部署方法具体包含有如下内容:
步骤100:应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求。
可以理解的是,本申请步骤100引入了网络演算,而网络演算在进行服务链时延上限的推导时引入了非线性约束,因此问题最终被建模成混合整数非线性规划。
在步骤100中,在网络演算中,最重要的概念就是到达曲线和服务曲线,核心思想即为将网络中的到达流和网络提供的服务用到达曲线和服务曲线去建模。到达曲线所描述的是流将发送的数据量的上限,而服务曲线所描述的则是数据处理节点能够保证处理的数据量的下限。
参见图2,我们假设业务的流量首先经过了令牌桶过滤器TBF(Token BucketFilter),其中TBF的发送速率为ρ,令牌桶(Token Bucket)的大小为σ,那么我们由TBF发出来的流的到达曲线就被建模为ρt+σ,即直线①,代表着流随着时间到达的数据量(流量)的上限。随后业务流被发送到节点进行处理。节点的服务曲线则是直线②,γ(t-θ)。其中γ代表的是节点的处理速率,θ代表的是流在被节点进行处理之前等待的时间。基于到达曲线和服务曲线,我们可以得到时延上限,其值为两条曲线的最大水平偏差,即图2中的虚线所示。若我们用α(t)表示到达曲线,用β(t)表示服务曲线,那么时延上限的表达式可以表示为下述公式(1)。在图2的示例中,时延上限计算得σ/γ+θ。
网络演算中另一个十分重要的概念,叫做串联定理,是运用在多个节点串联的情况下的。我们假设有两条服务曲线,分别是β1(t)=γ1(t-θ1)和β2(t)=γ2(t-θ2)。那么根据串联定理,可以将两条服务曲线合并成为一条服务曲线,为其中符号表示最小化卷积,其表达式如下述公式(2)所示。而在示例的假设中,串联后的服务曲线计算得到为γ2(t-θ1-θ2),其中γ3为:γ3=min{γ1,γ2}。
其中,服务链端到端时延的构成说明如下:
一般来说,服务链的端到端时延包括链路时延和节点时延,如图3所示。链路时延指的是数据包在物理链路中传播所带来的时延,主要是由物理链路的长度来决定。而节点时延则是VNF节点时延。其中VNF节点时延我们通过网络演算来计算获得其上限。网络演算计算VNF节点时延的时候考虑了VNF的处理时延以及VNF产生的排队时延,其中VNF的处理时延是现有的服务链部署方案中没有考虑的。图3中的NIC表示网卡(network interfacecard)或网络接口控制器(network interface controller),是一块被设计用来允许计算机在计算机网络上进行通讯的计算机硬件。
步骤200:若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
从上述描述可知,本申请实施例提供的云边缘协同服务链部署方法,将网络演算理论应用到云边缘协同的服务链部署中,如果满足服务链的时延需求,那么优先部署在云端以此来节约边缘的资源。而如果部署在云端的时延上限大于服务链的时延需求,那么将服务链部署在边缘节点上;能够保证所提供的确定时延的网络服务的可靠性,并能够在资源受限的情况下部署时延上限确定的服务链,能够有效提高服务链部署的时延精度;进而能够在高时延要求且资源受限的前提下实现在云端和边缘环境下的服务链的动态协同部署,能够为部署的服务链提供一个端到端时延的保障,并能够提高服务链在云端和边缘系统中的协同部署的有效性及可靠性,有效降低误差,提高服务链部署的有效性及可靠性,尤其适用于时延要求高的物联网场景。
为了提高基于网络演算的云端算法的应用可靠性及有效性,在本申请实施例提供的一种云边缘协同服务链部署方法中,参见图4,所述云边缘协同服务链部署方法中的步骤100具体包含有如下内容:
步骤110:接收服务链请求,并获取该服务链请求对应的时延需求值。
步骤120:基于网络演算方式确定该服务链请求部署在所述云中心网络的时延上限值。
步骤130:判断所述云中心网络的时延上限值是否小于或等于所述时延需求值,若是,则执行步骤131:将该服务链请求存储至一预设的云端服务链集合中;
步骤140:针对所述云端服务链集合中的服务链请求,调用最优路径算法获取该服务链请求在所述云中心网络中的目标部署路径,将该目标部署路径确定为第一目标部署路径,并将基于该第一目标部署路径在所述云中心网络中部署所述服务链请求。
为了在高时延要求且资源受限的前提下进一步实现在云端和边缘环境下的服务链的动态协同部署,在本申请实施例提供的一种云边缘协同服务链部署方法中,参见图4,所述云边缘协同服务链部署方法中的步骤100还具体包含有如下内容:
在执行步骤130之后,若经判断获知所述云中心网络当前的时延上限值大于所述服务链请求的时延需求值,则执行步骤132:将所述服务链请求存储至一预设的边缘服务链集合中。
具体来说,云端算法用于判断服务链SFC是否部署在云中心网络。定义G是部署在云中心网络的服务链的集合,E为部署在边缘节点的服务链的集合,首先在将G和E都设为空集。具体的云端算法流程如下:
基于此,上述S1-S3完成云端计算,而后调用算法3执行S4,再调用边缘算法执行S5。可以看到在云端算法中没有过多的去考虑资源,而是主要考虑时延需求,那是因为云中心网络的资源很庞大,而云边的链路时延高,因此我们在云端算法中优先考虑时延需求而不是资源需求。
S4:对于集合G中的服务链请求,调用最优路径算法来获取在云中心网络内部的最优部署路径,并完成所述服务链请求对应的服务链部署;
S5:对于集合E中的服务链请求,将该集合E输入到边缘算法中。
为了提高基于边缘算法的应用可靠性及有效性,在本申请实施例提供的一种云边缘协同服务链部署方法中,所述云边缘协同服务链部署方法中的步骤200可以在步骤132之后执行,参见图5,所述步骤200具体包含有如下内容:
步骤210:获取所述服务链请求的服务链资源需求值以及属于所述服务链请求中的各个虚拟网络功能VNF的VNF资源需求值;
步骤220:根据所述服务链资源需求值、VNF资源需求值和所述边缘系统中各个边缘节点当前的可用资源值,生成所述服务链请求在所述边缘系统中的初始部署方案;
步骤230:判断所述服务链资源需求值是否小于或等于所述边缘系统当前的可用资源值,若是,则执行步骤231:基于网络演算方式确定该服务链请求部署在所述边缘系统的第一时延上限值;
步骤240:判断所述第一时延上限值是否小于或等于所述时延需求值,若否,则执行步骤241:调取所述最优路径算法生成该服务链请求在所述边缘系统中的目标部署路径;
步骤250:基于网络演算方式,应用所述部署路径重新确定所述服务链请求部署在所述边缘系统的第二时延上限值;
步骤260:判断所述第二时延上限值是否小于或等于所述时延需求值,若是,则执行步骤261:将所述服务链请求在所述边缘系统中的目标部署路径确认为第二目标部署路径,并基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
为了提高基于边缘算法的应用全面性及可靠性,在本申请实施例提供的一种云边缘协同服务链部署方法中,参见图5,所述云边缘协同服务链部署方法中的步骤200还具体包含有如下内容:
若经步骤240判断获知所述第一时延上限值小于或等于所述时延需求值,则执行步骤242:将所述初始部署方案作为第二目标部署路径,并基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
为了提高基于边缘算法的应用全面性及可靠性,在本申请实施例提供的一种云边缘协同服务链部署方法中,参见图3,所述云边缘协同服务链部署方法中的步骤200还具体包含有如下内容:
若经步骤230判断获知所述服务链资源需求值大于所述边缘系统当前的可用资源值,或者,若步骤260判断获知所述第二时延上限值仍然大于所述时延需求值则拒绝执行该服务链请求,则执行步骤270:拒绝执行所述服务链请求。
具体来说,边缘算法用于判断剩余的SFC是否部署在边缘节点上。针对上述步骤S5,具体的云端算法流程如下:
S53:按照边缘节点集合中的各个边缘节点的可用资源Rv将边缘节点集合V降序排列,得到新的边缘节点集合V’;
S56:若虚拟网络功能VNF f遍历了边缘节点集合V’都没有部署成功,那么包含该虚拟网络功能VNF f的SFC请求将被拒绝;
可以看到边缘算法一开始没有直接调用最优路径算法来获得最短路径,而是在第一次部署不满足时延需求之后才调用最优路径算法。这是因为在边缘节点的环境中,资源紧缺才是最优先考虑的问题,因此我们先考虑根据资源需求来进行部署,然后再判断是否满足时延需求。若不满足时延需求,才再优先考虑时延需求来进行部署。
为了提高最优路径算法的应用有效性及可靠性,在本申请实施例提供的一种云边缘协同服务链部署方法中:所述云边缘协同服务链部署方法中的最优路径算法具体包含有如下内容:
步骤300:获取所述服务链请求在当前目标环境中的部署路径,其中,所述目标环境包括:所述云中心网络或所述边缘系统;
步骤400:判断所述部署路径中的各个服务节点是否均满足所述服务链请求对应的资源需求,若是,则执行步骤410:将该部署路径确定为最优路径;
若所述部署路径中的各个服务节点中存在不满足所述服务链请求对应的资源需求的服务节点,则执行步骤420:在所述部署路径中将该不满足所述资源需求的服务节点删除,再将该部署路径确定为最优路径;
步骤500:判断所述最优路径中的各个服务节点是否均满足预审的带宽限制,若是,则执行步骤510:将该最优路径确定为目标部署路径。
具体来说,最优路径算法用于寻找满足资源需求的最快路径。最优路径算法每次输入的SFC请求只有一条。针对上述S4,具体的最优路径算法流程如下:
S41:首先调用Dijkstra算法来获取云中心网络或边缘系统中的最优路径lij,各个最优路径lij形成集合L;
S44:对路径的带宽限制进行判断,若判断都满足带宽限制,则最后返回路径作为输出;若判断路径lij不满足带宽限制,则将该路径lij从集合L中删除,并迭代调用FastPath算法。
从软件层面来说,本申请还提供一种用于执行所述云边缘协同服务链部署方法中全部或部分内的云边缘协同服务链部署装置,参见图6,所述云边缘协同服务链部署装置具体包含有如下内容:
云端部署模块10,用于应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求。
边缘部署模块20,用于若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
本申请提供的云边缘协同服务链部署装置的实施例具体可以用于执行上述实施例中的云边缘协同服务链部署方法的实施例的处理流程,其功能在此不再赘述,可以参照上述云边缘协同服务链部署方法实施例的详细描述。
所述云边缘协同服务链部署装置进行云边缘协同服务链部署的部分可以在服务器中执行,而在另一种实际应用情形中,也可以所有的操作都在客户端设备中完成。具体可以根据所述客户端设备的处理能力,以及用户使用场景的限制等进行选择。本申请对此不作限定。若所有的操作都在所述客户端设备中完成,所述客户端设备还可以包括处理器,用于云边缘协同服务链部署的具体处理。
上述的客户端设备可以具有通信模块(即通信单元),可以与远程的服务器进行通信连接,实现与所述服务器的数据传输。所述服务器可以包括任务调度中心一侧的服务器,其他的实施场景中也可以包括中间平台的服务器,例如与任务调度中心服务器有通信链接的第三方服务器平台的服务器。所述的服务器可以包括单台计算机设备,也可以包括多个服务器组成的服务器集群,或者分布式装置的服务器结构。
上述服务器与所述客户端设备端之间可以使用任何合适的网络协议进行通信,包括在本申请提交日尚未开发出的网络协议。所述网络协议例如可以包括TCP/IP协议、UDP/IP协议、HTTP协议、HTTPS协议等。当然,所述网络协议例如还可以包括在上述协议之上使用的RPC协议(Remote Procedure Call Protocol,远程过程调用协议)、REST协议(Representational State Transfer,表述性状态转移协议)等。
从上述描述可知,本申请实施例提供的云边缘协同服务链部署装置,将网络演算理论应用到云边缘协同的服务链部署中,如果满足服务链的时延需求,那么优先部署在云端以此来节约边缘的资源。而如果部署在云端的时延上限大于服务链的时延需求,那么将服务链部署在边缘节点上;能够保证所提供的确定时延的网络服务的可靠性,并能够在资源受限的情况下部署时延上限确定的服务链,能够有效提高服务链部署的时延精度;进而能够在高时延要求且资源受限的前提下实现在云端和边缘环境下的服务链的动态协同部署,能够为部署的服务链提供一个端到端时延的保障,并能够提高服务链在云端和边缘系统中的协同部署的有效性及可靠性,有效降低误差,提高服务链部署的有效性及可靠性,尤其适用于时延要求高的物联网场景。
为了进一步说明本方案,本申请还提供一种用于实现云边缘协同服务链部署方法的具体应用实例,具体涉及一种基于网络演算的延迟敏感的云边缘协同服务链部署算法,本申请应用实例所提出的云边缘协同部署算法CECDA可以分为三个子算法。第一个子算法是云端算法。我们首先调用该算法来判断SFC是否部署在云中心网络。第二个子算法,为边缘算法。我们会调用该算法来判断剩下被云端拒绝的SFC能否部署在边缘节点,并完成SFC的部署。而第三个子算法是最优路径算法,在算法1确定SFC部署在云端的时候,会调用该算法来确定最优部署路径;在算法2初次规划路径不满足时延需求的时候,也会调用该算法来寻找最优部署路径。
CECDA算法完成云边协同服务链部署会分为三步。首先调用算法1来判断是否部署在云端,若是,则调用算法3来完成最优路径选择并完成部署;若否,则调用算法2来将该SFC部署在边缘节点,若时延需求不符合,则调用算法3来获取部署最优路径来完成部署,若还是不满足时延需求,则拒绝该SFC请求。主要包括以下步骤:
(一)算法1-云端算法
云端算法是用于判断SFC是否部署在云中心网络。定义G是部署在云中心网络的SFC的集合,E为部署在边缘节点的SFC的集合。首先在将G,E都设为空集。对于每一个输入进来的SFC请求,我们会运用网络演算理论来计算该SFCs部署在云中心网络的时延上限。紧接着将该时延上限与SFCs的时延需求进行比较,若时延上限满足SFC的时延需求,那么将该SFCs放到集合G中;否则将该SFCs放到集合E中。而对于集合G中的SFC请求,算法会调用最优路径算法来获取在云中心网络内部的最优部署路径,并完成SFC的部署,而集合E则会输出到算法2中,作为算法2的输入。可以看到在云端算法中没有过多的去考虑资源,而是主要考虑时延需求,那是因为云中心网络的资源很庞大,而云边的链路时延高,因此我们在云端算法中优先考虑时延需求而不是资源需求。
具体来说,算法1-云端算法的举例如表1所示。
表1
在表1中,输入的服务链资源需求会在FastPath()中用到。且输出中仅有集合E的原因为:当前集合G已经部署完毕,因此输出的只有集合E,从而进入下一个算法。
(二)算法2-边缘算法
边缘算法用于判断剩余的SFC是否部署在边缘节点上。算法2首先对SFC的集合E按照资源需求进行降序排列,新得到的集合设为E’。然后将属于SFCs的VNF集合Fs也按照资源需求进行降序排列,新得到的集合设为Fs’。边缘算法进一步将服务器集合V按照可用资源Rv降序排列,得到集合V’。该算法从资源需求最小的SFCs开始部署,在SFCs内部也先从资源需求最小的VNF f进行部署。若VNF f的资源需求小于等于服务器v的可用资源Rv,那么我们就先将其部署在该服务器v中。若VNF f遍历了服务器集合V’都没有部署成功,那么包含该VNF f的SFC请求将被拒绝。在SFCs部署完毕之后,边缘算法会引用网络演算理论来计算其部署时延上限若满足时延需求那么该SFC则部署完毕;若不满足时延需求,那么则调用最最优路径算法来获取最快路径。若返回的路径不为空,则再次计算部署时延上限若该次部署满足时延需求则该SFC部署完毕,否则该SFC请求被拒绝。可以看到边缘算法一开始没有直接调用最最优路径算法来获得最短路径,而是在第一次部署不满足时延需求之后才调用最最优路径算法。这是因为在边缘节点的环境中,资源紧缺才是最优先考虑的问题,因此我们先考虑根据资源需求来进行部署,然后再判断是否满足时延需求。若不满足时延需求,我们才再优先考虑时延需求来进行部署。
具体来说,算法2-边缘算法的举例如表2所示。
表2
(三)算法3-最优路径算法
最优路径算法用于寻找满足资源需求的最快路径。算法3每次输入的SFC请求只有一条。最优路径算法首先调用Dijkstra算法来获取最优路径。然后对于路径中的服务器v,若判断都满足资源需求,则最后返回路径作为输出;若判断服务器v不满足资源需求,则将该服务器v从集合V’中删除,并迭代调用FastPath算法。之后对路径的带宽限制进行判断,若判断都满足带宽限制,则最后返回路径作为输出;若判断路径lij不满足带宽限制,则将该路径lij从集合L中删除,并迭代调用FastPath算法。
具体来说,算法3-最优路径算法的举例如表3所示。
表3
与现有技术相比,本申请应用实例的有益效果是:
本申请应用实例提出一种云边缘协同服务链部署方法,分别提供了针对云边缘环境下的服务链部署的云端算法、针对云边缘环境下的服务链部署的边缘算法和针对云边缘环境下的服务链部署的最优路径算法,较之前的方法,本申请应用实例为服务链的部署提供了严格的时延保障;增加了云边缘环境下的服务链请求的接受率。
本申请应用实例能够在高时延要求且资源受限的前提下实现在云端和边缘环境下的服务链的动态协同部署,能够为部署的服务链提供一个端到端时延的保障,并能够提高服务链在云端和边缘系统中的协同部署的有效性及可靠性,有效降低误差,提高服务链部署的有效性及可靠性,尤其适用于时延要求高的物联网场景。
本申请实施例还提供了一种电子设备(也即电子设备),该电子设备可以包括处理器、存储器、接收器及发送器,处理器用于执行上述实施例提及的云边缘协同服务链部署方法,其中处理器和存储器可以通过总线或者其他方式连接,以通过总线连接为例。该接收器可通过有线或无线方式与处理器、存储器连接。所述电子设备可自所述无线多媒体传感器网络中的传感器接收实时运动数据,并自所述视频采集装置接收原始视频序列。
处理器可以为中央处理器(Central Processing Unit,CPU)。处理器还可以为其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片,或者上述各类芯片的组合。
存储器作为一种非暂态计算机可读存储介质,可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块,如本申请实施例中的云边缘协同服务链部署方法对应的程序指令/模块。处理器通过运行存储在存储器中的非暂态软件程序、指令以及模块,从而执行处理器的各种功能应用以及数据处理,即实现上述方法实施例中的云边缘协同服务链部署方法。
存储器可以包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可存储处理器所创建的数据等。此外,存储器可以包括高速随机存取存储器,还可以包括非暂态存储器,例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中,存储器可选包括相对于处理器远程设置的存储器,这些远程存储器可以通过网络连接至处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
所述一个或者多个模块存储在所述存储器中,当被所述处理器执行时,执行实施例中的云边缘协同服务链部署方法。
在本申请的一些实施例中,用户设备可以包括处理器、存储器和收发单元,该收发单元可包括接收器和发送器,处理器、存储器、接收器和发送器可通过总线系统连接,存储器用于存储计算机指令,处理器用于执行存储器中存储的计算机指令,以控制收发单元收发信号。
作为一种实现方式,本申请中接收器和发送器的功能可以考虑通过收发电路或者收发的专用芯片来实现,处理器可以考虑通过专用处理芯片、处理电路或通用芯片实现。
作为另一种实现方式,可以考虑使用通用计算机的方式来实现本申请实施例提供的服务器。即将实现处理器,接收器和发送器功能的程序代码存储在存储器中,通用处理器通过执行存储器中的代码来实现处理器,接收器和发送器的功能。
本申请实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时以实现前述云边缘协同服务链部署方法的步骤。该计算机可读存储介质可以是有形存储介质,诸如随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、软盘、硬盘、可移动存储盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质。
本领域普通技术人员应该可以明白,结合本文中所公开的实施方式描述的各示例性的组成部分、系统和方法,能够以硬件、软件或者二者的结合来实现。具体究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。当以硬件方式实现时,其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时,本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中,或者通过载波中携带的数据信号在传输介质或者通信链路上传送。
需要明确的是,本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见,这里省略了对已知方法的详细描述。在上述实施例中,描述和示出了若干具体的步骤作为示例。但是,本申请的方法过程并不限于所描述和示出的具体步骤,本领域的技术人员可以在领会本申请的精神后,作出各种改变、修改和添加,或者改变步骤之间的顺序。
本申请中,针对一个实施方式描述和/或例示的特征,可以在一个或更多个其它实施方式中以相同方式或以类似方式使用,和/或与其他实施方式的特征相结合或代替其他实施方式的特征。
以上所述仅为本申请的优选实施例,并不用于限制本申请,对于本领域的技术人员来说,本申请实施例可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
Claims (10)
1.一种云边缘协同服务链部署方法,其特征在于,包括:
应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求;
若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
2.根据权利要求1所述的云边缘协同服务链部署方法,其特征在于,所述应用基于网络演算的云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求,包括:
接收服务链请求,并获取该服务链请求对应的时延需求值;
基于网络演算方式确定该服务链请求部署在所述云中心网络的时延上限值;
判断所述云中心网络的时延上限值是否小于或等于所述时延需求值,若是,则将该服务链请求存储至一预设的云端服务链集合中;
针对所述云端服务链集合中的服务链请求,调用最优路径算法获取该服务链请求在所述云中心网络中的目标部署路径,将该目标部署路径确定为第一目标部署路径,并将基于该第一目标部署路径在所述云中心网络中部署所述服务链请求。
3.根据权利要求2所述的云边缘协同服务链部署方法,其特征在于,还包括:
若经判断获知所述云中心网络当前的时延上限值大于所述服务链请求的时延需求值,则将所述服务链请求存储至一预设的边缘服务链集合中。
4.根据权利要求1所述的云边缘协同服务链部署方法,其特征在于,所述若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求,包括:
获取所述服务链请求的服务链资源需求值以及属于所述服务链请求中的各个虚拟网络功能VNF的VNF资源需求值;
根据所述服务链资源需求值、VNF资源需求值和所述边缘系统中各个边缘节点当前的可用资源值,生成所述服务链请求在所述边缘系统中的初始部署方案;
判断所述服务链资源需求值是否小于或等于所述边缘系统当前的可用资源值,若是,则基于网络演算方式确定该服务链请求部署在所述边缘系统的第一时延上限值;
判断所述第一时延上限值是否小于或等于所述时延需求值,若否,则调取所述最优路径算法生成该服务链请求在所述边缘系统中的目标部署路径;
基于网络演算方式,应用所述部署路径重新确定所述服务链请求部署在所述边缘系统的第二时延上限值;
判断所述第二时延上限值是否小于或等于所述时延需求值,若是,则将所述服务链请求在所述边缘系统中的目标部署路径确认为第二目标部署路径,并基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
5.根据权利要求4所述的云边缘协同服务链部署方法,其特征在于,还包括:
若经判断获知所述第一时延上限值小于或等于所述时延需求值,则将所述初始部署方案作为第二目标部署路径,并基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
6.根据权利要求4所述的云边缘协同服务链部署方法,其特征在于,还包括:
若经判断获知所述服务链资源需求值大于所述边缘系统当前的可用资源值,或者,若经判断获知所述第二时延上限值仍然大于所述时延需求值则拒绝执行该服务链请求,则拒绝执行该服务链请求。
7.根据权利要求1至6任一项所述的云边缘协同服务链部署方法,其特征在于,所述最优路径算法包括:
获取所述服务链请求在当前目标环境中的部署路径,其中,所述目标环境包括:所述云中心网络或所述边缘系统;
判断所述部署路径中的各个服务节点是否均满足所述服务链请求对应的资源需求,若是,则将该部署路径确定为最优路径;
若所述部署路径中的各个服务节点中存在不满足所述服务链请求对应的资源需求的服务节点,则在所述部署路径中将该不满足所述资源需求的服务节点删除,再将该部署路径确定为最优路径;
判断所述最优路径中的各个服务节点是否均满足预审的带宽限制,若是,则将该最优路径确定为目标部署路径。
8.一种云边缘协同服务链部署装置,其特征在于,包括:
云端部署模块,用于基于云端算法判断云中心网络当前是否满足服务链请求对应的时延需求,若是,则调用最优路径算法获取该服务链请求在所述云中心网络中的第一目标部署路径并基于该第一目标部署路径在所述云中心网络中部署所述服务链请求;
边缘部署模块,用于若所述服务链请求未部署在所述云中心网络中,且若基于边缘算法获知边缘系统当前满足所述服务链请求对应的资源需求,则判断所述边缘系统当前是否满足所述时延需求,若不满足,且若根据所述最优路径算法和所述时延需求生成该服务链请求在所述边缘系统中的第二目标部署路径,则基于该第二目标部署路径在所述边缘系统中部署所述服务链请求。
9.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的云边缘协同服务链部署方法。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该计算机程序被处理器执行时实现如权利要求1至7任一项所述的云边缘协同服务链部署方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211192420.5A CN115941678A (zh) | 2022-09-28 | 2022-09-28 | 云边缘协同服务链部署方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211192420.5A CN115941678A (zh) | 2022-09-28 | 2022-09-28 | 云边缘协同服务链部署方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115941678A true CN115941678A (zh) | 2023-04-07 |
Family
ID=86699539
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211192420.5A Pending CN115941678A (zh) | 2022-09-28 | 2022-09-28 | 云边缘协同服务链部署方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115941678A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117527590A (zh) * | 2024-01-04 | 2024-02-06 | 湖北省楚天云有限公司 | 基于边缘网络的微服务部署与请求路由方法、系统及介质 |
-
2022
- 2022-09-28 CN CN202211192420.5A patent/CN115941678A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117527590A (zh) * | 2024-01-04 | 2024-02-06 | 湖北省楚天云有限公司 | 基于边缘网络的微服务部署与请求路由方法、系统及介质 |
CN117527590B (zh) * | 2024-01-04 | 2024-05-21 | 湖北省楚天云有限公司 | 基于边缘网络的微服务部署与请求路由方法、系统及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3968594B1 (en) | Method, apparatus and system for selecting mobile edge computing node | |
CN106936857B (zh) | 一种混合云的连接管理方法、sdn控制器及混合云系统 | |
US10003540B2 (en) | Flow forwarding method, device, and system | |
WO2021093515A1 (zh) | 一种数据传输的方法以及相关装置 | |
CN110730105B (zh) | 图片数据传输方法、装置、设备及存储介质 | |
US11025724B2 (en) | Transport of control data in proxy-based network communications | |
WO2021088964A1 (zh) | 推理系统、推理方法、电子设备及计算机存储介质 | |
EP3468132A1 (en) | Method and device for transmitting speech data | |
JP6952816B2 (ja) | 基地局装置及び端末装置とQoS制御方法 | |
US11258717B2 (en) | Method for sending service packet, network device, and system | |
CN111212156B (zh) | 一种网络连接方法与装置 | |
CN111629030A (zh) | 基于边缘计算平台的通信处理方法、装置、介质及设备 | |
US11640368B2 (en) | Acceleration system for facilitating processing of API calls | |
CN115941678A (zh) | 云边缘协同服务链部署方法及装置 | |
CN114118447A (zh) | 新型联邦学习系统、方法、装置、计算机设备及存储介质 | |
CN112532466A (zh) | 流量识别方法、装置及存储介质 | |
WO2016202224A1 (zh) | 一种传输层参数调整方法和装置 | |
WO2020048504A1 (zh) | 网络功能所需资源的部署方法、装置、存储介质及电子装置 | |
CN107113186A (zh) | 统一机器到机器系统中数据传输的方法和公共服务实体 | |
WO2021031744A1 (zh) | 链路路径计算方法、装置、终端及计算机可读存储介质 | |
CN114173429A (zh) | 5g专网下无线接入网和边缘计算平台的通信方法及系统 | |
CN112367708A (zh) | 一种网络资源分配方法及装置 | |
CN115378872B (zh) | 一种流量控制方法、系统、计算机设备及可读存储介质 | |
CN111064673A (zh) | 一种用户面数据完整性保护方法、装置、电子设备及介质 | |
US20220303223A1 (en) | Optimizing data priority by managing network resources |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |