具体实施方式

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

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。这里使用的诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

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

本申请的至少一个实施例中，通过将游戏更新信息增加到游戏更新请求中，进而在获取游戏更新请求后，可基于游戏更新信息确定至少一个待更新渠道，从而对每个待更新渠道，将待更新游戏进行下架，并基于游戏更新信息更新待更新游戏的游戏信息，以及将部署通知发送给渠道下辖的多个游戏服务端，以使游戏服务端部署待更新游戏所需的资源，这样，在游戏更新过程中，用户可以看到游戏的下架状态，进而了解该游戏正在更新，避免游戏更新过程中使用该游戏的错误版本。

图1为本申请实施例提供的一种应用场景的示意图。在图1中，请求端11可通过网络与运维服务端12进行数据交互；运维服务端12可通过网络与待更新渠道13下辖的多个游戏服务端进行数据交互。网络可以为4G网络、5G网络及其他用于数据交互的网络。在一些实施例中，可以有多个请求端11访问运维服务端12；也可以有多个运维服务端12服务不同的请求端11；可以有多个待更新渠道13，每个待更新渠道13下辖的多个游戏服务端通过网络与运维服务端12进行数据交互。

请求端

请求端11可以是任一可通过运维服务端12进行鉴权的任意端，例如，请求端11可以为运维页面、运维服务端12自身、运营服务端、用户端(User Agent，UA)等。其中，用户端是能够访问云游戏服务端的任意设备，例如，用户端可以是安装有用于访问云游戏服务端的软件(例如云游戏客户端软件)的任意设备，其中，用于访问云游戏服务端的软件也可以理解为用户端的软件实现。

在一些实施例中，用户端可包括但不限于：瘦客户端、通用计算机、专用计算机、游戏控制台、个人计算机、膝上型计算机、平板计算设备、移动计算设备、便携式游戏设备、蜂窝电话、智能手机、笔记本电脑、头戴式显示器、智能可穿戴设备、机顶盒、流媒体接口/设备、智能电视或联网显示器等。

在一些实施例中，用户端至少用于访问云游戏服务端的云游戏，接收用户输入的游戏操作，并生成相应的操作指令，进而将操作指令上传到云游戏服务端。用户可通过用户端访问云游戏服务端的云游戏列表，选择云游戏。在一些实施例中，当有多个云游戏服务端时，多个云游戏服务端可分布于不同地区，用户通过用户端访问用户所在地区对应的云游戏服务端。

在一些实施例中，云游戏服务端可以是能够运行云游戏程序的任意设备，例如可以是安装有云游戏程序以及提供云游戏服务的软件的任意设备，这里的提供云游戏服务的软件也可以理解为云游戏服务端的软件实现。

在一些实例中，云游戏服务端可以是单个服务器，也可以是服务器集群，服务器群组可以为集中式的，也可以为分布式的。在一些实施例中，云游戏服务端可以是远程服务器、虚拟计算机、云游戏服务器、云应用服务器、远程应用服务器、数字媒体服务器、用于提供游戏开发者/游戏赞助商店面(storefront)的服务器、网站服务器、终端服务器、控制台服务器等。

在一些实施例中，云游戏服务商可以将云游戏部署在云游戏服务集群中，云游戏服务集群的节点服务器上可以运行有云游戏程序，多个云游戏服务端属于云游戏服务器集群。本实施例中，用户可以通过用户端访问云游戏服务端，并由其为用户端调度用户所在地区对应的节点服务器登录云游戏，以及用户在用户端上进行游戏操作，从而用户端可以将相应的操作指令上传到节点服务器。之后，节点服务器可以基于云游戏程序的执行逻辑，结合操作指令计算并生成游戏画面，然后将游戏画面反馈给用户端进行显示。

运维服务端

运维服务端12至少用于更新游戏。在一些实施例中，运维服务端12可接收请求端11发送的游戏更新请求，游戏更新请求包括游戏更新信息，进而基于游戏更新信息确定至少一个待更新渠道13。在一些实施例中，运维服务端12可对每个待更新渠道13，将待更新游戏进行下架，这样，在游戏更新过程中，用户可以看到游戏的下架状态，进而了解该游戏正在更新，避免游戏更新过程中使用该游戏的错误版本。在一些实施例中，运维服务端12可基于游戏更新信息更新待更新游戏的游戏信息，其中，待更新游戏可以为下架的游戏，也可以为游戏更新请求中指定的待更新游戏。在一些实施例中，运维服务端12可将部署通知发送给待更新渠道13下辖的多个游戏服务端，以使游戏服务端部署待更新游戏所需的资源。

游戏服务端

待更新渠道13下辖多个游戏服务端，其中，游戏服务端即游戏服务组件(GameService，GS)，运行于云游戏服务端，也即游戏服务端属于云游戏服务端的一部分。游戏服务端用于控制游戏实例，为用户端提供云游戏服务。在一些实施例中，游戏服务端会在启动前(通过运维系统或人员)配置其支持的渠道的渠道标识、其所属区域的区域信息和其对应的运营商信息、以及其支持的游戏标识列表。

在一些实施例中，游戏服务端用于控制游戏实例，为用户端提供云端服务资源来执行云游戏、编码云游戏的视频帧音频帧以及将编码的视频帧音频帧流式传输到云游戏客户端以用于渲染和用户交互。在一些实施例中，游戏服务端，至少用于获取云游戏客户端上传的操作指令，并基于云游戏程序的执行逻辑，结合操作指令计算并生成游戏画面，然后将游戏画面反馈给用户端进行显示。在一些实施例中，游戏服务端可以为软件装置、硬件装置或者软硬件结合的装置。

图2为本申请实施例提供的一种游戏更新装置20的框图。在一些实施例中，游戏更新装置20可以实现为图1中的运维服务端12或者运维服务端12的一部分。如图2所示，游戏更新装置20可包括但不限于以下单元：获取单元21、确定单元22、下架单元23、更新单元24和发送单元25。各单元具体描述如下：

获取单元

获取单元21，用于获取游戏更新请求，游戏更新请求包括游戏更新信息。其中，游戏更新请求由图1所示的请求端11发送。需要说明的是，若请求端11为运维服务端12自身，则获取单元21直接获取运维服务端12自身产生的获取游戏更新请求，无需发送的动作；若请求端11非运维服务端12自身，则获取单元21接收请求端11发送的游戏更新请求。

在一些实施例中，游戏更新信息可包括待更新游戏的游戏标识。获取单元21在获取游戏更新请求后，可进一步获取到游戏更新信息所包括的待更新游戏的游戏标识，进而明确更新对象为游戏标识所对应的游戏。

在一些实施例中，游戏更新信息可包括待更新游戏的第一游戏信息。第一游戏信息可包括但不限于以下一个或多个：游戏本身信息和游戏相关信息。其中，游戏本身信息可包括但不限于以下一个或多个：游戏描述、游戏版本、游戏安装包信息等。游戏相关信息可包括但不限于以下一个或多个：GS当前云端操控模拟的方式、云端渲染的方式、视音频捕获方式、编码方式和编码参数等。

在一些实施例中，游戏更新信息可包括第一配置信息。需要说明的是，不论是否更新，每个游戏都有与自身对应的配置信息，且每次更新前或更新后，每个游戏同一时间只有一种配置信息。在一些实施例中，配置信息是与游戏标识一一对应的。

在一些实施例中，第一配置信息可包括但不限于：待更新游戏及其相关服务组件的各配置项的信息。需要说明的是，每个游戏及其相关服务组件构成每个游戏在云游戏服务端能够正常运行和正常提供云游戏服务必须的环境。在一些实施例中，相关服务组件可包括但不限于以下一个或多个：GS、游戏虚拟设备组件、服务QoS数据收集组件和服务日志组件等。在一些实施例中，各配置项的信息可包括但不限于以下一个或多个：组件的版本、目标配置(比如视频捕获组件的来源、分辨率，音频捕获组件的频率、声道、编码组件的算法、码率等)、组件的部署脚本等。

在一些实施例中，游戏更新信息可包括游戏部署脚本。游戏部署脚本是一种可执行文件。游戏部署脚本被执行后，可触发游戏部署任务。游戏部署任务例如包括但不限于以下一个或多个：待更新游戏的下载、升级、和/或安装，待更新游戏相关服务组件的下载、升级、和/或安装。

在一些实施例中，游戏更新信息可包括渠道标识(即渠道ID)，该渠道标识用于指定游戏更新所针对的渠道，也即更新的是该渠道标识所对应的渠道下的待更新游戏。即使其他渠道也有该待更新游戏，也不会进行更新。例如，渠道A、渠道B和渠道C都有游戏A，但是游戏更新信息包括渠道A的渠道标识，则只更新渠道A下的游戏A，渠道B和渠道C下的游戏A不进行更新。在一些实施例中，若游戏更新信息不包括渠道标识，则默认对包含待更新游戏的所有渠道下的待更新游戏进行更新。

确定单元

确定单元22，用于确定一个或多个待更新渠道。待更新渠道为包含待更新游戏的渠道。在一些实施例中，确定单元22基于游戏更新信息和预设的一个或多个渠道信息，确定至少一个待更新渠道。需要说明的是，若运维服务端仅预设了一个渠道，则确定单元22基于游戏更新信息和预设的一个渠道信息，至多确定一个待更新渠道。

在一些实施例中，确定单元22若确定所有预设的渠道均不是待更新渠道，则反馈更新失败信息作为游戏更新响应至请求端。需要说明的是，若请求端为运维服务端自身，则运维服务端可直接获取确定单元22产生的游戏更新响应，确定单元22无需发送(游戏更新响应)的动作；若请求端非运维服务端自身，则确定单元22将游戏更新响应发送至请求端。

在一些实施例中，渠道信息包括渠道的第一游戏列表，第一游戏列表包括每个游戏的游戏标识。通常一个渠道下有多个游戏，那么该渠道的第一游戏列表就包括这多个游戏中每个游戏的游戏标识。确定单元22可确定游戏更新信息包括的待更新游戏的游戏标识，进而从一个或多个第一游戏列表中查找待更新游戏的游戏标识，也即查找具有待更新游戏的游戏标识的第一游戏列表，从而将查找到的第一游戏列表所对应的渠道确定为待更新渠道。

在一些实施例中，渠道信息包括第二渠道标识，若游戏更新请求包括第一渠道标识，则确定单元22确定与第一渠道标识匹配的渠道信息，例如，确定单元22判断第一渠道标识与任一渠道信息的第二渠道标识是否相同，若相同，则确定该渠道信息与第一渠道标识匹配。进而，确定单元22对与第一渠道标识匹配的渠道信息所包括的第一游戏列表进行查找，以确定第一游戏列表中是否包括待更新游戏的游戏标识，若查找到待更新游戏的游戏标识，则确定与第一渠道标识匹配的渠道为待更新渠道。

在一些实施例中，第一游戏列表除了包括每个游戏的游戏标识，还可包括每个游戏的游戏状态。其中，游戏状态例如为下架状态、上架状态或运行状态。下架状态表示游戏正在更新。上架状态表示游戏已更新，可以运行。运行状态表示游戏正在运行中。

在一些实施例中，第一游戏列表可包括每个游戏的第二游戏信息，第二游戏信息可包括但不限于以下一个或多个：游戏本身信息和游戏相关信息。其中，游戏本身信息可包括但不限于以下一个或多个：游戏描述、游戏版本、游戏安装包信息等。游戏相关信息可包括但不限于以下一个或多个：GS当前云端操控模拟的方式、云端渲染的方式、视音频捕获方式、编码方式和编码参数等。

下架单元、更新单元和发送单元

下架单元23，用于针对每个待更新渠道，将该待更新渠道所对应的待更新游戏进行下架。在一些实施例中，下架单元23将该待更新渠道的第一游戏列表中所述待更新游戏的游戏状态设置为下架状态，以便用户基于下架状态确定游戏已下架并正在更新，进而不会请求该游戏，从而避免游戏无法游玩导致的用户体验差的问题。

在一些实施例中，针对每个待更新渠道，该待更新渠道可对应一个或多个用户端(User Agent，UA)。当下架单元将待更新游戏的游戏状态设置为下架状态后，每个UA在获取该待更新游戏时，显示该游戏正在更新中。其中，获取该待更新游戏的方式包括但不限于以下一种或多种：方式一：向云游戏服务端发送云游戏请求，该云游戏请求中携带该待更新游戏的游戏标识；方式二：获取该待更新游戏的状态，比如获取游戏列表，该游戏列表包括该待更新游戏的游戏标识及游戏状态。需要说明的是，游戏更新过程中涉及该游戏的所有获取行为，都应显示该游戏正在更新中。

更新单元24，用于针对每个待更新渠道，基于游戏更新信息更新待更新游戏的游戏信息。在一些实施例中，更新单元24可在下架单元23将待更新游戏进行下架后，基于游戏更新信息更新下架后的待更新游戏的游戏信息。在一些实施例中，更新单元24用游戏更新信息中的第一游戏信息替换该待更新渠道的第一游戏列表中待更新游戏的第二游戏信息。例如，更新单元24可确定与游戏更新信息中的第一游戏信息相匹配的第二游戏信息，进而用第一游戏信息替换第二游戏信息。其中，匹配例如为第一游戏信息对应的游戏标识与第二游戏信息对应的游戏标识相同。其中，第二游戏信息为待更新渠道的第一游戏列表中待更新游戏的游戏信息。

发送单元25，用于针对每个待更新渠道，向该待更新渠道下辖的多个游戏服务端发送部署通知，以使每个游戏服务端基于部署通知部署待更新游戏所需的资源。其中，资源是云游戏服务端用以安装和运行游戏的各服务器，游戏服务端负责部署这些服务器。在一些实施例中，资源可以为虚拟机、也可以为物理机。例如，对于安卓系统的游戏，资源可以是安卓模拟器，可以是物理的云手机，也可以是虚拟的云手机。

在一些实施例中，部署通知可包括但不限于：待更新游戏的第一游戏信息、第一配置信息和游戏部署脚本等。每个游戏服务端基于部署通知对待更新游戏所需的资源进行部署的过程为：基于待更新游戏的第一游戏信息和第一配置信息，生成第二配置信息，并执行游戏部署脚本。其中，第二配置信息为存储于待更新游戏所需资源上的配置信息，也即，第二配置信息可以理解为待更新游戏的本地配置信息，“本地”指游戏服务端所负责部署的服务器。可见，第二配置信息可以理解为基于第一配置信息通过部署过程生成的本地配置信息。另外，游戏服务端执行游戏部署脚本，可完成待更新游戏及其相关服务组件在本地的下载、升级、和/或安装等，即游戏服务端完成对其所负责的服务器的部署。

需要说明的是，由于机器环境或游戏服务端版本的不同，每个游戏服务端同时并行部署所生成的第二配置信息可以有所不同。若机器环境和游戏服务端版本均相同，则每个游戏服务端同时并行部署所生成的第二配置信息可能相同。

在一些实施例中，第二配置信息可包括但不限于：待更新游戏及其相关服务组件的各配置项的信息。在一些实施例中，相关服务组件可包括但不限于以下一个或多个：GS、游戏虚拟设备组件、服务QoS数据收集组件和服务日志组件等。在一些实施例中，各配置项的信息可包括但不限于以下一个或多个：组件的版本、目标配置(比如视频捕获组件的来源、分辨率，音频捕获组件的频率、声道、编码组件的算法、码率等)、组件的部署脚本等。

在一些实施例中，发送单元25针对每个待更新渠道，可获取该待更新渠道下辖的游戏服务端列表，游戏服务端列表包括了该待更新渠道下辖的每个游戏服务端的GS信息，GS信息可包括但不限于以下一种或多种：GS标识(GSID)，GS状态，GS版本号、GS命令行、第二游戏列表(即GS现已部署的游戏的列表)等。进而，发送单元25针对每个待更新渠道，向该待更新渠道下辖的游戏服务端列表中的每个游戏服务端发送部署通知。

在一些实施例中，发送单元25针对每个待更新渠道，可将该待更新渠道下辖的多个游戏服务端分批，每次对同属一批的各游戏服务端发送部署通知。其中，分批可以是一个游戏服务端为一批，也可以是多个游戏服务端为一批。这样，在待更新游戏更新的过程中，该待更新渠道下辖的未接收到部署通知的游戏服务端仍可提供其他游戏(即不是待更新游戏)给用户游玩，同时，用户也可以看到待更新游戏的下架状态，进而了解该待更新游戏正在更新，避免该待更新游戏更新过程中使用该待更新游戏的错误版本。

在一些实施例中，发送单元25针对每个待更新渠道，将该待更新渠道下辖的多个游戏服务端分批后，可基于预先设置的发送策略，每次对同属一批的各游戏服务端发送部署通知。其中，发送策略例如为：若返回部署结果的游戏服务端数量小于该待更新渠道下辖的游戏服务端数量，则继续对同属下一批的各游戏服务端发送部署通知。在一些实施例中，发送单元25可等待上一次发送的一批部署通知均有对应的部署结果后，也即，接收到部署通知的所有游戏服务端均返回了部署结果后，发送单元25再对同属下一批的各游戏服务端发送部署通知。其中，等待可以为带超时的等待，例如，等待时长超过预设时长，仍有游戏服务端未返回部署结果，则发送单元25对同属下一批的各游戏服务端发送部署通知。又例如，预设时长为无穷大，则发送单元25可以一直等待，直至接收到部署通知的所有游戏服务端均返回了部署结果后，发送单元25再对同属下一批的各游戏服务端发送部署通知。又例如，预设时长为零，则发送单元25不等待，直接对同属下一批的各游戏服务端发送部署通知。

游戏服务端(GS)接收到部署通知后，可以直接通知其正在服务的用户端(UserAgent，UA)本次云游戏服务即将结束，以使UA重新向云游戏服务端请求调度另一GS继续当前游戏的云游戏服务。进而，接收到部署通知的GS在收到UA与另一GS成功连接或达到预定的超时值时，断开与UA的连接，即本次云游戏服务结束，接收到部署通知的GS开始处理当前的部署通知。在一些实施例中，接收到部署通知的GS首先判断自身状态是否为空闲，如正在对外提供云游戏服务，则将该部署通知缓存至本地部署排期队列尾，待本次对外的云游戏服务结束，即接收到部署通知的GS自身状态为空闲，该GS从本地部署队列首逐个处理缓存的部署通知。

在一些实施例中，发送单元25发送部署通知后，将接收部署通知的每个游戏服务端的状态(即GS状态)修改为正在部署状态。需要说明的是，游戏服务端接收部署通知之前，GS状态可以为空闲、占用或其他不是正在部署的状态，发送单元25向游戏服务端发送部署通知之后，会将该游戏服务端的状态修改为正在部署状态。

在一些实施例中，发送单元25在发送部署通知后，可获取每个接收部署通知的游戏服务端对待更新游戏所需资源的部署结果。其中，部署结果为部署成功的结果或部署失败的结果。部署成功的结果可包括但不限于：用于描述部署成功的信息、游戏服务端的标识(GSID)、游戏标识和第二配置信息等。部署失败的结果可包括但不限于：用于描述部署失败的信息和失败信息，其中，失败信息包括错误码或错误信息。游戏服务端检测到部署过程中存在任何异常而无法顺利完成本次部署时，可生成部署失败的结果。

在一些实施例中，发送单元25可基于部署结果更新对应的游戏服务端的信息(即GS信息)和状态(即GS状态)。其中，对应的游戏服务端可以理解为发送该部署结果的游戏服务端。

例如，部署结果为部署成功的结果，将部署结果中的第二配置信息更新至对应的游戏服务端的GS信息的第二游戏列表中，并将对应的游戏服务端的状态设置为空闲状态。

又例如，部署结果为部署失败的结果，基于错误码或错误信息判断部署失败的具体情况或分类，相应地，若对应的游戏服务端可以继续对外提供服务，则将对应的游戏服务端的状态设置为空闲状态；若对应的游戏服务端无法继续对外提供服务，则将对应的游戏服务端的状态设置为异常状态。

在一些实施例中，发送单元25可基于部署结果向请求端发送游戏更新响应，游戏更新响应包括已更新的渠道标识和已更新的游戏标识。需要说明的是，若请求端为运维服务端自身，则运维服务端可记录已更新的渠道标识和已更新的游戏标识，也即，发送单元25无需发送的动作；若请求端非运维服务端自身，且请求端发送了游戏更新请求，则发送单元25向请求端发送游戏更新响应。在一些实施例中，发送单元25基于部署结果为首个成功的部署结果，向请求端发送游戏更新响应，游戏更新响应包括已更新的渠道标识和已更新的游戏标识。可见，只要至少一个游戏服务端完成部署，就可以通知请求端完成了待更新游戏的更新，无需等待其他游戏服务端完成部署，即可向用户提供该待更新游戏的云游戏服务，缩短用户等待游戏更新的时间。

在一些实施例中，发送单元25针对每个待更新渠道，可统计该待更新渠道中已返回部署结果的GS数量，若GS数量等于该待更新渠道下辖的GS数量时，表明该待更新渠道下辖的所有GS均已完成待更新游戏所需的资源的部署，进行结束对该待更新渠道的GS分批发送部署通知。

上架单元

在一些实施例中，游戏更新装置20还可包括图2中未示出的上架单元。上架单元，用于获取游戏上架请求，游戏上架请求包括渠道标识和游戏标识。在一些实施例中，请求端接收到游戏更新响应后发送游戏上架请求。在一些实施例中，运维人员可直接通过请求端向运维服务端发送获取某渠道的GS信息列表的请求，然后对有完成游戏更新的GS进行人工或自动化脚本的测试，可根据测试结果发送游戏上架请求。

这样，上架单元基于游戏上架请求包括的渠道标识和游戏标识，确定需要将该游戏标识对应的游戏在该渠道标识对应的渠道进行上架。需要说明的是，游戏上架请求包括的渠道标识和游戏标识可以不是游戏更新响应包括的已更新的渠道标识和已更新的游戏标识，也即可以对任一渠道下的任一游戏发起游戏上架请求。

在一些实施例中，上架单元可统计该渠道标识对应的渠道下返回的针对该游戏标识的部署结果的游戏服务端数量。进而，上架单元基于至少一个部署结果为成功，将该渠道标识对应的渠道下该游戏标识所对应的游戏设置为上架状态。另外，上架单元基于不存在部署成功的结果，保持该渠道标识对应的渠道下该游戏标识所对应的游戏为下架状态。

这样，当上架单元将该渠道标识对应的渠道下该游戏标识所对应的游戏设置为上架状态后，属于该渠道标识对应的渠道下的任一用户端(User Agent，UA)，在获取该游戏标识的游戏信息或游戏状态时，均显示该游戏标识对应的游戏正常可用。同样地，其他渠道UA获取该游戏标识的游戏信息或游戏状态时，按其所属渠道下该游戏标识对应的游戏的当前状态对应显示。

在一些实施例中，游戏更新装置20中各单元的划分仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如获取单元21、确定单元22、下架单元23、更新单元24和发送单元25中的至少两个单元可以实现为一个单元；获取单元21、确定单元22、下架单元23、更新单元24或发送单元25也可以划分为多个子单元。可以理解的是，各个单元或子单元能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。

图3为本申请实施例提供的一种游戏更新过程中的多端交互图，如图3所示，游戏更新的流程包括如下步骤301至311：

在步骤301中，请求端将游戏更新请求发送给运维服务端，其中，游戏更新请求包括游戏更新信息。游戏更新信息可包括待更新游戏的游戏标识、第一游戏信息、第一配置信息和游戏部署脚本。

在步骤302中，运维服务端基于游戏更新信息和预设的一个或多个渠道信息，确定至少一个待更新渠道。其中，渠道信息包括渠道的第一游戏列表，第一游戏列表包括每个游戏的游戏标识、每个游戏的游戏状态以及每个游戏的第二游戏信息。例如，运维服务端基于查找具有待更新游戏的游戏标识的第一游戏列表；进而将查找到的第一游戏列表所对应的渠道确定为待更新渠道。

在步骤303中，运维服务端将每个待更新渠道所对应的待更新游戏进行下架。例如，运维服务端将每个待更新渠道所对应的待更新游戏的游戏状态设置为下架状态。

在步骤304中，运维服务端基于游戏更新信息更新待更新游戏的游戏信息。例如，运维服务端针对每个待更新渠道，用第一游戏信息替换该待更新渠道的第一游戏列表中该待更新游戏的第二游戏信息。

在步骤305中，运维服务端针对每个待更新渠道，向该待更新渠道下辖的多个游戏服务端发送部署通知。例如，一个待更新渠道下辖两个游戏服务端，运维服务端可分别向这两个游戏服务端发送部署通知。其中，部署通知包括待更新游戏的第一游戏信息、第一配置信息和游戏部署脚本。

在步骤306中，游戏服务端基于部署通知部署待更新游戏所需的资源。例如，游戏服务端基于待更新游戏的第一游戏信息和第一配置信息，生成第二配置信息，并执行游戏部署脚本；其中，第二配置信息为存储于待更新游戏所需资源上的配置信息。

在步骤307中，游戏服务端若部署成功，则向运维服务端发送部署结果且部署结果为成功，部署结果中包括：用于描述部署成功的信息、游戏服务端的标识(GSID)、游戏标识和第二配置信息等。游戏服务端若部署失败，则向运维服务端发送部署结果且部署结果为失败，部署结果中包括：用于描述部署失败的信息和失败信息，其中，失败信息例如包括错误码或错误信息。

在步骤308中，运维服务端基于部署结果更新对应的游戏服务端的信息和状态。例如，部署结果为部署成功的结果，将部署结果中的第二配置信息更新至对应的游戏服务端的GS信息的第二游戏列表中，并将对应的游戏服务端的状态设置为空闲状态。又例如，部署结果为部署失败的结果，基于错误码或错误信息判断部署失败的具体情况或分类，相应地，若对应的游戏服务端可以继续对外提供服务，则将对应的游戏服务端的状态设置为空闲状态；若对应的游戏服务端无法继续对外提供服务，则将对应的游戏服务端的状态设置为异常状态。

在步骤309中，运维服务端基于部署结果为首个成功的部署结果，向请求端发送游戏更新响应。游戏更新响应包括已更新的渠道标识和已更新的游戏标识。可见，只要至少一个游戏服务端完成部署，就可以通知请求端完成了待更新游戏的更新，无需等待其他游戏服务端完成部署，即可向用户提供该待更新游戏的云游戏服务，缩短用户等待游戏更新的时间。

在步骤310中，请求端将游戏上架请求发送给运维服务端，游戏上架请求包括渠道标识和游戏标识。需要说明的是，游戏上架请求包括的渠道标识和游戏标识可以不是步骤309中已更新的渠道标识和已更新的游戏标识，也即可以对任一渠道下的任一游戏发起游戏上架请求。

在步骤311中，基于游戏上架请求中的渠道标识和游戏标识，运维服务端统计该渠道标识对应的渠道下返回的针对该游戏标识的部署结果的游戏服务端数量。进而，运维服务端基于至少一个部署结果为成功，将该渠道标识对应的渠道下该游戏标识所对应的游戏设置为上架状态。

这样，当运维服务端将该渠道标识对应的渠道下该游戏标识所对应的游戏设置为上架状态后，属于该渠道标识对应的渠道下的任一用户端(User Agent，UA)，在获取该游戏标识的游戏信息或游戏状态时，均显示该游戏标识对应的游戏正常可用。

本申请实施例还提供了一种电子设备。在一些实施例中，电子设备可实现为图1中的运维服务端12或者运维服务端12的一部分。如图4所示，电子设备40包括：处理器41和存储器43。其中，处理器41和存储器43相连，如通过总线42相连。进一步地，电子设备4还可以包括收发器44。需要说明的是，实际应用中收发器44不限于一个，该电子设备4的结构并不构成对本申请实施例的限定。

其中，处理器41应用于本申请实施例中，用于实现图2所示的游戏更新装置20的功能。

处理器41可以是CPU，通用处理器，DSP，ASIC，FPGA或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器41也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线42可包括一通路，在上述组件之间传送信息。总线42可以是PCI总线或EISA总线等。总线42可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器43可以是ROM或可存储静态信息和指令的其他类型的静态存储设备，RAM或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM、CD-ROM或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器43用于存储执行本申请方案的应用程序代码，并由处理器41来控制执行。处理器41用于执行存储器43中存储的应用程序代码，以实现游戏更新装置20的动作。

本申请实施例提供的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，与现有技术相比，通过将游戏更新信息增加到游戏更新请求中，进而在获取游戏更新请求后，可基于游戏更新信息确定至少一个待更新渠道，从而对每个待更新渠道，将待更新游戏进行下架，并基于游戏更新信息更新待更新游戏的游戏信息，以及将部署通知发送给渠道下辖的多个游戏服务端，以使游戏服务端部署待更新游戏所需的资源，这样，在游戏更新过程中，用户可以看到游戏的下架状态，进而了解该游戏正在更新，避免游戏更新过程中使用该游戏的错误版本。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现游戏更新方法各实施例的步骤，为避免重复，在此不再赘述。

图5为本申请实施例提供的一种游戏更新方法的流程图，该方法应用于运维服务端，可包括如下步骤501至505：

在步骤501中，运维服务端获取游戏更新请求，游戏更新请求包括游戏更新信息。

在步骤502中，运维服务端基于游戏更新信息和预设的一个或多个渠道信息，确定至少一个待更新渠道。

在一些实施例中，游戏更新信息包括待更新游戏的游戏标识；渠道信息包括渠道的第一游戏列表，第一游戏列表包括每个游戏的游戏标识。运维服务端基于游戏更新信息和预设的一个或多个渠道信息，确定至少一个待更新渠道时，通过查找具有待更新游戏的游戏标识的第一游戏列表，进而将查找到的第一游戏列表所对应的渠道确定为待更新渠道。

在步骤503中，运维服务端针对每个待更新渠道，将该待更新渠道所对应的待更新游戏进行下架。

在一些实施例中，第一游戏列表还包括每个游戏的游戏状态。运维服务端将该待更新渠道所对应的待更新游戏进行下架时，可将该待更新渠道的第一游戏列表中待更新游戏的游戏状态设置为下架状态。

在步骤504中，运维服务端针对每个待更新渠道，基于游戏更新信息更新待更新游戏的游戏信息。

在一些实施例中，游戏更新信息还包括待更新游戏的第一游戏信息；第一游戏列表还包括每个游戏的第二游戏信息。运维服务端基于游戏更新信息更新待更新游戏的游戏信息时，用第一游戏信息替换该待更新渠道的第一游戏列表中待更新游戏的第二游戏信息。

在步骤505中，运维服务端针对每个待更新渠道，向该待更新渠道下辖的多个游戏服务端发送部署通知，以使每个游戏服务端基于部署通知部署待更新游戏所需的资源。

在一些实施例中，游戏更新信息还包括第一配置信息和游戏部署脚本。部署通知包括待更新游戏的第一游戏信息、第一配置信息和游戏部署脚本。每个游戏服务端基于部署通知部署待更新游戏所需的资源时，基于待更新游戏的第一游戏信息和第一配置信息，生成第二配置信息，并执行游戏部署脚本；其中，第二配置信息为存储于待更新游戏所需资源上的配置信息。

在一些实施例中，运维服务端向该待更新渠道下辖的多个游戏服务端发送部署通知时，通过将该待更新渠道下辖的多个游戏服务端分批，进而基于预先设置的发送策略，每次对同属一批的各游戏服务端发送部署通知。

在一些实施例中，发送策略包括：若返回部署结果的游戏服务端数量小于该待更新渠道下辖的游戏服务端数量，则继续对同属下一批的各游戏服务端发送部署通知。

在一些实施例中，运维服务端发送部署通知后，还可将对应的游戏服务端的状态修改为正在部署状态。

在一些实施例中，运维服务端还可获取每个游戏服务端对待更新游戏所需资源的部署结果；进而基于部署结果更新对应的游戏服务端的信息和状态。

在一些实施例中，部署结果包括：用于描述部署成功的信息、游戏服务端的标识、游戏标识和第二配置信息；或，用于描述部署失败的信息和失败信息。

在一些实施例中，运维服务端接收请求端发送的游戏更新请求，进而基于部署结果向请求端发送游戏更新响应；游戏更新响应包括已更新的渠道标识和已更新的游戏标识。在一些实施例中，运维服务端基于部署结果向请求端发送游戏更新响应时，基于部署结果为首个成功的部署结果，向请求端发送游戏更新响应。

在一些实施例中，运维服务端还可获取游戏上架请求，游戏上架请求包括渠道标识和游戏标识；进而统计渠道标识对应的渠道下返回的针对游戏标识的部署结果的游戏服务端数量；从而判断若至少一个部署结果为成功，则将渠道标识对应的渠道下游戏标识所对应的游戏设置为上架状态。

可见，通过将游戏更新信息增加到游戏更新请求中，进而在获取游戏更新请求后，可基于游戏更新信息确定至少一个待更新渠道，从而对每个待更新渠道，将待更新游戏进行下架，并基于游戏更新信息更新待更新游戏的游戏信息，以及将部署通知发送给渠道下辖的多个游戏服务端，以使游戏服务端部署待更新游戏所需的资源，这样，在游戏更新过程中，用户可以看到游戏的下架状态，进而了解该游戏正在更新，避免游戏更新过程中使用该游戏的错误版本。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。