CN111026425A - 服务更新方法、装置、服务器及介质 - Google Patents

Abstract

本申请公开了一种服务更新方法、装置、服务器及计算机可读存储介质，属于网络技术领域。本申请实施例提供的技术方案，通过将待更新的服务区分为关键和非关键，从而对关键服务进行轮动更新，而对非关键服务直接进行更新，采用不同的更新方式进行服务更新，可以使得热更新场景下能够最大程度上的避免对正常服务运行造成影响，可以在保证用户无感知的情况下，完成服务的更新，还能够提高用户的使用体验。

Description

服务更新方法、装置、服务器及介质

技术领域

本申请涉及网络技术领域，特别涉及一种服务更新方法、装置、服务器及计算机可读存储介质。

背景技术

随着网络技术的发展，应用服务更新的频率也越来越高，为了在更新过程中不影响用户的正常使用，通常可以在服务器侧采用热更新的方式来进行，例如，对于一些线上游戏来说，可以在新服务集群中提供更新后的游戏服务，将用户接口层切换至已更新的新服务集群，新用户会直接接入新服务集群，再等待原服务集群上所接入的老用户自然退出。

然而，上述热更新方式需要大量的硬件资源才能实现，其成本消耗代价巨大，且老用户无法在原服务集群中使用到更新后的游戏服务，实际上并没有达到无感知更新的目的，影响正常服务的运行，也会降低用户的使用体验。

发明内容

本申请实施例提供了一种服务更新方法、装置、服务器及计算机可读存储介质，可以实现无感知的更新，避免对正常服务的运行造成影响，还能够提高用户的使用体验。所述技术方案如下：

一方面，提供了一种服务更新方法，所述方法包括：

根据待更新服务的服务类型，将所述待更新服务划分为关键服务和非关键服务；

暂停所述非关键服务的运行，对所述非关键服务进行更新；

对于所述关键服务中的任一服务，保持所述服务中一部分子服务处于运行状态，暂停所述服务中另一部分子服务的运行，对所述另一部分子服务进行更新，将更新完成的子服务切换至运行状态，对未更新的子服务继续进行更新。

一方面，提供了一种服务更新装置，其特征在于，所述装置包括：

服务划分模块，用于根据待更新服务的服务类型，将所述待更新服务划分为关键服务和非关键服务；

第一更新模块，用于暂停所述非关键服务的运行，对所述非关键服务进行更新；

第二更新模块，用于对于所述关键服务中的任一服务，保持所述服务中一部分子服务处于运行状态，暂停所述服务中另一部分子服务的运行，对所述另一部分子服务进行更新，将更新完成的子服务切换至运行状态，对未更新的子服务继续进行更新。

在一种可能实现方式中，所述第二更新模块用于：保持所述服务中属于主服务身份的子服务处于运行状态，暂停所述服务中属于备服务身份的子服务的运行。

在一种可能实现方式中，所述第二更新模块用于：对于场景服务，将第一场景服务中的用户迁移至第二场景服务，保持所述第二场景服务的运行，在迁移完成后，暂停所述第一场景服务的运行。

在一种可能实现方式中，所述第一更新模块用于：通知运行有所述非关键服务的第一服务器暂停运行，从服务路由目录中删除所述第一服务器，所述服务路由目录用于记录各个服务的服务器的路由信息；对所述第一服务器进行重启，在重启后更新所述非关键服务，当更新完成后，将更新后的第一服务器添加至所述服务路由目录中。

在一种可能实现方式中，所述装置还包括：

版本更新模块，用于当任一服务的更新过程中，在服务路由目录中更新所述服务的版本信息；访问控制模块，用于当接收到任一业务请求时，根据所述服务路由目录中所记录的版本信息对所述业务请求进行访问控制。

在一种可能实现方式中，所述访问控制模块，用于根据所述业务请求所携带的版本信息，从所述服务路由目录中确定目标服务器，所述目标服务器的版本信息与所述所携带的版本信息匹配；基于所述目标服务器响应所述业务请求。

在一种可能实现方式中，所述访问控制模块，用于根据所述业务请求所携带的版本信息，判断所述业务请求所指示的服务器的版本信息与所述业务请求所携带的版本信息是否匹配，若不匹配，则拒绝所述业务请求。

一方面，提供了一种服务器，所述服务器包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条指令，所述指令由所述一个或多个处理器加载并执行以实现所述服务更新方法所执行的操作。

一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现所述服务更新方法所执行的操作。

本申请实施例提供的技术方案，通过将待更新的服务区分为关键和非关键，从而对关键服务进行轮动更新，而对非关键服务直接进行更新，采用不同的更新方式进行服务更新，可以使得热更新场景下能够最大程度上的避免对正常服务运行造成影响，可以在保证用户无感知的情况下，完成服务的更新，还能够提高用户的使用体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种服务更新方法的实施环境的示意图；

图2是本申请实施例提供的一种服务集群的架构示意图；

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

图4是本申请实施例提供的一种服务更新的方法的流程图；

图5是本申请实施例提供的一种对场景服务进行更新的示例性流程图；

图6是本申请实施例提供的一种在服务集群内部进行服务更新的整体示意性流程图；

图7是本申请实施例提供的一种新旧版本的对比示意图；

图8是本申请实施例提供的一种场景服务和帮派服务之间的版本共存对比图；

图9是本申请实施例提供的一种路由示意图；

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

图11是本申请实施例提供的一种服务器的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

图1是本申请实施例提供的一种服务更新方法的实施环境的示意图，参见图1，该实施环境中包括服务集群100，该服务集群中包括多个服务器110。

服务器110可以是云计算平台、虚拟化中心等。服务器110用于为终端140上所安装的应用程序提供后台服务。可选地，以游戏服务器为例，服务器110承担主要游戏处理工作，终端110承担次要游戏处理工作；或者，服务器110承担次要游戏处理工作，终端110承担主要游戏处理工作；或者，服务器110或终端110分别可以单独承担游戏处理工作。

在本申请实施例中，可以将该服务更新方法应用于服务集群100中，可选地，服务器110包括：全局服务器(General server，GS)、场景服务器和数据库。全局服务器用于为终端140提供例如用户登录、数据处理负载均衡等服务，例如调度、邮件、帮派、家园等服务。场景服务器用于提供场景有关的后台服务。该数据库可以包括用户游戏数据、游戏配置数据以及素材等，基于服务器所提供的不同服务可以对应于不同数据库，场景服务器可以是一台或多台，不同场景服务器上可以运行有不同场景。当场景服务器是多台时，存在至少两台场景服务器用于提供不同的服务，和/或，存在至少两台场景服务器用于提供相同的服务，比如以负载均衡方式提供同一种服务，本申请实施例对此不加以限定。

终端140可以泛指多个终端中的一个，本实施例仅以终端140来举例说明。

本领域技术人员可以知晓，上述终端的数量可以更多或更少。比如上述终端可以仅为一个，或者上述终端为几十个或几百个，或者更多数量，此时上述实施环境中还包括其他终端。本申请实施例对终端的数量和设备类型不加以限定。

上述实施例所提供的系统架构中，服务集群通过在各个服务器上运行后台程序，来为终端提供服务，这些服务可以按照其重要程度分为关键服务和非关键服务，关键服务可以是指用户在使用应用程序时会实时感知的服务，非关键服务可以是指用户在使用应用程序时不会实时感知的服务，这些服务一般不太会变动，即使有变动因为本身是无状态的服务，当然，还可以包括一些有状态的服务，也即是，可以理解为非关键服务是应用程序的一些附加服务，不会影响用户对应用程序基本功能的使用。

例如，对于游戏应用来说，参见图2，其已有服务可以包括场景(scene)服务、邮件(mail)服务、标识(freeid)服务、大厅(world)服务(用于提供用户登录服务)、调度(schedule)服务、路由(route)服务、帮派(Social)服务、家园(home)服务、拍卖行(auction)服务等。

其中，场景服务，对于玩家来说至关重要，玩家无时无刻都处于某一个场景中，因此，可以将其划分为关键服务；场景服务可以基于其场景个数运行于多个场景服务器上，例如图2所示，该图2所示的服务集群中包括三台场景服务器，每个场景服务器上运行有三个场景服务。由于场景服务的数据量相对较大，因此，可以采用独立服务器专门提供场景服务，而在其他全局服务器上来运行其他服务，本申请实施例对此不做限定。

邮件服务，对于玩家来说，与其他玩家进行游戏时，收发邮件是一个基本功能，因此，也可以将其划分为关键服务；标识申请服务，用于分配标识，对于玩家来说必不可少，因此，也可以将其划分为关键服务；大厅(world)服务是玩家在登录应用程序时必不可少的服务，例如玩家在登录应用程序时均需要进行登录大厅的阶段，因此，也可以将其划分为关键服务。

调度(schedule)服务、路由(route)服务，属于服务治理相关功能，一般不太会变动，即使有变动因为本身是无状态的服务，可以将其划分为非关键服务。

帮派(Social)服务、家园(home)服务、拍卖行(auction)服务等有状态服务，可以是游戏中附加的一些功能，可以将其划分为非关键服务。

上述除场景服务以外的服务可以运行于全局服务器上，如图2所示，该图2所示的服务集群中可以包括有两台全局服务器，该两台全局服务器GS1和GS2可以分别运行有主备调度服务等。

基于上述的关键服务和非关键服务的划分，可以将服务集群内的各个服务在热更新时进行分类，对于不同类型的服务，可以采用不同的更新方式，以便服务集群能够在为用户提供基本的运行功能的同时，保障热更新的实现。例如，对于关键服务，可以在保证服务持续可用的情况下，采取轮动更新的方式进行更新，例如，针对上述图2中的三台场景服务器，则可以将其分为三组，逐步轮动更新，而对于非关键服务，可以采用在更新期间暂停服务来进行更新，更新后重启的方式进行。

图3是本申请实施例提供的一种服务更新的方法的流程图，参见图3，仅以服务集群的更新过程为例进行说明，具体可以包括下述步骤。

301、服务器根据待更新服务的服务类型，将该待更新服务划分为关键服务和非关键服务。

该服务器可以是服务集群中的一台用于对更新进行调度的服务器，也可以是由服务集群的调度服务来进行，本申请实施例对此不做限定。需要说明的是，上述划分过程可以是在更新之前划分完成，并在服务器上存储其划分结果，在后续热更新的过程中，可以直接应用该划分结果对属于不同类型的服务进行不同方式的更新。

需要说明的是，上述划分关键服务和非关键服务可以是基于服务的使用人次或者服务在用户的使用行为中的使用次数占比来确定，例如，关键服务可以是应用程序中使用人次大于全服人数的目标比例，例如，对于场景服务，每个用户均会使用场景服务，也即是，使用人次等于全服人数，则该场景服务为关键服务。而对于拍卖行服务，其使用次数人次小于全服人数的目标比例，则可以将其划分为非关键服务。

对于不同的应用程序，可以根据其服务的实际使用情况来识别上述关键服务和非关键服务，以便基于不同应用程序来进行适合其实际服务结构的更新流程，本公开实施例对此不做限定。

302、该服务器暂停非关键服务的运行，对该非关键服务进行更新。

对于非关键服务，服务器可以通知运行有该非关键服务的第一服务器暂停运行，从服务路由目录中删除该第一服务器，该服务路由目录用于记录各个服务的服务器的路由信息；对该第一服务器进行重启，在重启后更新该非关键服务，当更新完成后，将更新后的第一服务器添加至该服务路由目录中。

其中，服务路由目录用于为用户提供服务的路由服务，当用户发出任一业务请求时，则可以基于该服务路由目录来将业务请求转发给相应服务器进行响应，而若在某一个服务器被暂停运行时将其从服务路由目录中删除，则可以使得请求目标为该服务器的业务请求不被响应，也就不会造成错误处理的情况出现，而当该第一服务器重启后可以直接更新该非关键服务，在更新完成后，再将其添加回服务路由目录中，以使其能够开始正常提供服务。

需要说明的一点是，上述暂停运行和从服务路由目录中删除第一服务器的步骤还可以为先删除第一服务器，再暂停运行，以保证在暂停运行之前不会再有新的业务请求被路由至该第一服务器。

需要说明的另一点是，上述非关键服务包括多种服务，对于这多种服务，可以按照服务集群的热更新能力进行更新，例如，当服务集群的热更新能力较强，可以同时对多种服务进行更新，则可以对该多种服务在同一时间段进行暂停运行以及重启更新的流程，使得在最短时间内可以完成其这部分服务的热更新，从而将其重新上线运行。当然，如果服务集群的热更新能力不足以进行同时更新，则可以按照其热更新能力进行分批的暂停运行以及重启更新，此时，还可以进一步按照非关键服务中各个服务的重要程度进一步划分，以便确定更新的顺序。

303、对于该关键服务中的任一服务，保持该服务中一部分子服务处于运行状态，暂停该服务中另一部分子服务的运行，对该另一部分子服务进行更新，将更新完成的子服务切换至运行状态，对未更新的子服务继续进行更新。

对于每个关键服务来说，可以在保证服务持续可用的情况下，采取轮动更新的方式进行更新，也即是，可以对关键服务的多个子服务进行分组，保持其中一组或多组处于运行状态，暂停其余组的运行，并对暂停运行的子服务进行更新后，启动更新后的子服务，再将上一轮更新中处于运行状态的子服务中的一组或多组暂停运行，从而使得在整个服务的更新过程中，总是有一组或多组子服务能够对外提供可用服务。

本申请实施例提供的技术方案，通过将待更新的服务区分为关键和非关键，从而对关键服务进行轮动更新，而对非关键服务直接进行更新，采用不同的更新方式进行服务更新，可以使得热更新场景下能够最大程度上的避免对正常服务运行造成影响，可以在保证用户无感知的情况下，完成服务的更新，还能够提高用户的使用体验。进一步地，整个服务更新过程中不需要额外的硬件资源，仅通过服务集群内部的服务器即可以完成上述服务更新过程，大大降低了硬件资源的消耗，且由于支持了用户迁移，从而也就支持了在线扩容以及缩容。

图4是本申请实施例提供的一种服务更新的方法的流程图，参见图4，仅以服务集群中一种关键服务的更新过程为例进行说明，具体可以包括下述步骤。

401、服务器确定待更新的关键服务。

该步骤401与上述步骤301同理，该关键服务的确定时机也可以在进行热更新之前进行，本申请实施例对此不做限定。

402、服务器对关键服务中的多个子服务进行分组，得到多个子服务组。

在对关键服务进行分组时，可以按照预定分组方式进行，例如预先设置将特定关键服务分为两组进行轮动更新，又或者预先设置将特定关键服务分为三组进行轮动更新，本公开实施例对此不做限定。

在一种可能实现方式中，服务器可以按照关键服务所包括的子服务的数量和当前服务集群中的登录人数进行分组，可以根据当前登录人数与一个子服务的可容纳人数，来确定分组，例如，若当前登录人数为一个子服务可容纳人数的N倍，则可以将N+1个子服务划分为一组，以得到多个子服务组，其中，N为大于0的正整数。

需要说明的是，上述分组过程中，一个组内的子服务可以运行在同一个服务器上，还可以运行于不同的服务器上，本申请实施例对此不做限定。

403、服务器保持多个子服务组中第一子服务组的运行状态，对多个子服务组中的第二子服务组进行更新。

404、当第二子服务组更新完成后，服务器启动第二子服务组，暂停该第一子服务组的运行，对该第一子服务组进行更新。

上述步骤403和404中所示，为将关键服务分为两组的形式进行轮动更新，而当对上述关键服务分为三组的情况下，则可以保持多个子服务组中第一子服务组和第二子服务组的运行状态，对多个子服务组中的第三子服务组进行更新，当第三子服务组更新完毕，则启动第三子服务组提供服务，保持第一子服务组的运行状态，暂停第二子服务组的运行，对第二子服务组进行更新，当第二子服务组更新完毕，则启动第二子服务组提供服务，保持第三子服务组的运行状态，暂停第一子服务组的运行，对第一子服务组进行更新。当然，具体的轮动更新顺序可以为服务集群预先设置好的更新顺序，在此不做限定。

另外，上述示例中仅以每次更新仅更新一组子服务组为例进行说明，而在一些可能实现方式中，还可以每次更新仅保持一组子服务组处于运行状态，而对其他子服务组进行同步更新，来实现迅速的更新，使得更新的速度更快。

本申请实施例提供的技术方案，通过对关键服务进行分组后来实现轮动更新，逐步对这些组进行更新，某一个组的功能在更新时有其他组承担，可以使得热更新场景下保证应用的基本服务能够正常运行，可以在保证用户无感知的情况下，完成服务的更新，还能够提高用户的使用体验。

下面以场景服务的更新为例对属于关键服务的场景服务的更新过程进行示例性描述，以图5为例，该过程可以包括下述步骤。

501、服务器对多个场景服务进行分组，得到第一场景服务组和第二场景服务组。

在本申请实施例中，仅以场景服务被划分为两组为例进行说明，在一些可能实现方式中，还可以基于系统性能等需求划分为两组以上，本申请实施例对其具体分组不做限定。

502、服务器确定本轮更新中待更新的第一场景服务组以及保持运行状态的第二场景服务组。

其中，在确定更新顺序时，可以按照系统预设的顺序进行，还可以根据当前服务器上各个场景服务内的人数来确定，例如，为了提高处理效率，可以在第一轮更新中，将多个场景服务组中登录人数最少的场景服务组作为待更新的组，从而在进行用户迁移时其迁移量较小。

503、服务器将第一场景服务组中第一场景服务中的用户迁移至第二场景服务组中的第二场景服务。

将待更新的服务内用户迁移至其他场景服务，可以给用户提供连续的服务体验，不仅能够给用户提供场景的探索空间，还可以保证用户无感知的情况下进行更新。

504、当用户迁移完成后，服务器暂停该第一场景服务组中第一场景服务的运行。

505、服务器保持第二场景服务组中的第二场景服务处于运行状态，对该第一场景服务组中第一场景服务进行更新。

506、当该第一场景服务组中第一场景服务更新完成后，服务器启动第一场景服务组中的第一场景服务，将第二场景服务组中第二场景服务中的用户迁移至第一场景服务组中的第一场景服务。

507、当迁移完成后，服务器暂停该第二场景服务组中第二场景服务的运行。

508、服务器保持第一场景服务组中的第一场景服务处于运行状态，对该第二场景服务组中第二场景服务进行更新。

在上述更新完成后，可以根据迁移前后用户所处的场景服务，来对用户进行场景恢复，也即是，将用户还原回发生热更新之前所在的场景服务，从而避免服务出现错乱的情况。

在一些可能实现方式中，对于关键服务和非关键服务，当该服务采用了主备方式运行时，也可以采用下述轮动更新方式：保持该服务中属于主服务身份的子服务处于运行状态，暂停该服务中属于备服务身份的子服务的运行，对暂停的子服务进行更新，当更新完毕时，再启动该更新完毕的子服务，暂停之前处于运行状态的子服务，对该子服务进行更新，依次方式轮动进行更新，直到服务内所有子服务更新完毕。例如，参见图2所示，调度服务和路由服务的主服务运行于GS1上，调度服务和路由服务的备服务运行于GS2上，因此，其更新可以按照先主后备的顺序进行，例如，先暂停运行有主服务的GS1，对其进行更新，再关闭运行有备服务的GS2。

需要说明的是，上述的更新过程可以基于服务器的调度进行，服务器可以通过向相应服务器发送控制指令等方式来控制整体更新的进度。下面以负责对更新进行调度的服务与各个作为更新目标的服务器之间的交互流程为例对上述服务集群的更新过程进行说明。参见图6，服务器可以通过调度功能通知非关键服务停止服务，再通知例如大厅2、邮件2以及标识2这类关键服务停止服务，在非关键服务停止后，可以从服务路由目录中删除非关键服务对应的节点，然后进行重启的通知，进而控制关键服务进行用户迁移、并在迁移以后进行重启以及更新，最终实现服务集群基于服务的更新流程。

在上述实施过程中，由于更新过程中服务集群中会出现新旧版本同时存在的场景，且该服务集群还面向用户提供正常服务，因此，为了避免新旧版本数据互相污染的问题，还可以在更新过程中基于版本进行服务隔离，也即是，该方法还包括：当任一服务的更新过程中，在服务路由目录中更新该服务的版本信息；当接收到任一业务请求时，根据该服务路由目录中所记录的版本信息对该业务请求进行访问控制。该访问控制用于引导用户访问对应版本的服务。

在一种可能实现方式中，该根据该服务路由目录中所记录的版本信息对该业务请求进行访问控制包括：根据该业务请求所携带的版本信息，从该服务路由目录中确定目标服务器，该目标服务器的版本信息与该所携带的版本信息匹配；基于该目标服务器响应该业务请求。通过引导用户的业务请求，使得运行有对应版本的服务器能够进行正确的响应，从而避免了新旧版本之间的数据污染，实现了数据隔离。

在一种可能实现方式中，该根据该服务路由目录中所记录的版本信息对该业务请求进行访问控制包括：根据该业务请求所携带的版本信息，判断该业务请求所指示的服务器的版本信息与该业务请求所携带的版本信息是否匹配，若不匹配，则拒绝该业务请求。通过基于版本来判断用户的业务请求是否为合法请求，从而避免了新旧版本之间的数据污染，实现了数据隔离。

相应地，对于服务集群来说，可以维护服务集群当前的版本信息，当每次更新时，对版本信息进行增量处理，以得到本次更新后的版本信息，当任一个新版本的服务更新完成后，可以拉取更新后的版本信息作为自身的版本信息，也即是，如图7所示，旧服务的版本信息为11，而新服务的版本信息则为12，其所包含的各项服务在更新后则均为版本信息12。上述版本信息可以存储于服务路由目录中，而参见图8，可以看出在场景服务下，由于其更新是轮动更新，因此可能出现新旧版本共存的情况，例如版本11和版本12并存，对于帮派服务，由于其更新是重启更新，因此，其版本均为版本12。

通过在调度服务侧按照版本进行隔离，不同版本的服务目录存储于不同地址，如图9所示，其服务目录互相独立，路由规则上不同版本之间的服务访问直接拒绝服务，则通过上述隔离方式，可以避免新旧版本数据的互相污染。另外，通过基于版本信息进行更新过程，实际上可以实现从旧版本向新版本的逐渐转换的过程。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

图10是本申请实施例提供的一种服务更新装置的结构示意图。参见图10，所述装置包括：

服务划分模块1001，用于根据待更新服务的服务类型，将所述待更新服务划分为关键服务和非关键服务；

第一更新模块1002，用于暂停所述非关键服务的运行，对所述非关键服务进行更新；

第二更新模块1003，用于对于所述关键服务中的任一服务，保持所述服务中一部分子服务处于运行状态，暂停所述服务中另一部分子服务的运行，对所述另一部分子服务进行更新，将更新完成的子服务切换至运行状态，对未更新的子服务继续进行更新。

在一种可能实现方式中，所述第二更新模块用于：保持所述服务中属于主服务身份的子服务处于运行状态，暂停所述服务中属于备服务身份的子服务的运行。

在一种可能实现方式中，所述第二更新模块用于：对于场景服务，将第一场景服务中的用户迁移至第二场景服务，保持所述第二场景服务的运行，在迁移完成后，暂停所述第一场景服务的运行。

在一种可能实现方式中，所述第一更新模块用于：通知运行有所述非关键服务的第一服务器暂停运行，从服务路由目录中删除所述第一服务器，所述服务路由目录用于记录各个服务的服务器的路由信息；对所述第一服务器进行重启，在重启后更新所述非关键服务，当更新完成后，将更新后的第一服务器添加至所述服务路由目录中。

在一种可能实现方式中，所述装置还包括：

版本更新模块，用于当任一服务的更新过程中，在服务路由目录中更新所述服务的版本信息；访问控制模块，用于当接收到任一业务请求时，根据所述服务路由目录中所记录的版本信息对所述业务请求进行访问控制。

在一种可能实现方式中，所述访问控制模块，用于根据所述业务请求所携带的版本信息，从所述服务路由目录中确定目标服务器，所述目标服务器的版本信息与所述所携带的版本信息匹配；基于所述目标服务器响应所述业务请求。

在一种可能实现方式中，所述访问控制模块，用于根据所述业务请求所携带的版本信息，判断所述业务请求所指示的服务器的版本信息与所述业务请求所携带的版本信息是否匹配，若不匹配，则拒绝所述业务请求。

需要说明的是：上述实施例提供的服务更新装置在服务更新时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的服务更新装置与服务更新方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图11是本申请实施例提供的一种服务器的结构示意图，该服务器1100可因配置或性能不同而产生比较大的差异，可以包括一个或多个处理器(central processing units，CPU)1101和一个或多个的存储器1102，其中，所述一个或多个存储器1102中存储有至少一条指令，所述至少一条指令由所述一个或多个处理器1101加载并执行以实现上述各个方法实施例提供的方法。当然，该服务器1100还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器1100还可以包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括指令的存储器，上述指令可由处理器执行以完成上述实施例中的服务更新方法。例如，该计算机可读存储介质可以是只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random AccessMemory，RAM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)、磁带、软盘和光数据存储设备等。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

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

Claims (10)

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

根据待更新服务的服务类型，将所述待更新服务划分为关键服务和非关键服务；

暂停所述非关键服务的运行，对所述非关键服务进行更新；

对于所述关键服务中的任一服务，保持所述服务中一部分子服务处于运行状态，暂停所述服务中另一部分子服务的运行，对所述另一部分子服务进行更新，将更新完成的子服务切换至运行状态，对未更新的子服务继续进行更新。

2.根据权利要求1所述的方法，其特征在于，所述保持所述服务中一部分子服务处于运行状态，暂停所述服务中另一部分子服务的运行包括：

保持所述服务中属于主服务身份的子服务处于运行状态，暂停所述服务中属于备服务身份的子服务的运行。

3.根据权利要求1所述的方法，其特征在于，所述保持所述服务中一部分子服务处于运行状态，暂停所述服务中另一部分子服务的运行包括：

对于场景服务，将第一场景服务中的用户迁移至第二场景服务，保持所述第二场景服务的运行，在迁移完成后，暂停所述第一场景服务的运行。

4.根据权利要求1所述的方法，其特征在于，所述暂停所述非关键服务的运行，对所述非关键服务进行更新包括：

通知运行有所述非关键服务的第一服务器暂停运行，从服务路由目录中删除所述第一服务器，所述服务路由目录用于记录各个服务的服务器的路由信息；

对所述第一服务器进行重启，在重启后更新所述非关键服务，当更新完成后，将更新后的第一服务器添加至所述服务路由目录中。

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

当任一服务的更新过程中，在服务路由目录中更新所述服务的版本信息；

当接收到任一业务请求时，根据所述服务路由目录中所记录的版本信息对所述业务请求进行访问控制。

6.根据权利要求5所述的方法，其特征在于，所述根据所述服务路由目录中所记录的版本信息对所述业务请求进行访问控制包括：

根据所述业务请求所携带的版本信息，从所述服务路由目录中确定目标服务器，所述目标服务器的版本信息与所述所携带的版本信息匹配；

基于所述目标服务器响应所述业务请求。

7.根据权利要求5所述的方法，其特征在于，所述根据所述服务路由目录中所记录的版本信息对所述业务请求进行访问控制包括：

根据所述业务请求所携带的版本信息，判断所述业务请求所指示的服务器的版本信息与所述业务请求所携带的版本信息是否匹配，若不匹配，则拒绝所述业务请求。

8.一种服务更新装置，其特征在于，所述装置包括：

服务划分模块，用于根据待更新服务的服务类型，将所述待更新服务划分为关键服务和非关键服务；

第一更新模块，用于暂停所述非关键服务的运行，对所述非关键服务进行更新；

第二更新模块，用于对于所述关键服务中的任一服务，保持所述服务中一部分子服务处于运行状态，暂停所述服务中另一部分子服务的运行，对所述另一部分子服务进行更新，将更新完成的子服务切换至运行状态，对未更新的子服务继续进行更新。

9.一种服务器，其特征在于，所述服务器包括一个或多个处理器和一个或多个存储器，所述一个或多个存储器中存储有至少一条程序代码，所述程序代码由所述一个或多个处理器加载并执行以实现如权利要求1至权利要求7任一项所述的服务更新方法所执行的操作。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条程序代码，所述程序代码由处理器加载并执行以实现如权利要求1至权利要求7任一项所述的服务更新方法所执行的操作。

Images