CN110688202A - 服务进程调度方法、装置、设备及存储介质 - Google Patents
服务进程调度方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN110688202A CN110688202A CN201910953616.3A CN201910953616A CN110688202A CN 110688202 A CN110688202 A CN 110688202A CN 201910953616 A CN201910953616 A CN 201910953616A CN 110688202 A CN110688202 A CN 110688202A
- Authority
- CN
- China
- Prior art keywords
- virtual machine
- container
- service process
- equipment
- over
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 297
- 230000008569 process Effects 0.000 title claims abstract description 218
- 238000003860 storage Methods 0.000 title claims abstract description 21
- 238000005516 engineering process Methods 0.000 claims abstract description 76
- 230000015654 memory Effects 0.000 claims description 60
- 230000002159 abnormal effect Effects 0.000 claims description 9
- 230000001976 improved effect Effects 0.000 abstract description 8
- 238000013473 artificial intelligence Methods 0.000 description 22
- 238000012545 processing Methods 0.000 description 17
- 238000010586 diagram Methods 0.000 description 16
- 230000006870 function Effects 0.000 description 11
- 238000012360 testing method Methods 0.000 description 11
- 238000011161 development Methods 0.000 description 10
- 238000002955 isolation Methods 0.000 description 9
- 238000010801 machine learning Methods 0.000 description 9
- 238000012549 training Methods 0.000 description 9
- 238000007726 management method Methods 0.000 description 6
- 238000012544 monitoring process Methods 0.000 description 6
- 238000011160 research Methods 0.000 description 6
- 241000282414 Homo sapiens Species 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000003058 natural language processing Methods 0.000 description 5
- 230000015572 biosynthetic process Effects 0.000 description 4
- 238000004140 cleaning Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000001965 increasing effect Effects 0.000 description 4
- 230000006378 damage Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000013135 deep learning Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000014509 gene expression Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 241000282412 Homo Species 0.000 description 1
- 244000035744 Hura crepitans Species 0.000 description 1
- 241000276420 Lophius piscatorius Species 0.000 description 1
- 101100513046 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) eth-1 gene Proteins 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000008602 contraction Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 235000019800 disodium phosphate Nutrition 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000001939 inductive effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 238000011056 performance test Methods 0.000 description 1
- 230000002787 reinforcement Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000008093 supporting effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 238000013526 transfer learning Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
本申请实施例提供了一种服务进程调度方法、装置、设备及存储介质，其中，方法包括：当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量；采用容器化技术，在每一所述虚拟机中部署至少一个容器；当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程。通过本申请，能够充分利用设备的资源，提高设备资源利用率。
Description
技术领域
本申请实施例涉及互联网技术领域，涉及但不限于一种服务进程调度方法、装置、设备及存储介质。
背景技术
目前，为了物理机设备上所运行的服务进程的正常有序调度，常用的方法是采用虚拟化技术，通过装箱率来衡量服务进程的运行情况，或者，采用容器化技术，在容器中运行服务进程，依托容器本身的轻量性，实现设备资源的伸缩。
但是，随机物理机设备的高密度大容量发展趋势，普通的业务进程不能吃满整个物理机的资源负载，会造成物理机资源的浪费，并且，单纯的虚拟机缺乏调度的灵活性，单纯的容器化缺乏容器之间的安全隔离性。
发明内容
本申请实施例提供一种服务进程调度方法、装置、设备及存储介质，能够提高物理机设备的资源利用率，保证服务进程的安全有序调度。
本申请实施例的技术方案是这样实现的：
本申请实施例提供一种服务进程调度方法，包括：
当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量；
采用容器化技术，在每一所述虚拟机中部署至少一个容器；
当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程。
本申请实施例提供一种服务进程调度装置，包括：
虚拟机形成模块，用于当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量；
容器部署模块，用于采用容器化技术，在每一所述虚拟机中部署至少一个容器；
运行模块，用于当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程。
本申请实施例提供一种服务进程调度设备，包括：
存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现上述的方法。
本申请实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现上述的方法。
本申请实施例具有以下有益效果：
当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量。如此，在形成虚拟机时申请的资源量大于设备的总资源量，可以实现在所述设备上同时运行更多的服务进程，从而充分利用设备的资源，提高设备资源利用率。
附图说明
图1是本申请实施例提供的资源申请的结构示意图；
图2是实际资源使用量与资源申请量之间的关系图；
图3是采用超卖技术进行资源申请的流程示意图；
图4A是本申请实施例提供的IaaS层、PaaS层和SaaS层的部署关系图；
图4B是本申请实施例提供的服务进程调度的应用场景示意图；
图5是本申请实施例提供的服务器集群的结构示意图；
图6是本申请实施例提供的控制节点的结构示意图；
图7是本申请实施例提供的服务进程调度方法的一个可选的流程示意图；
图8是本申请实施例提供的服务进程调度方法的一个可选的流程示意图；
图9是本申请实施例提供的服务进程调度方法的一个可选的流程示意图；
图10是本申请实施例提供的服务进程调度方法的一个可选的流程示意图；
图11是本申请实施例提供的服务进程调度方法的实现流程示意图；
图12是本申请实施例提供的单个容器的结构框架图；
图13是本申请实施例提供的王者AI训练场景下的实现流程；
图14是本申请实施例提供的发起形成超卖子机操作的实现流程示意图；
图15是本申请实施例提供的超卖自己上容器的销毁流程示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)资源：在本文中是指物理机的资源，包括计算机程序运行时所需的中央处理器(CPU，Central Processing Unit)资源、内存资源、硬盘资源和网络资源。各类编程语言在进行软件开发时，都支持对计算资源的申请、分配等操作，例如，C语言的申请数组；而对线程的申请，则根据计算机CPU资源的情况而申请。又例如，在分布式计算架构中，可以对不同任务进行CPU资源、内存资源、硬盘资源和网络资源的控制的分配。
2)虚拟机：是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。虚拟系统通过生成现有操作系统的全新虚拟镜像，它具有真实windows系统完全一样的功能，进入虚拟系统后，所有操作都是在这个全新的独立的虚拟系统里面进行，可以独立安装运行软件，保存数据，拥有自己的独立桌面，不会对真正的系统产生任何影响，而且具有能够在现有系统与虚拟镜像之间灵活切换的一类操作系统
3)镜像(Image)：是对应用程序和其依赖的运行环境的封装。例如，镜像可以是文件系统格式，除了包括提供容器节点运行时所需的应用程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。
4)容器(Docker)：是根据镜像在物理机(即，用来部署容器的宿主机)的操作系统中或者在虚拟机的操作系统中直接创建的实例，它可以被启动、开始、停止或删除。宿主机的每个容器都包括独立的运行环境(即逻辑上的操作系统，包括用户权限、进程空间、用户空间和网络空间等)以及运行在其中的应用程序，多个容器能够直接运行在宿主机的各种操作系统中并共享操作系统的内核，由于每个应用程序独占运行环境，从而实现应用程序之间的隔离。
5)超卖：是指在服务器上跑的业务所申请的资源的综合，超出了服务器本身所拥有的资源量。
为了更好地理解本申请实施例中提供的服务进程调度方法，首先对超卖技术进行分析说明：
如图1所示，是本申请实施例提供的资源申请的结构示意图，在对业务进行容器化过程中，业务以前是对物理机10(图中示例性示出了所采购的物理机10a、物理机10b和物理机10c)的采购，即通过物理机10a、物理机10b和物理机10c形成物理机集群100，则在资源利用的时候，可以利用整个物理机集群的全部资源，即可以利用物理机10a、物理机10b和物理机10c的资源总量。那么在经过容器化处理之后，资源申请可以转向对各项物理资源(例如CPU资源101、存储资源102和网络资源103等)的申请。
但是，在业务的实际运行过程中，业务对资源的使用，往往是达不到业务所申请的资源量的，也就是说，比如业务进行申请的存储资源是1M，但是实际上在业务进程的运行过程中所需要的实际存储大小是小于1M的，业务进程的运行并不能完全吃满所申请的全部资源，如图2所示，是实际资源使用量与资源申请量之间的关系图，其中，横坐标表示业务处理过程(或者时间)，纵坐标表示资源量，则从图2可以看出，在实际业务处理过程中，资源申请量通常是大于实际资源使用量的，这样才能保证业务的正常有序进行，否则，一旦实际资源使用量大于资源申请量，就会导致系统崩溃。然而，这样的业务处理过程，又难免存在资源大量浪费的问题。
基于图1和图2的业务处理过程，为了提高资源的利用率，本申请引入超卖的概念，即在服务器上跑的业务所申请的资源的总和，超出了服务器本身所拥有的资源量。如图3所示，是采用超卖技术进行资源申请的流程示意图，其中，物理机的整机资源31可以实现业务1至n，但是在进行资源申请的时候，可以多申请一部分资源，即图3中实现业务n+1至m的资源。也就是说，在资源申请的时候，申请了能够实现m个业务的资源，但是实际上物理机的整机资源只能够实现n个业务，n小于m，那么，申请时所超出的申请资源即为超卖申请的超卖资源32。
本申请可以采用云技术实现服务进程的调度方法，其中，云技术(Cloudtechnology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利，云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。
云计算是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。
作为云计算的基础能力提供商，会建立云计算资源池平台，简称云平台，一般称为基础设施即服务(IaaS，Infrastructure as a Service)，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备和网络设备。
按照逻辑功能划分，在IaaS层上可以部署平台即服务(PaaS，Platform asaService)层，PaaS层之上再部署软件即服务(SaaS，Software as a Service)层，也可以直接将SaaS层部署在IaaS层上。PaaS层为软件运行的平台，如数据库、web容器等。SaaS层为各式各样的业务软件，如web门户网站、短信群发器等。其中，IaaS层401、PaaS层402和SaaS层403部署关系如图4A所示，一般来说，SaaS层403和PaaS层402相对于IaaS层401是上层。
本申请实施例提供的服务进程调度方法，还可以应用于人工智能(AI，ArtificialIntelligence)场景，例如，在游戏的AI训练场景下，通过本申请实施例提供的服务进程调度方法，即可对AI训练场景进行游戏进程的调度。
这里，为了更好地理解本申请实施例提供的方法，首先对人工智能、人工智能的各个分支，以及本申请实施例提供的方法所涉及的应用领域进行说明。
人工智能是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。换句话说，人工智能是计算机科学的一个综合技术，它企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。人工智能也就是研究各种智能机器的设计原理与实现方法，使机器具有感知、推理与决策的功能。
人工智能技术是一门综合学科，涉及领域广泛，既有硬件层面的技术也有软件层面的技术。人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。以下对各个方向分别进行说明。
计算机视觉技术(CV，Computer Vision)计算机视觉是一门研究如何使机器“看”的科学，更进一步的说，就是指用摄影机和电脑代替人眼对目标进行识别、跟踪和测量等机器视觉，并进一步做图形处理，使电脑处理成为更适合人眼观察或传送给仪器检测的图像。作为一个科学学科，计算机视觉研究相关的理论和技术，试图建立能够从图像或者多维数据中获取信息的人工智能系统。计算机视觉技术通常包括图像处理、图像识别、图像语义理解、图像检索、OCR、视频处理、视频语义理解、视频内容/行为识别、三维物体重建、3D技术、虚拟现实、增强现实、同步定位与地图构建等技术，还包括常见的人脸识别、指纹识别等生物特征识别技术。
语音技术(Speech Technology)的关键技术有自动语音识别技术(ASR，AutomaticSpeech Recognition)和语音合成技术(TTS，Text To Speech)以及声纹识别技术。让计算机能听、能看、能说、能感觉，是未来人机交互的发展方向，其中语音成为未来最被看好的人机交互方式之一。
自然语言处理(NLP，Nature Language Processing)是计算机科学领域与人工智能领域中的一个重要方向。它研究能实现人与计算机之间用自然语言进行有效通信的各种理论和方法。自然语言处理是一门融语言学、计算机科学、数学于一体的科学。因此，这一领域的研究将涉及自然语言，即人们日常使用的语言，所以它与语言学的研究有着密切的联系。自然语言处理技术通常包括文本处理、语义理解、机器翻译、机器人问答、知识图谱等技术。
机器学习(ML，Machine Learning)是一门多领域交叉学科，涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能，重新组织已有的知识结构使之不断改善自身的性能。机器学习是人工智能的核心，是使计算机具有智能的根本途径，其应用遍及人工智能的各个领域。机器学习和深度学习通常包括人工神经网络、置信网络、强化学习、迁移学习、归纳学习等技术。
随着人工智能技术研究和进步，人工智能技术在多个领域展开研究和应用，例如常见的智能家居、智能穿戴设备、虚拟助理、智能音箱、智能营销、无人驾驶、自动驾驶、无人机、机器人、智能医疗、智能客服等，相信随着技术的发展，人工智能技术将在更多的领域得到应用，并发挥越来越重要的价值。
本申请实施例提供的方案可以涉及人工智能的计算机视觉、语音技术和机器学习等至少一种技术，具体通过如下实施例进行说明。
下面以物理机中的服务器通过使用容器化技术为例，即在虚拟机的操作系统中形成提供通用计算、网络和存储能力的服务的容器，进而形成基于虚拟机和容器的多层架构，说明实现本申请实施例的服务进程调度方法，进而实现对AI场景下的应用的服务进程进行调度的应用场景，图4B是本申请实施例提供的服务进程调度的应用场景示意图，如图4B所示，开发者400可以通过提交容器的镜像文件到镜像仓库410，以在镜像仓库410中存储镜像文件，其中，镜像仓库410中保存有多种容器的镜像文件。设备470对应的控制中心通过虚拟化技术在所述设备470上形成至少一个虚拟机471(图中示例性的示出了虚拟机471a和虚拟机471b)，虚拟机471提供镜像文件的开发环境420、测试环境430和线上环境440，其中，开发环境420用于实现对应用程序的镜像文件等进行开发和持续更新，测试环境420用于实现对所开发或所更新的镜像文件进行性能测试，线上环境440即发布环境，用于提供真实用户访问的环境。
举例来说，所述应用程序可以是游戏APP(例如，王者人机对战游戏APP)，那么，所述开发环境420可以为该游戏APP的开发环境，所述测试环境430可以为该游戏APP的测试环境，所述线上环境440可以为该游戏APP的线上环境，所述虚拟机470则可以用来承载该游戏APP后台的服务，例如，该游戏APP的道具选择服务、游戏场景更新服务和游戏训练服务等。
虚拟机470可以从镜像仓库410中获取镜像文件，以在开发环境420对镜像文件进行开发和持续更新，在测试环境对镜像文件进行测试，或者在线上环境440对镜像文件对应的容器服务进行上线发布。镜像文件可以在虚拟机470的开发环境420和测试环境430运行，通过测试环境对镜像文件测试，测试时的输出数据是不会触及到用户对应的客户端，当测试通过后的镜像文件提交上线后，用户460可以通过客户端450与线上环境440连接，测试后的这个镜像文件对应的版本才会通过客户端450与用户接触，使用户通过客户端450获取容器所实现的服务。其中，线上环境可以是实现任意一种服务的环境，例如，所述线上环境可以实现视频服务、即时通信服务和游戏背景音乐播放服务等。
本申请实施例中，所述控制中心可以是运行于所述设备470上的控制进程，也可以是独立于所述设备470的一个控制节点，例如，所述控制节点可以是独立于所述设备470的服务器、物理机设备等。当所述控制节点为与所述设备470相同的另一物理机设备时，则所述控制节点与所述设备470形成服务器集群，如图5所示，是本申请实施例提供的服务器集群的结构示意图，所述控制节点510作为所述服务器集群50的管理节点，负责管理服务器集群，以实现对所述服务器集群的其他设备520(包括所述设备470和示例性其他设备520a等)进行控制。例如，所述控制节点510可以用于管理服务器集群50的其他设备520的上线、下线，或者还可以用于实现节点调度、负载均衡等。也就是说，控制节点510可以接收设备470和其他设备520的资源利用率，并基于资源利用率向设备470和其他设备520发送控制指令，其中所述控制指令可以包括以下至少之一：控制采用虚拟化技术形成虚拟机的指令、控制采用容器化技术部署容器的指令、服务进程调度指令等。
为了充分利用设备的资源，提高设备资源利用率，本申请实施例提供一种服务进程调度方法、装置、设备及存储介质，采用超卖技术在设备上形成物理机，并增加管理调度策略实现资源虚拟机隔离和容器化，从而可以实现在所述设备上同时运行更多的服务进程，从而充分利用设备的资源，提高设备资源利用率。
下面说明本申请实施例提供的服务进程调度设备的示例性应用，本申请实施例提供的设备可以实施为控制中心，所述控制中心可以是运行于所述设备470上的控制进程，也可以是独立于所述设备470的一个控制节点510。下面，将说明设备实施为控制节点510时的示例性应用。
参见图6，图6是本申请实施例提供的控制节点510的结构示意图，图6所示的控制节点510包括：至少一个处理器610、存储器650、至少一个网络接口620和用户接口630。控制节点510中的各个组件通过总线系统640耦合在一起。可理解，总线系统640用于实现这些组件之间的连接通信。总线系统640除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图6中将各种总线都标为总线系统640。
处理器610可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。
用户接口630包括使得能够呈现媒体内容的一个或多个输出装置631，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口630还包括一个或多个输入装置632，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
存储器650可以是可移除的、不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器650可选地包括在物理位置上远离处理器610的一个或多个存储设备。存储器650包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器650旨在包括任意适合类型的存储器。在一些实施例中，存储器650能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。
操作系统651，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；
网络通信模块652，用于经由一个或多个(有线或无线)网络接口620到达其他计算设备，示例性的网络接口620包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；
输入处理模块653，用于对一个或多个来自一个或多个输入装置632之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图6示出了存储在存储器650中的一种服务进程调度装置654，其可以是程序和插件等形式的软件，包括以下软件模块：虚拟机形成模块6541、容器部署模块6542和运行模块6543，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的服务进程调度方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。
下面将结合本申请实施例提供的控制节点510的示例性应用和实施，说明本申请实施例提供的服务进程调度方法。
参见图7，图7是本申请实施例提供的服务进程调度方法的一个可选的流程示意图，将结合图7示出的步骤进行说明。
步骤S701，当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机。
这里，所述资源利用率可以是以下至少之一：所述设备当前的网络资源利用率、CPU资源利用率、内存资源利用率和硬盘资源利用率。所述第一阈值为资源利用率阈值，所述第一阈值可以是根据实际需要设置的阈值，当所述设备的资源利用率低于所述第一阈值时，表明所述设备当前的资源利用率较低，因而所述设备当前还有大量的可用资源，此时可以采用本申请实施例的方法，采用超卖技术形成虚拟机。
本申请实施例中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量。也就是说，在所述设备上所形成的虚拟机申请的资源量大于所述设备的总资源量。这里采用超卖技术进行虚拟机的部署，这样，可以保证后续可以在每一虚拟机中均运行有一定量的服务进程，进而从整体上来看，可以同时对设备的资源进行较大的利用，提高设备的资源利用率。
举例来说，当所述虚拟机申请的为内存资源时，所述设备的实际内存资源量为500M，但是所述至少两个虚拟机的内存资源需求量为600M，因此，所述至少两个虚拟机的内存资源需求量大于所述设备的实际内存资源量。但是，在实际运行服务进程时，每一虚拟机中不可能对申请资源进行完全占用，因此实际上对于整个设备来说，所运行的全部服务进程也不会吃满设备的总的资源量，因此，本申请实施例的方案在实际应用中是可行的。
所述虚拟化技术可以是指将设备上的各种实体资源，如服务器、网络、内存及存储等，予以抽象、转换后呈现出来，打破实体结构间的不可切割的障碍，使用户可以比原本的组态更好的方式来应用这些资源，即通过模拟计算机的硬件，来实现在同一台计算机上同时运行不同的操作系统的技术。这些资源的新虚拟部分是不受现有资源的架设方式、地域或物理组态所限制。一般所指的虚拟化资源包括计算能力和资料存储。传统的虚拟化技术从操作系统层下手，目标是建立一个可以用来执行整套操作系统的沙盒独立执行环境，习惯以虚拟机(VM，Virtual Machine)来称呼。
通过虚拟化技术在所述设备上形成至少两个虚拟机，所述至少两个虚拟机之间是相互隔离的，所述虚拟机是指可以像真实机器一样运行程序的计算机的软件实现。本申请实施例中，每一虚拟机的资源需求量与其他虚拟机的资源需求量可以相同也可以不同，具体可以在虚拟化过程中由控制节点进行控制，以实现每一虚拟机向所述设备申请对应的资源量。
步骤S702，采用容器化技术，在每一所述虚拟机中部署至少一个容器。
这里，每一虚拟机中可以部署一个或多个容器，所述容器化技术是一种以应用程序为中心的虚拟化技术，是直接将一个应用程序所需的相关程序代码、函式库、环境配置文件都打包起来建立执行环境。所述容器就是在隔离环境运行的一个进程，如果进程停止，容器就会销毁，其中，隔离的环境拥有自己的系统文件、IP地址和主机名等。
本申请实施例中，通过容器化技术在每一虚拟机中部署至少一个容器，其中，以实现在所述容器中运行服务进程。每一虚拟机中部署的容器的数量与其他虚拟机中部署的容器的数量可以相同，也可以不同。所述设备中的虚拟机中的全部容器共享所述设备的内核资源。
步骤S703，当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程。
这里，当调度服务进程时，则表明存在新的服务进程需要运行或者有服务进程的更新，因此，确定所述设备上是否具有空闲的虚拟机，如果有的话，在所述空闲的虚拟机上的容器中运行所述服务进程。
所述空闲的虚拟机是指所述虚拟机中有至少一个容器是空闲的，即所述空闲的虚拟机中存在至少一个容器中没有运行服务进程。
一次可以调度一个或多个服务进程，当一次调度多个服务进程时，可以将多个服务进程运行在不同的容器中，即在每一容器中运行一个服务进程。其中，所述多个服务进程可以运行于同一虚拟机中的多个容器中，也可以运行于不用虚拟机中的多个容器中。
举例来说，设备上具有3个虚拟机A、B和C，其中，虚拟机A中部署有三个容器A1、A2和A3，虚拟机B中部署有三个容器B1、B2和B3，虚拟机C中部署有三个容器C1、C2和C3。如果当前调度了一个游戏进程S1，则需需要判断3个虚拟机中是否存在空闲的虚拟机，此时，如果虚拟机A的3个容器中均运行有服务进程，则表明虚拟机A为非空闲虚拟机，如果虚拟机B中的容器B1和B2中运行有服务进程，而容器B3中没有运行服务进程，则表明虚拟机B为空闲虚拟机，如果虚拟机C中的容器C1中运行有服务进程，而容器C2和C3中没有运行服务进程，则表明虚拟机C也为空闲虚拟机。因此，则可以在虚拟机B和C中选择一个合适的虚拟机作为目标虚拟机，并在目标虚拟机中的空闲容器中运行游戏进程S1。当然，本申请实施例还提供一种在多个虚拟机中选择一个合适的虚拟机作为目标虚拟机的方案，在下文中进行描述。
本申请实施例可以应用于以下场景：某游戏公司的服务器实际可以同时实现100万人同时在线玩某款游戏，而在游戏上线发布之后，该游戏的注册账户高达150万用户，但是这150万用户是不可能同时在线的，因此，可以继续使用原有的服务器来支持游戏的运行，则可以采用本申请实施例的方法，采用虚拟化技术在服务器上形成多个虚拟机，其中多个虚拟机的资源需求量之和是实现150万用户在线玩游戏，并且，采用虚拟化技术，在每一虚拟机中部署至少一个容器，在所述容器中运行每一用户的游戏进程，当某一用户上线之后，则可以将该用户的游戏进程在空闲的虚拟机的至少一个容器中运行。
本申请实施例提供的服务进程调度方法，当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量。如此，在形成虚拟机时申请的资源量大于设备的总资源量，可以实现在所述设备上同时运行更多的服务进程，从而充分利用设备的资源，提高设备资源利用率。
基于图7，如图8所示，在一些实施例中，所述虚拟机包括非超卖虚拟机和超卖虚拟机；对应地，步骤S701可以通过以下步骤实现：
步骤S801，判断设备的资源利用率是否低于第一阈值。
如果判断结果为是，则执行步骤S802；如果判断结构为否，则执行步骤S805。
步骤S802，判断设备的缓存失效率是否低于第二阈值。
这里，所述第二阈值为缓存失效率的阈值，所述第二阈值也可以是根据实际需要设置的阈值。在一些实施例中所述缓存失效率可以是一级缓存(L1 cache)的失效率，其中，所述一级缓存都内置在CPU内部并与CPU同速运行，可以有效的提高CPU的运行效率，一级缓存越大，CPU的运行效率越高。
本申请实施例中，可以实时监控一级缓存失效率，用来评估设备对于任务指令所执行的时钟周期是否升高，如果一级缓存失效率低于第二阈值，则表明任务指令执行的时钟周期没有升高，即时钟周期正常，因而可以发起采用超卖技术形成虚拟机的操作。
这里，如果判断结果为是，则执行步骤S803；如果判断结构为否，则执行步骤S806。
步骤S803，采用所述虚拟化技术在所述设备上形成至少一个非超卖虚拟机和至少一个超卖虚拟机。
这里，所述非超卖虚拟机是指资源需求量小于所述设备的总资源量的虚拟机，所述超卖虚拟机是指资源需求量超出所述设备的总资源量的虚拟机，所述非超卖虚拟机与所述超卖虚拟机的资源需求量之和大于所述设备的总资源量。
本申请实施例中，所述非超卖虚拟机的数量和所述超卖虚拟机的数量均不固定，所述非超卖虚拟机的数量与所述超卖虚拟机的数量可以相同也可以不同。所述超卖虚拟机与所述非超卖虚拟机的作用和数据结构等完全相同，也就是说，所述超卖虚拟机能够实现与所述非超卖虚拟机相同的功能。在运行服务进程时，同一服务进程既可以运行于所述非超卖虚拟机中，或者也可以运行于所述超卖虚拟机中。
在一些实施例中，在形成超卖虚拟机和非超卖虚拟机之后，执行步骤S702，本申请实施例中，步骤S702可以通过以下步骤实现：
步骤S804，采用容器化技术，在每一超卖虚拟机和每一非超卖虚拟机中部署至少一个容器。
步骤S805，对所述超卖虚拟机中的容器运行的服务进程进行调度，以减小所述容器的资源占用量；并释放所述超卖虚拟机占用的所述设备的资源。
这里，对设备的资源利用率进行实时监控，当判断出设备的资源利用率高于第一阈值时，表明所述设备当前的资源利用率较高，因而所述设备当前没有太多的可用资源，此时需要对超卖虚拟机中的容器运行的服务进程进行调度，以防止在超卖虚拟机中运行有过多的服务进程，从而占满设备的总资源，而使得设备上的其他服务进程运行异常。本申请实施例中，对所述超卖虚拟机中的容器运行的服务进程进行调度，目的是为了减小所述容器的资源占用量，并且，还需要释放所述超卖虚拟机占用的设备的资源，以使得当前只有非超卖虚拟机占用设备的资源。
在一些实施例中，所述释放所述超卖虚拟机占用的所述设备的资源，可以通过以下步骤实现：
步骤S8051，结束所述超卖虚拟机中的容器对应的容器进程。
这里，结束所述容器对应的容器进程以实现销毁所述容器。在销毁容器之后并进行容器对应的脏数据的清理，以尽可能多的释放容器进程对设备资源的占用量。
步骤S8052，结束所述超卖虚拟机对应的虚拟机进程，以释放所述超卖虚拟机占用的所述设备的资源。
在销毁容器之后，结束超卖虚拟机对应的虚拟机进程，以实现销毁所述超卖虚拟机，从而释放虚拟机所占用的资源给设备。
本申请实施例中，当设备的资源利用率高于第一阈值，对超卖虚拟机中的容器运行的服务进程进行调度，并销毁所述容器，以及销毁所述超卖虚拟机，如此能够彻底的释放所述超卖虚拟机占用所述设备的资源量，从而保证了设备上其他服务进程的正常有序运行。
步骤S806，对所述超卖虚拟机中的容器运行的服务进程进行调度，以减小所述容器的资源占用量。
这里，对设备的资源利用率进行实时监控，当判断出设备的资源利用率低于第一阈值时，则继续实时监控设备的缓存失效率，当设备的缓存失效率高于第二阈值时，表明所述设备当前的缓存异常，不能实现服务进程的正常运行，因而对所述超卖虚拟机中的容器运行的服务进程进行调度，即调度走超卖虚拟机中的容器中所运行的服务进程，并销毁容器。同时，由于是存在缓存异常，因此超卖虚拟机对设备其他资源的占用并没有受到影响，因而保留超卖虚拟机。
本申请实施例中，当设备的资源利用率低于第一阈值，且设备的缓存失效率高于第二阈值时，对所述超卖虚拟机中的容器运行的服务进程进行调度，以减小所述容器的资源占用量。如此，通过对容器中服务进程的调度，能够保证容器中服务进程在调度之后继续有效运行，避免服务进程运行异常；并且，由于设备其他资源的占用并没有受到影响，因而超卖虚拟机保留，可以在后续的服务进程调度过程中，继续在超卖虚拟机上采用容器化技术形成新的容器以实现新的服务进程的运行，从而保证服务进程在设备上的稳定运行。
在一些实施例中，如图9所示，上述步骤S803还可以通过以下步骤实现：
步骤S901，当所述设备的资源利用率低于第一阈值，且所述设备的缓存失效率低于第二阈值时，确定所述设备的内存剩余量。
这里，所述设备的资源利用率低于第一阈值，且所述设备的缓存失效率低于第二阈值，是触发采用超卖技术形成超卖虚拟机的操作的条件。同时，由于虚拟机占用设备的内存，因而当触发采用超卖技术形成超卖虚拟机的操作时，首先需要确定所述设备当前的内存剩余量，以确定能够形成的超卖虚拟机的数量。
步骤S902，根据所述设备的所述资源利用率确定所述非超卖虚拟机的第一数量。
这里，所述非超卖虚拟机占用的资源对应所述设备当前的资源利用率，所述非超卖虚拟即为正常虚拟机，因而正常虚拟机占用的资源即为所述设备当前的资源利用率，所以根据所述设备的所述资源利用率确定所述非超卖虚拟机的第一数量。
本申请实施例中，可以根据所述资源利用率对应的资源量与非超卖虚拟机所占用的资源量(其中，每一非超卖虚拟机所占用的资源量相等)之间的比值，确定所述第一数量，或者，根据所述资源利用率对应的资源量与每一非超卖虚拟机所占用的资源量(其中，每一非超卖虚拟机所占用的资源量可以相等也可以不等)，确定所述第二数量，也就是使全部非超卖虚拟机所占用的资源量之和等于所述资源利用率对应的资源量。
步骤S903，根据所述设备的内存剩余量确定所述超卖虚拟机的第二数量。
这里，由于虚拟机占用设备的内存，所述非超卖虚拟机已经占用了设备的部分内存，因此超卖虚拟机可以占用设备当前所剩余的内存，即所述内存剩余量，因而可以根据设备的内存剩余量确定所述超卖虚拟机的第二数量。
本申请实施例中，可以根据所述内存剩余量与超卖虚拟机所占用的内存量(其中，每一超卖虚拟机所占用的内存量相等)之间的比值，确定所述第二数量，或者，根据所述内存剩余量与每一超卖虚拟机所占用的内存量(其中，每一超卖虚拟机所占用的内存量可以相等也可以不等)，确定所述第二数量，也就是使全部超卖虚拟机所占用的内存量之和等于所述内存剩余量。
步骤S904，采用虚拟化技术在所述设备上形成所述第一数量的非超卖虚拟机和所述第二数量的超卖虚拟机。
这里，当确定出所述第一数量和所述第二数量之后，采用虚拟化技术，在所述设备上形成第一数量的非超卖虚拟机和第二数量的超卖虚拟机。
本申请实施例提供的服务进程调度方法，根据资源利用率和内存剩余量分别确定非超卖虚拟机和超卖虚拟机应该部署的数量，从而能够在设备上部署准确数量的非超卖虚拟机和超卖虚拟机，以实现对设备资源的有效利用，进一步提高设备的资源利用率。
在一些实施例中，每一服务进程对应一用户标识；基于图7，如图10所示，在步骤S702之后，所述方法还包括以下步骤：
步骤S1001，禁止将具有不同用户标识的服务进程，运行在同一虚拟机中的容器中。
这里，不将具有相同用户标识的服务进程运行在同一虚拟机中的容器中，也就是说，在同一虚拟机中，运行的是同一用户的服务进程，如此能够通过虚拟机实现对不用用户的服务进程的隔离。
对应地，步骤S703可以通过以下步骤实现：
步骤S1002，当调度新的服务进程时，确定所述新的服务进程对应的所述用户标识。
步骤S1003，将所述新的服务进程运行于所述用户标识对应的空闲的虚拟机中的容器中。
这里，每一虚拟机对应一个用户标识，这样可以在一个虚拟机中运行对应的用户的服务进程。一个用户标识可以对应于至少一个虚拟机，也就是说，一个用户的服务进程可以运行于一个或多个虚拟机中，但是每一虚拟机中只能运行同一个用户的服务进程。
所述空闲的虚拟机是指所述虚拟机中具有空闲的容器。本申请实施例中，所述新的服务进程可以是一个或多个，所述空闲的虚拟机也可以是一个或多个。对应地，本申请实施例可以对应于以下几种场景：
场景一：设备上具有3个虚拟机A、B和C，其中，虚拟机A中部署有三个容器A1、A2和A3，虚拟机A对应的用户标识为K1；虚拟机B中部署有三个容器B1、B2和B3，虚拟机B对应的用户标识为K2；虚拟机C中部署有三个容器C1、C2和C3，虚拟机C对应的用户标识为K3。当调度新的服务进程S1时，确定服务进程S1对应的用户标识K1，则判断虚拟机A是否为空闲的虚拟机，如果虚拟机A中的容器A3空闲，则将服务进程S1运行于容器A3中。
场景二：设备上具有3个虚拟机A、B和C，其中，虚拟机A中部署有三个容器A1、A2和A3，虚拟机A对应的用户标识为K1；虚拟机B中部署有三个容器B1、B2和B3，虚拟机B对应的用户标识为K1；虚拟机C中部署有三个容器C1、C2和C3，虚拟机C对应的用户标识为K2。当调度新的服务进程S1和S2时，确定服务进程S1和S2对应的用户标识均为K1，则判断虚拟机A是否为空闲的虚拟机，如果虚拟机A中的容器A3空闲，显然一个容器A3不能运行完服务进程S1和S2，则继续判断虚拟机B是否为空闲的虚拟机，如果虚拟机B中的容器B3空闲，将服务进程S1运行于容器A3中，将服务进程S2运行于容器B3中。
步骤S1004，当所述用户标识对应的虚拟机中没有空闲的容器时，在所述虚拟机中扩容新的容器，以实现在所述新的容器中运行所述新的服务进程。
这里，在所述虚拟机中扩容新的容器，是指采用容器化技术在虚拟机中运行新的容器进程，形成新的容器。本申请实施例可以对应于以下场景：
场景三(基于上述场景一)：如果判断出虚拟机A不是空闲的虚拟机，即虚拟机A中的容器A1、A2和A3均运行有服务进程，则表明用户标识对应的虚拟机中没有空闲的容器，因此在虚拟机A中扩容新的容器A4，并将服务进程S1运行于容器A4中。
在其他实施例中，所述方法还可以包括以下步骤：
步骤S1010，当所述用户标识对应的虚拟机中没有足够运行所述新的服务的空闲的容器时，在其他虚拟机中确定空闲的虚拟机为目标虚拟机。
步骤S1011，将所述新的服务进程运行在所述目标虚拟机的容器中。
本申请实施例可以对应于以下几种场景：
场景四：设备上具有4个虚拟机A、B、C和D，其中，虚拟机A中部署有三个容器A1、A2和A3，虚拟机A对应的用户标识为K1；虚拟机B中部署有三个容器B1、B2和B3，虚拟机B对应的用户标识为K2；虚拟机C中部署有三个容器C1、C2和C3，虚拟机C对应的用户标识为K3；虚拟机D中部署有三个容器D1、D2和D3，虚拟机D没有运行服务进程。当调度新的服务进程S1和S2时，确定服务进程S1和S2对应的用户标识均为K1，则判断虚拟机A是否为空闲的虚拟机，如果虚拟机A中的容器A3空闲，显然一个容器A3不能运行完服务进程S1和S2，则继续判断其他虚拟机是否为空闲的虚拟机，则确定虚拟机D为空闲的虚拟机，因此确定虚拟机D为目标虚拟机，并将服务进程S2运行于虚拟机D中的容器D1中，并将虚拟机D对应的用户标识确定为K1。
在其他实施例中，所述方法还可以包括以下步骤：
步骤S1012，当所述用户标识对应的虚拟机中的容器的服务进程处于异常运行状态时，采用所述新的服务进程替换所述容器中的服务进程，以实现在所述容器中运行所述新的服务进程。
这里，可以实时监控虚拟机中的容器中的服务进程运行是否正常，当监测到服务进程处于异常运行状态时，及时杀掉异常的服务进程，并采用新的服务进程替换所述异常服务进程，即将新的服务进程运行于异常服务进程所在的容器中。
本申请实施例提供的服务进程调度方法，当调度新的服务进程时，对应不同的场景采用不同的实现方式，能够灵活的合理利用设备的资源，以提高设备的资源利用率，且能够保证服务进程的正常有序运行。
下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。
本申请实施例提供一种服务进程调度方法，主要讨论物理机设备虚拟化加容器化后的管理调度，在保持独立内核隔离的基础上，通过容器层的调度，实现资源层的超卖。
本申请实施例的方法通过分层组合虚拟化和容器技术，虚拟化层完成超卖，容器层结合资源负载或者业务负载做调度，具有以下优点：1)独立的内核，方便业务无缝迁移，而且避免内核抢占的问题；2)容器化的接口方式，可复用社区已有的容器管理系统；3)针对同一个物理机设备生产的虚拟机分属多租户的场景，既有容器化的接口，亦保持了虚拟机的隔离、安全属性；4)从运营的角度出发，容器化的自动伸缩解决了业务突发的资源需求，虚拟化隔离避免了定位问题的模糊性，而且避免了容器进程逃逸的问题；5)从服务的业务场景角度看，虚拟化和容器化分层后的架构相比单纯的虚拟机或者容器，对于服务业务更有通用性。
本申请实施例中，针对集群的架构，采用虚拟化和容器分层构建，虚拟化层负责超卖并为业务提供独立的内核，容器负责对接用户，用户的程序跑在容器里，用户可登陆容器部署、发布和调试等。
如图11所示，是本申请实施例提供的服务进程调度方法的实现流程示意图，物理机的资源通过名字化服务110的方式对接业务，当容器层120(示例性的示出了容器层120中的容器121、容器122、容器123和容器124)存在扩缩或者替换等变动，会通过名字化服务110透明的对接业务侧；虚拟化层130(示例性的示出了虚拟机131、虚拟机132和超卖虚拟机133)主要用于超卖，但容器层120无需识别是否超卖，超卖的策略由超卖控制中心140把控，依据物理机设备11上部署的负载监控模块150收集的资源监控数据。用户可登陆容器权限的放开是建立在虚拟机安全隔离的基础上，因此同一个虚拟机只能跑一个用户的容器，避免不同用户间的容器共享虚拟机，造成网络扫描、资源抢占等安全的风险。
本申请实施例中容器采用单根I/O虚拟化(SR-IOV，Single-root I/OVirtualization)的方式配置网络，如图12所示，是单个容器的结构框架图(这里以容器121为例进行说明)，每个容器挂载一个虚拟函数(VF，Virtual Functions)1210，VF 1210用于通过eth1端口1212控制容器的暂停功能1211，容器121配置网络互联网协议地址(IP，Internet Protocol)，该IP可以外联和接受访问，容器121默认开始安全外壳协议(SSH，Secure Shell)服务，支持用户可登陆。需要说明的是，容器121共享设备11的网络空间111，容器121中运行有业务容器1213的业务容器进程，例如，sbin目录、init进程、crond服务等。
本申请实施例的安全超卖是基于虚拟化层130提出的，每个虚拟机挂独立的IP，为用户创建的容器复用虚拟机的网络空间，用户直接操作容器，不可操作虚拟机的内核层，但对内核的差异化需求可定制；超卖的语义是CPU算力的复用，CPU算力被多个虚拟机共用，主要适用于独占CPU算力但不能完全吃满的场景，尤其面向计算型和流量型的业务混部场景。在超卖的实现中，存在两种方案，一种是超卖CPU物理核心，即超卖和非超卖使用的CPU核是物理隔离的，另一种是超卖逻辑核心，即超卖和非超卖共享物理核心。
在一些实施例中，对于物理机上已有业务是重流量轻计算的业务，则可以使用上述第二种超卖逻辑核心的方案实现虚拟化层130的安全超卖。
举例来说，超卖的算力重点服务的可以是王者AI训练场景，如图13所示，是本申请实施例提供的王者AI训练场景下的实现流程，包括以下步骤：
步骤S1301，在王者人机对战中，基于超卖算力对王者游戏的源数据进行数据清洗，即在机器学习流程中进行数据清洗。
这里，可以采用AI技术中的计算机视觉、语音技术和机器学习等至少一种技术获取所述源数据，并且，在机器学习流程中对所述源数据进行数据清洗，以检查源数据的数据一致性、处理无效值和缺失值等。
步骤S1302，清洗后的数据推入图形处理器(GPU，Graphics Processing Unit)设备做王者英雄的强化训练，得到训练模型。
步骤S1303，将所述训练模型服务于王者人机对战中的在线推理。
在其他实施例中，虚拟化层完成超卖，监控程序收集数据到超卖控制中心，超卖控制中心首先判断设备的CPU利用率是否低于超卖设置的阈值，若低于阈值，再参考一级缓存(L1 cache)的失效率，监控L1 cache的失效率，用来评估指令执行的时钟周期是否升高，若失效率低过阈值，则执行发起超卖子机(对应上述超卖虚拟机)的操作，超卖的子机量取决于剩余内存的大小。如图14所示，是本申请实施例提供的发起形成超卖子机操作的实现流程示意图，所述流程包括以下步骤：
步骤S1401，实时监控物理机的资源和负载情况，判断所述物理机的CPU利用率是否高于第一阈值。
当判断结果为是，则结束流程，当判断结果为否，则执行步骤S1402。
步骤S1402，判断一级缓存的失效率是否高于第二阈值。
当判断结果为是，则结束流程，当判断结果为否，则执行步骤S1403。
步骤S1403，发起形成超卖子机的操作。
本申请实施例中，超卖子机以及子机上容器的销毁判断依据来源母机(即物理机或者上述任一实施例中的设备)上的负载监控数据，如果母机的CPU利用率高，则调度走超卖子机的容器业务，并销毁容器完成脏数据的清理，再销毁超卖子机，完成释放资源给母机；若仅L1 cache的失效率高，则调度走超卖子机的容器业务，然后销毁容器，保留超卖子机。如图15所示，是本申请实施例提供的超卖自己上容器的销毁流程示意图，所述流程包括以下步骤：
步骤S1501，实时监控物理机的资源和负载情况，判断所述物理机的CPU利用率是否高于第一阈值。
当判断结果为是，则执行步骤S1502，当判断结果为否，则执行步骤S1504。
步骤S1502，销毁超卖子机中的容器。
步骤S1503，销毁超卖子机。
步骤S1504，判断一级缓存的失效率是否高于第二阈值。
当判断结果为是，则执行步骤S1505，当判断结果为否，则结束流程。
步骤S1505，销毁超卖子机的容器。
本申请实施例所提供方法的数据结构是资源负载监控的消息设计，其中，数据结构如下：
message CpuInfo{
required string uuid＝1；
required double cpi＝2；
required double cpu_usage＝3；
required uint32 cache_miss＝4；
optional double cpu_normalize＝5；
……
}
在上述数据结构中，uuid是标识容器的ID，全局唯一；cpu_usage标识母机CPU的利用率；cpi和cache_miss来评估L1 cache的失效率。
在高密度大容量设备的趋势下，普通的业务不能吃满整机的资源负载，单虚拟化缺乏调度的灵活性，单容器化缺失安全隔离性，而本申请实施例提供的服务进程调度方法，通过分层组合两者，并增加管理调度策略实现资源虚拟化隔离和容器化的超卖，此架构称之为容器多层架构，能够充分利用设备的资源，提高设备资源利用率。
下面继续说明本申请实施例提供的服务进程调度装置654的实施为软件模块的示例性结构，在一些实施例中，如图6所示，存储在存储器650的服务进程调度装置654中的软件模块可以包括：
虚拟机形成模块6541，用于当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量；容器部署模块6542，用于采用容器化技术，在每一所述虚拟机中部署至少一个容器；运行模块6543，用于当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程。
在一些实施例中，所述虚拟机包括非超卖虚拟机和超卖虚拟机；
所述虚拟机形成模块还用于：当所述设备的资源利用率低于第一阈值，且所述设备的缓存失效率低于第二阈值时，采用所述虚拟化技术在所述设备上形成至少一个非超卖虚拟机和至少一个超卖虚拟机。
在一些实施例中，所述虚拟机形成模块还用于：当所述设备的资源利用率低于第一阈值，且所述设备的缓存失效率低于第二阈值时，确定所述设备的内存剩余量；根据所述设备的所述资源利用率确定所述非超卖虚拟机的第一数量；根据所述设备的内存剩余量确定所述超卖虚拟机的第二数量；采用虚拟化技术在所述设备上形成所述第一数量的非超卖虚拟机和所述第二数量的超卖虚拟机。
在一些实施例中，所述装置还包括：第一调度模块，用于当所述设备的所述资源利用率高于所述第一阈值时，对所述超卖虚拟机中的容器运行的服务进程进行调度，以减小所述容器的资源占用量；并释放所述超卖虚拟机占用的所述设备的资源。
在一些实施例中，所述第一调度模块还用于：结束所述超卖虚拟机中的容器对应的容器进程；结束所述超卖虚拟机对应的虚拟机进程，以释放所述超卖虚拟机占用的所述设备的资源。
在一些实施例中，所述装置还包括：第二调度模块，用于当所述设备的资源利用率低于所述第一阈值，且所述设备的缓存失效率高于所述第二阈值时，对所述超卖虚拟机中的容器运行的服务进程进行调度，以减小所述容器的资源占用量。
在一些实施例中，每一服务进程对应一用户标识；所述装置还包括禁止模块，用于禁止将具有不同用户标识的服务进程，运行在同一虚拟机中的容器中。
在一些实施例中，所述运行模块还用于：当调度新的服务进程时，确定所述新的服务进程对应的所述用户标识；将所述新的服务进程运行于所述用户标识对应的空闲的虚拟机中的容器中；当所述用户标识对应的虚拟机中没有空闲的容器时，在所述虚拟机中扩容新的容器，以实现在所述新的容器中运行所述新的服务进程。
在一些实施例中，所述运行模块还用于：当所述用户标识对应的虚拟机中没有足够运行所述新的服务的空闲的容器时，在其他虚拟机中确定空闲的虚拟机为目标虚拟机；将所述新的服务进程运行在所述目标虚拟机的容器中。
在一些实施例中，所述装置还包括：替换模块，用于当所述用户标识对应的虚拟机中的容器的服务进程处于异常运行状态时，采用所述新的服务进程替换所述容器中的服务进程，以实现在所述容器中运行所述新的服务进程。
需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图7示出的方法。
在一些实施例中，存储介质可以是铁电存储器(FRAM，Ferromagnetic RandomAccess Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，ErasableProgrammable Read Only Memory)、带电可擦可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read Only Memory)、闪存、磁表面存储器、光盘、或光盘只读存储器(CD-ROM，CompactDisk-Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(Hyper Text MarkupLanguage，HTML)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。
以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。
Claims (13)
1.一种服务进程调度方法，其特征在于，所述方法包括：
当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量；
采用容器化技术，在每一所述虚拟机中部署至少一个容器；
当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程。
2.根据权利要求1所述的方法，其特征在于，所述虚拟机包括非超卖虚拟机和超卖虚拟机；
所述当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机，包括：
当所述设备的资源利用率低于第一阈值，且所述设备的缓存失效率低于第二阈值时，采用所述虚拟化技术在所述设备上形成至少一个非超卖虚拟机和至少一个超卖虚拟机。
3.根据权利要求2所述的方法，其特征在于，所述当所述设备的资源利用率低于第一阈值，且所述设备的缓存失效率低于第二阈值时，采用所述虚拟化技术在所述设备上形成至少一个非超卖虚拟机和至少一个超卖虚拟机，包括：
当所述设备的资源利用率低于第一阈值，且所述设备的缓存失效率低于第二阈值时，确定所述设备的内存剩余量；
根据所述设备的所述资源利用率确定所述非超卖虚拟机的第一数量；
根据所述设备的内存剩余量确定所述超卖虚拟机的第二数量；
采用虚拟化技术在所述设备上形成所述第一数量的非超卖虚拟机和所述第二数量的超卖虚拟机。
4.根据权利要求2所述的方法，其特征在于，所述方法还包括：
当所述设备的所述资源利用率高于所述第一阈值时，对所述超卖虚拟机中的容器运行的服务进程进行调度，以减小所述容器的资源占用量；
并释放所述超卖虚拟机占用的所述设备的资源。
5.根据权利要求4所述的方法，其特征在于，所述释放所述超卖虚拟机占用的所述设备的资源，包括：
结束所述超卖虚拟机中的容器对应的容器进程；
结束所述超卖虚拟机对应的虚拟机进程，以释放所述超卖虚拟机占用的所述设备的资源。
6.根据权利要求2所述的方法，其特征在于，所述方法还包括：
当所述设备的资源利用率低于所述第一阈值，且所述设备的缓存失效率高于所述第二阈值时，对所述超卖虚拟机中的容器运行的服务进程进行调度，以减小所述容器的资源占用量。
7.根据权利要求1所述的方法，其特征在于，每一服务进程对应一用户标识；所述方法还包括：
禁止将具有不同用户标识的服务进程，运行在同一虚拟机中的容器中。
8.根据权利要求7所述的方法，其特征在于，所述当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程，包括：
当调度新的服务进程时，确定所述新的服务进程对应的所述用户标识；
将所述新的服务进程运行于所述用户标识对应的空闲的虚拟机中的容器中；
当所述用户标识对应的虚拟机中没有空闲的容器时，在所述虚拟机中扩容新的容器，以实现在所述新的容器中运行所述新的服务进程。
9.根据权利要求8所述的方法，其特征在于，所述当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程，还包括：
当所述用户标识对应的虚拟机中没有足够运行所述新的服务的空闲的容器时，在其他虚拟机中确定空闲的虚拟机为目标虚拟机；
将所述新的服务进程运行在所述目标虚拟机的容器中。
10.根据权利要求8所述的方法，其特征在于，所述方法还包括：
当所述用户标识对应的虚拟机中的容器的服务进程处于异常运行状态时，采用所述新的服务进程替换所述容器中的服务进程，以实现在所述容器中运行所述新的服务进程。
11.一种服务进程调度装置，其特征在于，包括：
虚拟机形成模块，用于当设备的资源利用率低于第一阈值时，采用虚拟化技术在所述设备上形成至少两个虚拟机；其中，所述至少两个虚拟机的资源需求量之和大于所述设备的总资源量；
容器部署模块，用于采用容器化技术，在每一所述虚拟机中部署至少一个容器；
运行模块，用于当调度服务进程时，在空闲的所述虚拟机的至少一个容器中运行所述服务进程。
12.一种服务进程调度设备，其特征在于，包括：
存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至10任一项所述的方法。
13.一种存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至10任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910953616.3A CN110688202A (zh) | 2019-10-09 | 2019-10-09 | 服务进程调度方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910953616.3A CN110688202A (zh) | 2019-10-09 | 2019-10-09 | 服务进程调度方法、装置、设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110688202A true CN110688202A (zh) | 2020-01-14 |
Family
ID=69111720
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910953616.3A Pending CN110688202A (zh) | 2019-10-09 | 2019-10-09 | 服务进程调度方法、装置、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110688202A (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111324432A (zh) * | 2020-01-21 | 2020-06-23 | 腾讯科技（深圳）有限公司 | 处理器调度方法、装置、服务器及存储介质 |
| CN112148489A (zh) * | 2020-09-22 | 2020-12-29 | 网易（杭州）网络有限公司 | 游戏资源调度方法、装置、设备及存储介质 |
| CN112214413A (zh) * | 2020-10-27 | 2021-01-12 | 北京字节跳动网络技术有限公司 | 一种应用程序的测试方法、装置、设备及存储介质 |
| CN112416578A (zh) * | 2020-11-05 | 2021-02-26 | 中山大学 | 一种基于深度强化学习的容器云集群资源利用优化方法 |
| CN113407348A (zh) * | 2021-07-07 | 2021-09-17 | Tcl通讯（宁波）有限公司 | 应用进程的管理方法、装置、设备及存储介质 |
| CN113726553A (zh) * | 2021-07-29 | 2021-11-30 | 浪潮电子信息产业股份有限公司 | 一种节点故障恢复方法、装置、电子设备及可读存储介质 |
| CN113742009A (zh) * | 2020-05-28 | 2021-12-03 | 深信服科技股份有限公司 | 桌面云环境资源调度方法、装置、设备及存储介质 |
| CN114399006A (zh) * | 2022-03-24 | 2022-04-26 | 山东省计算中心（国家超级计算济南中心） | 基于超算的多源异构图数据融合方法及系统 |
| WO2024093574A1 (zh) * | 2022-10-31 | 2024-05-10 | 中国电信股份有限公司 | 虚拟机及其配置方法和装置 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106227578A (zh) * | 2016-07-12 | 2016-12-14 | 腾讯科技（深圳）有限公司 | 一种虚拟机热迁移的方法、设备及系统 |
| CN107368358A (zh) * | 2016-05-11 | 2017-11-21 | 华为技术有限公司 | 实现客户端所在虚拟机在不同主机间迁移的装置和方法 |
| US9830192B1 (en) * | 2014-11-10 | 2017-11-28 | Turbonomic, Inc. | Managing application performance in virtualization systems |
| CN110196753A (zh) * | 2019-01-21 | 2019-09-03 | 腾讯科技（北京）有限公司 | 基于容器的图形处理器gpu虚拟化方法、装置和可读介质 |
-
2019
- 2019-10-09 CN CN201910953616.3A patent/CN110688202A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9830192B1 (en) * | 2014-11-10 | 2017-11-28 | Turbonomic, Inc. | Managing application performance in virtualization systems |
| CN107368358A (zh) * | 2016-05-11 | 2017-11-21 | 华为技术有限公司 | 实现客户端所在虚拟机在不同主机间迁移的装置和方法 |
| CN106227578A (zh) * | 2016-07-12 | 2016-12-14 | 腾讯科技（深圳）有限公司 | 一种虚拟机热迁移的方法、设备及系统 |
| CN110196753A (zh) * | 2019-01-21 | 2019-09-03 | 腾讯科技（北京）有限公司 | 基于容器的图形处理器gpu虚拟化方法、装置和可读介质 |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111324432A (zh) * | 2020-01-21 | 2020-06-23 | 腾讯科技（深圳）有限公司 | 处理器调度方法、装置、服务器及存储介质 |
| CN113742009A (zh) * | 2020-05-28 | 2021-12-03 | 深信服科技股份有限公司 | 桌面云环境资源调度方法、装置、设备及存储介质 |
| CN113742009B (zh) * | 2020-05-28 | 2024-04-09 | 深信服科技股份有限公司 | 桌面云环境资源调度方法、装置、设备及存储介质 |
| CN112148489A (zh) * | 2020-09-22 | 2020-12-29 | 网易（杭州）网络有限公司 | 游戏资源调度方法、装置、设备及存储介质 |
| CN112214413A (zh) * | 2020-10-27 | 2021-01-12 | 北京字节跳动网络技术有限公司 | 一种应用程序的测试方法、装置、设备及存储介质 |
| CN112214413B (zh) * | 2020-10-27 | 2024-01-16 | 北京字节跳动网络技术有限公司 | 一种应用程序的测试方法、装置、设备及存储介质 |
| CN112416578A (zh) * | 2020-11-05 | 2021-02-26 | 中山大学 | 一种基于深度强化学习的容器云集群资源利用优化方法 |
| CN112416578B (zh) * | 2020-11-05 | 2023-08-15 | 中山大学 | 一种基于深度强化学习的容器云集群资源利用优化方法 |
| CN113407348B (zh) * | 2021-07-07 | 2024-04-09 | Tcl通讯（宁波）有限公司 | 应用进程的管理方法、装置、设备及存储介质 |
| CN113407348A (zh) * | 2021-07-07 | 2021-09-17 | Tcl通讯（宁波）有限公司 | 应用进程的管理方法、装置、设备及存储介质 |
| CN113726553A (zh) * | 2021-07-29 | 2021-11-30 | 浪潮电子信息产业股份有限公司 | 一种节点故障恢复方法、装置、电子设备及可读存储介质 |
| CN114399006A (zh) * | 2022-03-24 | 2022-04-26 | 山东省计算中心（国家超级计算济南中心） | 基于超算的多源异构图数据融合方法及系统 |
| CN114399006B (zh) * | 2022-03-24 | 2022-07-12 | 山东省计算中心（国家超级计算济南中心） | 基于超算的多源异构图数据融合方法及系统 |
| WO2024093574A1 (zh) * | 2022-10-31 | 2024-05-10 | 中国电信股份有限公司 | 虚拟机及其配置方法和装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110688202A (zh) | 服务进程调度方法、装置、设备及存储介质 | |
| CN112416599B (zh) | 一种资源调度方法、装置、设备及计算机可读存储介质 | |
| Snowdon et al. | Aviary: Design issues for future large-scale virtual environments | |
| CN110781007A (zh) | 任务处理方法、装置、服务器、客户端、系统和存储介质 | |
| Rowley et al. | SpiNNTools: the execution engine for the SpiNNaker platform | |
| CN103645957B (zh) | 一种虚拟机资源管控方法及装置 | |
| CN110083455B (zh) | 图计算处理方法、装置、介质及电子设备 | |
| CN110442041B (zh) | 一种基于异构云计算框架的仿真平台构建方法及仿真系统 | |
| Gui et al. | Toward architecture-based context-aware deployment and adaptation | |
| CN114881233B (zh) | 一种基于容器的分布式模型推理服务方法 | |
| CN112256430A (zh) | 容器的部署方法、装置、设备及存储介质 | |
| CN105183566A (zh) | 3d游戏渲染引擎的资源管理方法 | |
| KR20190028210A (ko) | 컨테이너 기반 인공지능 어플리케이션을 배포하는 클라우드 서비스 방법과 시스템 | |
| Anthony | Systems programming: designing and developing distributed applications | |
| Dissaux et al. | The SMART project: Multi-agent scheduling simulation of real-time architectures | |
| Kim et al. | RIDE: real-time massive image processing platform on distributed environment | |
| Katz | Augmenting deep neural networks with scenario-based guard rules | |
| CN110732137A (zh) | 对深度学习网络的注意力的持续控制 | |
| CN112418447B (zh) | 提供机器学习服务的系统、方法、介质和设备 | |
| CN114675978A (zh) | 算法应用元的运行框架和数据处理方法、设备及存储介质 | |
| CN114217825A (zh) | 用于决策引擎的方法、装置、机器可读存储介质及处理器 | |
| Trencansky et al. | Applying a uml-based agent modeling language to the autonomic computing domain | |
| Battarra et al. | Storm clouds platform: a cloud computing platform for smart city applications | |
| Bolton et al. | Knowledge-based support for requirements engineering | |
| Humphrys | The world-wide-mind: Draft proposal |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40020122 Country of ref document: HK |
|
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |