CN116510312A - 一种云游戏多开实现方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种云游戏多开实现方法、装置、设备及存储介质，涉及计算机技术领域。该方法包括：获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上；协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。在容器基础上构建至少两个虚拟机，并通过容器协调不同虚拟机发送的资源访问请求对内核的访问，以便内核根据容器的协调按序处理每个资源访问请求，从而实现协调多个云游戏对内核的访问，实现云游戏多开，解决在云游戏多开场景下管理调度混乱的问题。

Description

一种云游戏多开实现方法、装置、设备及存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种云游戏多开实现方法、装置、设备及存储介质。

背景技术

目前，应用程序(APP)多开实现，常见的方案包括多用户方式、修改APP、修改Android framework(框架)层、插件机制或虚拟化技术等实现，但这些方案在云游戏多开场景下存在管理调度混乱的问题。

发明内容

有鉴于此，本发明的目的在于提供一种云游戏多开实现方法、装置、设备及介质，能够实现协调多个云游戏对内核的访问，实现云游戏多开，解决在云游戏多开场景下管理调度混乱的问题。其具体方案如下：

第一方面，本申请公开了一种云游戏多开实现方法，应用于容器，包括：

获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上；

协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。

可选的，所述获取基于所述容器构建的至少两个虚拟机发送的资源访问请求之前，还包括：

启动至少两个init进程构建得到所述虚拟机；其中，所述容器为所述内核启动的。

可选的，所述启动至少两个init进程构建得到所述虚拟机，包括：

利用每个所述init进程解析不同的系统配置信息，以得到多个系统配置不同的虚拟机；所述系统配置信息包含身份信息。

可选的，所述利用每个所述init进程解析不同的系统配置信息之后，还包括：

根据所述身份信息为每个init进程添加身份标识；

相应的，所述协调不同的所述资源访问请求对内核的访问，包括：

根据所述资源访问请求对应的身份标识协调不同的所述资源访问请求对内核的访问。

可选的，所述身份标识为用户ID，同一个init进程的子孙进程的用户ID开头相同，所述根据所述资源访问请求对应的身份标识协调不同的所述资源访问请求对内核的访问，包括：

通过对比所述资源访问请求对应的进程的用户ID和init进程的用户ID，确定发起所述资源访问请求的虚拟机；

根据所述资源访问请求对应的虚拟机，协调不同的所述资源访问请求对内核的访问。

可选的，所述云游戏多开实现方法，还包括：

获取所述虚拟机上的云游戏对应的客户端发送的硬件数据；所述硬件数据为所述客户端上硬件设备采集到的数据；

将所述硬件数据添加至预先创建的虚拟硬件中，以便利用所述虚拟硬件支持所述虚拟机访问；所述虚拟硬件为根据读取的虚拟化配置信息创建生成的。

可选的，所述将所述硬件数据添加至预先创建的虚拟硬件之前，还包括：

创建本地虚拟硬件服务端；

在所述init进程派生出的硬件抽象层上创建虚拟硬件客户端，以便利用所述虚拟硬件客户端接收云游戏发送的对所述虚拟硬件的访问请求，并将所述访问请求转发给所述虚拟硬件服务端，以便所述虚拟硬件服务端根据所述访问请求访问所述虚拟硬件。

可选的，所述获取基于所述容器构建的至少两个虚拟机发送的资源访问请求之前，还包括：

按照预设资源管理策略为每个所述虚拟机分配所述内核中的硬件资源；所述资源管理策略包括对资源的预留处理或/和分配处理。

可选的，所述协调不同的所述资源访问请求对内核的访问之前，还包括：

将所述虚拟机分配至对应的控制组，以便所述内核根据当前资源访问请求对应的虚拟机所属控制组的资源限制配置，在处理过程中对当前资源访问请求进行资源控制；所述控制组为根据所述预设资源管理策略在内核上创建的。

可选的，所述将所述虚拟机分配至对应的控制组，包括：

实时监测所述虚拟机的资源使用状态；

当目标虚拟机对应的资源使用状态满足预设调整条件时，重新为所述目标虚拟机分配新的控制组。

第二方面，本申请公开了一种云游戏多开实现装置，应用于容器，包括：

资源访问请求获取模块，用于获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上，所述访问请求包含虚拟机身份信息；

资源访问请求协调模块，用于协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。

第三方面，本申请公开了一种电子设备，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现前述的云游戏多开实现方法。

第四方面，本申请公开了一种计算机可读存储介质，用于存储计算机程序；其中计算机程序被处理器执行时实现前述的云游戏多开实现方法。

本申请中，获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上；协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。可见，在容器基础上构建至少两个虚拟机，并通过容器协调不同虚拟机发送的资源访问请求对内核的访问，以便内核根据容器的协调按序处理每个资源访问请求，从而实现协调多个云游戏对内核的访问，实现云游戏多开，解决在云游戏多开场景下管理调度混乱的问题。

附图说明

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

图1为本申请提供的一种云游戏多开实现方法流程图；

图2为现有技术中一种云游戏实现结构图；

图3为本申请提供的一种具体的云游戏多开实现结构图；

图4为本申请提供的一种具体的硬件数据添加流程图；

图5为本申请提供的一种具体的云游戏多开实现方法流程图；

图6为本申请提供的一种具体的资源分配方式示意图；

图7为本申请提供的另一种具体的资源分配方式示意图；

图8为本申请提供的一种云游戏多开实现装置结构示意图；

图9为本申请提供的一种电子设备结构图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现有技术中，应用程序多开实现，常见的方案包括多用户方式、修改APP、修改Android framework层、插件机制或虚拟化技术等实现，但这些方案在云游戏多开场景下存在管理调度混乱的问题。为克服上述技术问题，本申请提出一种云游戏多开实现方法，能够实现协调多个云游戏对内核的访问，实现云游戏多开，解决在云游戏多开场景下管理调度混乱的问题。

本申请实施例公开了一种云游戏多开实现方法，参见图1所示，该方法可以包括以下步骤：

步骤S11：获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上。

本实施例中，获取基于容器构建的至少两个虚拟机发送的针对内核资源的资源访问请求，也即，上述资源访问请求为运行在虚拟机上的云游戏发送的请求，且上述虚拟机是在上述容器上建立的。

本实施例中，所述获取基于所述容器构建的至少两个虚拟机发送的资源访问请求之前，还可以包括：启动至少两个init进程构建得到所述虚拟机；其中，所述容器为所述内核启动的。init进程为容器启动的第一个用户级进程，是所有进程的鼻祖。即内核启动完成后拉起容器，容器通过启动至少两个init进程构建得到虚拟机，其中，一个init进程对应一个虚拟机。

可以理解的是，本实施例中在内核(Kernel)和init之间创建容器，容器为虚拟化管理器，管理着init向上服务。以安卓系统启动过程为例，传统方案如图2所示，设备加电后引导芯片启动，引导芯片从固化ROM(Read-OnlyMemory，只读存储器)里预设的代码开始执行，检查硬件和初始化硬件参数等功能；进入到Kernel层，主要加载硬件设备驱动、初始化进程、电源管理等操作，完成后才开始进入init内核启动的第一个用户级进程；init准备完成后，会启动孵化器(zygote)，zygote启动会拉起系统服务(system_server)，所有的应用进程入口都在zygote启动，创建应用进程后由system_server提供接口回调和各类资源加载解析，zygote和system_server就构造了强大的APP生存环境。即安卓原生默认，每一层都需要来自其底层的服务，Kernel启动完成拉起init并为init、zygote、system_server、APP提供服务，init拉起zygote并为zygote、system_server、APP提供服务，zygote拉起system_server并为system_server、APP提供服务，在创建应用进程时由zygote和system_server协作创建应用进程并为APP提供服务。

本实施例中，例如图3所示，在启动过程中，内核启动完成后，构造一个容器，容器上面有多个init，然后init再启动后续流程，即驱动启动完成后不是按照正常流程去启动init，而是去启动容器，再由容器启动init，容器可以启动多个init，每个init进程继续按照传统方式创建应用进程。相当于容器就是init的管理者，容器就是虚拟化核心，管理着其上虚拟化每个init及服务，并与内核保持着通信服务，是Kernel与用户空间层(init、zygote、system_server、APP)沟通的桥梁。

本实施例中，所述启动至少两个init进程构建得到所述虚拟机，可以包括：利用每个所述init进程解析不同的系统配置信息，以得到多个系统配置不同的虚拟机；所述系统配置信息包含身份信息。即系统配置信息中包含身份信息，且不同系统配置信息中的身份信息不同，通过init进程解析不同的系统配置信息，得到多个身份信息不同且系统配置不同的虚拟机。通过不同系统配置信息创建的每个虚拟机不一样，每个虚拟设备可以在同一个时刻运行相同游戏或者不同游戏，同一个时刻满足用户输入、输出、播放音视频等，例如每个虚拟机上可以根据客户端的显示信息，设置不一样的分辨率。

步骤S12：协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。

本实施例中，容器协调不同的资源访问请求对内核的访问，即协调多个云游戏对内核的访问，内核对接收到的资源访问请求进行处理，即内核根据init访问时提供的身份信息轮流给每个访问程序服务，由于CPU运行快，处理任务轮流时间片短，对于上层用户是无感知的，然后将处理结果反馈给容器。

本实施例中，所述利用每个所述init进程解析不同的系统配置信息之后，还可以包括：根据所述身份信息为每个init进程添加身份标识；相应的，所述协调不同的所述资源访问请求对内核的访问，可以包括：根据所述资源访问请求对应的身份标识协调不同的所述资源访问请求对内核的访问。即每个init启动在容器都有一个唯一的身份标识，访问硬件资源时需要容器协调通信，容器主要根据身份标识来协调访问内核。可以理解的是，init拉起后开始解析系统配置信息，相当于每个init就是一个虚拟化操作系统，其启动后每个系统信息配置不一样可以为云游戏调度管理提供支撑。内核同时为多个虚拟化设备共用一个硬件资源，因为每个init名字不一样，就相当于同一个硬件资源平台运行不同虚拟化设备，一个虚拟化设备就是一个操作系统，即为内核的一个应用程序。

本实施例中，所述身份标识可以为用户ID(user identifier)，并且同一个init进程的子孙进程的用户ID开头相同，所述根据所述资源访问请求对应的身份标识协调不同的所述资源访问请求对内核的访问，可以包括：通过对比所述资源访问请求对应的进程的用户ID和init进程的用户ID，确定发起所述资源访问请求的虚拟机；根据所述资源访问请求对应的虚拟机，协调不同的所述资源访问请求对内核的访问。即虚拟机上的子孙进程对应的用户ID与该虚拟机的init进程对应的用户ID的开头相同。举例说明，某个虚拟机的某个子孙进程对应的用户ID为58775420，该虚拟机的init进程的用户ID为58784524，可见前3位一致，当然上述用户ID仅仅是为了解释说明，并无实际含义。可见通过配置虚拟机的init进程对应的用户ID与该虚拟机上init进程派生的子孙进程对应的用户ID的开头相同，由此根据资源访问进程对应的用户ID与每个虚拟机对应的用户ID的头部进行对比，可以判断出资源访问请求发起的虚拟机，最后根据所在虚拟机，协调不同的资源访问请求对内核的访问，用户ID可以存储在容器作为管理init的依据，容器与内核通信也根据用户ID进行服务以及资源调度。

本实施例中，所述云游戏多开实现方法，还可以包括：获取所述虚拟机上的云游戏对应的客户端发送的硬件数据；所述硬件数据为所述客户端上硬件设备采集到的数据；将所述硬件数据添加至预先创建的虚拟硬件中，以便利用所述虚拟硬件支持所述虚拟机访问；所述虚拟硬件为根据读取的虚拟化配置信息创建生成的。本实施例中，云游戏运行过程中获取虚拟机上的云游戏对应的客户端发送的硬件数据，硬件数据为客户端上硬件设备采集到的数据，可以理解的是，在云游戏模型中，所有的游戏逻辑和渲染都在服务器端运行，然后再从服务器把压缩的视频传给用户，这样玩家就不需要高性能的计算机，唯一的要求就是一个基本的视频解压软件和可靠的网络，但是某些数据并非云端依靠游戏逻辑即可得到的，如客户端的麦克风、摄像头、陀螺仪、重力感应器和加速度等相关硬件数据，然后，将硬件数据添加至预先创建的虚拟硬件中，以便利用虚拟硬件支持虚拟机访问。虚拟硬件包括麦克风、摄像头、陀螺仪、重力感应器、加速度器等。即本实施例中为每个虚拟机预配置一个虚拟硬件，用于存储该虚拟机对应的客户端生成的硬件数据。

本实施例中，所述将所述硬件数据添加至预先创建的虚拟硬件之前，还可以包括：创建本地虚拟硬件服务端；在所述init进程派生出的硬件抽象层上创建虚拟硬件客户端，以便利用所述虚拟硬件客户端接收云游戏发送的对所述虚拟硬件的访问请求，并将所述访问请求转发给所述虚拟硬件服务端，以便所述虚拟硬件服务端根据所述访问请求访问所述虚拟硬件。即在容器上创建用于根据访问请求访问虚拟硬件的硬件服务端，在init进程派生出的硬件抽象层上创建用于接收云游戏发送的对虚拟硬件的访问请求的虚拟硬件客户端。即创建虚拟硬件设备服务端，服务于虚拟机客户端的访问。虚拟硬件客户端与容器上虚拟硬件服务端，安卓的HAL层(硬件抽象层)可以相当于虚拟硬件客户端，供安卓系统访问，HAL定义的硬件接口由容器虚拟硬件服务端实现，当安卓应用访问虚拟硬件时，调用HAL接口即可访问到容器虚拟硬件服务端。

也即，本实施例中，通过增加容器创建多个虚拟机，对应游戏应用在虚拟机上运行作为服务端，客户端启动游戏时获取客户端信息(分辨率、陀螺仪、麦克风、相机等)传到服务端配置好虚拟机，然后拉起游戏，服务端游戏运行的界面实时推送到客户端，客户端硬件信息相关采集实时传到服务端作为响应。并且，游戏运行访问部分硬件(如输入输出、陀螺仪、麦克风、摄像头等)在init及其以上来执行，减轻了容器访问内核的压力。

本实施例中，云游戏多开虚拟硬件访问实现过程具体包括以下步骤：

1.启动虚拟机，即安卓系统启动。由容器拉起安卓系统启动，其第一个进程即为init，init再拉起zygote，zygote再启动system_server，system_server启动桌面应用，桌面应用加载系统安装的应用图标到桌面排列，至此安卓系统启动大概流程完成。

2.虚拟硬件客户端在安卓系统启动的init实现。init是native服务，主要是包括init进程以及其派生出来的用户空间的守护进程、HAL层、开机动画等，而虚拟硬件主要接口是在HAL层，HAL定义的接口服务端实现在容器，当应用访问虚拟硬件时，通过虚拟硬件客户端访问虚拟硬件服务端得以实现。

3.init启动各阶段按照安卓正常启动，依次包括看门狗跳转及环境变量设置，挂载文件系统和创建系统必要目录，挂载分区，初始化属性系统，执行安全上下文策略，开始属性系统服务并执行服务启动，虚拟硬件客户端就是这里启动的，启动时查询虚拟硬件服务端是否正常并设置可用状态。

4.init启动native服务，包括虚拟硬件客户端。虚拟硬件服务端在容器创建设备节点和必要的硬件信息，这里包括两点，一个是安卓系统能识别的虚拟硬件，另一个是等待虚拟硬件数据注入的服务端。容器按照安卓虚拟设备创建流程创建虚拟硬件设备，此时安卓系统作为客户端能根据API正常访问虚拟硬件服务端，但此时没有功能。虚拟硬件服务端的真正功能是需要不同的设备生成不同的数据供给硬件客户端，客户端再提供给应用消费，这里只创建了虚拟设备服务端和虚拟硬件，虚拟硬件客户端连接虚拟硬件服务端设备并没有数据给上层应用消费，所以还得另外获取数据填充到虚拟硬件上，这样才满足应用访问硬件需求，至此虚拟硬件服务端的硬件数据可以从云端获取，即云游戏客户端上获取，然后传到服务端填充到虚拟硬件设备上，这样就能让应用正常访问硬件了。

结合上述虚拟硬件中硬件数据添加过程，以麦克风音频为例，通过虚拟硬件服务端的硬件数据添加流程如下：

1.客户端通过app开启某个云游戏时，客户端app会连接服务端对应的游戏启动。客户端可以是任何云游戏的客户端(包括手机、平板等)，客户端的app是能访问服务端的云游戏应用，app有已经上线的云游戏。

2.服务端对应的游戏启动后，游戏开启麦克风音频，此时服务端通过安卓系统对应的麦克风接口感知正在运行的游戏需要开启麦克风，便通过SDK(软件开发工具包)通知到客户端设备的云游戏app开启麦克风。

3.客户的app开启麦克风后开始录制音频数据，把音频数据再通过SDK送到服务端，服务端接收到麦克风数据后，连接容器虚拟硬件管理服务，然后由服务注入到虚拟硬件中。

4.服务端的应用此时就能通过安卓标准的麦克风接口通过虚拟硬件客户端访问虚拟硬件服务端正常消费声音数据了。

5.虚拟硬件设备按照安卓标准创建，然后再另外创建一个虚拟硬件管理服务用于接收客户端传来的硬件数据，这个服务区别于虚拟硬件服务端和虚拟硬件客户端，因为虚拟硬件客户端是供安卓应用访问，按照安卓标准服务流程走，虚拟硬件服务端作为虚拟硬件HAL层接口的实现服务，但虚拟硬件管理服务是通过远端客户端传来的硬件采集数据接收到后，再注入到虚拟硬件服务端，这样虚拟硬件客户端访问虚拟硬件服务端才能正常工作。例如图4所示，包括app向虚拟硬件服务端调用硬件数据，以及客户端采集到的硬件数据填充到虚拟硬件设备上，由此运行在服务端的应用即可正常获取硬件数据了。

可见，本实施例中通过容器协调不同虚拟机对内核中可协调资源的资源访问请求，即针对内核中如CPU、内存、IO读写等资源，通过容器协调访问。而针对客户端生成的无法协调的硬件数据，通过将硬件数据添加至虚拟硬件，由虚拟硬件支持虚拟机的访问。由此，通过结合容器对内核资源的协调以及虚拟硬件提供硬件数据的访问，实现云游戏多开场景下针对虚拟机对不同资源的访问协调，提高了云游戏多开的服务能力。

由上可见，本实施例中获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上；协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。可见，在容器基础上构建至少两个虚拟机，并通过容器协调不同虚拟机发送的资源访问请求对内核的访问，以便内核根据容器的协调按序处理每个资源访问请求，从而实现协调多个云游戏对内核的访问，实现云游戏多开，解决在云游戏多开场景下管理调度混乱的问题。

在上述实施例的基础上，本申请实施例还公开了一种具体的云游戏多开实现方法，参见图5所示，该方法可以包括以下步骤：

步骤S21：按照预设资源管理策略分别为基于容器构建的至少两个虚拟机分配所述内核中的硬件资源；所述资源管理策略包括对资源的预留处理和或/和分配处理。

即容器启动后搜集初始化完成可用的硬件信息，为虚拟机分配磁盘存储和内存等硬件资源，按照预设资源管理策略分别为每个虚拟机分配内核中的硬件资源，其中，资源管理策略包括对资源的预留处理或/和分配处理，具体的，可以首先预留部分资源，然后将剩余的资源分配给每个虚拟机，资源分配可以是平均分配也可以是非平均分配。

例如，容器启动安卓系统完成时，平均分配CPU资源，预留25％的CPU资源作为后续调整策略的补充。若CPU资源总共是100％，启动三个虚拟机，每个虚拟机平均分配到25％的CPU资源，三个虚拟机即分出了75％CPU资源，另外25％还没有分配，预留作为动态调整分配。内存、IO读写、网络等也是基于此逻辑平均分配。

步骤S22：获取所述虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上。

步骤S23：将所述虚拟机分配至对应的控制组，协调不同的所述资源访问请求对内核的访问，以便所述内核根据当前资源访问请求对应的虚拟机所属控制组的资源限制配置，在处理过程中对当前资源访问请求进行资源控制；所述控制组为根据所述预设资源管理策略在内核上创建的。

本实施例中，采用控制组(CGroups，Linux Control Groups)来限制、控制与分离一个进程组群资源(如CPU、内存、磁盘输入输出等)，实时能够监控到所有进程的状态(冻结、停止或重新启动)。可以对容器启动的每个进程进行严格控制，如虚拟机控制、资源限制、优先级控制等，互斥资源控制处理，控制程序互斥访问。可以理解的是，硬件(CPU、内存、网卡等)资源有限，内核通过组建控制组控制程序访问资源，以便解决访问冲突。

本实施例中，所述将所述虚拟机分配至对应的控制组，可以包括：实时监测所述虚拟机的资源使用状态；当目标虚拟机对应的资源使用状态满足预设调整条件时，重新为所述目标虚拟机分配新的控制组。即当有游戏启动时，系统通知到容器启动资源监控，资源监控包括CPU、内存、IO、网络等。也即根据硬件的使用频次、负载、磁盘IO、网络等状态信息，动态调用控制组以实现做资源调整。

其中，CGroups对资源的管理有很多子系统，包括但不限于：cpu子系统，主要限制进程的cpu使用率；cpuacct子系统，可以统计CGroups中的进程的cpu使用报告；cpuset子系统，可以为CGroups中的进程分配单独的cpu节点或者内存节点；memory子系统，可以限制进程的memory使用量；blkio子系统，可以限制进程的块设备io；devices子系统，可以控制进程能够访问某些设备；net_cls子系统，可以标记CGroups中进程的网络数据包，然后可以使用tc模块(traffic control)对数据包进行控制；freezer子系统，可以挂起或者恢复CGroups中的进程；ns子系统，可以使不同CGroups下面的进程使用不同的namespace。每个子系统通过与内核的其他模块配合来完成资源的控制，比如对cpu资源的限制是通过进程调度模块根据cpu子系统的配置来完成的；对内存资源的限制则是内存模块根据memory子系统的配置来完成的，而对网络数据包的控制则需要Traffic Control子系统来配合完成等。

资源监控管理在一定的周期(可以是100毫秒)从CGroups的cpuacct读取资源使用情况，达到CPU紧张程度或者消耗很小的CPU时，重新把虚拟机对应的进程号设置到对应的CGroups策略中，其中，子进程自动成为父进程所在的控制组的成员，但也可按需求将子进程移到不同的CGroup中，如此周期循环容器根据读取当前正在运行的CPU设备进行再管理。其他如内存、IO读写、网络等资源也是基于这样的思路来进行管理。

例如图6所示，为按资源百分比分配，每个CGroups可以有自己的子CGroups，但子CGroup不能大于父CGroup的限制值，每个CGroups都是一个CGroups策略，对应的进程加进去即可限制资源使用。CGroup1可以使用CPU的75％时间片，Cgroup2可以使用CPU的25％时间片，以此类推，当要限制进程在某个策略时，可以把对应的进程号加到对应的控制策略里面即可(如可以把一个进程号加入到CGroup6策略中，策略CGroup6的进程都受到上限5％资源的限制)，这样进程运行就不会超过策略限制的值。当虚拟机启动系统但没有游戏启动时，子进程自动成为父进程CGroups的成员，也就跟父进程受到同样的CGroups组策略制约，但经过cpuacct生成CPU使用报告可按需对子进程进行动态调整，可以设置子进程到不同的CGroups策略中，一个进程在一个CGroups资源控制子系统中只能在一个CGroups策略上，加入到一个新的CGroups策略中，原来旧的策略自动移除进程节点失效。类似的，其他如内存、IO、网络等也可以基于这样的策略来调整资源，使其资源得到充分利用。

例如图7所示，为按CPU核来分配，当虚拟机系统启动但没有游戏启动时，CPU平均绑定两个核，这样即为CGroupA策略，总共8个核，三个虚拟机，每个虚拟机系统绑定两个核，这样利用就是2/8＝25％，还有25％资源为动态分配，即为CGroupsB策略，其他策略也需要根据具体的值，算CPU时间片的使用，单核策略为1/8＝12.5％。即CGroupsD为单核资源，CGroupsC为四核资源，CGroupsB为双核资源，CGroupsE为3核资源，加入到其下的进程号即为绑定到某个具体策略，策略里面限制到CPU核。一个CGroup组可以加入多个进程号限制，在这个组内的进程即为受到此组策略的约束。当某个虚拟机CPU紧张时(通过上面的管理策略读取cpuacct生成CPU使用报告得知紧张程度)，可以协调剩下动态分配的25％资源来使用，如在CGroupsB上的策略CPU还是紧张，那么可以把进程号移到CGroupE，增加一个CPU核，这样进程在原来两个核跑紧张的时候移到新策略上能跑到三个CPU核。

其中，关于上述步骤S22的具体过程可以参考前述实施例公开的相应内容，在此不再进行赘述。

由上可见，本实施例中按照预设资源管理策略分别为基于容器构建的至少两个虚拟机分配所述内核中的硬件资源；所述资源管理策略包括对资源的预留处理或/和分配处理；获取所述虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上；将所述虚拟机分配至对应的控制组，协调不同的所述资源访问请求对内核的访问，以便所述内核根据当前资源访问请求对应的虚拟机所属控制组的资源限制配置，在处理过程中对当前资源访问请求进行资源控制；所述控制组为根据所述预设资源管理策略在内核上创建的。可见，内核通过组建控制组控制程序访问资源，实现资源限制，以便解决访问冲突。

相应的，本申请实施例还公开了一种云游戏多开实现装置，参见图8所示，该装置包括：

资源访问请求获取模块11，用于获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上，所述访问请求包含虚拟机身份信息；

资源访问请求协调模块12，用于协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。

由上可见，本实施例中获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上；协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。可见，在容器基础上构建至少两个虚拟机，并通过容器协调不同虚拟机发送的资源访问请求对内核的访问，以便内核根据容器的协调按序处理每个资源访问请求，从而实现协调多个云游戏对内核的访问，实现云游戏多开，解决在云游戏多开场景下管理调度混乱的问题。

在一些具体实施例中，所述云游戏多开实现装置具体可以包括：

虚拟机构建单元，用于在获取基于所述容器构建的至少两个虚拟机发送的资源访问请求之前，启动至少两个init进程构建得到所述虚拟机；其中，所述容器为所述内核启动的。

在一些具体实施例中，所述虚拟机构建单元具体可以包括：

解析单元，用于利用每个所述init进程解析不同的系统配置信息，以得到多个系统配置不同的虚拟机；所述系统配置信息包含身份信息。

在一些具体实施例中，所述虚拟机构建单元具体可以包括：

身份标识添加单元，用于在利用每个所述init进程解析不同的系统配置信息之后，根据所述身份信息为每个init进程添加身份标识；

相应的，所述资源访问请求协调模块12，包括：

资源访问请求协调单元，用于根据所述资源访问请求对应的身份标识协调不同的所述资源访问请求对内核的访问。

在一些具体实施例中，所述身份标识为用户ID，同一个init进程的子孙进程的用户ID开头相同，所述资源访问请求协调单元，包括：

对比单元，用于通过对比所述资源访问请求对应的进程的用户ID和init进程的用户ID，确定发起所述资源访问请求的虚拟机；

协调单元，用于根据所述资源访问请求对应的虚拟机，协调不同的所述资源访问请求对内核的访问。

在一些具体实施例中，所述云游戏多开实现装置具体可以包括：

硬件数据获取单元，用于获取所述虚拟机上的云游戏对应的客户端发送的硬件数据；所述硬件数据为所述客户端上硬件设备采集到的数据；

硬件数据添加单元，用于将所述硬件数据添加至预先创建的虚拟硬件中，以便利用所述虚拟硬件支持所述虚拟机访问；所述虚拟硬件为根据读取的虚拟化配置信息创建生成的。

在一些具体实施例中，所述云游戏多开实现装置具体可以包括：

虚拟硬件服务端创建单元，用于创建本地虚拟硬件服务端；

虚拟硬件客户端创建单元，用于在所述init进程派生出的硬件抽象层上创建虚拟硬件客户端，以便利用所述虚拟硬件客户端接收云游戏发送的对所述虚拟硬件的访问请求，并将所述访问请求转发给所述虚拟硬件服务端，以便所述虚拟硬件服务端根据所述访问请求访问所述虚拟硬件。

在一些具体实施例中，所述云游戏多开实现装置具体可以包括：

硬件资源分配单元，用于在获取基于所述容器构建的至少两个虚拟机发送的资源访问请求之前，按照预设资源管理策略为每个所述虚拟机分配所述内核中的硬件资源；所述资源管理策略包括对资源的预留处理或/和分配处理。

在一些具体实施例中，所述云游戏多开实现装置具体可以包括：

控制组分配单元，用于在协调不同的所述资源访问请求对内核的访问之前，将所述虚拟机分配至对应的控制组，以便所述内核根据当前资源访问请求对应的虚拟机所属控制组的资源限制配置，在处理过程中对当前资源访问请求进行资源控制；所述控制组为根据所述预设资源管理策略在内核上创建的。

在一些具体实施例中，所述控制组分配单元具体可以包括：

监测单元，用于实时监测所述虚拟机的资源使用状态；

重分配单元，用于当目标虚拟机对应的资源使用状态满足预设调整条件时，重新为所述目标虚拟机分配新的控制组。

进一步的，本申请实施例还公开了一种电子设备，参见图9所示，图中的内容不能被认为是对本申请的使用范围的任何限制。

图9为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的云游戏多开实现方法中的相关步骤。

本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统221、计算机程序222及包括资源访问请求在内的数据223等，存储方式可以是短暂存储或者永久存储。

其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，以实现处理器21对存储器22中海量数据223的运算与处理，其可以是Windows Server、Netware、Unix、Linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的云游戏多开实现方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。

进一步的，本申请实施例还公开了一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器加载并执行时，实现前述任一实施例公开的云游戏多开实现方法步骤。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种云游戏多开实现方法、装置、设备及介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

1.一种云游戏多开实现方法，其特征在于，应用于容器，包括：

获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上；

协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。

2.根据权利要求1所述的云游戏多开实现方法，其特征在于，所述获取基于所述容器构建的至少两个虚拟机发送的资源访问请求之前，还包括：

启动至少两个init进程构建得到所述虚拟机；其中，所述容器为所述内核启动的。

3.根据权利要求2所述的云游戏多开实现方法，其特征在于，所述启动至少两个init进程构建得到所述虚拟机，包括：

利用每个所述init进程解析不同的系统配置信息，以得到多个系统配置不同的虚拟机；所述系统配置信息包含身份信息。

4.根据权利要求3所述的云游戏多开实现方法，其特征在于，所述利用每个所述init进程解析不同的系统配置信息之后，还包括：

根据所述身份信息为每个init进程添加身份标识；

相应的，所述协调不同的所述资源访问请求对内核的访问，包括：

根据所述资源访问请求对应的身份标识协调不同的所述资源访问请求对内核的访问。

5.根据权利要求4所述的云游戏多开实现方法，其特征在于，所述身份标识为用户ID，同一个init进程的子孙进程的用户ID开头相同，所述根据所述资源访问请求对应的身份标识协调不同的所述资源访问请求对内核的访问，包括：

通过对比所述资源访问请求对应的进程的用户ID和init进程的用户ID，确定发起所述资源访问请求的虚拟机；

根据所述资源访问请求对应的虚拟机，协调不同的所述资源访问请求对内核的访问。

6.根据权利要求2所述的云游戏多开实现方法，其特征在于，还包括：

获取所述虚拟机上的云游戏对应的客户端发送的硬件数据；所述硬件数据为所述客户端上硬件设备采集到的数据；

将所述硬件数据添加至预先创建的虚拟硬件中，以便利用所述虚拟硬件支持所述虚拟机访问；所述虚拟硬件为根据读取的虚拟化配置信息创建生成的。

7.根据权利要求6所述的云游戏多开实现方法，其特征在于，所述将所述硬件数据添加至预先创建的虚拟硬件之前，还包括：

创建本地虚拟硬件服务端；

在所述init进程派生出的硬件抽象层上创建虚拟硬件客户端，以便利用所述虚拟硬件客户端接收云游戏发送的对所述虚拟硬件的访问请求，并将所述访问请求转发给所述虚拟硬件服务端，以便所述虚拟硬件服务端根据所述访问请求访问所述虚拟硬件。

8.根据权利要求1至7任一项所述的云游戏多开实现方法，其特征在于，所述获取基于所述容器构建的至少两个虚拟机发送的资源访问请求之前，还包括：

按照预设资源管理策略为每个所述虚拟机分配所述内核中的硬件资源；所述资源管理策略包括对资源的预留处理或/和分配处理。

9.根据权利要求8所述的云游戏多开实现方法，其特征在于，所述协调不同的所述资源访问请求对内核的访问之前，还包括：

将所述虚拟机分配至对应的控制组，以便所述内核根据当前资源访问请求对应的虚拟机所属控制组的资源限制配置，在处理过程中对当前资源访问请求进行资源控制；所述控制组为根据所述预设资源管理策略在内核上创建的。

10.根据权利要求9所述的云游戏多开实现方法，其特征在于，所述将所述虚拟机分配至对应的控制组，包括：

实时监测所述虚拟机的资源使用状态；

当目标虚拟机对应的资源使用状态满足预设调整条件时，重新为所述目标虚拟机分配新的控制组。

11.一种云游戏多开实现装置，其特征在于，应用于容器，包括：

资源访问请求获取模块，用于获取基于所述容器构建的至少两个虚拟机发送的资源访问请求；所述云游戏运行在所述虚拟机上，所述访问请求包含虚拟机身份信息；

资源访问请求协调模块，用于协调不同的所述资源访问请求对内核的访问，并接收所述内核根据所述资源访问请求进行处理后反馈的处理结果，以便协调多个云游戏对内核的访问。

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

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现如权利要求1至10任一项所述的云游戏多开实现方法。

13.一种计算机可读存储介质，其特征在于，用于存储计算机程序；其中计算机程序被处理器执行时实现如权利要求1至10任一项所述的云游戏多开实现方法。