CN113852693B - 一种边缘计算服务的迁移方法 - Google Patents

Abstract

本申请公开了一种边缘计算服务的迁移方法，其特征在于，在云计算中心设置若干中心控制节点进行迁移服务的锁定，在边缘节点上设置使用sidecar模式部署的用户接入层管理，方法包括：迁移前的第一边缘节点接收用户终端上报的自身状态和向第二边缘节点的服务迁移请求，当确定允许进行服务迁移后，所述第一边缘节点获取第二边缘节点的地址发送给所述用户终端，所述中心控制节点锁定所述服务迁移，拒绝服务迁移过程中所述用户终端相同方向上其他服务的迁移请求；所述第一边缘节点中断要迁移的服务，并将该服务的迁移数据发送给所述第二边缘节点，用于所述第二边缘节点在接收到所述用户终端的服务请求后恢复中断的服务。应用本申请，能够大大降低迁移时延，并保证迁移数据的一致性。

Description

一种边缘计算服务的迁移方法

技术领域

本申请涉及边缘计算技术，特别涉及一种边缘计算服务的迁移方法。

背景技术

近年来，随着以智慧城市、智能交通等物联网(Internet of Things,IoT)应用为代表的新一代信息技术、移动支付服务等新型服务模式的迅猛发展，网络流量的迅速增长带来了对数据中心传输时延的更高要求。同时接入设备的数量和随之产生的数据量也呈海量增长趋势，传统采取集中处理的云计算模型已经对海量的数据处理不堪重负，造成了更大的数据瓶颈。为了解决相关问题，边缘计算提出将计算资源下沉到离用户更近的位置，称之为边缘云或边缘节点。这改变了数据中心单一、集中的模式，大量数据在边缘云上就能得到处理并返回用户，使得网络结构支撑时延敏感业务与超量计算业务成为可能。而通过在边缘节点分流高带宽占比业务，能够有效减少业务在核心骨干网的资源占用，极大提升无线网络的利用率。且边缘计算业务作为中心云计算的延伸，天然具有部署分散、广域覆盖、环境多样化的特点，方便提供针对性的细化能力以大幅降低计算资源损耗、提升AI类业务的效费比，同时也具备多维数据场景的处理能力来应对智慧城市等新兴场景需求。

但网络计算架构的改变也为服务的提供带来了新的技术难点：边缘服务器具有一定的服务覆盖范围,移动终端的移动性会导致服务质量的下降甚至服务的中断，为了保证用户移动时的服务连续性，降低服务迁移的时延并实现服务跟随，使如车联网自动驾驶、用户AR/VR设备的网络性能符合服务连续性要求，需要一种合适的边缘网络架构和成熟的服务迁移解决方案。

在服务迁移的场景下，有两类典型业务：其一是类似断点续传等可间断业务，其特点是连续性要求较低、切换简单，但强调传输过程的稳定和可靠；另一类是连续性要求较强的业务，这一类业务对于连续性要求更高的同时，对切换速度和占用资源有了更高的要求。针对这两种业务，其服务迁移解决方案可根据移动终端用户是否感知分为无状态迁移和有状态的迁移。无状态迁移占用资源较少，主要用来支持可间断业务的迁移，而有状态迁移则更为复杂，主要用来支持连续性较强的业务。对于不同业务，合适迁移方式的选择与相关系统的设计与实现是当前工业界和学界的热点话题，尤其热迁移方案，包括虚拟机热迁移(预拷贝热迁移算法和后置拷贝热迁移)和容器热迁移是关键讨论点。

相对于较为普遍基于虚拟机和容器的迁移方案，尽管虚拟机直接迁移有很多优化方案减小了传输代价，但虚拟机占用了主机的大量系统资源并且其大小为GB级别，在虚拟服务器上运行单个应用程序意味着还要运行虚拟机所需的Guest OS以及Guest OS运行所需的所有硬件的虚拟副本，如此一来增加了很多RAM和CPU资源消耗。迁移虚拟机上运行的应用程序的过程也很复杂，因为它始终附加在操作系统上。必须同时迁移应用程序和操作系统才能完成“快照”式迁移工作，这相对于单独运行的服务器资源来说有很大提升，但是对于边缘计算应用的量级并不实用。

容器技术的优势在于其资源占用量比虚拟机小很多，甚至可以小到数MB，可以轻松限制容器的内存和CPU使用率。与部署应用需要部署整个操作系统的虚拟机相比，容器非常轻巧且启动迅速。这样可以快速扩展容器并添加相同的容器，因此对于持续集成和持续部署(CI/CD)实施也是极好的选择。对于虚拟化技术中在节点间的有状态实时迁移应用上，容器尽管在安全性和封闭性上不如虚拟机，但是容器的数据量大小和待迁移部分都更轻量级，而VM的文件系统和内存内容和其他许多与的应用程序无关的后台进程相关联。但容器直接迁移首先并没有成熟的实现接口，其次产生的迁移包数量级仍然不足以支撑有着实时性要求的数量级。

随着以物联网为代表的新一代信息技术的迅猛发展，网络流量的迅速增长带来了对数据中心传输时延的更高要求，为了应对对应的海量数据流量压力、去除数据瓶颈，边缘计算使得网络机构支撑时延敏感业务与超量计算业务成为可能。

发明内容

本申请提供一种边缘计算服务的迁移方法，能够方便地实现用户任一服务在边缘服务节点间的迁移。

为实现上述目的，本申请采用如下技术方案：

一种边缘计算服务的迁移方法，在云计算中心设置若干中心控制节点进行迁移服务的锁定，在边缘节点上设置使用sidecar模式部署的用户接入层管理，所述方法包括：

迁移前的第一边缘节点接收用户终端上报的自身状态和向第二边缘节点的服务迁移请求，当确定允许进行服务迁移后，所述第一边缘节点获取第二边缘节点的地址，所述中心控制节点锁定所述服务迁移，拒绝服务迁移过程中所述用户终端相同方向上其他服务的迁移请求；

所述第一边缘节点中断要迁移的服务，并将该服务的迁移数据发送给所述第二边缘节点，用于所述第二边缘节点在接收到所述用户终端的服务请求后恢复中断的服务。

较佳地，所述中心控制节点还用于进行迁移服务的授权；

确定是否允许进行服务迁移的方式包括：所述第一边缘节点根据所述自身状态和所述服务迁移请求，判断请求的服务迁移是主动迁移还是被动迁移；若是主动迁移，则确定允许进行所述服务迁移；若是被动迁移，所述第一边缘节点向所述中心控制节点请求迁移令牌，所述中心控制节点判断是否允许进行所述服务迁移，若允许，则解析出所述第二边缘节点的地址发送给所述第一边缘节点，若不允许，则通知所述第一边缘节点拒绝所述服务迁移。

较佳地，在通知所述第一边缘节点拒绝所述服务迁移后，该方法进一步包括：当用户终端的空口切换到第二边缘节点后，对于所述服务的服务请求，所述第二边缘节点向所述第一边缘节点请求进行服务处理，并将所述第一边缘节点反馈给所述第二边缘节点的服务处理结果发送给所述用户终端。

较佳地，所述中心控制节点判断是否允许进行所述服务迁移包括：

当请求服务迁移的用户未包含在系统黑名单、且所述第二边缘节点处于激活状态下，则获取迁移模式配置，按照所述迁移模式配置获取计算参数的取值，根据各个计算参数的取值及其对应的权重计算用户令牌值，若所述用户令牌值高于令牌阈值，则判定允许进行所述服务迁移，否则，拒绝所述服务迁移。

较佳地，所述计算参数包括：设定时间内的迁移次数、所述第二边缘节点的节点压力、迁移服务的任务持续时间和/或偏移进度。

较佳地，该方法进一步包括：

对于上报轨迹的所述用户终端，预先保存用户轨迹，并将服务迁移时需要迁移的基础资源层和静态资源层的数据预先部署在用户轨迹的设定边缘节点上；

当所述服务迁移为主动迁移时，所述将该服务的迁移数据发送给所述第二边缘节点包括：将实例应用信息层的迁移数据发送给所述第二边缘节点。

一种边缘计算服务迁移系统，包括：用户接入层、节点服务层和迁移系统层；

所述用户接入层，用于与用户终端交互，使用sidecar模式实现用户接入层管理；还用于为用户终端提供移动边缘节点的计算服务，进行服务迁移的实际操作，获取服务迁移的目的边缘节点的地址，并将当前用户接入的物理节点地址更新给所述用户终端；

所述节点服务层，用于控制和管理一个或多个移动边缘节点，控制和管理移动边缘节点间的服务迁移进程；

所述迁移系统层，用于进行迁移服务的锁定，保证同一用户在同一时刻的单一方向上仅允许一个服务进行迁移；还用于对移动边缘节点间的服务迁移进行管理和记录。

较佳地，所述用户接入层包括用户代理模块和边缘用户服务模块；

所述用户代理模块，用于与用户终端交互，使用sidecar模式实现用户接入层管理；还用于与所述移动边缘节点管理模块进行交互，实现所述移动边缘节点管理模块对边缘节点的服务管理和迁移服务的控制，并控制所述边缘用户服务模块实现服务迁移的数据处理；还用于获取服务迁移的目的边缘节点的地址，并将当前用户接入的物理节点地址更新给所述用户终端；

所述边缘用户服务模块，用于提供边缘计算服务，并实现服务迁移过程中的数据处理；

所述移动边缘节点管理模块，用于通过所述用户代理模块控制所述服务迁移的进程。

较佳地，所述用户代理模块，还用于接收用户终端上报的自身状态和向其他边缘节点迁移的请求，进行主动迁移和被动迁移的判断，并通过所述移动边缘节点管理模块向所述服务迁移系统管理核心模块获取服务迁移的令牌，并在获取所述令牌后，控制所述边缘用户服务模块进行服务迁移过程中的数据处理；

所述迁移系统层，用于在所述服务迁移为被动迁移时，判断所述服务迁移是否被允许；还用于发放服务迁移的令牌。

较佳地，所述边缘用户服务模块位于移动边缘节点上；所述节点服务层位于其所管理的一个或多个移动边缘节点中的任一移动边缘节点上或独立于所述移动边缘节点的物理实体上。

由上述技术方案可见，本申请中，在云计算中心设置若干中心控制节点进行迁移服务的锁定，在边缘节点上设置使用sidecar模式部署的用户接入层管理。用户终端向迁移前的第一边缘节点上报自身状态和向第二边缘节点的服务迁移请求，当确定允许进行服务迁移后，中心控制节点锁定相应的服务迁移，拒绝用户终端相同方向上其他服务的迁移请求；第一边缘节点中断要迁移的服务，并将该服务的迁移数据发送给第二边缘节点。通过上述方式，一方面通过中心控制节点进行迁移服务锁定，保证迁移过程中数据的一致性；另一方面在边缘节点上使用sidecar模式部署的用户接入层管理，实现服务迁移的服务中断、数据打包传输和服务恢复的处理，以完成具体服务迁移处理。

附图说明

图1为本申请中边缘计算服务系统的基本结构示意图；

图2为本申请中迁移方法的流程示意图；

图3为服务迁移系统的优选实现模块图示例；

图4为在图3系统中服务迁移方法的时序图。

具体实施方式

为了使本申请的目的、技术手段和优点更加清楚明白，以下结合附图对本申请做进一步详细说明。

本申请提出一种新的边缘计算服务系统，本系统针对移动边缘计算下服务迁移的问题进行分析，实现了服务分层架构和链式迁移模式，在设计上采取容器部署方案结合单节点服务的链式拆分作为真实环境下的运行时环境，充分利用容器的特性满足本系统的分层设计。在多节点服务迁移的服务发现、需求感知、服务链维持、迁移判定算法等系统层面，依托于底层链式服务上构建了迁移系统采取包括sidecar式服务代理、分布式系统信息获取、分布式服务链跟踪等能力以解决服务如何保存其自身运行时状态并在目的节点进行数据传输和恢复的需求，同时也满足边缘计算和服务迁移的多样化、针对化情景需求。

为实现用户在边缘节点上的高效服务迁移，设计分层架构的服务迁移系统来应对服务迁移任务需求，如图1所示，该系统包括用户接入层、节点服务层和迁移系统层。其中，用户接入层，用于与用户终端交互，使用sidecar模式实现用户接入层管理；还用于获取服务迁移的目的边缘节点的地址，并将当前用户接入的物理节点地址更新给所述用户终端。节点服务层，用于为用户终端提供移动边缘节点的计算服务，还用于控制和管理移动边缘节点，控制移动边缘节点间的服务迁移进程。迁移系统层，用于进行迁移服务的锁定，保证同一用户在同一时刻的单一方向上仅允许一个服务进行迁移；还用于对移动边缘节点间的服务迁移进行管理和记录。更详细地，可以在边缘节点上设置用户接入层，使用sidecar模式部署对应的用户代理管理，以适应边缘节点高异构性特点、要求任务部署的便捷控制和对于底层链式迁移的管理需要；同时，针对数量庞大的用户服务和能力需求，在云计算中心设置若干中心控制节点(用于实现迁移系统层)进行迁移服务的锁定，保证同一用户在同一时刻的单一方向上仅允许一个服务进行迁移，从而实现对边缘节点的服务层管理，保证迁移中的一致性问题和避免由于用户移动引起的服务迁移混乱问题。在此基础上优选地，本系统还可以在边缘节点服务层管理上，采用迁移阈值算法来进行服务迁移的许可判定，从而与迁移服务锁定的方式一起构成服务迁移许可模式。同时由于系统高可用、高扩展、操作模式跨平台和系统功能高复用性的需求，系统采取微服务的设计理念和解耦合思想增设了最上层的系统层，包括注册中心、配置中心、消息总线和服务链跟踪监控模块来支持用户的移动性管理，该系统层可以设置在中心控制节点上。

在上述服务迁移系统架构的基础上，来实现边缘计算服务的迁移方法。图2为本申请中迁移方法的流程示意图，如图2所示，该方法包括：

步骤201，迁移前的第一边缘节点接收用户终端上报的自身状态和向第二边缘节点的服务迁移请求。

假定用户终端希望将某服务从第一边缘节点迁移到第二边缘节点。那么，用户终端向第一边缘节点上报自身状态和服务迁移请求，第一边缘节点接收用户终端上报的用户终端状态和服务迁移请求。

另外，本申请中在边缘节点上设置使用sidecar模式部署的用户接入层管理。具体地，系统底层设计是使用Docker等无状态容器技术进行服务部署的，对于第一边缘节点上的用户其他服务是无侵入的，用户接入层单独与用户的各项请求沟通。从技术实现上来说运行是完全隔离的，从代码逻辑和系统部署上来说对用户服务是无侵入的，因此称之为sidecar模式部署。

步骤202，当确定允许进行服务迁移后，第一边缘节点获取第二边缘节点的地址发送给用户终端，中心控制节点锁定相应服务的服务迁移，拒绝服务迁移过程中用户终端在相同方向上其他服务的迁移请求。

本申请中，服务迁移系统作为一个分布式系统，在数据一致性管理上仍然采取分布式一致性理论来保证迁移数据的安全，由于用户的迁移是单向的，因此对服务迁移中的一致性问题的考量将纳入系统容错处理的范畴。本申请中主要采取锁式控制来保证服务迁移中的数据一致性问题，具体地，在确定允许进行相应服务的迁移后，第一边缘节点获取第二边缘节点的地址，然后第一边缘节点向中心控制节点上报准备进行的服务迁移，中心控制节点将相应服务的迁移处理进行锁定，在该服务迁移过程中不再允许该用户终端在相同方向上进行其他服务的迁移。

更详细地，在中心控制节点上进行的锁定处理的实现可以采用如下伪代码给出的迁移竞态锁管理算法：

迁移任务锁竞态管理算法

输入：用户码，迁移任务号

输出：空输出型，过程执行了用户的单向迁移管理

1 激活用户迁移锁管理函数，并输入用户码、迁移任务号；

2 远程服务调用验证用户身份；

3 本地缓存池获取用户身份信息；

4 若信息验证为空则返回并全局失败处理；

5 否则用户任务池加入任务信息；

6 分配线程并且工厂产生任务实体；

7 循环进入点：

使用用户码和迁移任务号校验是否可获取对应任务锁

8 若成功获取任务锁则

若迁移任务信息校验成功则

9 线程池发起远程调用或异步任务；

10 更新用户令牌；

否则拒绝任务并跳出循环

11 返回循环进入点

12 清除任务信息；

13 结束任务；

在上述伪代码中，用户号用于标记用户终端，迁移任务号用于标记本次进行的服务迁移。通过上述任务锁静态管理算法，能够上锁某一迁移的服务，拒绝该用户终端相同方向上的其他服务迁移请求。具体实现时可以使用Java技术上的锁处理，以验证的形式锁定正在进行迁移处理的任务号和用户号。

步骤203，第一边缘节点中断要迁移的服务，并将该服务的迁移数据发送给第二边缘节点，用于第二边缘节点恢复中断的服务。

执行服务迁移的操作，第一边缘节点中断服务，将迁移数据打包发送给第二边缘节点，第二边缘节点接收迁移数据，并在用户向第二边缘节点请求服务时恢复中断的服务。

更详细地，第一边缘节点可以调度底层系统进行终止状态、打包数据的任务。打包完成后将数据发送给第二边缘节点，并将结果日志打点记录到中心控制节点当中，此外，第一边缘节点也会对本地以用户代理为哈希键值的数据缓存和内存状态进行清除。用户凭借步骤202中获取的第二边缘节点的地址即可再次接入服务迁移系统获取服务，至此一次完整的服务迁移过程完成。

至此，本申请中最基本的服务迁移方法流程结束。通过上述处理，能够有效实现服务迁移，并保持迁移过程中的数据一致性。

另外，为了更好地减小迁移时延，本系统构建用户的迁移过程可以分为两种方式：主动迁移和被动迁移。其中，类似火车、公交等上报轨迹的边缘节点计算用户，这类用户在节点间迁移的过程时，路径上经过的几个节点顺序是固定的，这类服务迁移称为主动迁移；对于其他不可预知迁移轨迹的服务迁移过程，称为被动迁移。对应主动迁移和被动迁移，步骤202中确定是否允许进行迁移的处理以及具体的迁移的过程可以是不同的，从而能够进一步降低迁移时延。

具体地，对于主动迁移的服务，用户终端预先保存用户轨迹，并将服务迁移时需要迁移的数据中无状态层的数据(例如基础资源层和静态资源层的数据)预先部署在用户轨迹的边缘节点上；在确定允许迁移后需要进行数据迁移时，仅将状态层(例如实例应用信息层)的迁移数据发送给第二边缘节点，这样，将无状态层的迁移数据预先部署，迁移过程中仅迁移部分状态层的迁移数据，大大降低了服务迁移过程中数据迁移的传输时延，从而降低整个迁移时延。在具体实现时，可以将用户轨迹上的所有节点都进行预部属，或者，也可以在设定的节点(例如用户轨迹上当前节点之后的N个节点)上进行预部署。一般地，预部署可以保证在运行路径上后续的至少两个以上的节点得到启动。

被动迁移是指个体用户在边缘节点之间的边界进行转移从而引起服务迁移过程，对应个人用户在商场、街道、商圈等区域上的服务节点边界所进行迁移时的场景。这类迁移会产生诸如“乒乓迁移”(即用户在两个边缘节点或几个边缘节点之间反复迁移，造成迁移过程被反复拉起的问题)、“宕机迁移”(即用户在边缘节点边界上进行迁移的过程中，预部署资源被持续占用但未发生迁移过程，导致服务节点堆积过多计算资源浪费)的问题。针对这些问题，优选地，本系统主要在中心控制节点设计了令牌工厂模式来获取用户的迁移许可，其内部主要根据服务相关的计算参数来判断是否允许进行相应的服务迁移。如果允许进行服务迁移，则通过步骤202进行服务迁移上锁，并启动服务迁移过程；如果不允许，则可以保证服务的计算由其他节点进行并转发至本节点而不触发迁移，避免服务的迁移问题影响服务节点工作效率。其中，用来判断是否允许进行服务迁移的参数可以包含短时间的迁移次数、节点压力、任务持续时间和/或迁移进度等。其中，偏移进度参数是指：请求迁移的服务当前的服务进度。更详细地，用户的服务可能存在若干子服务阶段，请求迁移时当前服务可能正处于某个子服务阶段，那么偏移进度就是指请求迁移的服务当前所处的子服务阶段；一般地，将由多个子服务构成的一个完整服务用服务链表示，利用offset表示当前服务在其服务链上运行到第几个子服务，本申请中的偏移进度就可以用offset来表示。对于上述用来判断是否允许进行服务迁移的各个参数，可以进行加权求和再与迁移阈值进行比较，若高于迁移阈值，则可以允许进行迁移，否则不允许迁移。下面给出一种伪代码实现的服务迁移许可算法：

服务迁移许可算法

输入：用户码，节点信息值

输出：用户令牌

1 激活服务迁移许可算法，并输入用户码，节点信息值，调度许可模式码；

2 进行黑白名单检测：

3 若用户处于系统黑名单则系统拒绝服务并进入后置处理

4 否则若用户处于系统优先名单则进入准许流程

5 对节点进行探活；

6 若节点失活则进行节点异常处理；

7 否则获取迁移模式配置；

8 按照迁移配置循环获取计算参数：

9 获取公式的参数列表；

10 配置中心获取阈值；

11 循环进入点:

12 若参数值处于正确范围且节点存活：

13 则循环计算K值，参数权重乘以参数值；

14 返回循环进入点

15 若用户令牌大于K值则发放令牌；

16 结束任务；

上述伪代码中的用户令牌与迁移任务锁竞态管理代码中的更新的用户令牌相同。为了对用户进行的服务迁移次数进行计数，在迁移任务锁竞态管理代码中通过更新用户令牌(更新通常为自加的操作)来实现，当然，为了记录可以将更新后的用户令牌保存在设定位置上，然后将迁移任务锁竞态管理代码中更新的用户令牌进行销毁，以节省系统资源。

结合上述主动迁移和被动迁移的处理，对于步骤202判断是否允许进行服务迁移的处理可以优选总结为如下处理进行：第一边缘节点根据接收的用户终端的自身状态和服务迁移请求，判断请求的服务迁移是主动迁移还是被动迁移；若是主动迁移，则确定允许进行该服务迁移，并获取第二边缘节点的地址发送给用户终端；若是被动迁移，第一边缘节点向中心控制节点请求迁移令牌，中心控制节点判断是否允许进行该服务迁移，若允许，则解析出第二边缘节点的地址发送给第一边缘节点，若不允许，则通知第一边缘节点拒绝相应的服务迁移。

更详细地，对于被动迁移，中心控制节点判断是否允许进行服务迁移的处理可以包括：当请求服务迁移的用户未包含在系统黑名单、且第二边缘节点处于激活状态下，则获取迁移模式配置，按照迁移模式配置获取计算参数的取值，根据各个计算参数的取值及其对应的权重计算用户令牌值，若用户令牌值高于令牌阈值，则判定允许进行服务迁移，否则，拒绝相应的服务迁移。

当确定不允许进行服务迁移时，也可以启动请求转发机制，在用户终端向第二边缘节点请求服务时，第二边缘节点将触发第一边缘服务节点进行相应服务的处理，并将第一边缘服务节点发来的服务处理结果转发给用户终端。这种处理尤其适用于5G框架下空口切换过程的处理。在5G框架下，锚点是用户标定自己服务连接对象的唯一标识，当用户终端的空口由第一边缘节点切换到第二边缘节点后，第二边缘节点就成为用户终端的锚点，由于锚点已经由第一边缘节点切换到第二边缘节点上，因此引起了链路重定向过程。但是由于第二边缘节点的节点压力、迁移频率等因素中心控制节点可能拒绝将服务迁移到第二边缘节点时，这种情况下，当用户终端向第二边缘节点请求进行服务处理时，由于前面描述的请求转发机制已经启动，因此第二边缘节点会将服务请求发送给第一边缘节点，由第一边缘节点进行相应服务的处理，在服务处理结束后，第一边缘节点将服务处理结果发送给第二边缘节点，再由第二边缘节点将服务处理结果发送给用户终端。这里关于第二边缘节点向第一边缘节点请求服务并向用户终端反馈结果的处理可以是由sidecar模式部署的用户代理完成的。

上述即为本申请中边缘服务系统以及在该系统中实现的边缘服务迁移方法的具体实现。

对于边缘服务系统，在系统的具体软件实现上，可以通过设计三个功能性子系统来完成：负责用户接入与服务支持的用户子系统、负责管控迁移与提供核心服务的迁移子系统和负责跟踪服务链与计划任务下发的消息子系统。同时，注册中心和配置中心也可以通过集成的方式提供给所有接入的边缘节点使用，系统按照微服务的组织形式和接口约定实现了远程服务调用、接口缓存/本地热备/数据落表的三级数据持久化支持以及异步消息的传递，能够完整地实现所需要的服务迁移功能。

图3给出一个服务迁移系统的优选实现模块图示例。在图3中，图1的用户接入层位于图3的移动边缘节点实体中，图1的节点服务层位于图3的移动边缘节点管理模块中，移动边缘节点管理模块在具体实现时可以位于移动边缘节点实体中，但是二者并不是一对一的关系，移动边缘节点管理模块可以服务和控制一个或多个移动边缘节点，并位于其服务的某个移动边缘节点中。也就是说，移动边缘节点管理模块位于移动边缘节点中，但是并不是每个移动边缘节点都包括移动边缘节点管理模块。当然，移动边缘节点管理模块也可以位于一个独立于移动边缘节点的物理实体中。以图3的服务迁移系统的构成为例，通过图4所示的具体时序图给出本申请中服务迁移方法的完整示例过程。

如图3和图4所示，一个完整的服务迁移的时序图是由多个不同的模块共同调度完成的，用户终端首先向第一边缘节点的用户代理模块上报自身状态，用户代理模块内用户信息代理模块的迁移管理功能接收用户信息，对用户的主动迁移(计划任务调用)和被动迁移(自身移动导致切换)进行判断。当判断为主动迁移时，确定允许进行迁移；当判断为被动迁移时，向上层API获取使用迁移许可算法计算得到的令牌。具体通过上层API获取令牌的过程包括：用户代理模块的服务链路模块向移动边缘节点管理模块中的服务迁移平台管理模块传输信号，再发送给服务迁移系统管理核心模块，服务迁移系统管理核心模块进行是否允许迁移的判断，并通过服务迁移平台管理模块向用户代理模块反馈令牌。接下来，无论是主动迁移还是被动迁移，用户代理模块中的注册中心模块都向移动边缘节点管理模块中的服务发现模块获取第二边缘节点的地址信息，也就是迁移后节点计算结果的获取地址，用户代理模块将用户接入的物理节点地址更新给用户终端。这里，如果服务迁移系统管理核心模块判断拒绝服务迁移，则启动请求转发机制，如前所述，在空口切换到第二边缘节点后，计算处理仍然由第一边缘节点完成，再将计算结果通过第二边缘节点返回用户。然后，第一边缘节点的用户代理模块和第二边缘节点的用户代理模块进行沟通协商确定允许进行服务迁移后，第一边缘节点的用户代理模块中断服务，迁移打包，通过数据访问接口进行服务打点和迁移准备，两个用户代理模块间通过系统虚拟资源及设施管理器进行迁移数据发送，数据发送结束后，第一边缘节点将终止状态和打包数据的结果日志打点记录到系统的数据模组当中，进行迁移数据清理和日志发送。用户终端根据更新的地址，第二边缘节点的用户代理模块进行迁移恢复。此外，第一边缘节点的用户代理模块也会对本地以相应用户的用户代理为哈希键值的数据缓存和内存状态进行清除。同时，用户代理模块向中心控制节点请求锁定服务迁移，中心控制节点进行服务迁移锁定后，将回执交付用户代理模块。异步任务完成后，用户凭借新的服务结果下发地址向第二边缘节点的用户代理模块获取服务，第一节点的服务迁移平台管理模块将异步任务中打包好的数据发送到第二边缘节点的服务迁移平台管理模块；回执信息在服务代理模块的迁移恢复流程结束后回传，至此一次完整的服务迁移过程完成。

这里，用户凭借的新的结果下发地址指的是系统指定给用户获取计算结果的API地址，这个地址可以为迁移目的节点的地址也可以不是，它对于用户是透明的。

其中，节点地址指的是系统自己清楚服务在哪个节点上，各节点通过服务发现确定自己要访问彼此的服务(比如迁移)如何进行，这个是系统内部确定下来的事实。从安全性和迁移无感知的角度上讲用户都是无权获知这个信息的。

对于被动迁移，步骤201中用户上报向第二边缘节点的迁移请求，其中请求中包括目的节点地址，该目的节点地址实际上是用户的代理，也即“用户接入层”替用户翻译并获取了这个信息上传给系统，而非用户自己就知道自己要去哪个节点，并且清楚它的ip。对于主动迁移来说系统会把用户上传的节点代号转译为精确的ip再进行处理。

通过上述图3和图4给出的示例可见，服务迁移系统采取微服务式的、分层式的系统架构建设在异构适应性、模块解耦、接口规范、分布式检错和容错以及服务通信管理等方面上都能很好地进行能力支持。整个服务迁移系统依托于底层的容器有状态迁移和服务链式计算技术，在选取了底层迁移方式并显著降低了迁移时延的同时，迁移时延的另一个重要影响因素便是系统的处理响应时间。系统在用户进行迁移时管理服务迁移的整个生命周期，并且针对不同网元的功能进行系统级的实现，来应对海量的用户迁移需求并采取了一种适宜边缘架构的解耦合的系统设计方案。

由上述本申请中服务迁移系统和服务迁移方法的具体实现可见，本申请提出并实现了边缘系统的三层架构，解决了多节点之间服务如何进行相互发现、通信，在定位用户服务所在位置后实现服务迁移的问题。同时提出服务令牌模式和迁移许可算法的服务迁移方案，成功解决了迁移过程中如时延瓶颈、服务紊乱和乒乓迁移等问题。此外，提供了微服务思想的边缘系统架构和服务迁移方案，聚焦并解决了微服务模块化、控制面灵活部署等问题，使用具体的微服务技术展示了可控的服务支持、部署和迁移在边缘网络下的表现，实现了高可用、高性能的服务迁移架构。基于上述系统实现的服务迁移方法，能够有效实现边缘节点间的服务迁移，大大降低迁移时延，并保证服务迁移过程中的数据一致性。

对于如何有针对性地提升服务迁移的连续性是解决用户在边缘节点上服务跟随的重点，针对边缘复杂的环境会有不同的服务架构，无论利用打通边缘协议和组网的统一架构进行传输的方式，还是利用虚拟化技术的封闭安全性构建不同层的应用数据分离架构方式，都是可行的探究方案。本申请系统针对二者的优点进行了集成并且通过方案一定程度上规避了复杂的架构能力要求，力争设计合理的边缘服务迁移系统并加以实现。

此外，服务迁移系统作为适应边缘计算环境的分布式架构实现，不仅在底层系统的容器编排上是分布式的且需要满足随着5G技术快速发展的应用模块化需求，因此解耦上层的公用服务、融合消息通知中间件、加入分布式数据存储技术和使用远程接口调用就成为系统的主要设计理念。这和微服务架构的开发思想不谋而合，与微服务架构相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序，这种形式更适应于传统的互联网C/S开发架构的需求。即便后期为了大型网站架构的需求加入了分布式系统(包括分布式存储、分布式运维、分布式前后端形式等)，但其本质仍然适应于互联网技术模式。微服务的核心是服务治理和服务划分，这样的开发模式更适应于建设面对海量用户的多节点接入系统，实际上使得互联网产业模式逐渐靠向传统制造业和工业互联网的需求靠拢。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (8)

1.一种边缘计算服务的迁移方法，其特征在于，在云计算中心设置若干中心控制节点进行迁移服务的锁定，在边缘节点上设置使用sidecar模式部署的用户接入层管理，所述方法包括：

迁移前的第一边缘节点接收用户终端上报的自身状态和向第二边缘节点的服务迁移请求，当确定允许进行服务迁移后，所述第一边缘节点获取第二边缘节点的地址，所述中心控制节点锁定所述服务迁移，拒绝服务迁移过程中所述用户终端相同方向上其他服务的迁移请求；

所述第一边缘节点中断要迁移的服务，并将该服务的迁移数据发送给所述第二边缘节点，用于所述第二边缘节点在接收到所述用户终端的服务请求后恢复中断的服务；

其中，所述中心控制节点还用于进行迁移服务的授权；

确定是否允许进行服务迁移的方式包括：所述第一边缘节点根据所述自身状态和所述服务迁移请求，判断请求的服务迁移是主动迁移还是被动迁移；若是主动迁移，则确定允许进行所述服务迁移；若是被动迁移，所述第一边缘节点向所述中心控制节点请求迁移令牌，所述中心控制节点判断是否允许进行所述服务迁移，若允许，则解析出所述第二边缘节点的地址发送给所述第一边缘节点，若不允许，则通知所述第一边缘节点拒绝所述服务迁移。

2.根据权利要求1所述的方法，其特征在于，在通知所述第一边缘节点拒绝所述服务迁移后，该方法进一步包括：当用户终端的空口切换到第二边缘节点后，对于所述服务的服务请求，所述第二边缘节点向所述第一边缘节点请求进行服务处理，并将所述第一边缘节点反馈给所述第二边缘节点的服务处理结果发送给所述用户终端。

3.根据权利要求1所述的方法，其特征在于，所述中心控制节点判断是否允许进行所述服务迁移包括：

当请求服务迁移的用户未包含在系统黑名单、且所述第二边缘节点处于激活状态下，则获取迁移模式配置，按照所述迁移模式配置获取计算参数的取值，根据各个计算参数的取值及其对应的权重计算用户令牌值，若所述用户令牌值高于令牌阈值，则判定允许进行所述服务迁移，否则，拒绝所述服务迁移。

4.根据权利要求3所述的方法，其特征在于，所述计算参数包括：设定时间内的迁移次数、所述第二边缘节点的节点压力、迁移服务的任务持续时间和/或偏移进度。

5.根据权利要求1所述的方法，其特征在于，该方法进一步包括：

对于上报轨迹的所述用户终端，预先保存用户轨迹，并将服务迁移时需要迁移的基础资源层和静态资源层的数据预先部署在用户轨迹的设定边缘节点上；

当所述服务迁移为主动迁移时，所述将该服务的迁移数据发送给所述第二边缘节点包括：将实例应用信息层的迁移数据发送给所述第二边缘节点。

6.一种边缘计算服务迁移系统，其特征在于，包括：用户接入层、节点服务层、迁移系统层和移动边缘节点管理模块；

所述用户接入层，用于与用户终端交互，使用sidecar模式实现用户接入层管理；还用于为用户终端提供移动边缘节点的计算服务，进行服务迁移的实际操作，获取服务迁移的目的边缘节点的地址，并将当前用户接入的物理节点地址更新给所述用户终端；

所述节点服务层，用于控制和管理一个或多个移动边缘节点，控制和管理移动边缘节点间的服务迁移进程；

所述迁移系统层，用于进行迁移服务的锁定，保证同一用户在同一时刻的单一方向上仅允许一个服务进行迁移；还用于对移动边缘节点间的服务迁移进行管理和记录；

其中，所述用户接入层包括用户代理模块和边缘用户服务模块，所述系统进一步包括；

所述用户代理模块，用于与用户终端交互，使用sidecar模式实现用户接入层管理；还用于与所述移动边缘节点管理模块进行交互，实现所述移动边缘节点管理模块对边缘节点的服务管理和迁移服务的控制，并控制所述边缘用户服务模块实现服务迁移的数据处理；还用于获取服务迁移的目的边缘节点的地址，并将当前用户接入的物理节点地址更新给所述用户终端；

所述边缘用户服务模块，用于提供边缘计算服务，并实现服务迁移过程中的数据处理；

所述移动边缘节点管理模块，用于通过所述用户代理模块控制所述服务迁移的进程。

7.根据权利要求6所述的系统，其特征在于，所述系统进一步包括服务迁移系统管理核心模块；

所述用户代理模块，还用于接收用户终端上报的自身状态和向其他边缘节点迁移的请求，进行主动迁移和被动迁移的判断，并通过所述移动边缘节点管理模块向所述服务迁移系统管理核心模块获取服务迁移的令牌，并在获取所述令牌后，控制所述边缘用户服务模块进行服务迁移过程中的数据处理；

所述迁移系统层，用于在所述服务迁移为被动迁移时，判断所述服务迁移是否被允许；还用于发放服务迁移的令牌。

8.根据权利要求6或7所述的系统，其特征在于，所述边缘用户服务模块位于移动边缘节点上；所述节点服务层位于其所管理的一个或多个移动边缘节点中的任一移动边缘节点上或独立于所述移动边缘节点的物理实体上。

Images