CN116708170A

CN116708170A - 服务器更新方法、服务执行方法及相关设备

Info

Publication number: CN116708170A
Application number: CN202210173708.1A
Authority: CN
Inventors: 王扬
Original assignee: Shenzhen Tencent Information Technology Co Ltd
Current assignee: Shenzhen Tencent Information Technology Co Ltd
Priority date: 2022-02-24
Filing date: 2022-02-24
Publication date: 2023-09-05

Abstract

本申请实施例提供了一种服务器更新方法、服务执行方法及相关设备，涉及通信、互联网技术领域；可应用于系统升级维护、游戏服务等场景。服务器更新方法包括：针对验证版本的服务器循环执行版本更新操作，直至将所有当前版本的服务器更新为目标版本的服务器；版本更新操作包括：在当前版本的服务器集群中配置验证版本的服务器；接收到基于目标服务发起的服务器分配请求且确定服务器存在不同版本时，将高版本的服务器确定为目标服务器，并将该目标服务器分配执行目标服务；若目标服务器为验证版本的服务器且对目标服务的响应操作满足预设要求，确定目标服务器通过验证并更新为目标版本的服务器。本申请在不停服的情况下完成服务器的更新。

Description

服务器更新方法、服务执行方法及相关设备

技术领域

本申请涉及通信、互联网技术领域，具体而言，本申请涉及一种服务器更新方法、服务执行方法及相关设备。

背景技术

在一些服务平台中，会配置服务器为用户终端提供各种服务。在服务过程中，由于需要对系统进行升级维护或针对一些用户需求进行数据更新，常常需要进行服务器的更新。

在现有技术中，在进行服务器更新的时间内，需要断开服务器与用户终端之间的连接，进行停机更新，在此期间无法向用户提供服务，且更新所耗费的资源较高。

发明内容

本申请的目的旨在提供一种服务器更新方法、装置、电子设备及存储介质，能够在不停服的情况下完成服务器的更新。为了实现该目的，本申请实施例提供的技术方案如下：

第一方面，本申请实施例提供了一种服务器更新方法，该方法包括：

针对验证版本的服务器循环执行版本更新操作，直至将所有当前版本的服务器更新为目标版本的服务器；所述验证版本的服务器用于验证所述目标版本的服务器在提供服务时的响应操作是否满足预设要求；

其中，所述版本更新操作包括：

在当前版本的服务器集群中配置至少一台验证版本的服务器；

在接收到基于目标服务所发起的服务器分配请求，且确定用于执行所述目标服务的服务器存在至少两个版本时，将高版本的服务器确定为目标服务器，并将该目标服务器分配执行所述目标服务；其中，目标版本的服务器版本高于验证版本的服务器版本，验证版本的服务器版本高于当前版本的服务器版本；

若所述目标服务器为验证版本的服务器且对所述目标服务的响应操作满足预设要求，确定该目标服务器通过验证并更新为目标版本的服务器。

在一可行的实施例中，所述在当前版本的服务器集群中配置至少一台验证版本的服务器，包括：

在当前版本的服务器集群所对应的第一配置信息中，针对验证版本的服务器设置至少一条第二配置信息；

触发执行服务的第一指令，并调用第一服务进程响应所述第一指令；

在接收到所述第一服务进程反馈的第一心跳消息时，启动所述验证版本的服务器；

其中，所述第一心跳消息指示存在与所述第二配置信息对应的验证版本的服务器待配置。

在一可行的实施例中，所述若所述目标服务器为验证版本的服务器且对所述目标服务的响应操作满足预设要求时，确定该目标服务器通过验证并更新为目标版本的服务器，包括：

若所述目标服务器为验证版本的服务器，且对所述目标服务的响应操作满足预设要求时，确定该目标服务器通过当前轮次的验证；

当该目标服务器通过预设阈值轮次的验证时，将该目标服务器更新为目标版本的服务器，并设置与该目标版本的服务器对应的第三配置信息；

触发执行服务的第二指令，并调用第二服务进程响应所述第二指令；

在接收到所述第二服务进程反馈的第二心跳消息时，启动该目标版本的服务器；

其中，所述第二心跳消息指示所述第二配置信息被替换为所述第三配置信息。

在一可行的实施例中，所述将该目标服务器更新为目标版本的服务器，还包括：

基于预设的第一间隔时间，清除该目标服务器及其对应的第二配置信息。

在一可行的实施例中，所述在当前版本的服务器集群所对应的第一配置信息中，针对验证版本的服务器设置至少一条第二配置信息，还包括：

若所述第一配置信息中包括历史更新信息，且当前设置的第二配置信息与上一轮次执行版本更新操作所对应的第二配置信息一致，则将所述验证版本的服务器更新为目标版本的服务器，并启动该目标版本的服务器；。

在一可行的实施例中，所述将该目标服务器分配执行所述目标服务，包括：

基于所述分配请求反馈所述目标服务器的连接信息，以将所述目标服务器分配为执行所述目标服务；

当正在运行的验证版本的服务器数量少于预设配置数量时，启动相应数量的验证版本的服务器。

在一可行的实施例中，所述针对验证版本的服务器循环执行版本更新操作，直至将所述当前版本的服务器更新为目标版本的服务器，包括：

根据资源配置信息，将各服务模式下所需服务器的数量以及当前提供服务的服务器的配置信息，确定为当前版本的服务器对应的第一配置信息；

基于所述第一配置信息调整各服务模式对应的预设启动池信息；

针对验证版本的服务器循环执行版本更新操作，直至将所述当前版本的服务器更新为目标版本的服务器，并基于更新后的第一配置信息调整各服务模式对应的预设启动池信息。

第二方面，本申请实施例提供了一种服务器更新方法，该方法包括：

针对验证版本的服务器循环执行版本更新操作，直至将各个分区中所有当前版本的服务器更新为目标版本的服务器；所述验证版本的服务器用于验证所述目标版本的服务器在提供服务时的响应操作是否满足预设要求；

其中，所述版本更新操作包括：

获取各分区的负载信息；

根据负载信息，以分区为单位在当前版本的服务器集群中配置至少一台验证版本的服务器；

在接收到基于目标服务所发起的服务器分配请求，且确定用于执行所述目标服务的服务器存在至少两个版本时，将负载低的分区中高版本的服务器确定为目标服务器，并将该目标服务器分配执行所述目标服务；其中，目标版本的服务器版本高于验证版本的服务器版本，验证版本的服务器版本高于当前版本的服务器版本；

第三方面，本申请实施例提供了一种服务执行方法，该方法包括：

响应于针对目标服务发起的匹配请求，执行与所述目标服务对应的匹配操作后发送服务器分配请求；

接收第一方面和第二方面中任一项基于所述分配请求所分配的目标服务器的连接信息；

基于所述连接信息采用所述目标服务器执行所述目标服务。

第四方面，本申请实施例提供了一种服务器更新装置，该装置包括：

第一更新模块，用于针对验证版本的服务器循环执行版本更新操作，直至将所有当前版本的服务器更新为目标版本的服务器；所述验证版本的服务器用于验证所述目标版本的服务器在提供服务时的响应操作是否满足预设要求；

其中，所述版本更新操作包括：

第五方面，本申请实施例提供了一种服务器更新装置，该装置包括：

第二更新模块，用于针对验证版本的服务器循环执行版本更新操作，直至将各个分区中所有当前版本的服务器更新为目标版本的服务器；所述验证版本的服务器用于验证所述目标版本的服务器在提供服务时的响应操作是否满足预设要求；

其中，所述版本更新操作包括：

获取各分区的负载信息；

第六方面，本申请实施例提供了一种服务执行装置，该装置包括：

发送模块，用于响应于针对目标服务发起的匹配请求，执行与所述目标服务对应的匹配操作后发送服务器分配请求；

接收模块，用于接收第一方面和第二方面中任一项基于所述分配请求所分配的目标服务器的连接信息；

执行模块，用于基于所述连接信息采用所述目标服务器执行所述目标服务。

第七方面，本申请还提供了一种电子设备，该电子设备包括存储器和处理器，其中，存储器中存储有计算机程序，处理器在运行该计算机程序时用于执行本申请任一可选实施例中提供的方法。

第八方面，本申请还提供了一种计算机可读存储介质，该存储介质中存储有计算机程序，该计算机程序在处理器中运行时，处理器用于执行本申请任一可选实施例中提供的方法。

第九方面，本申请提供了一种计算机程序产品，该计算机程序产品或计算机程序包括计算机程序，该计算机程序被处理器执行时实现本申请任一可选实施例中提供的方法。

本申请提供的技术方案带来的有益效果是：

本申请实施例提供一种服务器更新方法，该方法具体为一种在不停服的情况下采用灰度迭代的更新方法，在服务器迭代更新的过程中采用验证版本的服务器作为服务器版本更新的对象，而服务器更新结束得到目标版本的服务器；其中，验证版本的服务器用于验证目标版本的服务器在提供服务时的响应操作是否满足预设要求。具体地，本申请针对验证版本的服务器循环执行版本更新操作，直至将所有当前版本的服务器更新为目标版本的服务器。其中，版本更新操作包括以下步骤：在当前版本的服务器集群中配置至少一台验证版本的服务器；在接收到基于目标服务所发起的服务器分配请求，且确定用于执行目标服务的服务器存在至少两个版本时，将高版本的服务器确定为目标服务器，并将目标服务器分配执行目标服务；若目标服务器为验证版本的服务器且对目标服务的响应操作满足预设要求，确定该目标服务器通过验证并更新为目标版本的服务器。其中，本申请设定目标版本的服务器版本高于验证版本的服务器版本，验证版本的服务器版本高于当前版本的服务器版本。本申请的实施在服务器更新的过程中仍可以向用户终端提供服务，在不停服的情况下完成所有服务器的更新，且将验证版本的服务器分配于执行客户端请求的目标服务，可以同步完成对验证版本服务器的验证，以将验证版本的服务器更新为目标版本的服务器；另外，本申请通过循环执行版本更新操作，可以在一定的时间内通过目标版本的服务器与当前版本的服务器之间的替换，实现对当前版本的服务器的淘汰，提高服务器更新的效率。

本申请实施例还提供一种服务器更新方法，在该方法中，与上述服务器更新方法的区别在于服务器采用分区的形式进行管理，针对各分区的服务器采用负载均衡的策略进行服务器更新，可以在服务器更新的过程中有效均衡各分区的负载。

本申请实施例还提供一种服务执行方法，在该方法中，用户终端响应于针对目标服务发起的匹配请求，执行与目标服务对应的匹配操作后向服务器发送服务器分配请求，并接收服务器执行上述服务器更新方法的过程中基于分配请求所分配的目标服务器的连接信息，继而基于连接信息采用目标服务器执行目标服务。其中，目标服务器可以是当前版本的服务器、验证版本的服务器，还可以是目标版本的服务器。本申请可以实现在服务器更新的过程中用户终端仍然可以请求服务器提供服务，对用户而言，服务器更新的处理并不影响其正在的使用且无任何感知，有利于提高用户体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的一种服务器更新方法的流程示意图；

图2为本申请实施例提供的另一种服务器更新方法的流程示意图；

图3为为本申请实施例提供的一种服务执行方法的流程示意图；

图4为本申请实施例提供的一种运行架构的示意图；

图5为本申请实施例提供的另一种运行架构的示意图；

图6为本申请实施例提供的一种服务器更新方法的执行流程图；

图7为本申请实施例提供的一种界面示意图；

图8为本申请实施例提供的另一种界面示意图；

图9为本申请实施例提供的又一种界面示意图；

图10为本申请实施例提供的一种服务器更新装置的结构示意图

图11为本申请实施例提供的一种服务器更新装置的结构示意图；

图12为本申请实施例提供的一种服务执行装置的结构示意图；

图13为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本申请是针对现有服务器更新的方案中所存在需要停服更新导致用户流失以及资源耗费高的问题，而提出的一种服务器更新方法、服务执行方法及相关设备，基于该方案的实施，可以实现在不停服的情况下完成服务器的更新。

本申请实施例的方案涉及到程序或平台的升级、维护或基于需求做出的调整，如在游戏服务场景，基于本申请实施例的方案，能够在现网不停的情况下进行灰度迭代验证及全量推送的服务器更新。

可选的，本申请提供的该服务器更新方法中所涉及的数据(比如各种版本服务器的配置信息等)可以保存于区块链中。本申请所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一定量的处理数据，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词及术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

灰度更新：在本申请实施例中是指在当前版本的服务器和目标版本的服务器之间，通过替换算法实现服务器不同版本过渡的更新方式。在该过程中，可以采用当前版本的服务器为一部分用户提供服务，同时采用目标版本的服务器(或验证版本的服务器)为另一部分用户提供服务。在采用验证版本的服务器为用户提供服务，且用户对该服务器提供的服务无意见时，可以逐步将该验证版本的服务器更新为目标版本的服务器，并逐步把所有用户迁移到目标版本的服务器上。

匹配服务器(Match Server)：在一些指定需要多用户进行的操作中，为发起匹配请求的用户匹配相应数量的用户。如在多人对战的游戏中，在用户A触发启动游戏时，用于为用户A撮合单局对战的服务器进程。

第一管理服务器：用于进行服务器的管理，当全区的服务器不采用分区形式管理时，第一管理服务器针对所有服务器进行管理；当全区的服务器采用分区形式管理时，第一管理服务器针对各分区的第二管理服务器进行管理。也即，在本申请实施例中，第一管理服务器属于全局管理服务器。

第二管理服务器：用于进行服务器的管理，适应于分布式系统，第二管理服务器可以是针对某一分区的所有服务器进行管理。

在一些指定的场景中，如在游戏服务的对战场景中，一般布局有专用服务器(Dedicated Server，DS)提供该对战的战局服务，此时第一管理服务器可以是专用于全局DS的管理服务器，而第二管理服务器可以是专用于分区DS的管理服务器；相应地，第一管理服务器可以管理各第二管理服务器。其中，由于专用服务器是基于虚幻引擎(UnrealEngine，UE)开发的，其对机器硬件的要求很高，所消耗的机器资源也高，单台服务器所能承载DS有限，因此，随着所服务的用户数量增加，布局有数量较多的DS。其中，DS中所指的专用意味着这台服务器的全部硬件资源只用于某种指定的服务器，不作其他用途；在实际应用中，游戏类和交易类服务器可以采用专用服务器，以使所提供的指定服务获得更高的性能，或者实现物理隔离，保障数据和通信的安全性。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1示出了本申请实施例提供的一种服务器更新方法的流程示意图，该方法可以由任一电子设备执行，如可以是服务器。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。在该方法中，执行服务器更新的过程中系统可以响应用户终端的请求，用户终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等；其中，终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

具体地，如图1所示，本申请实施例提供的服务器更新方法包括以下步骤S100：

步骤S100：针对验证版本的服务器循环执行版本更新操作，直至将所有当前版本的服务器更新为目标版本的服务器。

其中，所述验证版本的服务器用于验证所述目标版本的服务器在提供服务时的响应操作是否满足预设要求。

具体地，验证版本的服务器也可以称为灰度版本的服务器，是一种从当前版本的服务器到目标版本的服务器之间的过渡服务器。验证版本的服务器所提供的服务与目标版本的服务器一致。在本申请实施例中，采用验证版本的服务器执行灰度更新的流程(如图6所示的步骤3和步骤4)，从而在确定验证版本的服务器通过验证后，执行滚动更新的流程(如图6所示的步骤5)将当前版本的服务器更新为目标版本的服务器。

其中，版本更新操作包括以下步骤S101-S103：

步骤S101：在当前版本的服务器集群中配置至少一台验证版本的服务器。

具体地，本申请实施例采用的是灰度迭代的更新方式，也即在执行一次版本更新操作时，若当前版本的服务器集群中包括N台服务器，则所配置的验证版本的服务器的数量可以在[1,N-1]中取值，以保证在针对验证版本的服务器进行验证的过程中，还有当前版本的服务器为部分用户提供服务。

可选地，在执行版本更新操作的每一轮次中，步骤S101中所配置的验证版本的服务器数量可以根据当前版本的服务器集群中所包括服务器的数量、预设验证过程中的配置数量来确定，以实现为用户提供服务的当前版本的服务器数量与验证版本的服务器数量保持预设的比例；该比例可以设置为1：1、2:1等。以比例为1：1说明：此时当有M个用户发起请求，响应该请求需要调用所有服务器(仅是一种实例，在实际应用中所调用的服务器数量需要根据实际情况确定)时，将采用所有的验证版本的服务器为M/2的用户提供服务，并采用与该验证版本的服务器相同数量的当前版本的服务器为另一半用户提供服务。

步骤S102：在接收到基于目标服务所发起的服务器分配请求，且确定用于执行所述目标服务的服务器存在至少两个版本时，将高版本的服务器确定为目标服务器，并将该目标服务器分配执行所述目标服务。

其中，目标版本的服务器版本高于验证版本的服务器版本，验证版本的服务器版本高于当前版本的服务器版本(对应于原始版本的服务器版本)。可选地，目标版本的服务器版本相对于验证版本的服务器版本和当前版本的服务器版本(对应于原始版本的服务器版本)而言，其版本为新版本(也即验证版本的服务器版本和当前版本的服务器版本属于旧版本)；验证版本的服务器版本相对于当前版本的服务器版本(对应于原始版本的服务器版本)而言，其版本为新版本(也即当前版本的服务器版本属于旧版本)。

其中，若当前具有M个用户针对目标服务发起服务请求时，直接与用户终端连接的服务器接收到该服务请求后，将向用于管理各单一服务器的管理服务器(本申请实施例的执行主体)发起服务器分配请求，管理服务器在接收到基于目标服务所发起的服务器分配请求后，首先确定出服务器集群中是否存在不同版本的服务器，若是，则将高版本的服务器确定为目标服务器，并将该目标服务器分配为执行目标服务的服务器。

可选地，在同一时期，服务器集群中可以包括原始版本的服务器V1、验证版本的服务器V2、和目标版本的服务器V3中的至少一项。其中，原始版本的服务器V1也即在执行服务器更新之前提供服务的服务器；相应地，在首次执行版本更新操作时，原始版本的服务器V1相当于当前版本的服务器。

步骤S103：若所述目标服务器为验证版本的服务器且对所述目标服务的响应操作满足预设要求，确定该目标服务器通过验证并更新为目标版本的服务器。

具体地，由于在同一时期可能存在多个版本的服务器，因此所确定的目标服务器不一定是验证版本的服务器。当目标服务器为原始版本的服务器时，也即当前向用户提供的服务不受服务器更新的影响，此时无需执行步骤S103。当目标服务器为目标版本的服务器时，也即当前采用已通过验证且更新后的服务器为用户提供服务，此时无需执行步骤S103。当目标服务器为验证版本的服务器时，也即提供目标服务的过程也属于服务器的验证过程，因此，在确定出目标服务器对目标服务的响应操作满足预设要求时，可以将该目标服务器更新为目标版本的服务器，更新的具体操作内容将在后续实施例中详细说明。

其中，预设要求可以是针对硬件资源、服务器的操作性能、所提供服务的情况设定。如针对提供服务的响应时间，若有用户反馈验证版本的服务器响应时间过长，或系统判定验证版本的服务器对目标服务的响应时间超出预设的要求时间，则该验证版本的服务器在提供服务的响应操作不满足预设要求，也即无法通过验证。

在本申请实施例中，上述步骤S100可以应用于如图4和5中的第一管理服务器，也可以应用于第二管理服务器。在图4和图5中，第一管理服务器可以为全局管理服务器，第二管理服务器可以为分区管理服务器；也即，本申请实施例提供的方法可以应用于全局管理服务器，也可以应用于分区管理服务器。

当应用于分区管理服务器时，也即仅在单台分区管理服务器上针对验证版本的服务器进行验证，此时可以有效降低对现网用户的影响，当在某一分区中确定验证版本的服务器通过验证后，可以将该分区中的服务器更新为目标版本的服务器，同时向全局管理服务器发送验证版本的服务器通过验证的通知消息，以使全局管理服务器针对全局(也即所有分区)的当前版本的服务器直接更新为目标版本的服务器。

当应用于全局管理服务器时，也即在各分区中针对验证版本的服务器进行验证，在确定验证版本的服务器通过验证后，可以将全局中当前版本的服务器更新为目标版本的服务器。

在一可行的实施例中，在步骤S101中在当前版本的服务器集群中配置至少一台验证版本的服务器，包括以下步骤A1-A3：

步骤A1：在当前版本的服务器集群所对应的第一配置信息中，针对验证版本的服务器设置至少一条第二配置信息。

步骤A2：触发执行服务的第一指令，并调用第一服务进程响应所述第一指令。

步骤A3：在接收到所述第一服务进程反馈的第一心跳消息时，启动所述验证版本的服务器。

具体地，在系统的服务器配置中，各服务器具有与自身一一对应的配置信息，其中，配置信息可以包括版本信息、路径信息(如包括连接对应服务器的路径)。在本申请实施例中，当前版本的服务器对应于第一配置信息，验证版本的服务器对应于第二配置信息。

其中，在服务器集群中针对验证版本的服务器进行配置时，首先需要在该集群中设置好相应的配置信息，通过该配置信息可以区分出各版本的服务器以及确定出与该服务器进行连接的路径。

具体地，在进程启动时，以服务器的心跳情况表征相应服务器是否可置为可用状态。如服务器A处于心跳保持的状态时，服务器A可以被置为服务可用；服务器B处于心跳超时或中断心跳的状态时，则服务器B可以被置为服务不可用，且在心跳恢复正常后再加入到服务中。可选地，与心跳情况相关的信息可以同步记录于服务器的配置信息中。

具体地，在执行步骤A1后，可以通过信号(如触发执行服务的第一指令)触发服务进程感知服务器的配置变化。当接收到第一服务进程反馈的第一心跳消息时，表征当前服务器集群中存在验证版本的服务器配置，因此，可以基于该第一心跳消息启动部分已设置有第二配置信息的验证版本的服务器；启动后的验证版本的服务器可以被分配为向用户终端提供服务。可选地，验证版本的服务器的启动数量可以根据预设验证过程中的配置数量(针对验证版本的服务器的配置数量)进行确定，也即考虑应投入多少数量的验证版本的服务器以维持该服务器所能提供服务的能力。

如图6所示，上述步骤A1可以对应于图6中的步骤3，步骤A3可以对应于图6中的步骤2。

在一可行的实施例中，在步骤S103中若所述目标服务器为验证版本的服务器且对所述目标服务的响应操作满足预设要求时，确定该目标服务器通过验证并更新为目标版本的服务器，包括以下步骤B1-B4：

步骤B1：若所述目标服务器为验证版本的服务器，且对所述目标服务的响应操作满足预设要求时，确定该目标服务器通过当前轮次的验证。

步骤B2：当该目标服务器通过预设阈值轮次的验证时，将该目标服务器更新为目标版本的服务器，并设置与该目标版本的服务器对应的第三配置信息。

步骤B3：触发执行服务的第二指令，并调用第二服务进程响应所述第二指令。

步骤B4：在接收到所述第二服务进程反馈的第二心跳消息时，启动该目标版本的服务器。

具体地，结合步骤B1和步骤B2可见，在本申请实施例中，验证版本的服务器需要经过若干周期的验证后(通过预设阈值轮次的验证)，方可认定验证版本的服务器可以被更新为目标版本的服务器，也即相当于可以确定将目标版本的服务器投入正式使用。在后续的处理中，可以通过信号(如触发执行服务的第二指令)触发服务进程感知配置变化。当接收到第二服务进程反馈的第二心跳消息时，表征当前服务器集群中与通过验证的验证版本的服务器对应的第二配置信息被替换为第三配置信息(可以包括版本信息和路径信息)，因此，可以基于该第二心跳消息启动已设置有第三配置信息的目标版本的服务器；启动后的目标版本的服务器可以被分配为向用户终端提供服务。

如图6所示，上述步骤B2可以对应于图6中的步骤5，步骤B4可以对应于图6中的步骤2。

在一可行的实施例中，在步骤B2中将该目标服务器更新为目标版本的服务器，还包括以下步骤B21：

步骤B21：基于预设的第一间隔时间，清除该目标服务器及其对应的第二配置信息。

具体地，考虑到验证版本的服务器的引入旨在验证目标版本的服务器对目标服务的响应操作是否满足预设要求，本申请实施例可以在配置验证版本的服务器的同时启动回收机制，在该回收机制中，若验证版本的服务器被确定通过验证，且已修改为目标版本的服务器时，可以基于预设的第一间隔时间清除与该验证版本的服务器相关的数据，如第二配置信息。其中，对目标服务器的清除可以视为停止该目标服务器的运行，使其不再被分配为用户终端提供服务。

如图6所示，步骤B21可以对应于图6中的步骤6和步骤7。

在一可行的实施例中，在步骤A1中在当前版本的服务器集群所对应的第一配置信息中，针对验证版本的服务器设置至少一条第二配置信息，还包括以下步骤A11-A13：

步骤A11：若所述第一配置信息中包括历史更新信息，且当前设置的第二配置信息与上一轮次执行版本更新操作所对应的第二配置信息一致，则将所述验证版本的服务器更新为目标版本的服务器，并启动该目标版本的服务器。

具体地，历史更新信息表征第一配置信息曾发生替换，如从原始版本的服务器对应的第一配置信息替换为目标版本的第三配置信息。由于版本更新操作是循环执行的，因此在第二轮次及之后执行版本更新操作时，当前版本的服务器可能是原始版本的服务器，还可能是目标版本的服务器，因此，与当前版本的服务器对应的第一配置信息可能是与原始版本的服务器对应的配置信息，也可能是与目标版本的服务器对应的配置信息。其中，若当前设置的第二配置信息与上一轮次执行版本更新操作所对应的第二配置信息一致，表征服务器已通过验证，可以直接更新为目标版本的服务器。其中，步骤A11中将验证版本的服务器更新为目标版本的服务器，也即将当前版本的服务器直接更新为目标版本的服务器。

可选地，步骤A11的执行操作可以是通过信号触发服务进程感知配置变化而实施的，如触发执行服务的第三指令，调用第三服务进程响应该第三指令，在接收到第三服务进程反馈的第三心跳消息时，启动步骤A11中所指的目标版本的服务器。启动后的目标版本的服务器可以被分配为向用户提供服务。其中，第三心跳消息表征第一配置信息中包括历史更新信息，且当前设置的第二配置信息与上一轮次执行版本更新操作所对应的第二配置信息一致(如服务进程发现当前服务器的版本信息和路径信息产生变化，且与上次验证版本的服务器的版本信息和路径信息是相同的)。

在本申请实施例中，步骤A11的执行相当于触发滚动更新的流程。

步骤A12：结束当前轮次的版本更新操作。

具体地，由于当前轮次需要进行验证的验证版本的服务器已直接更新为目标版本的服务器，因此可以结束当前轮次的版本更新操作，并进入下一轮次的版本更新操作。

步骤A13：基于预设的第二间隔时间，清除当前版本的服务器及其对应的第一配置信息。

具体地，考虑到原始版本的服务器在完成服务器的更新后，需要被淘汰，因此，本申请实施例可以配置回收机制，在该回收机制中，若确定当前版本的服务器已被更新为目标版本的服务器后，可以基于预设的第二间隔时间清除与该当前版本的服务器相关的数据，如第一配置信息。其中，对当前版本的服务器的清除可以视为停止该服务器的运行，使其不再被分配为向用户终端提供服务的服务器。

如图6所示，上述步骤A11可以对应于图6中的步骤4，步骤A13可以对应于图6中的步骤6和步骤7。

在一可行的实施例中，在步骤S103中将该目标服务器分配执行所述目标服务，包括以下步骤C1-C2：

步骤C1：基于所述分配请求反馈所述目标服务器的连接信息，以将所述目标服务器分配为执行所述目标服务。

其中，连接信息可以包括服务器的IP信息(如Internet Protocol Address，网际协议地址)和PORT信息(如接口信息)。

步骤C2：当正在运行的验证版本的服务器数量少于预设配置数量时，启动相应数量的验证版本的服务器。

其中，考虑到在验证版本的服务器进行验证的过程中，需要维持其服务能力，因此可以适应设置配置数量，若检测到正在运行的验证版本的服务器数量少于预设配置数量时，可以适应触发启动相应数量的验证版本的服务器。如步骤A3中，虽然设置有若干验证版本的服务器对应的第二配置信息，但在执行步骤A3时，设置有第二配置信息的验证版本的服务器可以不用全部启动。

在一可行的实施例中，在步骤S100中针对验证版本的服务器循环执行版本更新操作，直至将所述当前版本的服务器更新为目标版本的服务器，包括以下步骤D1-D3：

步骤D1：根据资源配置信息，将各服务模式下所需服务器的数量以及当前提供服务的服务器的配置信息，确定为当前版本的服务器对应的第一配置信息。

其中，在一个平台中，可能向用户提供多种服务，因此在进程启动时，可以根据资源配置信息读取各服务模式下需要维持预设的服务器待分配数量的安全阈值，也即所需服务器的数量；同时，根据资源配置信息还可以读取当前提供服务的服务器的配置信息，如原始版本的服务器的配置信息。

步骤D2：基于所述第一配置信息调整各服务模式对应的预设启动池信息。

具体地，在读取到步骤D1所指的信息后，等待各服务器心跳保持完成后，可以按照配置信息统一调整各服务模式对应的预设的启动池大小。

步骤D3：针对验证版本的服务器循环执行版本更新操作，直至将所述当前版本的服务器更新为目标版本的服务器，并基于更新后的第一配置信息调整各服务模式对应的预设启动池信息。

具体地，由于将旧版本的服务器更新为目标版本的服务器时，相应的配置信息将发生变化，因此可以基于更新后的配置信息调整各服务模式对应的预设启动池大小。

图2示出了本申请实施例提供的另一种服务器更新方法的流程示意图，该方法可以由任一电子设备执行，如可以是服务器。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。在该方法中，执行服务器更新的过程中系统可以响应用户终端的请求，用户终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等；其中，终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

如图2所示，本申请实施例提供的另一种服务器更新方法包括以下步骤S200：

步骤S200：针对验证版本的服务器循环执行版本更新操作，直至将各个分区中所有当前版本的服务器更新为目标版本的服务器。

其中，版本更新操作包括以下步骤S201-S204：

步骤S201：获取各分区的负载信息。

步骤S202：根据负载信息，以分区为单位在当前版本的服务器集群中配置至少一台验证版本的服务器。

步骤S203：在接收到基于目标服务所发起的服务器分配请求，且确定用于执行所述目标服务的服务器存在至少两个版本时，将负载低的分区中高版本的服务器确定为目标服务器，并将该目标服务器分配执行所述目标服务；其中，目标版本的服务器版本高于验证版本的服务器版本，验证版本的服务器版本高于当前版本的服务器版本。

步骤S204：若所述目标服务器为验证版本的服务器且对所述目标服务的响应操作满足预设要求，确定该目标服务器通过验证并更新为目标版本的服务器。

在本申请实施例中，上述步骤S200可以应用于如图4和图5中的第一管理服务器。在图4和图5中，第一管理服务器可以为全局管理服务器；也即本申请实施例提供的服务器更新方法可以应用于全局管理服务器。

当应用于全局管理服务器时，可以根据负载均衡策略继承上述步骤S100对应的服务器更新方法中所包括的任一项实施例。

为了更好地说明步骤S200对应的服务器更新方法，下面结合图5和图6，并以专用服务器的更新为例进行说明：

首先，全局DS管理服务器(第一管理服务器)在进程启动时，根据资源配置读取到各服务模式需要维持预设的DS待分配数量的安全阈值，根据资源配置读取到当前V1版本的DS及路径信息，等待所有分区DS管理服务器(第二管理服务器)心跳保持完成后，通知分区DS管理服务器按照配置版本信息，统一调整各游戏模式为预设的启动池大小。

其中，分区DS管理服务器会定时向全局DS管理服务器上报其负载及版本信息；负载信息的更新频率可以设置为大约1秒或500ms刷新一次。

其中，全局DS管理服务器可以缓存所有分区DS管理服务器上报的负载信息及全局DS管理服务器自身的信息，当分区DS管理服务器心跳超时或中断心跳，则分区DS管理服务器对应的信息会被置为服务不可用，待心跳恢复正常后再加入到服务中。

对应于图6中的步骤3，当设置全局DS管理服务器的灰度DS版本及路径信息为有效值，且开启DS回收机制时，通过信号触发进程感知配置变化，全局DS管理服务器进程发现存在灰度DS配置，可以根据负载均衡请求分区DS管理服务器，在指定灰度DS路径拉起一定配置数量的新的V2版本DS，并通过监控心跳状态的方式在下一个心跳周期感知到启动结果。

对应于图6中的步骤5，当修改全局DS管理服务器的灰度DS版本及路径信息时，通过信号触发进程感知配置变化，全局DS管理服务器进程发现灰度信息(与验证版本的服务器相关的配置信息)与之前的信息不一致，则继续根据负载均衡请求分区DS管理服务器，在新的灰度DS路径拉起新配置的V3版本DS，并通过监控心跳状态方式在下一个心跳周期感知到启动结果。同时，启动一个指定时间间隔的定时器(对应于图6的步骤7)，在若干时间后触发通知，通知分区DS管理服务器回收V2版本DS。

对应于图6中的步骤4，当修改全局DS管理服务器的当前DS版本及路径信息，且重置灰度DS版本及路径信息时，通过信号触发进程感知配置变化，全局DS管理服务器进程发现当前DS版本及路径信息产生变化，且与上次灰度DS版本及路径相同，则触发滚动更新，通知DS管理服务器按照配置版本信息，统一调整各游戏模式为预设的启动池大小。

如图5所示，若在服务器更新的过程中，用户发起匹配请求，匹配成功后匹配服务器会向全局DS管理服务器发送分配DS请求，全局DS管理服务器根据缓存的DS信息判断是否多版本共存的DS，按照版本降级策略，通过负载均衡选择负载最低的分区DS管理服务器请求分配DS的IP和PORT信息并返回给客户端。用户所在客户端接收到DS信息即可连接DS开局。

下面针对图6中对应于步骤3和5的灰度更新流程和对应于步骤4的滚动更新流程相关的处理逻辑进行说明：

步骤1：进程初始化时，读取当前DS版本、路径配置信息及启动数量。

步骤2：根据配置信息向分区DS管理服务器发送预拉起指定版本DS请求。

步骤3：判断当前是否触发设置灰度版本及路径信息，如果触发，进行步骤2，否则进行步骤6。

步骤4：判断当前是否触发设置当前版本及路径信息，如果触发，进行步骤2，否则进行步骤6。

步骤5：判断当前是否触发更新灰度版本及路径信息，如果触发，进行步骤2，否则进行步骤6。

步骤6：判断是否产生需要回收的DS版本且开启DS旧版本回收机制，如果触发，进行步骤7，否则进行步骤8。

步骤7：触发DS回收定时器，根据配置时间设置定时器，定时器到达后，向分区DS管理服务器发送回收指定版本DS指令。

步骤8：返回等待下一次触发执行，计算逻辑结束。

可选地，在本申请实施例中，回收机制还可以针对未通过验证的验证版本的服务器及其配置信息进行回收。

图3示出了本申请实施例提供的一种服务执行方法的流程示意图，该方法可以由任一电子设备执行，如可以是用户终端，用户终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载设备等。

如图3所示，本申请实施例提供的一种服务执行方法包括以下步骤S301-S303：

步骤S301：响应于针对目标服务发起的匹配请求，执行与所述目标服务对应的匹配操作后发送服务器分配请求。

步骤S302：接收上述实施例基于分配请求所分配的目标服务器的连接信息。

步骤S303：基于所述连接信息采用所述目标服务器执行所述目标服务。

下面结合图5、图7、图8和图9对上述实施例的步骤S301-步骤S303进行说明：

图7-图9可以应用于一种游戏场景，在图7中，用户可以触发“开始游戏”的控件，使客户端发起匹配请求；在图8中，客户端响应匹配请求处于匹配操作中；在图9中，用户进入游戏内开局。

具体地，游戏用户在客户端点击图7中的开始游戏按钮，客户端即向服务器端发起匹配请求，服务端的匹配处理模块(匹配服务器)即会撮合玩家开局。客户端收到服务器返回的匹配结果后，便会显示当前匹配进度，满足人数要求后即可开局，匹配界面如图8所示。用户匹配成功后，服务器端的全局层DS管理器(第一管理服务器)会接收到服务器分配请求，便可以采用上述实施例提供的服务器更新方法进行处理并返回给客户端访问速度最优且负载适中的最高版本的DS服务器IP和Port供用户连接进入游戏，界面如图9所示。

其中，上述实施例的服务器更新方法的执行在图8和图9的界面转换之间发生作用。

在本申请实施例中，整个游戏架构中其他逻辑模块都是全区全服固定机器数量部署，而对于要求响应及时的开局部分，可以以初始化机器数量为基础部署，但对用户而言，机器的部署是透明的，属于全区全服的情况(不分服)，只是不同的用户在匹配后被撮合为同局用户后，全局DS管理器会根据DS集群的实际情况将其引导进入版本最高的，且对应访问速度最优、负载适中的DS服务器中进行游戏。

如图5所示，游戏的DS集群和分区DS管理服务器(第二管理服务器)可以部署在三地机房中，全局DS管理服务器和其他全局模块(如匹配服务器)部署在同一机房。全局DS管理服务器按版本管理所有DS状态，同时全局DS管理服务器支持配置更新以触发灰度版本DS以配置数量负载均衡分配到不同地区拉起。

具体地，在服务器更新的过程中，当用户1-M开始发起匹配请求并匹配成功，匹配服务器向全局DS管理服务器(第一管理服务器)发起分配DS的请求，全局DS管理服务器经过内部一系列计算处理后，判断所请求模式的DS是否多版本共存，将负载较低的分区2中的高版本DS(图5中虚线所示的V3版本的服务器)分配给用户1-M进行开局战斗。

同时，由于分区2的DS分配了战局导致DS集群状态变化，全局DS管理服务器会根据分区1-3中分区DS管理服务器(第二管理服务器)上报的负载信息进行内部计算处理，发现全局现存的DS版本数量不足以满足配置需求时，可以根据负载状态向若干分区(例如分区1-2)请求启动或停止若干该版本DS以维持该版本DS服务能力到预设的灰度DS配置。

在本申请实施例中，所提供的服务器更新方法和服务执行方法对用户而言，服务器保持全区全服特点，匹配成功后部分用户优先分配进入灰度版本战局(由验证版本的服务器提供服务的战局)，其他用户继续被分配到当前版本战局(由原始版本的服务器提供服务的战局)。适应于游戏服务场景而言，游戏的登录及其他逻辑服务器都是全区全服，只有DS和匹配服务器会根据地理区域分别就近部署，其中灰度DS战局(灰度版本战局)可以散列随机分布在各区域。另外，游戏内部通过算法实现灰度DS战局的优先分配和灰度比例保持，保证灰度比例范围内的用户快速验证灰度版本功能，同时比例范围外的用户对服务器更新无感知。

下面结合图4对本申请实施例的运行架构进行说明。

如图4所示，用户终端20与对接服务器10可以通过网络30进行通信和数据交互；其中，对接服务器10可以是上述实施例所指的匹配服务器。另外，如图4所示，第一管理服务器11与对接服务器10进行通信，第一管理服务器11为全局管理服务器；第二管理服务器12与第一管理服务器11进行通信，第二管理服务器12为分区管理服务器。可选地，当包括K(K可以大于或等于1)个分区时，第一管理服务器11分别与K个第二管理服务器12进行通信。

基于上述方法实施例相同的原理，本申请实施例还提供了一种服务器更新装置，如图10中所示，该服务器更新装置100可以包括第一更新模块101。

其中，第一更新模块101用于针对验证版本的服务器循环执行版本更新操作，直至将所有当前版本的服务器更新为目标版本的服务器；所述验证版本的服务器用于验证所述目标版本的服务器在提供服务时的响应操作是否满足预设要求；

其中，所述版本更新操作包括：

在一可行的实施例中，第一更新模块101用于执行在当前版本的服务器集群中配置至少一台验证版本的服务器时，具体用于：

在一可行的实施例中，第一更新模块101用于执行若所述目标服务器为验证版本的服务器且对所述目标服务的响应操作满足预设要求时，确定该目标服务器通过验证并更新为目标版本的服务器时，具体用于：

在一可行的实施例中，第一更新模块101用于执行将该目标服务器更新为目标版本的服务器时，还具体用于：

在一可行的实施例中，第一更新模块101用于执行在当前版本的服务器集群所对应的第一配置信息中，针对验证版本的服务器设置至少一条第二配置信息时，还具体用于：

若所述第一配置信息中包括历史更新信息，且当前设置的第二配置信息与上一轮次执行版本更新操作所对应的第二配置信息一致，则将所述验证版本的服务器更新为目标版本的服务器，并启动该目标版本的服务器；

结束当前轮次的版本更新操作；

基于预设的第二间隔时间，清除当前版本的服务器及其对应的第一配置信息。

在一可行的实施例中，第一更新模块101用于执行将该目标服务器分配执行所述目标服务时，具体用于：

在一可行的实施例中，第一更新模块101用于执行针对验证版本的服务器循环执行版本更新操作，直至将所述当前版本的服务器更新为目标版本的服务器时，具体用于：

基于上述方法实施例相同的原理，本申请实施例还提供了一种服务器更新装置，如图11中所示，该服务器更新装置200可以包括第二更新模块201。

其中，第二更新模块201用于针对验证版本的服务器循环执行版本更新操作，直至将各个分区中所有当前版本的服务器更新为目标版本的服务器；所述验证版本的服务器用于验证所述目标版本的服务器在提供服务时的响应操作是否满足预设要求；

其中，所述版本更新操作包括：

获取各分区的负载信息；

基于上述方法实施例相同的原理，本申请实施例还提供了一种服务执行装置，如图12中所示，该服务执行装置300可以包括发送模块301、接收模块302、执行模块303。

其中，发送模块301用于响应于针对目标服务发起的匹配请求，执行与所述目标服务对应的匹配操作后发送服务器分配请求；接收模块302用于接收上述实施例基于所述分配请求所分配的目标服务器的连接信息；执行模块303用于基于所述连接信息采用所述目标服务器执行所述目标服务。

本申请实施例的装置可执行本申请实施例所提供的方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

本申请实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现服务器更新方法的步骤，与相关技术相比：

一方面：本申请实施例提供一种服务器更新方法，该方法具体为一种在不停服的情况下采用灰度迭代的更新方法，在服务器迭代更新的过程中采用验证版本的服务器作为服务器版本更新的对象，而服务器更新结束得到目标版本的服务器；其中，验证版本的服务器用于验证目标版本的服务器在提供服务时的响应操作是否满足预设要求。具体地，本申请针对验证版本的服务器循环执行版本更新操作，直至将所有当前版本的服务器更新为目标版本的服务器。其中，版本更新操作包括以下步骤：在当前版本的服务器集群中配置至少一台验证版本的服务器；在接收到基于目标服务所发起的服务器分配请求，且确定用于执行目标服务的服务器存在至少两个版本时，将高版本的服务器确定为目标服务器，并将目标服务器分配执行目标服务；若目标服务器为验证版本的服务器且对目标服务的响应操作满足预设要求，确定该目标服务器通过验证并更新为目标版本的服务器。其中，本申请设定目标版本的服务器版本高于验证版本的服务器版本，验证版本的服务器版本高于当前版本的服务器版本。本申请的实施在服务器更新的过程中仍可以向用户终端提供服务，在不停服的情况下完成所有服务器的更新，且将验证版本的服务器分配于执行客户端请求的目标服务，可以同步完成对验证版本服务器的验证，以将验证版本的服务器更新为目标版本的服务器；另外，本申请通过循环执行版本更新操作，可以在一定的时间内通过目标版本的服务器与当前版本的服务器之间的替换，实现对当前版本的服务器的淘汰，提高服务器更新的效率。

另一方面：本申请实施例还提供一种服务器更新方法，在该方法中，与上述服务器更新方法的区别在于服务器采用分区的形式进行管理，针对各分区的服务器采用负载均衡的策略进行服务器更新，可以在服务器更新的过程中有效均衡各分区的负载。

又一方面：本申请实施例还提供一种服务执行方法，在该方法中，用户终端响应于针对目标服务发起的匹配请求，执行与目标服务对应的匹配操作后向服务器发送服务器分配请求，并接收服务器执行上述服务器更新方法的过程中基于分配请求所分配的目标服务器的连接信息，继而基于连接信息采用目标服务器执行目标服务。其中，目标服务器可以是当前版本的服务器、验证版本的服务器，还可以是目标版本的服务器。本申请可以实现在服务器更新的过程中用户终端仍然可以请求服务器提供服务，对用户而言，服务器更新的处理并不影响其正在的使用且无任何感知，有利于提高用户体验。

在一个可选实施例中提供了一种电子设备，如图13所示，图13所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器4003用于存储执行本申请实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。

其中，电子设备包括但不限于：服务器、用户终端、车载设备。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是，虽然本申请实施例的流程图中通过箭头指令各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指令的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims

1.一种服务器更新方法，其特征在于，包括：

其中，所述版本更新操作包括：

2.根据权利要求1所述的方法，其特征在于，所述在当前版本的服务器集群中配置至少一台验证版本的服务器，包括：

3.根据权利要求2所述的方法，其特征在于，所述若所述目标服务器为验证版本的服务器且对所述目标服务的响应操作满足预设要求时，确定该目标服务器通过验证并更新为目标版本的服务器，包括：

4.根据权利要求3所述的方法，其特征在于，所述将该目标服务器更新为目标版本的服务器，还包括：

5.根据权利要求2所述的方法，其特征在于，所述在当前版本的服务器集群所对应的第一配置信息中，针对验证版本的服务器设置至少一条第二配置信息，还包括：

结束当前轮次的版本更新操作；

6.根据权利要求1所述的方法，其特征在于，所述将该目标服务器分配执行所述目标服务，包括：

7.根据权利要求1所述的方法，其特征在于，所述针对验证版本的服务器循环执行版本更新操作，直至将所述当前版本的服务器更新为目标版本的服务器，包括：

8.一种服务器更新方法，其特征在于，包括：

其中，所述版本更新操作包括：

获取各分区的负载信息；

9.一种服务执行方法，其特征在于，包括：

接收权利要求1-7和8中任一项基于所述分配请求所分配的目标服务器的连接信息；

基于所述连接信息采用所述目标服务器执行所述目标服务。

10.一种服务器更新装置，其特征在于，包括：

其中，所述版本更新操作包括：

11.一种服务器更新装置，其特征在于，服务器以分区形式进行管理，包括：

其中，所述版本更新操作包括：

获取各分区的负载信息；

12.一种服务执行装置，其特征在于，包括：

接收模块，用于接收权利要求1-7和8中任一项基于所述分配请求所分配的目标服务器的连接信息；

13.一种电子设备，其特征在于，包括存储器和处理器，其中，所述存储器中存储有计算机程序，所述处理器在运行所述计算机程序时用于执行权利要求1至9中任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述存储介质中存储有计算机程序，所述计算机程序在处理器中运行时，所述处理器用于执行权利要求1至9中任一项所述的方法。

15.一种计算机程序产品，其特征在于，所述计算机产品包括计算机程序，所述计算机程序被处理器执行时实现权利要求1至9中任一项所述的方法。