服务处理方法、装置、电子设备、存储介质及程序产品与流程

1.本技术涉及计算机图形图像技术，尤其涉及一种服务处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品。


背景技术：

2.基于图形处理硬件的显示技术，扩展了感知环境以及获取信息的渠道，尤其是虚拟场景的显示技术，能够根据实际应用需求实现受控于用户或人工智能的虚拟对象之间的多样化的交互，具有各种典型的应用场景，例如在游戏等的虚拟场景中，能够模拟虚拟对象之间的真实的对战过程。
3.近年来随着游戏内容更新速度加快，往往也会给游戏服务(一种有状态服务)功能带来各种问题。相关技术中，通过停机更新以实现游戏服务更新，这种方案由于停机更新期间所有游戏服务均不可用，严重影响服务的应用流畅性。


技术实现要素：

4.本技术实施例提供一种服务处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品，能够实现在线更新有状态服务，提高服务的应用流畅性。
5.本技术实施例的技术方案是这样实现的：
6.本技术实施例提供一种服务处理方法，包括：
7.获取用于更新的第一有状态服务；
8.基于所述第一有状态服务进行有状态服务的注册处理，得到第二有状态服务，所述第二有状态服务与所述第一有状态服务对应；
9.在所述第一有状态服务运行过程中，将所述第一有状态服务的协程迁移至所述第二有状态服务中，得到迁移后的所述第二有状态服务；
10.通过迁移后的所述第二有状态服务的协程执行对应的协程服务请求。
11.本技术实施例提供一种服务处理装置，包括：
12.获取模块，用于获取用于更新的第一有状态服务；
13.注册模块，用于基于所述第一有状态服务进行有状态服务的注册处理，得到第二有状态服务，所述第二有状态服务与所述第一有状态服务对应；
14.迁移模块，用于在所述第一有状态服务运行过程中，将所述第一有状态服务的协程迁移至所述第二有状态服务中，得到迁移后的所述第二有状态服务；
15.处理模块，用于通过迁移后的所述第二有状态服务的协程执行对应的协程服务请求。
16.上述技术方案中，所述注册模块还用于基于与所述第一有状态服务对应的待注册有状态服务调用调度节点；
17.通过所述调度节点对所述待注册有状态服务进行注册验证处理；
18.当所述注册验证处理通过时，对所述待注册有状态服务进行注册处理，得到所述
第二有状态服务。
19.上述技术方案中，所述注册模块还用于基于与所述第一有状态服务对应的待注册有状态服务，确定所述待注册有状态服务的文件锁；
20.基于所述文件锁对应的共享内存消息通道调用所述调度节点。
21.上述技术方案中，所述注册模块还用于基于所述第一有状态服务，确定与所述第一有状态服务对应的多个候选文件锁；
22.基于与所述第一有状态服务对应的待注册有状态服务进行所述候选文件锁的占用处理；
23.当所述候选文件锁未被占用时，将所述候选文件锁作为所述待注册有状态服务的文件锁，并在所述文件锁中写入所述待注册有状态服务的版本号。
24.上述技术方案中，所述注册模块还用于确定所述待注册有状态服务的注册消息，所述注册消息包括所述待注册有状态服务的版本号；
25.通过所述文件锁对应的共享内存消息通道发送所述注册消息至所述调度节点。
26.上述技术方案中，所述注册模块还用于当所述待注册有状态服务的版本号大于已注册有状态服务的版本号时，将所述待注册有状态服务注册至服务列表，得到所述第二有状态服务，并将所述第二有状态服务的状态设置为协程迁移中。
27.上述技术方案中，所述迁移模块还用于针对所述第一有状态服务中的任一协程执行以下处理：
28.将所述协程无损迁移至所述第二有状态服务中，得到迁移后的所述第二有状态服务中的新协程，所述新协程与所述协程一一对应；
29.当所述第一有状态服务中协程的数量为零时，将迁移后的所述第二有状态服务的状态设置为正常运行中，并将所述第一有状态服务的状态设置为不可用状态。
30.上述技术方案中，所述迁移模块还用于获取所述协程的任务队列中的至少一个服务请求；
31.基于所述协程对所述至少一个服务请求进行数据处理，得到所述服务请求的处理结果；
32.在所述第二有状态服务中创建对应所述协程的新协程，并通过所述新协程保存所述服务请求的处理结果。
33.上述技术方案中，所述迁移模块还用于当所述第一有状态服务接收到针对所述协程的迁移请求时，将所述第一有状态服务的所述协程的状态设置为无损退出中，并从所述第一有状态服务对应的共享内存消息通道中，获取所述协程的任务队列中的至少一个服务请求；
34.其中，所述迁移请求用于指示所述第一有状态服务进行协程迁移。
35.上述技术方案中，所述在所述第二有状态服务中创建对应所述协程的新协程之前，所述迁移模块还用于当所述协程的任务队列中不存在所述服务请求时，发送通知消息至所述第二有状态服务，所述通知消息携带所述服务请求的处理结果；
36.基于所述通知消息，确定将执行在所述第二有状态服务中创建对应所述协程的新协程的操作。
37.上述技术方案中，所述迁移模块还用于获取所述协程的状态数据，所述状态数据
包括虚拟场景的场景数据；
38.将所述状态数据保存至迁移后的所述第二有状态服务中的所述新协程。
39.上述技术方案中，所述处理模块还用于在所述第一有状态服务迁移过程中，将针对所述协程的新协程服务请求缓存至调度节点；
40.在所述第一有状态服务迁移完成后，迁移后的所述第二有状态服务从所述调度节点中获取所述新协程服务请求，并执行所述新协程服务请求。
41.上述技术方案中，所述将所述第一有状态服务的协程迁移至所述第二有状态服务中之前，所述迁移模块还用于确定所述协程服务请求的数量；
42.当所述协程服务请求的数量小于数量阈值时，确定将执行将所述第一有状态服务的协程迁移至所述第二有状态服务中的操作。
43.上述技术方案中，所述将所述第一有状态服务的协程迁移至所述第二有状态服务中之前，所述迁移模块还用于确定所述第一有状态服务运行过程中的网络质量；
44.当所述网络质量大于质量阈值时，确定将执行将所述第一有状态服务的协程迁移至所述第二有状态服务中的操作。
45.本技术实施例提供一种用于服务处理的电子设备，所述电子设备包括：
46.存储器，用于存储可执行指令；
47.处理器，用于执行所述存储器中存储的可执行指令时，实现本技术实施例提供的服务处理方法。
48.本技术实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本技术实施例提供的服务处理方法。
49.本技术实施例提供一种计算机程序产品，包括计算机程序或指令，其特征在于，所述计算机程序或指令被处理器执行时实现本技术实施例提供的服务处理方法。
50.本技术实施例具有以下有益效果：
51.通过注册第二有状态服务，并在第一有状态服务运行过程中，将第一有状态服务的协程迁移至第二有状态服务中，以实现在线更新有状态服务的功能，提高服务的应用流畅性，并通过协程迁移的方式提高服务更新的效率，从而节约了相关的通信资源和计算资源。
附图说明
52.图1a-图1b是本技术实施例提供的服务处理方法的应用模式示意图；
53.图2是本技术实施例提供的用于服务处理的电子设备的结构示意图；
54.图3-图5是本技术实施例提供的服务处理方法的流程示意图；
55.图6是本技术实施例提供的服务处理方法的架构示意图；
56.图7是本技术实施例提供的服务处理方法的流程示意图；
57.图8是本技术实施例提供的服务注册的流程示意图；
58.图9是本技术实施例提供的面向玩家协程无损迁移的流程示意图。
具体实施方式
59.为了使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术作进
一步地详细描述，所描述的实施例不应视为对本技术的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本技术保护的范围。
60.在以下的描述中，所涉及的术语“第一\第二”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
61.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
62.对本技术实施例进行进一步详细说明之前，对本技术实施例中涉及的名词和术语进行说明，本技术实施例中涉及的名词和术语适用于如下的解释。
63.1)响应于：用于表示所执行的操作所依赖的条件或者状态，当满足所依赖的条件或状态时，所执行的一个或多个操作可以是实时的，也可以具有设定的延迟；在没有特别说明的情况下，所执行的多个操作不存在执行先后顺序的限制。
64.2)客户端：终端中运行的用于提供各种服务的应用程序，例如视频播放客户端、游戏客户端等。
65.3)虚拟场景：游戏程序在终端上运行时显示(或提供)的虚拟游戏场景。该虚拟场景可以是对真实世界的仿真环境，也可以是半仿真半虚构的虚拟环境，还可以是纯虚构的虚拟环境。虚拟场景可以是二维虚拟场景、2.5维虚拟场景或者三维虚拟场景中的任意一种，本技术实施例对虚拟场景的维度不加以限定。例如，虚拟场景可以包括天空、陆地、海洋等，该陆地可以包括沙漠、城市等环境元素，用户可以控制虚拟对象在该虚拟场景中进行移动。
66.4)虚拟对象：虚拟场景中可以进行交互的各种人和物的形象，或在虚拟场景中的可活动对象。该可活动对象可以是虚拟人物、虚拟动物、动漫人物等，例如在虚拟场景中显示的人物、动物等。该虚拟对象可以是虚拟场景中的一个虚拟的用于代表用户的虚拟形象。虚拟场景中可以包括多个虚拟对象，每个虚拟对象在虚拟场景中具有自身的形状和体积，占据虚拟场景中的一部分空间。
67.5)场景数据：表示虚拟场景的特征数据，例如可以是虚拟场景中建造区域的面积、虚拟场景当前所处的建筑风格等；也可以包括虚拟建筑在虚拟场景中所处的位置、以及虚拟建筑的占地面积等。
68.6)服务：包括有状态服务和无状态服务，有状态服务和无状态服务是两种不同的服务架构，两者的不同之处在于对于服务状态的处理。服务状态是服务请求所需的数据，它可以是一个变量或者一个数据结构。无状态服务不会记录服务状态，不同请求之间也是没有任何关系；而有状态服务会记录服务状态，不同请求之间也是有关系的。有状态服务和无状态服务的判断依据为两个来自相同发起者的请求在服务器端是否具备上下文关系。
69.对于无状态服务，服务器端所能够处理的数据全部来自于请求所携带的信息，无状态服务对于客户端的单次请求的处理，不依赖于其他请求，处理一次请求的信息都包含在该请求里，例如通过储存在用户本地终端上的数据(cook ie)通过保存令牌(token)的方式传输请求数据。
70.对于有状态服务，服务器端会存储请求上下文相关的数据信息，先后的请求是可
以有关联的。例如，在网页(web)应用中，经常会使用时域(session)来维系登录用户的上下文信息，虽然超文本传输协议(http，hyper text tra nsfer protocol)是无状态的，但是借助session，可以使http服务转换为有状态服务。
71.7)协程(coroutine)：协程不是进程或线程，其执行过程更类似于子例程，或者说不带返回值的函数调用。协程是一种程序组件，例如合作式多任务、迭代器、无限列表和管道。相对子例程而言，协程更为灵活。需要说明的是，本技术实施例中的协程为golang协程(又称go协程或go协程)。
72.8)golang：又称go，是一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。go的语法接近c语言，但对于变量的声明有所不同。与c++相比，go并不包括如枚举、异常处理、继承、泛型、断言、虚函数等功能，但增加了切片(slice)型、并发、管道、垃圾回收、接口(interface)等特性的语言级支持。不同于java，go内嵌了关联数组(也称为哈希表(hashes)或字典(dictionaries))。
73.9)文件锁：又称文件续约锁，一种文件锁定机制，强制访问计算机文件只能由一个用户或在任何特定时间的过程，通过文件锁防止的恶意更新。
74.10)共享内存消息通道：多进程之间的通信通道，这种通道用于多进程间通信，实际上多个程序间也可以通过共享内存消息通道来传递信息。其中，共享内存(shared memory)指在多处理器的计算机系统中，可以被不同中央处理器(cpu)访问的大容量内存。
75.游戏有各种各样的有状态服务(又称有状态游戏服务)，有状态服务通过缓存玩家的状态数据，比如玩家数据库数据等，能有效减少对数据库的访问频率，提升服务器单体吞吐量。例如，大厅服务就是游戏中的一种有状态服务，玩家在游戏界面上参与活动、完成任务、升级英雄(一种虚拟对象)等功能绝大部分都由大厅服务提供。
76.近年来随着手游行业的蓬勃发展，为应对玩家对游戏内容消耗的速度过快问题，进一步吸引玩家以及保留玩家，需要游戏侧源源不断地更新游戏内容。另外，随着游戏内容更新速度加快，往往也会给游戏服务功能带来不稳定性，比如因自测不仔细导致功能出现异常，从而影响玩家体验等。因此，如何在不影响在线玩家体验的同时稳定地更新游戏内容，及遇到外网功能异常时能迅速更新修复，在实际游戏运营有着重要的价值，其中有状态服务的更新作为游戏服务的主要承载者，其在线更新技术一直是游戏后台设计中的重点以及难点。
77.相关技术中，通过停机更新，直接将所有的玩家踢线，从而进行服务更新，这种方式因为停机更新期间所有服务均不可用，严重影响玩家体验；采取灰度发布的方式，逐步对服务进行更新，但是需要处理一些兼容性的问题，比如新老版本同时存在的情况下某些业务逻辑的特殊处理，另外，更新过程需要一些冗余的灰度机器资源，并且灰度发布会比较耗时。
78.为了解决上述问题，本技术实施例提供一种服务处理方法、装置、电子设备、计算机可读存储介质及计算机程序产品，能够实现在线更新有状态服务，提高服务的应用流畅性。为便于更容易理解本技术实施例提供的服务处理方法，首先说明本技术实施例提供的服务处理方法的示例性实施场景，本技术实施例提供的服务处理方法中的虚拟场景(通过有状态服务实现)可以完全基于终端输出，或者基于终端和服务器协同输出。
79.在一些实施例中，虚拟场景可以是供游戏角色交互的环境，例如可以是供游戏角
色在虚拟场景中进行对战，通过控制游戏角色的行动可以在虚拟场景中进行双方互动，从而使用户能够在游戏的过程中舒缓生活压力。
80.在一个实施场景中，参见图1a，图1a是本技术实施例提供的服务处理方法的应用模式示意图，适用于一些完全依赖于终端400的图形处理硬件计算能力即可完成虚拟场景100的相关数据计算的应用模式，例如单机版/离线模式的游戏，通过智能手机、平板电脑和虚拟现实/增强现实设备等各种不同类型的终端400完成虚拟场景的输出。
81.作为示例，图形处理硬件的类型包括中央处理器(cpu，central processin g unit)和图形处理器(gpu，graphics processing unit)。
82.当形成虚拟场景100的视觉感知时，终端400通过图形计算硬件计算显示所需要的数据，并完成显示数据的加载、解析和渲染，在图形输出硬件输出能够对虚拟场景形成视觉感知的视频帧，例如，在智能手机的显示屏幕呈现二维的视频帧，或者，在增强现实/虚拟现实眼镜的镜片上投射实现三维显示效果的视频帧；此外，为了丰富感知效果，终端400还可以借助不同的硬件来形成听觉感知、触觉感知、运动感知和味觉感知的一种或多种。
83.作为示例，终端400上运行有客户端410(例如单机版的游戏应用)，在客户端410的运行过程中输出包括有角色扮演的虚拟场景(通过运行有状态服务(又称有状态游戏服务)实现，在有状态服务中对于每个玩家都会有一条协程用于处理玩家请求，即一条协程对应一个玩家)，虚拟场景可以是供游戏角色交互的环境，例如可以是用于供游戏角色进行对战的平原、街道、山谷等等；以第一人称视角显示虚拟场景100为例，在虚拟场景100中显示虚拟对象110，虚拟对象110可以是受用户(或称玩家)控制的游戏角色(对应有状态服务中的一条协程)，将响应于真实用户针对按钮(包括摇杆按钮、攻击按钮、防御按钮等)的操作而在虚拟场景中操作，例如当真实用户向左移动摇杆按钮时，虚拟对象将在虚拟场景中向左部移动，还可以保持原地静止、跳跃以及使用各种功能(如技能和道具)；虚拟对象110也可以是通过训练设置在虚拟场景对战中的人工智能(ai，artificial intelligence)；虚拟对象110还可以是设置在虚拟场景互动中的非用户角色(npc，non-player character)；虚拟对象110还可以是虚拟场景100中不可活动对象或者可活动对象。
84.举例来说，在有状态游戏服务运行的过程中，在虚拟场景100中显示虚拟对象110，玩家控制虚拟对象在虚拟场景中完成任务，但是有状态游戏服务有更新，通过本技术实施例的服务处理方法，注册新的有状态游戏服务，新的有状态服务与更新前的有状态服务对应，在有状态服务运行过程中，将有状态服务的协程迁移至新的有状态服务中，得到迁移后的新的有状态服务，通过迁移后的新的第二有状态服务的协程执行对应的协程服务请求，以通过迁移后的新的第二有状态服务在虚拟场景100中显示虚拟对象110，玩家控制虚拟对象在虚拟场景中完成任务。
85.在另一个实施场景中，参见图1b，图1b是本技术实施例提供的服务处理方法的应用模式示意图，应用于终端400和服务器200，适用于依赖于服务器200的计算能力完成虚拟场景计算、并在终端400输出虚拟场景的应用模式。
86.以形成虚拟场景100的视觉感知为例，服务器200进行虚拟场景相关显示数据(例如场景数据)的计算并通过网络300发送到终端400，终端400依赖于图形计算硬件完成计算显示数据的加载、解析和渲染，依赖于图形输出硬件输出虚拟场景以形成视觉感知，例如可以在智能手机的显示屏幕呈现二维的视频帧，或者，在增强现实/虚拟现实眼镜的镜片上投
射实现三维显示效果的视频帧；对于虚拟场景的形式的感知而言，可以理解，可以借助于终端400的相应硬件输出，例如使用麦克风形成听觉感知，使用振动器形成触觉感知等等。
87.作为示例，终端400上运行有客户端410(例如网络版的游戏应用)，通过连接服务器200(例如游戏服务器)与其他用户进行游戏互动，终端400输出客户端410的虚拟场景(通过运行有状态服务(又称有状态游戏服务)实现，在有状态服务中对于每个玩家都会有一条协程用于处理玩家请求，即一条协程对应一个玩家)，以第一人称视角显示虚拟场景100为例，在虚拟场景100中显示虚拟对象110，虚拟对象110可以是受用户(或称玩家)控制的游戏角色(对应有状态服务中的一条协程)，将响应于真实用户针对按钮(包括摇杆按钮、攻击按钮、防御按钮等)的操作而在虚拟场景中操作，例如当真实用户向左移动摇杆按钮时，虚拟对象将在虚拟场景中向左部移动，还可以保持原地静止、跳跃以及使用各种功能(如技能和道具)；虚拟对象110也可以是通过训练设置在虚拟场景对战中的人工智能(ai，artificial intelligence)；虚拟对象110还可以是设置在虚拟场景互动中的非用户角色(npc，non-player character)；虚拟对象110还可以是虚拟场景100中不可活动对象或者可活动对象。
88.举例来说，在有状态游戏服务运行的过程中，在虚拟场景100中显示虚拟对象110，玩家控制虚拟对象在虚拟场景中完成任务，但是有状态游戏服务有更新，通过本技术实施例的服务处理方法，注册新的有状态游戏服务，新的有状态服务与更新前的有状态服务对应，在有状态服务运行过程中，将有状态服务的协程迁移至新的有状态服务中，得到迁移后的新的有状态服务，通过迁移后的新的第二有状态服务的协程执行对应的协程服务请求，以通过迁移后的新的第二有状态服务在虚拟场景100中显示虚拟对象110，玩家控制虚拟对象在虚拟场景中完成任务。
89.在一些实施例中，终端400可以通过运行计算机程序来实现本技术实施例提供的服务处理方法，例如，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(native)应用程序(app，application)，即需要在操作系统中安装才能运行的程序，例如换装游戏app(即上述的客户端410)；也可以是小程序，即只需要下载到浏览器环境中就可以运行的程序；还可以是能够嵌入至任意app中的游戏小程序。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。
90.以计算机程序为应用程序为例，在实际实施时，终端400安装和运行有支持虚拟场景的应用程序。该应用程序可以是第一人称射击游戏(fps，first-per son shooting game)、第三人称射击游戏、虚拟现实应用程序、三维地图程序或者多人枪战类生存游戏中的任意一种。用户使用终端400操作位于虚拟场景中的虚拟对象进行活动，该活动包括但不限于：调整身体姿态、爬行、步行、奔跑、骑行、跳跃、驾驶、拾取、射击、攻击、投掷、建造虚拟建筑中的至少一种。示意性的，该虚拟对象可以是虚拟人物，比如仿真人物角色或动漫人物角色等。
91.在一些实施例中，本技术实施例还可以借助于云技术(cloud technology)实现，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。
92.云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、以及应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源。
93.示例的，图1b中的服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。终端400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端400以及服务器200可以通过有线或无线通信方式进行直接或间接地连接，本技术实施例中不做限制。
94.参见图2，图2是本技术实施例提供的用于服务处理的电子设备的结构示意图，以电子设备为服务器200为例进行说明，图2所示的电子设备400包括：至少一个处理器420、存储器460、至少一个网络接口430和用户接口440。终端400中的各个组件通过总线系统450耦合在一起。可理解，总线系统450用于实现这些组件之间的连接通信。总线系统450除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统450。
95.处理器420可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(dsp，digital signal processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
96.用户接口440包括使得能够呈现媒体内容的一个或多个输出装置441，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口440还包括一个或多个输入装置442，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
97.存储器460可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器460可选地包括在物理位置上远离处理器420的一个或多个存储设备。
98.存储器460包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(rom，read only me mory)，易失性存储器可以是随机存取存储器(ram，random access memor y)。本技术实施例描述的存储器460旨在包括任意适合类型的存储器。
99.在一些实施例中，存储器460能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
100.操作系统461，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
101.网络通信模块462，用于经由一个或多个(有线或无线)网络接口430到达其他计算设备，示例性的网络接口430包括：蓝牙、无线相容性认证(wifi)、和通用串行总线(usb，universal serial bus)等；
102.呈现模块463，用于经由一个或多个与用户接口440相关联的输出装置441(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；
103.输入处理模块464，用于对一个或多个来自一个或多个输入装置442之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
104.在一些实施例中，本技术实施例提供的服务处理装置可以采用软件方式实现，图2示出了存储在存储器460中的服务处理装置465，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块4651、注册模块4652、迁移模块4653、处理模块4654，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。
105.在另一些实施例中，本技术实施例提供的服务处理装置可以采用硬件方式实现，作为示例，本技术实施例提供的服务处理装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本技术实施例提供的服务处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(asic，application specific integrated circuit)、dsp、可编程逻辑器件(pld，progra mmable logic device)、复杂可编程逻辑器件(cpld，complex programmabl e logic device)、现场可编程门阵列(fpga，field-programmable gate array)或其他电子元件。
106.下面将结合附图对本技术实施例提供的服务处理方法进行具体说明。本技术实施例提供的服务处理方法可以由图1a中的终端400单独执行，也可以由图1b中的终端400和服务器200协同执行。
107.下面，以由图1a中的终端400单独执行本技术实施例提供的服务处理方法为例进行说明。参见图3，图3是本技术实施例提供的服务处理方法的流程示意图，将结合图3示出的步骤进行说明。
108.需要说明的是，图3示出的方法可以由终端400上运行的各种形式的计算机程序执行，并不局限于上述的客户端410，还可以是上文的操作系统461、软件模块和脚本，因此客户端不应视为对本技术实施例的限定。
109.在步骤101中，获取用于更新的第一有状态服务。
110.例如，为了吸引玩家以及保留玩家，需要游戏侧源源不断地更新游戏内容。另外，随着游戏内容更新速度加快，需要不断更新有状态服务。当游戏中当前的有状态服务的功能需要更新时，获取当前的有状态服务，并作为用于更新的第一有状态服务(即老有状态服务)。需要说明的是，不同有状态服务的服务功能不同，例如游戏中的大厅服务，用于提供玩家在游戏界面上参与活动、完成任务、升级英雄等功能；游戏中的好友服务，用于提供聊天等沟通功能。
111.在步骤102中，基于第一有状态服务进行有状态服务的注册处理，得到第二有状态服务，第二有状态服务与第一有状态服务对应。
112.例如，在确定了用于更新的第一有状态服务后，需要注册一个与第一有状态服务对应的第二有状态服务，即第一有状态服务为需要被更新替换的老有状态服务，第二有状态服务为更新后产生的新有状态服务。通过注册第二有状态服务后，以进行后续有状态服务中的协程迁移，以实现在线更新有状态服务的功能，无需进行停机更新，以提高服务的应用流畅性。
113.参见图4，图4是本技术实施例提供的服务处理方法的流程示意图，图4示出图3的步骤102可以通过步骤1021-步骤1023实现：在步骤1021中，基于与第一有状态服务对应的待注册有状态服务调用调度节点；在步骤1022中，通过调度节点对待注册有状态服务进行注册验证处理；在步骤1023中，当注册验证处理通过时，对待注册有状态服务进行注册处理，得到第二有状态服务。
114.例如，与第一有状态服务对应的待注册有状态服务(即待注册的第二有状态服务)启动服务，调用调度节点，通过调度节点对待注册有状态服务进行注册验证，当注册验证通过时，则通过调度节点对待注册有状态服务进行注册，即第二有状态服务注册成功，即将进行第一有状态服务的基于协程的迁移处理；当注册验证失败时，则不对待注册有状态服务进行注册，即第二有状态服务注册失败。
115.在一些实施例中，基于与第一有状态服务对应的待注册有状态服务调用调度节点，包括：基于与第一有状态服务对应的待注册有状态服务，确定待注册有状态服务的文件锁；基于文件锁对应的共享内存消息通道调用调度节点。
116.例如，在通过调度节点注册第二有状态服务前，须先通过文件续约锁取得共享内存消息管道的所有权，然后通过往共享内存消息管道传输注册消息，完成第二有状态服务的注册，通过文件续约锁能够解决第一有状态服务、第二有状态服务的区分问题。
117.需要说明的是，调度节点与每一个有状态服务(包括新有状态服务以及老有状态服务)之间有2对共4条共享内存消息通道，有状态服务与调度节点之间通信必须通过独占其中一对共享内存消息通道。由于新有状态服务、老有状态服务在迁移过程中需要同时运行，为了区分新有状态服务、老有状态服务，势必需要在配置上做区分。而一旦在配置上做区分，那么就是在服务进程标识(id)上作区分，即服务进程读取不同的配置。而一旦在进程id上做区分，势必就会给运维日常操作造成负担。针对这个问题，本技术实施例通过引入文件续约锁(简称文件锁)来解决新有状态服务、老有状态服务的区分问题，以减小维护的计算量。
118.需要说明的是，当调度节点、第一有状态服务以及第二有状态服务位于同一电子设备时，调度节点与每一个有状态服务之间通过共享内存消息通道传输信息；当调度节点、第一有状态服务以及第二有状态服务位于不同电子设备时，调度节点与每一个有状态服务之间通过消息中间件(基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统)传输信息。
119.在一些实施例中，基于与第一有状态服务对应的待注册有状态服务，确定待注册有状态服务的文件锁，包括：基于第一有状态服务，确定与第一有状态服务对应的多个候选文件锁；基于与第一有状态服务对应的待注册有状态服务进行候选文件锁的占用处理；当候选文件锁未被占用时，将候选文件锁作为待注册有状态服务的文件锁，并在文件锁中写入待注册有状态服务的版本号。
120.如图8所示，新有状态服务、老有状态服务在进行服务注册前，必须先通过占用其中一个文件，从而独占一对共享内存消息管道(shmpipe)，其中文件名即为共享内存消息管道id。文件锁中的文件内容包括2部分，一是拥有所有权的有状态服务的版本号，其中，这个版本号可以使用进程编译时间戳；二是当前有状态服务续约文件锁的过期时间戳。
121.如图8所示，基于第一有状态服务(即图8中所示的老有状态服务)，确定与第一有状态服务对应的多个候选文件锁(即图8中所示的文件1和文件2)，与第一有状态服务对应的待注册有状态服务(待注册的新有状态服务)向文件1(shmpipe1)发送所有权请求，以确定文件1已被老有状态服务占用，则与第一有状态服务对应的待注册有状态服务向文件2(shmpipe2)发送所有权请求，以确定文件2未被占用，则与第一有状态服务对应的待注册有状态服务占用文件2，并在文件2中写入待注册有状态服务的版本号，以表征文件2被待注册
有状态服务占用。
122.在一些实施例中，基于文件锁对应的共享内存消息通道调用调度节点，包括：确定待注册有状态服务的注册消息，注册消息包括待注册有状态服务的版本号；通过文件锁对应的共享内存消息通道发送注册消息至调度节点。
123.例如，当确定了待注册有状态服务的文件锁后，基于文件锁对应的共享内存消息通道发送待注册有状态服务的注册消息，以通过共享内存消息通道进行有状态服务的注册。
124.在一些实施例中，当注册验证处理通过时，对待注册有状态服务进行注册处理，得到第二有状态服务，包括：当待注册有状态服务的版本号大于已注册有状态服务的版本号时，将待注册有状态服务注册至服务列表，得到第二有状态服务，并将第二有状态服务的状态设置为协程迁移中。
125.例如，当确定了待注册有状态服务的文件锁后，基于文件锁对应的共享内存消息通道发送待注册有状态服务的注册消息，当注册消息中待注册有状态服务的版本号大于已注册有状态服务的版本号时，则说明注册验证通过，可以对待注册有状态服务进行注册，则将待注册有状态服务注册至服务列表，得到已注册的第二有状态服务，并将第二有状态服务的状态设置为协程迁移中，以表明需要进行协程迁移了。
126.在步骤103中，在第一有状态服务运行过程中，将第一有状态服务的协程迁移至第二有状态服务中，得到迁移后的第二有状态服务。
127.例如，通过注册第二有状态服务后，在第一有状态服务运行过程中，将第一有状态服务的协程迁移至第二有状态服务中，以实现在线更新有状态服务的功能，无需进行停机更新，以提高服务的应用流畅性，相对于灰度发布的方式，提高服务更新的效率，无需额外的计算机资源，从而节约了相关的通信资源和计算资源。
128.参见图5，图5是本技术实施例提供的服务处理方法的流程示意图，图5示出图3的步骤103可以通过步骤1031-步骤1032实现：在步骤1031中，针对第一有状态服务中的任一协程执行以下处理：将协程无损迁移至第二有状态服务中，得到迁移后的第二有状态服务中的新协程，新协程与协程一一对应；在步骤1032中，当第一有状态服务中协程的数量为零时，将迁移后的第二有状态服务的状态设置为正常运行中，并将第一有状态服务的状态设置为不可用状态。
129.例如，针对第一有状态服务中的协程1执行以下处理：将协程1无损迁移至第二有状态服务中，得到迁移后的第二有状态服务中的新协程，新协程与协程1对应，并将第一有状态服务中的协程1设置为无损退出，以表征协程1已退出第一有状态服务。当第一有状态服务中协程全部迁移至第二有状态服务时，将迁移后的第二有状态服务的状态设置为正常运行中，并将第一有状态服务的状态设置为不可用状态。
130.在一些实施例中，将协程无损迁移至第二有状态服务中，得到迁移后的第二有状态服务中的新协程，包括：获取协程的任务队列中的至少一个服务请求；基于协程对至少一个服务请求进行数据处理，得到服务请求的处理结果；在第二有状态服务中创建对应协程的新协程，并通过新协程保存服务请求的处理结果。
131.例如，针对第一有状态服务中的协程1，从第一有状态服务对应的共享内存消息通道中获取协程1的任务队列中的至少一个服务请求，通过协程1对至少一个服务请求进行处
理，得到服务请求的处理结果(即关键数据)，即当协程1处理完任务队列中所有的服务请求后，在第二有状态服务中创建对应协程1的新协程，并通过新协程保存服务请求的处理结果，以便新协程继续进行后续请求处理，避免信息中断。
132.在一些实施例中，获取协程的任务队列中的至少一个服务请求，包括：当第一有状态服务接收到针对协程的迁移请求时，将第一有状态服务的协程的状态设置为无损退出中，并从第一有状态服务对应的共享内存消息通道中，获取协程的任务队列中的至少一个服务请求；其中，迁移请求用于指示第一有状态服务进行协程迁移。
133.例如，如图7所示，调度节点注册第二有状态服务(新有状态服务)后，向第一有状态服务(老有状态服务)发送通知消息，以通知第一有状态服务开始协程迁移。当第一有状态服务接收到针对协程的迁移请求时，将第一有状态服务的协程的状态设置为无损退出中，并从第一有状态服务对应的共享内存消息通道中，获取协程的任务队列中的至少一个服务请求，第一状态服务处理协程剩余消息(又称服务请求或玩家请求)，第一有状态服务处理完协程剩余消息后，向调度节点发送协程迁移成功消息，以表征第一有状态服务的协程迁移成功，可登录第二有状态服务。
134.在一些实施例中，在第二有状态服务中创建对应协程的新协程之前，当协程的任务队列中不存在服务请求时，发送通知消息至第二有状态服务，通知消息携带服务请求的处理结果；基于通知消息，确定将执行在第二有状态服务中创建对应协程的新协程的操作。
135.例如，如图7所示，第一有状态服务(老有状态服务)处理协程剩余消息(又称服务请求或玩家请求)，第一有状态服务处理完协程剩余消息(即协程的任务队列中不存在服务请求)后，调度节点向第二有状态服务(新有状态服务)发送协程迁移成功消息，通知第一有状态服务的协程迁移成功，可登录第二有状态服务。调度节点向第二有状态服务发送协程迁移成功消息，第二有状态服务接收到协程迁移成功消息后，进行协程初始化，以创建对应协程的新协程。
136.在一些实施例中，获取协程的状态数据，状态数据包括虚拟场景的场景数据；将状态数据保存至迁移后的第二有状态服务中的新协程。
137.例如，在第一有状态服务的迁移过程中，获取状态数据(例如游戏过程中需要用到场景数据)，将状态数据保存至迁移后的第二有状态服务中的新协程，以避免数据遗漏，从而导致游戏宕机的情况。
138.在一些实施例中，将第一有状态服务的协程迁移至第二有状态服务中之前，确定协程服务请求的数量；当协程服务请求的数量小于数量阈值时，确定将执行将第一有状态服务的协程迁移至第二有状态服务中的操作。
139.例如，虽然本技术实施例提供的服务处理方法迁移速度快，对玩家影响小，并且无需等待在线人数少时才能更新，实时性好。但是为了避免不可预测的系统错误，还是可以在服务请求较少时，才触发迁移操作，尽可能减小迁移的负担。
140.在一些实施例中，将第一有状态服务的协程迁移至第二有状态服务中之前，确定第一有状态服务运行过程中的网络质量；当网络质量大于质量阈值时，确定将执行将第一有状态服务的协程迁移至第二有状态服务中的操作。
141.例如，虽然本技术实施例提供的服务处理方法迁移速度快，对玩家影响小，并且无需等待在线人数少时才能更新，实时性好。但是为了避免不可预测的系统错误，还是可以在
网络质量较好时，才触发迁移操作，尽可能提高迁移的安全性以及速度。
142.在步骤104中，通过迁移后的第二有状态服务的协程执行对应的协程服务请求。
143.例如，在协程迁移成功后，第一有状态服务将不可用，后续通过迁移后的第二有状态服务的协程执行对应的协程服务请求，以通过更新后的有状态服务处理协程服务请求。
144.在一些实施例中，在第一有状态服务迁移过程中，将针对协程的新协程服务请求缓存至调度节点；在第一有状态服务迁移完成后，迁移后的第二有状态服务从调度节点中获取新协程服务请求，并执行新协程服务请求。
145.例如，在第一有状态服务迁移前，将针对协程的老协程服务请求已加入共享内存消息通道的任务队列中，而在第一有状态服务迁移过程中，将针对协程的新协程服务请求缓存至调度节点，在第一有状态服务迁移完成后，迁移后的第二有状态服务从调度节点中获取新协程服务请求，并执行新协程服务请求。从而通过先缓存新协程服务请求，当迁移完成后，再执行新协程服务请求，避免增加迁移过程中的计算量，提高迁移速度。
146.下面，将说明本技术实施例在一个实际的应用场景中的示例性应用。
147.本技术实施例可以应用于各种游戏的服务更新场景，例如对抗游戏、赛车游戏、变装游戏等。
148.下面以虚拟场景为游戏为例进行说明：
149.近年来随着手游行业的蓬勃发展，为应对玩家对游戏内容消耗的速度过快问题，进一步吸引玩家以及保留玩家，需要游戏侧源源不断地更新游戏内容。其中有状态服务的更新作为游戏服务的主要承载者，其在线更新技术一直是游戏后台设计中的重点以及难点。
150.相关技术中，通过停机更新，直接将所有的玩家踢线，从而进行服务更新，这种方式因为停机更新期间所有服务均不可用，严重影响玩家体验；采取灰度发布的方式，逐步对服务进行更新，但是需要处理一些兼容性的问题，比如新老版本同时存在的情况下某些业务逻辑的特殊处理，另外，更新过程需要一些冗余的灰度机器资源，并且灰度发布会比较耗时。
151.为了解决上述问题，本技术实施例提供一种基于golang协程迁移的有状态游戏后台服务更新方法(即一种服务处理方法)，该方法使用golang作为编程语言，实时性高，对玩家影响小，且对运维友好，适用于大部分的有状态游戏服务的在线更新。
152.需要说明的是，golang语言丰富的社区生态、优秀的现代编程语言设计等吸引着众多开发者，在各互联网领域都有着广泛的应用，特别是语言级支持协程大大降低编写并发程序的门槛，很大程度上提高了开发效率。
153.下面具体说明本技术实施例提供的基于golang协程迁移的有状态游戏后台服务更新方法：
154.如图6所示的框架图，玩家的状态数据分为登录态数据以及游戏过程数据，其中调度节点上维护玩家的登录态数据，而后端的进程则会缓存玩家在线过程中的状态数据。调度节点与后端的有状态服务(包括老有状态服务以及新有状态服务)通过共享内存消息通道(shmpipe，share memory message pipe)进行通信。游戏客户端的服务请求首先发送至调度节点，由调度节点将服务请求路由到后端的有状态服务上，等后端的有状态服务器处理完后会经由调度节点将响应数据返回至玩家，其中后端的有状态服务对于每个玩家都会
设置有一条golang协程用于处理玩家的服务请求，并维护玩家对象的生命周期。
155.如图6所示，老有状态服务中的go1协程和go2协程为老有状态服务中已迁移完成的协程，老有状态服务中的go3协程、go4协程和go5协程为老有状态服务中正在迁移的协程，新有状态服务中的go1协程和go2协程为新有状态服务中已迁移完成的协程，新有状态服务中的go6协程和go7协程为迁移过程中产生的新协程(对应的迁移过程中产生的新玩家)。
156.如图7所示，本技术实施例提供的基于golang协程迁移的有状态游戏后台服务更新方法包括四个步骤，分别为服务注册、面向玩家协程(即golang协程)无损迁移、老有状态服务退出以及调度节点更新状态，下面具体说明这四个步骤：
157.步骤1、服务注册：新的有状态服务(又称新有状态服务)向调度节点注册服务前，须先通过文件续约锁取得共享内存消息管道的所有权，然后通过往共享内存消息管道传输注册消息，完成新的有状态服务的注册。
158.如图7所示，服务注册步骤具体包括以下步骤：
159.步骤11、老有状态服务向调度节点发送心跳请求。
160.步骤12、调度节点接收到心跳请求后，向老有状态服务发送心跳响应。
161.其中，通过心跳请求是每隔一段时间向调度节点发送的数据包，通过调度节点的心跳响应判断老有状态服务与调度节点之间的通讯链路是否连接。
162.步骤13、新有状态服务启动服务。
163.步骤14、新有状态服务向调度节点发送新有状态服务的注册请求(又称注册消息)。
164.步骤15、调度节点向新有状态服务发送新有状态服务的注册响应。
165.步骤16、调度节点将新有状态服务设置为可用。
166.其中，当调度节点确定新有状态服务的注册请求是合法时，将会向新有状态服务返回注册成功的响应，并将新有状态服务设置为可用，表征需要进入基于协程的迁移流程。
167.步骤2、面向玩家协程无损迁移：调度节点在收到新的服务注册时，会以协程为单位，开始驱动老有状态服务上的玩家协程进入基于协程的迁移流程。
168.如图7所示，面向玩家协程无损迁移步骤具体包括以下步骤：
169.步骤21、调度节点向老有状态服务发送通知消息，以通知老有状态服务开始协程迁移。
170.其中，通知消息用于指示老有状态服务进行协程迁移。
171.步骤22、调度节点在迁移过程中缓存发往协程的玩家请求。
172.需要说明的是，在迁移的过程中，可能会额外产生新的玩家请求，这些玩家请求不会发送至老有状态服务的协程，而是由调度节点缓存，待迁移完成后，由新有状态服务的协程处理。
173.步骤23、老有状态服务处理协程剩余消息(即玩家请求)。
174.步骤24、老有状态服务处理完协程剩余消息后，向调度节点发送协程迁移成功消息。
175.其中，协程迁移成功消息用于表征老有状态服务的协程迁移成功，可登录新有状态服务。
176.步骤25、调度节点向新有状态服务发送协程迁移成功消息。
177.其中，协程迁移成功消息用于表征老有状态服务的协程迁移成功，指示登录新有状态服务。
178.步骤26、调度节点向新有状态服务发送迁移过程中缓存的发往协程的玩家请求。
179.步骤27、新有状态服务进行协程初始化，并开始处理缓存消息(即缓存的发往协程的玩家请求)。
180.步骤3、老有状态服务退出：老有状态服务在开始进行协程迁移后便一直核查玩家协程的数量，当玩家协程数量降为0时，便自动进行进程退出。
181.如图7所示，老有状态服务退出步骤具体包括以下步骤：
182.步骤31、老有状态服务判断是否所有协程均已迁移成功。
183.步骤32、当所有协程均已迁移成功，老有状态服务自动进行进程退出。
184.步骤4、调度节点更新状态：当所有的玩家协程迁移成功后，将服务状态修改为正常运行中，并将老有状态服务设置为不可用。
185.如图7所示，调度节点更新状态步骤具体包括以下步骤：
186.步骤41、调度节点设置老有状态服务为不可用。
187.步骤42、新有状态服务向调度节点发送心跳请求。
188.步骤43、调度节点接收到心跳请求后，向新有状态服务发送心跳响应。
189.其中，通过心跳请求是每隔一段时间向调度节点发送的数据包，通过调度节点的心跳响应判断新有状态服务与调度节点之间的通讯链路是否连接。
190.需要说明的是，调度节点与每一个后端的有状态服务(包括新有状态服务以及老有状态服务)之间有2对共4条共享内存消息通道，后端的有状态服务与调度节点之间通信必须通过独占其中一对共享内存消息通道。由于新有状态服务、老有状态服务在迁移过程中需要同时运行，为了区分新有状态服务、老有状态服务，势必需要在配置上做区分。而一旦在配置上做区分，那么就是在服务进程标识(id)上作区分，即服务进程读取不同的配置。而一旦在进程id上做区分，势必就会给运维日常操作造成负担。针对这个问题，本技术实施例通过引入文件续约锁(简称文件锁)来解决新有状态服务、老有状态服务的区分问题，每个有状态服务进程与调度节点之间会有2个文件，分别对应2对共享内存消息通道，下面具体说明文件续约锁：
191.如图8所示，新有状态服务、老有状态服务在进行服务注册前，必须先通过占用其中一个文件，从而独占一对共享内存消息管道(shmpipe)，其中文件名即为共享内存消息管道id。文件锁中的文件内容包括2部分，一是拥有所有权的有状态服务的版本号，其中，这个版本号可以使用进程编译时间戳；二是当前有状态服务续约文件锁的过期时间戳。
192.如图8所示，基于文件续约锁的服务注册步骤具体包括以下步骤：
193.步骤11、新有状态服务向文件1(shmpipe1)发送所有权请求。
194.步骤12、新有状态服务确定文件1已被占用。
195.其中，新有状态服务在占用文件1之前，文件1已被老有状态服务占用，shmpipe1被老有状态服务占用。
196.步骤13、新有状态服务向文件2(shmpipe2)发送所有权请求。
197.步骤14、新有状态服务确定文件2未被占用，文件2占用成功。
198.其中，新有状态服务在占用文件2之前，文件2未被占用，处于空闲状态，则新有状态服务占用文件2成功，shmpipe2被新有状态服务占用。
199.步骤15、调度节点通过shmpipe2向新有状态服务发起注册。
200.需要说明的是，有状态服务启动(如图8中的新有状态服务)后会依次调用系统函数尝试占用文件锁，如果发现文件没有被占用，那么此时会占用此文件的文件所有权，并写入占用者的版本号(即有状态服务的版本号)以及该文件锁过期时间戳。当独占文件成功后，需要创建一个golang协程定期更新此文件的过期时间戳。例如定期更新文件的过期时间戳的时间间隔是30秒，而文件锁过期时间戳则会设置为当前时间戳加上60秒。
201.在文件所有权获取成功后，新有状态服务会往对应的共享内存消息通道发送注册消息至调度节点以注册有状态服务。调用节点为了保证新有状态服务的功能发生变化时才进行协程迁移，会根据注册消息中的版本号以及当前已经注册的有状态服务的版本号进行对比，如果注册消息中的版本号大于当前已注册的有状态服务的版本号，则确定该注册消息合法，将新有状态服务注册到服务列表，并将新有状态服务设置为迁移中。
202.需要说明的是，每个玩家在登录成功后，会在后端的有状态服务上创建一条golang协程用于处理该玩家的消息，其中，有状态服务与协程是一对多的关系。协程中有一条任务队列用于存放调度节点发送至该玩家的消息，协程通过不断处理任务队列中的消息(玩家请求)来完成相应的功能。
203.如图9所示，以协程1为例，具体说明面向玩家协程无损迁移步骤：
204.步骤21、调度节点向老有状态服务发送通知消息，以通知老有状态服务开始协程1迁移。
205.其中，通知消息用于指示老有状态服务进行协程1迁移。
206.步骤22、调度节点在迁移过程中缓存发往协程1的玩家请求。
207.需要说明的是，在迁移的过程中，可能会额外产生协程1的玩家请求，这些玩家请求不会发送至老有状态服务的协程1，而是由调度节点缓存，待协程1迁移完成后，由新有状态服务的协程1处理。
208.步骤23、老有状态服务处理协程1任务队列中剩余消息(即玩家请求)。
209.步骤24、老有状态服务处理完协程1剩余消息后，老有状态服务中的协程1无损退出，并向调度节点发送协程1迁移成功消息。
210.其中，协程1迁移成功消息用于表征老有状态服务的协程1迁移成功，可登录新有状态服务。
211.步骤25、调度节点向新有状态服务发送协程1迁移成功消息。
212.其中，协程1迁移成功消息用于表征老有状态服务的协程1迁移成功，指示登录新有状态服务。
213.步骤26、调度节点向新有状态服务发送迁移过程中缓存的发往协程1的玩家请求。
214.步骤27、新有状态服务创建新的协程(对应协程1)，并开始处理缓存消息(即缓存的发往协程1的玩家请求)。
215.需要说明的是，调度节点在进入迁移时，会以协程为单位，其中一个进程上承载一个有状态服务，一个进程服务多个玩家，一个玩家对应一个协程，则一个进程上有多个协程，通知后端的有状态服务上的玩家协程进入迁移状态。另外，若调度节点未收到老有状态
服务确认该玩家协程已迁移至新有状态服务前，所有发往该玩家协程的消息(即玩家请求)都会缓存至调度节点，例如图9中发往该玩家协程1的消息都会先缓存至调度节点。
216.老有状态服务收到调度节点的协程迁移通知后，确认需要将协程迁移至新有状态服务时，会将协程状态设置为无损退出中，例如图9中将老有状态服务中的协程1设置为无损退出。该无损退出的状态下，玩家协程首先将任务队列中所有剩余消息全部处理完，然后进行数据保存，将关键数据(例如消息对应的处理结果)保存至数据库。当所有关键数据均已成功保存后，将发送通知消息至调度节点，以通知玩家协程已准备迁移至新有状态服务，同时，还会在通知消息上携带该玩家协程的部分状态数据(例如游戏过程中需要用到数据，游戏过程中的临时数据)。
217.当调度节点确认该玩家协程可以迁移至新有状态服务时，会发送通知消息至新有状态服务，同时，会将协程迁移过程中缓存的玩家请求以及部分状态数据发送至新有状态服务上。新有状态服务收到通知消息后，将创建新的协程为玩家服务，保存状态数据并立即处理迁移过程中的玩家请求。
218.至此，该玩家协程已完成整个迁移流程。对老有状态服务上所有的玩家协程重复以上操作(协程1的迁移过程)即可将所有在线玩家协程迁移至新有状态服务上。
219.综上，本技术实施例提供适用于有状态服务进行在线更新，该更新方案仅需运维将新有状态服务启动即可自动完成新有状态服务的更新，老有状态服务的退出；且整个更新流程是面向玩家协程的，每个玩家协程的迁移互不影响，迁移速度快，对玩家影响小；由于整个迁移过程新有状态服务、老有状态服务上协程数量基本一致，迁移过程无需额外提供机器，并且无需等待在线人数少时才能更新，实时性好。
220.至此已经结合本技术实施例提供的电子设备的示例性应用和实施，说明本技术实施例提供的服务处理方法，下面继续说明本技术实施例提供的服务处理装置465中各个模块配合实现服务处理的方案。
221.获取模块4651，用于获取用于更新的第一有状态服务；注册模块4652，用于基于所述第一有状态服务进行有状态服务的注册处理，得到第二有状态服务，所述第二有状态服务与所述第一有状态服务对应；迁移模块4653，用于在所述第一有状态服务运行过程中，将所述第一有状态服务的协程迁移至所述第二有状态服务中，得到迁移后的所述第二有状态服务；处理模块4654，用于通过迁移后的所述第二有状态服务的协程执行对应的协程服务请求。
222.在一些实施例中，所述注册模块4652还用于基于与所述第一有状态服务对应的待注册有状态服务调用调度节点；通过所述调度节点对所述待注册有状态服务进行注册验证处理；当所述注册验证处理通过时，对所述待注册有状态服务进行注册处理，得到所述第二有状态服务。
223.在一些实施例中，所述注册模块4652还用于基于与所述第一有状态服务对应的待注册有状态服务，确定所述待注册有状态服务的文件锁；基于所述文件锁对应的共享内存消息通道调用所述调度节点。
224.在一些实施例中，所述注册模块4652还用于基于所述第一有状态服务，确定与所述第一有状态服务对应的多个候选文件锁；基于与所述第一有状态服务对应的待注册有状态服务进行所述候选文件锁的占用处理；当所述候选文件锁未被占用时，将所述候选文件
锁作为所述待注册有状态服务的文件锁，并在所述文件锁中写入所述待注册有状态服务的版本号。
225.在一些实施例中，所述注册模块4652还用于确定所述待注册有状态服务的注册消息，所述注册消息包括所述待注册有状态服务的版本号；通过所述文件锁对应的共享内存消息通道发送所述注册消息至所述调度节点。
226.在一些实施例中，所述注册模块4652还用于当所述待注册有状态服务的版本号大于已注册有状态服务的版本号时，将所述待注册有状态服务注册至服务列表，得到所述第二有状态服务，并将所述第二有状态服务的状态设置为协程迁移中。
227.在一些实施例中，所述迁移模块4653还用于针对所述第一有状态服务中的任一协程执行以下处理：将所述协程无损迁移至所述第二有状态服务中，得到迁移后的所述第二有状态服务中的新协程，所述新协程与所述协程一一对应；当所述第一有状态服务中协程的数量为零时，将迁移后的所述第二有状态服务的状态设置为正常运行中，并将所述第一有状态服务的状态设置为不可用状态。
228.在一些实施例中，所述迁移模块4653还用于获取所述协程的任务队列中的至少一个服务请求；基于所述协程对所述至少一个服务请求进行数据处理，得到所述服务请求的处理结果；在所述第二有状态服务中创建对应所述协程的新协程，并通过所述新协程保存所述服务请求的处理结果。
229.在一些实施例中，所述迁移模块4653还用于当所述第一有状态服务接收到针对所述协程的迁移请求时，将所述第一有状态服务的所述协程的状态设置为无损退出中，并从所述第一有状态服务对应的共享内存消息通道中，获取所述协程的任务队列中的至少一个服务请求；其中，所述迁移请求用于指示所述第一有状态服务进行协程迁移。
230.在一些实施例中，所述在所述第二有状态服务中创建对应所述协程的新协程之前，所述迁移模块4653还用于当所述协程的任务队列中不存在所述服务请求时，发送通知消息至所述第二有状态服务，所述通知消息携带所述服务请求的处理结果；基于所述通知消息，确定将执行在所述第二有状态服务中创建对应所述协程的新协程的操作。
231.在一些实施例中，所述迁移模块4653还用于获取所述协程的状态数据，所述状态数据包括虚拟场景的场景数据；将所述状态数据保存至迁移后的所述第二有状态服务中的所述新协程。
232.在一些实施例中，所述处理模块4654还用于在所述第一有状态服务迁移过程中，将针对所述协程的新协程服务请求缓存至调度节点；在所述第一有状态服务迁移完成后，迁移后的所述第二有状态服务从所述调度节点中获取所述新协程服务请求，并执行所述新协程服务请求。
233.在一些实施例中，所述将所述第一有状态服务的协程迁移至所述第二有状态服务中之前，所述迁移模块4653还用于确定所述协程服务请求的数量；当所述协程服务请求的数量小于数量阈值时，确定将执行将所述第一有状态服务的协程迁移至所述第二有状态服务中的操作。
234.在一些实施例中，所述将所述第一有状态服务的协程迁移至所述第二有状态服务中之前，所述迁移模块4653还用于确定所述第一有状态服务运行过程中的网络质量；当所述网络质量大于质量阈值时，确定将执行将所述第一有状态服务的协程迁移至所述第二有
状态服务中的操作。
235.本技术实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行本技术实施例上述的服务处理方法。
236.本技术实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本技术实施例提供的服务处理方法，例如，如图3-5示出的服务处理方法。
237.在一些实施例中，计算机可读存储介质可以是fram、rom、prom、ep rom、eeprom、闪存、磁表面存储器、光盘、或cd-rom等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
238.在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
239.作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(html，hyper text markup language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。
240.作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
241.以上所述，仅为本技术的实施例而已，并非用于限定本技术的保护范围。凡在本技术的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本技术的保护范围之内。