CN110180177B - 网络游戏的维护方法、装置、介质及电子设备 - Google Patents

Abstract

本公开涉及信息处理技术领域，具体而言，涉及一种网络游戏的维护方法、网络游戏的维护装置，以及实现上述网络游戏的维护方法的计算机可读介质和电子设备。其中，该方法包括：将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务；发布所述第二服务端的第二版本服务，以及发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端；关闭所述第一服务端，以完成对所述网络游戏的维护。本技术方案提供一种不停服维护方式，避免了通过停服来更新游戏服务带来的问题，能够使得玩家持续游戏，有利于提升玩家游戏体验。

Description

网络游戏的维护方法、装置、介质及电子设备

技术领域

本公开涉及信息处理技术领域，具体而言，涉及一种网络游戏的维护方法、网络游戏的维护装置，以及实现上述网络游戏的维护方法的计算机可读介质和电子设备。

背景技术

网络游戏，又称“在线游戏”是指以互联网为传输媒介，以游戏服务端和游戏客户端为处理终端的在线游戏。为了不断提升游戏玩家的游戏体验，则需不时地更新服务端所提供的游戏服务。

现有的相关技术中，一般通过停服方式实现网络游戏的维护。具体可以包括以下内容：提供游戏服务的服务器向游戏客户端推送消息，以通知游戏玩家将进行停机维护。维护期间所有在线用户下线，服务器保存用户数据并停止提供游戏服务，进一步地，服务器更新服务器代码和资源以及更新游戏客户端补丁。然后，发布服务器内网访问和客户端补丁内网下载，验证游戏是否正常。最后，发布服务器外网访问和客户端补丁外网下载，恢复用户登录游戏，从而完成一次网络游戏的维护。

可见，现有的相关技术在游戏维护期间由于需对游戏服务器进行停机而不能提供持续游戏服务，导致玩家游戏体验差。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开实施例的目的在于提供一种网络游戏的维护方法、网络游戏的维护装置，以及实现上述网络游戏的维护方法的计算机可读介质和电子设备，进而至少在一定程度上克服现有技术的不足。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开实施例的第一方面，提供了一种网络游戏的维护方法，所述方法包括：

将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务；

发布所述第二服务端的第二版本服务，以及发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端；

关闭所述第一服务端，以完成对所述网络游戏的维护。

在本公开的一些实施例，基于前述实施例，发布所述第二服务端的第二版本服务，包括：

发布所述第二服务端的非战斗服务，以及分批发布所述第二服务端的战斗服务；

将第二版本服务对应的第二服务版本标识更新至服务器列表中，以供第一客户端根据所述第二服务版本标识接入所述第二服务端，其中，维持所述第一服务端的第一服务版本标识存在于所述服务器列表中。

在本公开的一些实施例，基于前述实施例，在发布所述第二服务端的第二版本服务之后，所述方法还包括：

通过所述第二服务端接收来自所述第一客户端的服务调用请求，所述服务调用请求包括：游戏角色标识；

若根据所述游戏角色标识确定所述游戏角色未在所述第一服务端登录，则向所述第一客户端发送服务调用应答，并维护所述游戏角色对应的角色数据。

在本公开的一些实施例，基于前述实施例，在通过所述第二服务端接收来自所述第一客户端的服务调用请求之前，所述方法还包括：

确定所述第一客户端的补丁版本标识与所述第二服务版本标识相对应，其中，所述补丁版本标识是根据所述第二服务端/所述第一服务端发布的补丁包确定的。

在本公开的一些实施例，基于前述实施例，在发布所述第二服务端的第二版本服务之后，所述方法还包括：

通过所述第一服务端接收来自第二客户端的服务调用请求，所述服务调用请求包括：游戏角色标识；

若根据所述游戏角色标识确定所述游戏角色未在所述第二服务端登录，则向所述第二客户端发送服务调用应答和关于所述补丁包的更新提醒，并维护所述游戏角色对应的角色数据。

在本公开的一些实施例，基于前述实施例，在通过所述第一服务端接收来自第二客户端的服务调用请求之前，所述方法还包括：

确定所述第二客户端的补丁版本标识与所述第一服务标识一致，其中，所述补丁版本标识根据所述第二服务端/所述第一服务端发布的补丁包确定。

在本公开的一些实施例，基于前述实施例，所述补丁版本标识包括时间戳。

在本公开的一些实施例，基于前述实施例，在关闭所述第一服务端之前，所述方法还包括：

停止所述第一服务端的预设类型的服务，并开启所述第二服务端的所述预设类型的服务，其中，所述预设类型的服务包括：支付相关服务、单点服务；

获取接入所述第一服务端的第三客户端对应的账号信息，以根据所述账号信息确定关于所述第三客户端的服务策略，其中所述账号信息中包含游戏状态标识。

在本公开的一些实施例，基于前述实施例，根据所述账号信息确定关于所述第三客户端的服务策略，包括：

根据所述账号信息确定目标游戏角色的游戏状态；

若所述第三客户端对应的目标游戏角色处于战斗状态，则持续为所述第三客户端提供游戏服务；

若所述第三客户端对应的目标游戏角色处于非战斗状态，则向所述第三客户端推送关于所述补丁包的更新提醒。

在本公开的一些实施例，基于前述实施例，关闭所述第一服务端，包括：

响应于接入所述第一服务端的客户端数目小于预设数目阈值时，关闭所述第一服务端；或，

响应于发布所述第二版本服务的时长大于预设时长阈值时，关闭所述第一服务端。

本公开实施例的第二方面，提供了一种网络游戏的维护装置，包括：

服务更新模块，用于将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务；

服务发布模块，用于发布所述第二服务端的第二版本服务，以及发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端；

服务关闭模块，用于关闭所述第一服务端，以完成对所述网络游戏的维护。

根据本公开实施例的第三方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述实施例中第一方面所述的网络游戏的维护方法。

根据本公开实施例的第四方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中第一方面所述的网络游戏的维护方法。

本公开实施例提供的技术方案可以包括以下有益效果：

一方面，通过将第二服务端的游戏服务由第一版本服务更新为第二版本服务，同时维持第一服务端的游戏服务为所述第一版本服务。本实施例提供的技术方案在游戏维护期间同时提供更新前后两个版本的游戏服务。从而避免了通过停服来更新游戏服务带来的问题，能够使得玩家持续游戏，有利于提升玩家游戏体验。

另一方面，本实施例提供的技术方案中，通过述第二服务端提供更新后的第二版本服务，并且玩家客户端可以根据关于第二版本服务的补丁包接入第二服务端，从而玩家可以根据需求调用第一版本服务或第二版本服务。例如，维护过程中调用第一服务端的战斗游戏服务的客户端，无需因维护而停止战斗，其可以持续调用上述战斗游戏服务。可见，本实施例提供的技术方案不影响进行中的游戏服务(如上述战斗服务)，使得玩家对服务器的维护无感知，从而不会分散玩家注意力，进而不影响其游戏体验。

再一方面，在维护期间采用两套服务器进行切换，当达到预设条件时(将玩家从第一服务器导流到第二服务器的数目达到预设百分比时)，便关闭第一服务端，完成对网络游戏的一次维护。起到合理利用硬件资源，在保证不停服维护的基础上，减少开销成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了根据本公开的实施例的网络游戏的维护方法的流程示意图；

图2示出了根据本公开另一实施例的网络游戏的维护方法的流程示意图；

图3示出了根据本公开再一实施例的网络游戏的维护方法的流程示意图；

图4示出了根据本公开又一实施例的网络游戏的维护方法的流程示意图；

图5示出了根据本公开一实施例的网络游戏的维护方法的流程示意图；

图6示出了根据本公开另一实施例的网络游戏的维护方法的流程示意图；

图7示出了根据本公开的实施例的网络游戏的维护装置的结构示意图；

图8示意性示出一种用于实现上述订单配送路径的规划方法的计算机可读存储介质；以及，

图9示意性示出一种用于实现上述订单配送路径的规划方法的电子设备示例框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本公开的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

现有的停服维护方法中，在游戏维护期间，不仅玩家无法进行游戏或持续游戏；而且维护周期较长，将直接影响运营收入。

因此，针对于上述现有技术中存在的问题，有必要提供新的网络游戏维护方法为用户提供不间断的游戏服务，进而提高玩家的游戏体验，同时，降低维护成本，以保证游戏的运营收入。

图1示出了根据本公开的实施例的网络游戏的维护方法的流程示意图。本实施例提供的网络游戏的维护方法至少在一定程度上克服现有网络游戏的维护方法存在的以上缺点。其中，本实施例提供的网络游戏的维护方法的执行主体可以是具有计算处理功能的设备，比如服务器或移动终端等。

具体地，本实施例提供一种不停服维护网络的技术方案，而在不停机维护过程中主要解决多版本客户端补丁的逻辑与多个版本游戏服务器的协议之间的兼容性。而本实施例提供的技术方案应用于服务端。

参考图1，该实施例提供的网络游戏的维护方法包括步骤S110-步骤S130。

在步骤S110中，将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务。

在示例性的实施例中，上述第二服务端和第一服务端均为集群，并可以采用docker部署集群环境。在不停服维护期间，在每台物理机上启动两套docker环境。从而通过本方案，便能在固定的物理硬件条件下实现两套服务的维护流程而无需另外添加硬件，起到减少维护成本的技术效果。

在示例性的实施例中，在维持第一服务端的游戏服务为更新前版本(即上述第一版本服务)的情况下，将第二服务端的游戏服务由第一版本服务更新为第二版本服务。也就是说，在游戏维护期间，在不停止原游戏服务的情况下，启动一套部署了更新后的游戏服务的服务器/服务器集群来提供更新后的第二版本服务。在游戏维护期间同时提供更新前后两个版本的游戏服务，可以避免了通过停服来更新游戏服务带来的问题，从而能够使得玩家不间断游戏，有利于提升玩家游戏体验。

在步骤S120中，发布所述第二服务端的第二版本服务，以及发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端。

在示例性的实施例中，图2示出了根据本公开另一实施例的网络游戏的维护方法的流程示意图，具体可以作为步骤S120中发布所述第二服务端的第二版本服务的一种具体实施方式。参考图2，该实施例提供的方式包括步骤S210-步骤S220。

在步骤S210中，发布所述第二服务端的非战斗服务，以及分批发布所述第二服务端的战斗服务。

在示例性的实施例中，由于停服维护方案对于战斗中玩家的游戏体验影响较大，本实施例中将分别介绍战斗服务以及非战斗服务的启用以及调用。

在示例性的实施例中，通过步骤S110更新第二服务端的服务代码得到第一版本服务，并在对第二服务端的配置数据、网络数据检查检查之后，便可以启动第二服务端。具体地，在第二服务端为集群的情况下，可以启动共享集群服务以及非战斗集群服务和战斗集群服务。其中，可以通过分批启动战斗集群服务来尽量减少内存开销。进一步地，向公网发布第二服务端所提供的更新后的游戏服务。

在示例性的实施例中，向公网发布第二服务端所提供的更新后的游戏服务的同时，还发布关于上述第二版本服务的补丁包，以供客户端基于补丁包接入上述第二服务端，从而，调用第二服务端提供的上述非战斗集群服务、战斗集群服务，以实现向第二服务端的导流。

在步骤S220中，将第二版本服务对应的第二服务版本标识更新至服务器列表中，以供第一客户端根据所述第二服务版本标识接入所述第二服务端，其中，维持所述第一服务端的第一服务版本标识存在于所述服务器列表中。

在示例性的实施例中，在服务器列表(server list)上对两组不同集群环境添加服务版本标识(如上述第二版本服务对应的第二服务版本标识、第一版本服务对应的第一服务版本标识)，从而在不停服维护期间，客户端拉取玩家账号信息后，可以根据服务版本标识选择对应的集群进行连接，并在激活与所选择的服务版本标识对应客户端补丁之后，调用相关服务。

在示例性的实施例中，图3示出了根据本公开再一实施例的网络游戏的维护方法的流程示意图。具体的，不停服维护期间，在发布所述第二服务端的第二版本服务之后(即，同时存在更新前版本服务和更新后版本服务的状态下)，关于调用上述第二服务端所提供的游戏服务的一种具体实施方式。参考图3，该方法包括步骤S310-步骤S350。

在步骤S310中，确定第一客户端的补丁版本标识与所述第二服务版本标识相对应。

在示例性的实施例中，客户端的补丁版本标识是根据服务端发布的补丁包确定的，示例性的，服务端在每次更新游戏服务时生成一唯一的时间戳作为对应的补丁版本标识。例如，当第一版本服务之前的服务被更新为第一版本服务时，发布对应的具有第一补丁版本标识的客户端补丁，客户端下载此补丁之后，此时客户端的补丁版本标识为第一补丁版本标识。同理，当第二版本服务被更新为第二版本服务时，发布对应的具有第二补丁版本标识的客户端补丁，客户端下载此补丁之后，此时客户端的补丁版本标识为第二补丁版本标识。其中，上述第一客户端为待接入上述第二服务端的客户端。

服务端对不同的客户端的补丁版本进行校上述检查，避免客户端登录非对应版本的服务端而导致出现错误。如，避免仅具有第一补丁版本标识的客户端登入第二服务端，避免具有第二补丁版本标识的客户端登录低版本的第一服务端。

在步骤S320中，通过所述第二服务端接收来自所述第一客户端的服务调用请求，所述服务调用请求包括：游戏角色标识。

在示例性的实施例中，不停服维护过程中，存在提供更新前的游戏服务的第一服务集群与提供更新后的游戏服务的第二服务集群。对于同一个游戏角色只需维护一组数据，若两个服务器集群间发生数据互相覆盖，则不能保证角色数据的唯一，进而将由于角色数据错误导致角色表现异常，降低玩家的游戏体验。本实施例中，通过为每个游戏角色设置唯一标识的方式解决上述问题。

在示例性的实施例中，本实施例提供的游戏角色标识的确定方法可以是：根据表征已经在相同服务端创建的所有游戏角色的数量的第一数值进行预设计算得到第二数值，然后直接根据预设算法对游戏角色s对应的第二数值进行计算得到唯一标识信息，即得到游戏角色s对应的游戏角色标识。本实施例提供的游戏角色标识的确定方法，一方面，可以无需通过访问数据库来创建角色，使得角色创建时间缩短且避免了对游戏服务器端性能的高消耗，减少了玩家创建角色时游戏服务器端的负载压力。另一方面，可以间接提高游戏服务端的性能，有利于增强玩家的游戏体验。

在步骤S330中，根据所述游戏角色标识判断所述游戏角色是否在所述第一服务端登录。

在示例性的实施例中，由于上述游戏角色标识是唯一的，若根据所述游戏角色标识判断到游戏角色a已在所述第一服务端登录，则执行步骤S340：舍弃来自所述第一客户端的服务调用请求。也就是说，通过阻止向已在其他服务端登录的客户端提供游戏服务，进而避免两个服务器集群间同时作用于游戏角色a的角色数据，从而保证游戏角色a的角色数据唯一。

在示例性的实施例中，由于上述游戏角色标识是唯一的，若根据所述游戏角色标识判断到游戏角色a未在所述第一服务端登录，则执行步骤S350：向所述第一客户端发送服务调用应答，并维护所述游戏角色对应的角色数据。其中，服务调用应答可以是更新后的战斗服务、更新后的非战斗服务。

在示例性的实施例中，图4示出了根据本公开又一实施例的网络游戏的维护方法的流程示意图。具体的，不停服维护期间，在发布所述第二服务端的第二版本服务之后(即，同时存在更新前版本服务和更新后版本服务的状态下)，关于调用上述第一服务端所提供的游戏服务的一种具体实施方式。参考图4，该方法包括步骤S410-步骤S450。

在步骤S410中，确定第二客户端的补丁版本标识与所述第一服务版本标识相对应。

其中，上述第二客户端为待接入所述第一服务端的客户端。同前所述，客户端的补丁版本标识是根据服务端发布的补丁包确定的。当第一版本服务之前的服务被更新为第一版本服务时，发布对应的具有第一补丁版本标识的客户端补丁，客户端下载此补丁之后，此时客户端的补丁版本标识为第一补丁版本标识。通过服务端对不同的客户端的补丁版本进行校上述检查，能够避免客户端登录非对应版本的服务端而导致出现错误。

在步骤S420中，通过所述第一服务端接收来自所述第二客户端的服务调用请求，所述服务调用请求包括：游戏角色标识。

同前所述，本实施例中，通过为每个游戏角色设置唯一标识的方式解决上述问题。

在步骤S430中，根据所述游戏角色标识判断所述游戏角色是否在所述第二服务端登录。

在示例性的实施例中，由于上述游戏角色标识是唯一的，若根据所述游戏角色标识判断到游戏角色b已在所述第二服务端登录，则执行步骤S440：舍弃来自所述第二客户端的服务调用请求。也就是说，通过阻止向已在其他服务端登录的客户端提供游戏服务，进而避免两个服务器集群间同时作用于游戏角色b的角色数据，从而保证游戏角色b的角色数据唯一。

在示例性的实施例中，由于上述游戏角色标识是唯一的，若根据所述游戏角色标识判断到游戏角色b未在所述第二服务端登录，则执行步骤S450：向所述第二客户端发送服务调用应答以及关于所述补丁包的更新提醒，并维护所述游戏角色对应的角色数据。其中，服务调用应答可以是战斗服务、非战斗服务。

由于不停服维护期间，通过向接入第一服务端的客户端推送更新提醒，以实现玩家由第一服务端向第二服务端的导流，从而尽快关闭第一服务端，进而减少系统开销。

在示例性的实施例中，图5示出了根据本公开一实施例的网络游戏的维护方法的流程示意图。具体的，不停服维护期间，在关闭上述第一服务端之前，两服务端中提供相关服务的一种具体实施方式。参考图5，该方法包括步骤S510和步骤S520。

在步骤S510中，停止所述第一服务端的预设类型的服务，并开启所述第二服务端的所述预设类型的服务，其中，所述预设类型的服务包括：支付相关服务、单点服务。

在示例性的实施例中，为了进一步保证不停服维护期间敏感服务(如，支付类服务)、单点服务等数据一致性，则停止第一服务端的预设类型的服务，然后开启第二服务端的所述预设类型的服务。其中，上述预设类型的服务包括：支付相关服务、单点服务等。

在步骤S520中，获取接入所述第一服务端的第三客户端对应的账号信息，以根据所述账号信息确定关于所述第三客户端的服务策略，其中所述账号信息中包含游戏状态标识。

在示例性的实施例中，在关闭第一服务端之前需进行向第二服务端导流。然而，导流过程中，应保证处于战斗中的玩家不间断其游戏状态。因此，本实施例提供的技术方案中判断接入上述第一服务端的第三客户端是否处于战斗状态，并根据判断结果对不同客户端实时不同的服务策略。

在示例性的实施例中，图6示出了根据本公开另一实施例的网络游戏的维护方法的流程示意图。具体为根据账号信息确定关于第三客户端的服务策略的方法，可以作为步骤S520的一种具体实施方式。参考图6，给方法包括步骤S610-步骤S640。

在步骤S610中，根据所述账号信息确定目标游戏角色的游戏状态。

在示例性的实施例中，服务端向客户端提供战斗服务时，在数据库账号信息上更新battle_version字段，用于标识处于战斗。从而，可以根据账号信息中包含的游戏状态标识判断接入第一服务端的客户端是否处于战斗状态。

相较于相关技术中，通过在客户端记录一个处于战斗中的本地标记位，当玩家重启游戏、重入战斗时候检查标记位，能够使玩家客户端跳过更新补丁，实现用旧版本的客户端进入旧版本的战斗。本技术方案支持单账号多服多角色的结构。并且，玩家更换设备登陆、顶号时，不免出现由于新设备上并无本地标记而导致资源、脚本版本不一致带来的表现错误的问题。

在步骤S620中，判断所述第三客户端对应的目标游戏角色是否处于战斗状态。

在示例性的实施例中，若所述第三客户端对应的目标游戏角色处于战斗状态，则执行步骤S630：持续为所述第三客户端提供游戏服务。

在示例性的实施例中，对于处于战斗中的玩家客户端，为保证玩家的战斗体验，不停服维护期间需要支持不中断战斗(包括断线、顶号、换设备)。

在示例性的实施例中，若所述第三客户端对应的目标游戏角色处于战斗状态，则执行步骤S640：若所述第三客户端对应的目标游戏角色处于非战斗状态，则向所述第三客户端推送关于所述补丁包的更新提醒。

在示例性的实施例中，若所述第三客户端对应的目标游戏角色处于战斗状态，除了向第三客户端推动上述更新提醒之外，还可以在关闭第一服务端之前继续向第三客户端提供游戏服务(除了上述预设类型的服务之外)。从而，玩家也可以选择暂时不更新客户端补丁。另外，若玩家选择更新客户端补丁的话，便可以重启客户端游戏应用并下载安装上述补丁包之后，表可以直接登录第二服务端。由于更新过程耗时短，且不存在停服维护的问题，从而基本不影响非战斗玩家的游戏体验。

根据图5和图6所示实施例提供的技术方案，玩家可以根据需求调用第一版本服务或第二版本服务。例如，维护过程中调用第一服务端的战斗游戏服务的客户端，无需因维护而停止战斗，其可以持续调用上述战斗游戏服务。可见，本实施例提供的技术方案不影响进行中的游戏服务(如上述战斗服务)，使得玩家对服务器的维护无感知，从而不会分散玩家注意力，进而不影响其游戏体验。

继续参考图1，在步骤S130中，关闭所述第一服务端，以完成对所述网络游戏的维护。

在示例性的实施例中，在发布第二服务端的第二版本服务之后，除了为了保障数据一致性而关闭上述预设类型的服务(支付类敏感服务、点单服务)之外，还为了节省内存开销，关闭没有接入客户端的战斗服务进程。

在示例性的实施例中，综合考虑玩家游戏体验与维护成本等因素来确定第一服务端的关闭条件。例如，可以响应于接入所述第一服务端的客户端数目小于预设数目阈值时，关闭所述第一服务端。还可以响应于发布所述第二版本服务的时长大于预设时长阈值时，关闭所述第一服务端。当然还可以综合考虑接入所述第一服务端的客户端数目和发布所述第二版本服务的时长两方面因素，确定是否关闭第一服务端。在合理利用硬件资源以及不停服维护的基础上，减少开销成本。从而完成对网络游戏的一次不停服维护。

需要说明的是，以上各个实施例本实施例提供的技术方案应用于服务端。由于本技术方案提供一种不停服维护网络的技术方案，而在不停机维护过程中主要解决多版本客户端补丁的逻辑与多个版本游戏服务器的协议之间的兼容性。在服务端基于以上实施例的基础上，以下实施例提供的技术方案应用于客户端。

在上述实施例提供的不停服维护方案的实现中，服务端采用的是第一服务端和第二服务端方案，即维护期间会存在新/旧两个版本的游戏服务。另外，由于客户端补丁需要玩家重启游戏应用之后才会进行补丁包下载，那么同时会存在部分玩家使用了新版本的客户端而其他玩家使用旧版本的客户端。

在示例性的实施例中，客户端更新补丁的方法可以包括：通过从服务端发布的第一补丁包中获取第一文件版本信息，其中，第一补丁包为服务端中补丁包版本号最大的补丁包，第一文件版本信息包括服务端中多个游戏文件的文件版本号，并基于第一文件版本信息，确定客户端对应的目标文件版本号，然后从服务端发布的第二补丁包中，获取目标文件版本号对应的目标游戏文件，并采用目标游戏文件进行游戏更新，第二补丁包为与目标文件版本号对应的补丁包。从而实现了结合全量模式和增量模式的客户端游戏逻辑的更新模式，减小了服务端每次发布补丁包的大小，且无需客户端下载多个补丁包进行依次更新，当在多个补丁包均存在同一文件的修改版本时，客户端也无需重复下载更新。

在示例性的实施例中，为了达到按版本标识进行访问服务端的目标，客户端在下载补丁(Patch)包后采取了“Patch分组”的方案来实现。具体的，当每次服务端需要进行不停机更新的时候，都对应生成一唯一的时间戳。从而通过时间戳唯一确定提供某一个版本游戏服务的服务端。示例性的，在服务端制作patch的时候，设置该Patch的补丁版本标记为对应时间戳进行发布，以供客户端下载。

在示例性的实施例中，客户端进行Patch下载后，根据所下载Patch的补丁版本标记(即时间戳)，分别将不同时间戳的Patch放置到不同的访问目录下。当客户端需要支持N个游戏服务版本的服务端访问的时候，可以将访问目录分为n个，分别是Patch[1,2,3…N-1,Other]。其中，分组后的每一个Patch[i]组都对应一次不停机维护得到的游戏服务版本。

具体地，当客户端下载一个新Patch的时候，检查此最新Patch目录的时间戳标记，如果时间戳标记为更新，则将此新下载的Patch合并到Patch[1]中。当服务器标记更新时，则依次将Patch[i]设置为Patch[i+1]，并将Patch[N-1]中的内容合并到Patch[other]中；并重新建立一个Patch[1]，用于放置此新下载的Patch。

在示例性的实施例中，根据时间戳的新旧确定不同分组Patch访问目录的优先级，在客户端进行文件访问时，如果多个版本的Patch中都对同一个文件有进行更新的话，那么对时间戳更新的Patch访问目录的访问，会截断对老版本文件的访问。从而实现对文件访问的管理。

在示例性的实施例中，当客户端需接入服务端以获取游戏服务时，根据所需接入服务端所提供的游戏服务版本，确定对应的补丁版本，进而确定目标Patch[i]组。从而方便地屏蔽其他Patch组访问目录的有效性，进而也就达到了将客户端的逻辑回退到相应游戏服务版本。这样在与服务端进行协议交互的时候，就不会出现服务端-客户端版本不一致导致的报错或客户端表现的错误。

相关技术的一种不停机维护方案中，在客户端的代码逻辑中，对所有版本的游戏逻辑进行兼容。其客户端代码需向上兼容，难以对所有的场景进行测试。并且，相关技术只能兼容老版本脚本但不能兼容老版本资源。相较于此现有的不停机维护方案，本实施例提供的技术方案中极大地简化客户端逻辑，降低不停机维护的复杂度，同时降低了开发人员与测试人员的工作量。

相关技术的一种不停机维护方案中，客户端登陆服务端时判断需要进入哪个服务端以及服务端版本，如果服务器较旧，就把客户端Patch回滚到相应版本再进入游戏。这种方案的缺点在于需反复下载Patch，Patch回滚后如果玩家需要进入新版本的服务器，则可能又要重新下载之前已经更新过的资源、脚本内容。相较于此现有的不停机维护方案，本实施例提供的技术方案中无需反复下载Patch，造成资源浪费。

以下介绍本公开的装置实施例，可以用于执行本公开上述的网络游戏的维护方法。

图7示出了根据本公开的实施例的网络游戏的维护装置的结构示意图。

参考图7，上述网络游戏的维护装置700，包括：服务更新模块701、服务发布模块702和服务关闭模块703。

其中，上述服务更新模块701，用于将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务；

上述服务发布模块702，用于发布所述第二服务端的第二版本服务，以及发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端；

上述服务关闭模块703，用于关闭所述第一服务端，以完成对所述网络游戏的维护。

在本公开的一些实施例，基于前述实施例，上述服务发布模块702，包括：服务发布单元和标识更新单元；

其中，上述服务发布单元用于：发布所述第二服务端的非战斗服务，以及分批发布所述第二服务端的战斗服务；

上述标识更新单元用于：将第二版本服务对应的第二服务版本标识更新至服务器列表中，以供第一客户端根据所述第二服务版本标识接入所述第二服务端，其中，维持所述第一服务端的第一服务版本标识存在于所述服务器列表中。

在本公开的一些实施例，基于前述实施例，所述网络游戏的维护装置700还包括：第一接收模块、第一发送模块。

在上述服务发布模块702发布所述第二服务端的第二版本服务之后，上述第一接收模块用于：通过所述第二服务端接收来自所述第一客户端的服务调用请求，所述服务调用请求包括：游戏角色标识；

若根据所述游戏角色标识确定所述游戏角色未在所述第一服务端登录，则上述第一发送模块用于：向所述第一客户端发送服务调用应答，并维护所述游戏角色对应的角色数据。

在本公开的一些实施例，基于前述实施例，所述网络游戏的维护装置700还包括：第一确定模块。

在上述第一发送模块通过所述第二服务端接收来自所述第一客户端的服务调用请求之前，上述第一确定模块用于：确定所述第一客户端的补丁版本标识与所述第二服务版本标识相对应，其中，所述补丁版本标识是根据所述第二服务端/所述第一服务端发布的补丁包确定的。

在本公开的一些实施例，基于前述实施例，所述网络游戏的维护装置700还包括：第二接收模块、第二发送模块。

在上述服务发布模块702发布所述第二服务端的第二版本服务之后，上述第二接收模块用于：通过所述第一服务端接收来自第二客户端的服务调用请求，所述服务调用请求包括：游戏角色标识；

若根据所述游戏角色标识确定所述游戏角色未在所述第二服务端登录，则上述第二发送模块用于：向所述第二客户端发送服务调用应答和关于所述补丁包的更新提醒，并维护所述游戏角色对应的角色数据。

在本公开的一些实施例，基于前述实施例，所述网络游戏的维护装置700还包括：第二确定模块。

在上述第二接收模块通过所述第一服务端接收来自第二客户端的服务调用请求之前，上述第二确定模块用于：确定所述第二客户端的补丁版本标识与所述第一服务标识一致，其中，所述补丁版本标识根据所述第二服务端/所述第一服务端发布的补丁包确定。

在本公开的一些实施例，基于前述实施例，所述补丁版本标识包括时间戳。

在本公开的一些实施例，基于前述实施例，所述网络游戏的维护装置700还包括：服务停止模块、服务策略确定模块。

在上述服务关闭模块703关闭所述第一服务端之前，上述服务停止模块用于：停止所述第一服务端的预设类型的服务，并开启所述第二服务端的所述预设类型的服务，其中，所述预设类型的服务包括：支付相关服务、单点服务；

上述服务策略确定模块用于：获取接入所述第一服务端的第三客户端对应的账号信息，以根据所述账号信息确定关于所述第三客户端的服务策略，其中所述账号信息中包含游戏状态标识。

在本公开的一些实施例，基于前述实施例，上述服务策略确定模块，包括：游戏状态确定单元、战斗服务单元和非战斗服务单元。

其中，上述游戏状态确定单元用于：根据所述账号信息确定目标游戏角色的游戏状态；

若所述第三客户端对应的目标游戏角色处于战斗状态，则上述战斗服务单元用于：持续为所述第三客户端提供游戏服务；

若所述第三客户端对应的目标游戏角色处于非战斗状态，则上述非战斗服务单元用于：向所述第三客户端推送关于所述补丁包的更新提醒。

在本公开的一些实施例，基于前述实施例，上述服务关闭模块703具体用于：

响应于接入所述第一服务端的客户端数目小于预设数目阈值时，关闭所述第一服务端；或，

响应于发布所述第二版本服务的时长大于预设时长阈值时，关闭所述第一服务端。

由于本公开的示例实施例的网络游戏的维护装置的各个功能模块与上述网络游戏的维护方法的示例实施例的步骤对应，因此对于本公开装置实施例中未披露的细节，请参照本公开上述的网络游戏的维护方法的实施例。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的订单配送路径的规划方法。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。

参考图8所示，描述了根据本公开的实施方式的用于实现上述方法的程序产品800，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于：电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

下面参照图9来描述根据本公开的这种实施方式的电子设备900。图9显示的电子设备900仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：上述至少一个处理单元910、上述至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元910执行，使得所述处理单元910执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。例如，所述处理单元910可以执行如图1中所示的：步骤S110，将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务；步骤S120，发布所述第二服务端的第二版本服务，以及发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端；步骤S130，关闭所述第一服务端，以完成对所述网络游戏的维护。

存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)9201和/或高速缓存存储单元9202，还可以进一步包括只读存储单元(ROM)9203。

存储单元920还可以包括具有一组(至少一个)程序模块9205的程序/实用工具9204，这样的程序模块9205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备900也可以与一个或多个外部设备1000(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备900交互的设备通信，和/或与使得该电子设备900能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口950进行。并且，电子设备900还可以通过网络适配器960与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器960通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

此外，上述附图仅是根据本公开示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

Claims (12)

1.一种网络游戏的维护方法，其特征在于，应用于服务端，包括：

将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务；

发布所述第二服务端的非战斗服务，以及分批发布所述第二服务端的战斗服务；

将所述第二版本服务对应的第二服务版本标识更新至服务器列表中，以供第一客户端根据所述第二服务版本标识接入所述第二服务端；其中，维持所述第一服务端的第一服务版本标识存在于所述服务列表中；

发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端；

关闭所述第一服务端，以完成对所述网络游戏的维护。

2.根据权利要求1所述的网络游戏的维护方法，其特征在于，在发布所述第二服务端的第二版本服务之后，所述方法还包括：

通过所述第二服务端接收来自所述第一客户端的服务调用请求，所述服务调用请求包括：游戏角色标识；

若根据所述游戏角色标识确定所述游戏角色未在所述第一服务端登录，则向所述第一客户端发送服务调用应答，并维护所述游戏角色对应的角色数据。

3.根据权利要求2所述的网络游戏的维护方法，其特征在于，在通过所述第二服务端接收来自所述第一客户端的服务调用请求之前，所述方法还包括：

确定所述第一客户端的补丁版本标识与所述第二服务版本标识相对应，其中，所述补丁版本标识是根据所述第二服务端/所述第一服务端发布的补丁包确定的。

4.根据权利要求1所述的网络游戏的维护方法，其特征在于，在发布所述第二服务端的第二版本服务之后，所述方法还包括：

通过所述第一服务端接收来自第二客户端的服务调用请求，所述服务调用请求包括：游戏角色标识；

若根据所述游戏角色标识确定所述游戏角色未在所述第二服务端登录，则向所述第二客户端发送服务调用应答和关于所述补丁包的更新提醒，并维护所述游戏角色对应的角色数据。

5.根据权利要求4所述的网络游戏的维护方法，其特征在于，在通过所述第一服务端接收来自第二客户端的服务调用请求之前，所述方法还包括：

确定所述第二客户端的补丁版本标识与所述第一服务标识一致，其中，所述补丁版本标识根据所述第二服务端/所述第一服务端发布的补丁包确定。

6.根据权利要求3或4所述的网络游戏的维护方法，其特征在于，所述补丁版本标识包括时间戳。

7.根据权利要求1所述的网络游戏的维护方法，其特征在于，在关闭所述第一服务端之前，所述方法还包括：

停止所述第一服务端的预设类型的服务，并开启所述第二服务端的所述预设类型的服务，其中，所述预设类型的服务包括：支付相关服务、单点服务；

获取接入所述第一服务端的第三客户端对应的账号信息，以根据所述账号信息确定关于所述第三客户端的服务策略，其中所述账号信息中包含游戏状态标识。

8.根据权利要求7所述的网络游戏的维护方法，其特征在于，根据所述账号信息确定关于所述第三客户端的服务策略，包括：

根据所述账号信息确定目标游戏角色的游戏状态；

若所述第三客户端对应的目标游戏角色处于战斗状态，则持续为所述第三客户端提供游戏服务；

若所述第三客户端对应的目标游戏角色处于非战斗状态，则向所述第三客户端推送关于所述补丁包的更新提醒。

9.根据权利要求1所述的网络游戏的维护方法，其特征在于，关闭所述第一服务端，包括：

响应于接入所述第一服务端的客户端数目小于预设数目阈值时，关闭所述第一服务端；或，

响应于发布所述第二版本服务的时长大于预设时长阈值时，关闭所述第一服务端。

10.一种网络游戏的维护装置，其特征在于，应用于服务端，包括：

服务更新模块，用于将第二服务端的游戏服务由第一版本服务更新为第二版本服务，并维持第一服务端的游戏服务为所述第一版本服务；

发布战斗服务模块，用于发布所述第二服务端的非战斗服务，以及分批发布所述第二服务端的战斗服务；

接入模块，用于将所述第二版本服务对应的第二服务版本标识更新至服务器列表中，以供第一客户端根据所述第二服务版本标识接入所述第二服务端；其中，维持所述第一服务端的第一服务版本标识存在于所述服务列表中；

服务发布模块，发布关于所述第二版本服务的补丁包，以供客户端基于所述补丁包接入所述第二服务端；

服务关闭模块，用于关闭所述第一服务端，以完成对所述网络游戏的维护。

11.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至9中任一项所述的网络游戏的维护方法。

12.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至9中任一项所述的网络游戏的维护方法。

Images