CN114077504A - 一种消息管理的方法、装置及去服务器化系统 - Google Patents
一种消息管理的方法、装置及去服务器化系统 Download PDFInfo
- Publication number
- CN114077504A CN114077504A CN202010823536.9A CN202010823536A CN114077504A CN 114077504 A CN114077504 A CN 114077504A CN 202010823536 A CN202010823536 A CN 202010823536A CN 114077504 A CN114077504 A CN 114077504A
- Authority
- CN
- China
- Prior art keywords
- message
- function
- state
- stateful
- instance
- 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
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/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- 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/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- 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
-
- 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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- 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/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请公开了一种去服务器化系统,包括:消息管理装置可以接收第一消息,第一消息用于指示调度第一有状态函数操作第一状态实例;将第一消息存入与第一状态实例对应的第一消息队列,第一消息队列还用于存储多个消息,多个消息中的每个消息用于指示一个有状态函数操作第一状态实例;将第二消息,传递给第二消息对应的第二有状态函数,并运行第二消息对应的第二有状态函数操作处于空闲状态的第一状态实例,其中,第二消息为位于第一消息队列最前端的消息。本申请技术方案采用消息管理的方式控制不同有状态函数对状态实例的分时操作,有状态函数只有得到操作状态实例的消息后才操作该状态实例,从而避免了资源浪费。
Description
技术领域
本申请涉及计算机技术领域,具体涉及一种消息管理的方法、装置及去服务器化系统。
背景技术
去服务器化(serverless)指的是云厂商提供函数运行的资源,并动态管理资源的分配。用户可以按照无服务器的模式编写函数,不用提前购买运行该函数的服务器,函数在云上的运行位置,由云平台控制。云平台的主要特征就是按需部署,当有业务需求时,快速部署函数,从而快速处理业务。
云上运行的函数通常包括无状态函数和有状态函数。无状态函数指的是该函数运行过程中的状态数据无法被保留,函数每次运行也不会依赖之前运行的状态数据。状态数据指的是函数运行过程中的暂态数据或上下文数据。有状态函数指的是该函数运行过程中的状态数据可以被保留,该函数下次运行时还可以操作该状态数据。
状态数据包含于状态实例中,一个状态实例中的状态数据可以被修改,但状态实例的标识不会变化。一个状态实例在一个时刻只能被一个函数操作。如果两个不同的有状态函数要使用同一个状态实例,需要采用加锁互斥的方式进行操作。例如:有状态函数B和有状态函数C都要操作状态实例S,若有状态函数B先操作了状态实例S,则会加锁,以防止该状态实例S被其他函数修改。若有状态函数C也要操作该状态实例S,则会准备好要操作状态实例S的资源,但在有状态函数B没释放锁之前,有状态函数C无法操作该状态实例S,只能等待有状态函数B释放锁,等待过程中有状态函数C还一直占用着为操作状态实例S而准备的资源,造成资源浪费。
发明内容
本申请实施例提供一种去服务器化系统,用于采用消息管理的方式控制不同有状态函数对状态实例的分时操作,有状态函数只有得到操作状态实例的消息后才开始操作该状态实例,不需要占用资源等待正在操作状态实例的有状态函数释放锁,从而避免了资源浪费。本申请实施例还提供了相应的消息管理的方法及装置。
本申请第一方面提供一种去服务器化系统,包括:消息管理装置,该消息管理装置用于:接收第一消息,该第一消息用于指示调度第一有状态函数操作第一状态实例;将第一消息存入与第一状态实例对应的第一消息队列,第一消息队列还用于存储多个消息,多个消息中的每个消息用于指示一个有状态函数操作第一状态实例;将第二消息,传递给第二消息对应的第二有状态函数,并运行第二消息对应的第二有状态函数操作处于空闲状态的第一状态实例,其中,第二消息为位于第一消息队列最前端的消息。
该第一方面中,去服务器化系统可以是集群化的系统,包括控制节点和工作节点,控制节点有一个或多个,工作节点有多个,通常一个控制节点会管理多个工作节点。本申请中,“多个”包括“两个”。“多个”也可以描述为“至少两个”。消息管理装置(statemessagemanager)可以位于工作节点上。可以是一个工作节点上包括一个消息管理装置,也可以是有的工作节点上包括消息管理装置,有的工作节点上不包括消息管理装置。当有的工作节点上不包括消息管理装置时,该消息管理装置可以对应管理多个工作节点上的状态实例以及状态函数。消息管理装置可以是一个实例(instance)或容器(container)。第一消息中可以包括第一状态实例的标识(state ID)和第一有状态函数的函数名。有状态函数指的是该函数运行过程中的状态数据可以被保留,该函数下次运行时还可以操作该状态数据。状态数据指的是函数运行过程中的暂态数据或上下文数据。状态数据包含于状态实例中,一个状态实例中的状态数据可以被修改,但状态实例的标识不会变化。第一消息队列用于存储多个消息表示该第一消息队列可以存储多个消息,而不是当前存储多个消息。因为第一消息队列中的消息会出队列,所以一个时刻内,该第一消息队列中可能有一个消息,也可能有多个消息,也可以能一个消息都没有。该第二消息可以是在第一消息之前进入第一消息队列的,如果第一消息进入该第一消息队列时,该第一消息队列中没有消息,则该第二消息就是该第一消息,第二消息对应的第二有状态函数也就是第一有状态函数。第一消息队列中的消息采用先进先出的规则。第二消息位于第一消息队列的最前端表示该第二消息进入第一消息队列的时间早于第一消息队列中目前包含的其他消息。第一状态实例处于空闲状态表示该第一状态实例没有被其他与该第一状态实例有关联的有状态函数操作。由该第一方面可知,该第一方面采用消息管理的方式控制不同有状态函数对第一状态实例的分时操作,第二有状态函数只有被调度第二消息后才会操作第一状态实例,同样,与该第一状态实例关联的其他有状态函数也只有被调度到相应的消息后才会操作该第一状态实例,避免了一个有状态函数操作状态实例时其他有状态函数占用资源等待,避免了资源浪费,提高了资源利用率。
在第一方面的一种可能的实现方式中,消息管理装置还用于:若第二消息与第一消息不是同一消息,在将第二消息,传递给所述第二消息对应的第二有状态函数之后,将位于第一消息队列最前端的第一消息,传递给第一有状态函数,并运行第一有状态函数操作处于空闲状态的第一状态实例。
该种可能的实现方式中,第二消息在第一消息队列中位于第一消息之前,则会先调度第二消息给第二有状态函数,由该第二有状态函数先操作该第一状态实例。然后等到第一状态实例空闲后,而且第一消息在第一消息队列中也位于最前端时,将第一消息调度给第一有状态函数,进而运行第一有状态函数操作该第一状态实例。
在第一方面的一种可能的实现方式中,去服务器化系统还包括路由装置(routing)、调度装置(function state scheduler)和多个工作节点,该调度装置用于:接收路由装置发送的地址请求,地址请求包括第一状态实例的标识;根据第一状态实例的标识,在多个工作节点中的第一工作节点上部署第一状态实例;建立第一状态实例的标识与消息管理装置的地址的对应关系,该消息管理装置与第一工作节点对应。
该种可能的实现方式中,调度装置位于控制节点上,该调度装置可以是一个实例或容器。路由装置(routing)可以部署在交换机或路由器等路由设备上,也可以部署在客户端。若调度装置接收到地址请求,则表明第一状态实例还没有被部署到工作节点上。该地址请求用于指示调度装置将该第一状态实例部署在第一工作节点上,并建立第一状态实例的标识与消息管理装置的地址的对应关系,该消息管理装置与该第一工作节点对应。调度装置可以从多个工作节点中任意选择一个工作节点作为第一工作节点,也可以根据一些选择策略来选择第一工作节点,然后将第一状态实例部署在第一工作节点上,第一状态实例部署后,就可以确定出该第一状态实例所对应的消息管理装置,从而确定出对应的消息管理装置的地址。
在第一方面的一种可能的实现方式中,该调度装置还用于:将部署在第二工作节点上的第一有状态函数,迁移到第一工作节点上,第一有状态函数的迁移代价小于第一状态实例的迁移代价。
该种可能的实现方式中,迁移代价指的是因有状态函数迁移或者状态实例迁移所带来的资源消耗,如:传输资源消耗。由该种可能的实现方式可知,通过有状态函数的迁移代价以及第一状态实例的迁移代价来确定是迁移数据(shipping data),还是迁移函数(shipping function)。这样,可以在使用较小迁移开销的情况下,就达到较好的系统性能。
在第一方面的一种可能的实现方式中,该地址请求中还包括第一有状态函数的函数名;第一工作节点是根据多个工作节点的负载信息、第一状态实例的大小,以及至少两个有状态函数的需求策略确定的,至少两个有状态函数位于与第一有状态函数的函数名相关联的函数业务组中。
该种可能的实现方式中,调度装置可以根据所管理的多个工作节点的负载信息、第一状态实例的大小,以及对第一状态实例有操作权限的至少两个有状态函数的需求策略来确定用于部署第一状态实例的第一工作节点。工作节点的负载信息指示工作节点上目前的负载情况,可以包括工作节点上函数部署的情况、中央处理单元(central processingunit,CPU)的占用率或空闲率,内存的占用率或空闲率中的至少一种。第一状态实例的大小表示第一状态实例的数据量。对第一状态实例有操作权限的至少两个有状态函数的需求策略指的是至少两个有状态函数在部署时与第一状态实例的位置要求或对所部署的工作节点上可用资源的要求。如:该状态实例与对应的有状态函数是否需要部署在同一个工作节点上。或者,对所部署的工作节点上可用的计算资源或内存资源的要求,如:对CPU的空闲率要求要达到第一阈值,或者,对内存的空闲率要达到第二阈值等。第一阈值和第二阈值都可以根据需求设定。由该种可能的实现方式可知,将第一状态实例部署在负载较小或资源满足至少两个有状态函数需求的第一工作节点上,可以提高去服务器系统的整体性能。
在第一方面的一种可能的实现方式中,该地址请求中还包括第一有状态函数的函数名;第一工作节点是多个工作节点中总分数最高的工作节点,一个工作节点的总分数与工作节点的计算资源、存储资源或是否已部署至少两个状态函数相关,至少两个有状态函数位于与第一有状态函数的函数名相关联的函数业务组中。
该种可能的实现方式中,可以采用平均算法计算每个工作节点的总分数,评估算法可以是与资源相关的算法,如:与CPU相关的算法,与内存相关的算法,与亲和性相关的算法,如:有状态函数与状态实例是否位于同一工作节点的算法等。针对每个工作节点都可以至少一个评估算法中的每个评估算法计算一次分数,然后将所有评估算法分别对应的分数进行加和得到总分数,再根据每个工作节点的总分数选出得分最高的第一工作节点用于部署第一状态实例。由该种可能的实现方式可知,将第一状态实例部署在得分最高的第一工作节点上,可以提高去服务器系统的整体性能。
在第一方面的一种可能的实现方式中,消息管理装置还用于:相对于第一消息队列,并行将位于第二消息队列最前端的第三消息,传递给第三有状态函数,并运行第三有状态函数操作处于空闲状态的第二状态实例,第二消息队列与第二状态实例对应。
该种可能的实现方式中,一个消息管理装置可以管理多个消息队列,每个消息队列会对应一个状态实例,针对不同的状态实例的消息队列,可以采用并行调度的方式来调度不同队列中的消息,这样可以提高不同有状态函数对不同状态实例的操作效率。
在第一方面的一种可能的实现方式中,消息管理装置还用于:在第一消息队列和第二消息队列中的消息都调度完毕后,并行将位于第三消息队列最前端的第四消息,传递给第四有状态函数,并运行第四有状态函数操作处于空闲状态的第一状态实例和第二状态实例,第三消息队列与第一状态实例和第二状态实例对应,第四有状态函数的调度顺序位于第一有状态函数、第二有状态函数和第三有状态函数之后。
该种可能的实现方式中,第四有状态函数对第一状态实例和第二状态实例的组合实例有操作权限,而且,第四有状态函数在对第一状态实例和第二状态实例的操作顺序上位于第一有状态函数、第二有状态函数和第三有状态函数之后,则在调度完第一消息队列和第二消息队列中的消息后,才调度第三消息队列中的消息操作该组合实例。该种可能的实现方式提供了有状态函数多级管理的方式。
在第一方面的一种可能的实现方式中,该去服务器化系统还包括地址管理装置,该调度装置还用于:向地址管理装置发送第一状态实例的标识与第一工作节点对应的消息管理装置的地址的对应关系。地址管理装置存储对应关系。
该种可能的实现方式中,该地址管理装置也可以称为名字服务装置,调度装置确定消息管理装置的地址后,可以将第一状态实例的标识(state ID)与消息管理装置的地址(endpoint)的对应关系发送到该地址管理装置存储,这样,后续再有包含该state ID的调用请求时,就可以从该地址管理装置获取对应的endpoint,或者,从该地址管理装置获取上述对应关系,然后再根据该对应关系确定该state ID对应的endpoint,进而根据该endpoint发送第一消息。该种通过地址管理装置存储state ID与endpoint的对应关系的方式可以快速找到调用请求对应的消息管理装置,进而快速发送消息。
在第一方面的一种可能的实现方式中,该路由装置还用于:接收客户端对第一有状态函数的调用请求,调用请求包括第一状态实例的标识和第一有状态函数的函数名;获取与第一状态实例的标识对应的消息管理装置的地址;向消息管理装置的地址指示的消息管理装置发送第一消息。
该种可能的实现方式中,该路由装置可以在本地获取消息管理装置的地址,也可以从地址管理装置获取消息管理装置的地址,也可以从调度装置获取消息管理装置的地址。
在第一方面的一种可能的实现方式中,该路由装置用于:从调度装置获取与第一状态实例的标识对应的消息管理装置的地址;或者,从地址管理装置获取与第一状态实例的标识对应的消息管理装置的地址。
该种可能的实现方式中,若地址管理装置存储有state ID与endpoint的对应关系,则可以从地址管理装置获取该消息管理装置的地址。若地址管理装置没有存储有stateID与endpoint的对应关系,则需要由调度装置部署第一状态实例,然后再确定对应的消息管理装置的地址。
本申请第二方面提供一种消息管理的方法,包括:接收第一消息,第一消息用于指示调度第一有状态函数操作第一状态实例;将第一消息存入与第一状态实例对应的第一消息队列,第一消息队列用于存储多个消息,每个消息用于指示一个有状态函数操作第一状态实例;将第二消息,传递给第二消息对应的第二有状态函数,并运行第二消息对应的第二有状态函数操作处于空闲状态的第一状态实例,其中,第二消息为位于第一消息队列最前端的消息。
在第二方面的一种可能的实现方式中,该方法还包括:若第二消息与第一消息不是同一消息,在将第二消息,传递给所述第二消息对应的第二有状态函数之后,将位于第一消息队列最前端的第一消息,传递给第一有状态函数,并运行第一有状态函数操作处于空闲状态的第一状态实例。
在第二方面的一种可能的实现方式中,相对于所述第一消息队列,并行将位于第二消息队列最前端的第三消息,传递给所述第三有状态函数,并运行所述第三有状态函数操作处于空闲状态的第二状态实例,所述第二消息队列与所述第二状态实例对应。
在第二方面的一种可能的实现方式中,在所述第一消息队列和所述第二消息队列中的消息都调度完毕后,并行将位于第三消息队列最前端的第四消息,传递给所述第四有状态函数,并运行所述第四有状态函数操作处于空闲状态的第一状态实例和第二状态实例,所述第三消息队列与所述第一状态实例和所述第二状态实例对应,所述第四有状态函数的调度顺序位于所述第一有状态函数、所述第二有状态函数和所述第三有状态函数之后。
该第二方面提供的一种消息管理的方法应用于上述去服务化系统。该第二方面以及任一种可能的实现方式中所涉及到的特征和相应效果可以参阅第一方面及第一方面的相应可能的实现方式中的介绍进行理解。
本申请第三方面提供一种消息管理的方法,该方法应用于去服务器化系统,去服务器化系统包括消息管理装置、路由装置、调度装置和多个工作节点,该方法包括:接收路由装置发送的地址请求,该地址请求包括第一状态实例的标识;根据第一状态实例的标识,在多个工作节点中的第一工作节点上部署第一状态实例;建立第一状态实例的标识与消息管理装置的地址的对应关系,消息管理装置与第一工作节点对应。
在第三方面的一种可能的实现方式中,该方法还包括:将部署在第二工作节点上的第一有状态函数,迁移到第一工作节点上,第一有状态函数的迁移代价小于第一状态实例的迁移代价。
在第三方面的一种可能的实现方式中,该地址请求中还包括所述第一有状态函数的函数名,第一工作节点是根据多个工作节点的负载信息、第一状态实例的大小,以及至少两个有状态函数的需求策略确定的,所述至少两个有状态函数位于与所述第一有状态函数的函数名相关联的函数业务组中。
在第三方面的一种可能的实现方式中,该地址请求中还包括所述第一有状态函数的函数名,第一工作节点是多个工作节点中总分数最高的工作节点,一个工作节点的总分数与工作节点的计算资源、存储资源或是否已部署至少两个状态函数相关,所述至少两个有状态函数位于与所述第一有状态函数的函数名相关联的函数业务组中。
在第三方面的一种可能的实现方式中,该去服务器化系统还包括地址管理装置,该方法还包括:向地址管理装置发送第一状态实例的标识与第一工作节点对应的消息管理装置的地址的对应关系。
该第三方面中所涉及到的特征和相应效果可以参阅第一方面,以及第一方面中的可能实现方式中的相应介绍进行理解,此处不再重复赘述。
本申请第四方面提供一种消息管理装置,该消息管理装置具有实现上述第二方面或第二方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块,例如:接收单元、第一处理单元和第二处理单元。
本申请第五方面提供一种调度装置,该消息管理装置具有实现上述第三方面或第三方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块,例如:接收单元、第一处理单元和第二处理单元。
本申请第六方面提供一种计算机设备,该计算机设备包括至少一个处理器、存储器、输入/输出(input/output,I/O)接口以及存储在存储器中并可在处理器上运行的计算机执行指令,当计算机执行指令被处理器执行时,处理器执行如上述第二方面或第二方面任意一种可能的实现方式的方法。
本申请第七方面提供一种计算机设备,该计算机设备包括至少一个处理器、存储器、输入/输出(input/output,I/O)接口以及存储在存储器中并可在处理器上运行的计算机执行指令,当计算机执行指令被处理器执行时,处理器执行如上述第三方面或第三方面任意一种可能的实现方式的方法。
本申请第八方面提供一种存储一个或多个计算机执行指令的计算机可读存储介质,当计算机执行指令被处理器执行时,处理器执行如上述第二方面或第二方面任意一种可能的实现方式的方法。
本申请第九方面提供一种存储一个或多个计算机执行指令的计算机可读存储介质,当计算机执行指令被处理器执行时,处理器执行如上述第三方面或第三方面任意一种可能的实现方式的方法。
本申请第十方面提供一种存储一个或多个计算机执行指令的计算机程序产品,当计算机执行指令被处理器执行时,处理器执行如上述第二方面或第二方面任意一种可能的实现方式的方法。
本申请第十一方面提供一种存储一个或多个计算机执行指令的计算机程序产品,当计算机执行指令被处理器执行时,处理器执行如上述第三方面或第三方面任意一种可能的实现方式的方法。
本申请第十二方面提供了一种芯片系统,该芯片系统包括至少一个处理器,至少一个处理器用于支持进程间通信的装置实现上述第二方面或第二方面任意一种可能的实现方式中所涉及的功能。在一种可能的设计中,芯片系统还可以包括存储器,存储器,用于保存消息管理装置必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他分立器件。
本申请第十三方面提供了一种芯片系统,该芯片系统包括至少一个处理器,至少一个处理器用于支持进程间通信的装置实现上述第三方面或第三方面任意一种可能的实现方式中所涉及的功能。在一种可能的设计中,芯片系统还可以包括存储器,存储器,用于保存调度装置必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他分立器件。
本申请实施例采用消息管理的方式控制不同有状态函数对第一状态实例的分时操作,第一有状态函数只有被调度第一消息后才准备操作第一状态实例的资源,进而操作该第一状态实例,避免了一个有状态函数操作状态实例时其他有状态函数占用资源等待,避免了资源浪费,提高了资源利用率。
附图说明
图1是本申请实施例提供的去服务器系统的一结构示意图;
图2A是本申请实施例提供的去服务器系统的另一结构示意图;
图2B是本申请实施例提供的去服务器系统的另一结构示意图;
图3是本申请实施例提供的消息管理的方法的一实施例示意图;
图4A是本申请实施例提供的一场景实例示意图;
图4B是本申请实施例提供的另一场景实例示意图;
图5A是本申请实施例提供的另一场景实例示意图;
图5B是本申请实施例提供的另一场景实例示意图;
图5C是本申请实施例提供的另一场景实例示意图;
图6是本申请实施例提供的一视频场景的一实例示意图;
图7是本申请实施例提供的一视频场景的消息管理的方法的一实施例示意图;
图8A是本申请实施例提供的一效果对比图;
图8B是本申请实施例提供的另一效果对比图;
图9是本申请实施例提供的消息管理装置的一实施例示意图;
图10是本申请实施例提供的调度装置的一实施例示意图;
图11是本申请实施例提供的计算机设备的一结构示意图;
图12是本申请实施例提供的计算机设备的另一结构示意图。
具体实施方式
下面结合附图,对本申请的实施例进行描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。本领域普通技术人员可知,随着技术的发展和新场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本申请实施例提供本申请实施例提供一种去服务器化系统,用于采用消息管理的方式控制不同有状态函数对状态实例的分时操作,有状态函数只有得到操作状态实例的消息后才需要准备资源,进而操作该状态实例,避免了资源浪费。本申请实施例还提供了相应的消息管理的方法及装置。以下分别进行详细说明。
图1为本申请实施例中去服务器化系统的一实施例示意图。
如图1所示,该去服务器化系统包括客户端、路由设备、控制节点和工作节点。控制节点可以有一个,也可以有多个,如:图1中的控制节点1到控制节点X,X为大于1的整数。工作节点通常会有多个,如:工作节点1、工作节点2、工作节点3到工作节点M,工作节点P到工作节点S,M、P和S都为大于3的整数,且S>P>M。其中,控制节点1可以管理工作节点1到工作节点M。控制节点M可以管理工作节点P到工作节点S。当然,也不限于这种管理方式,也可以是控制节点1到控制节点X,一起管理工作节点1至工作节点M,以及工作节点P到工作节点S。或者,控制节点1到控制节点M轮流管理工作节点1至工作节点M,以及工作节点P到工作节点S。本申请中,“多个”包括“两个”。“多个”也可以描述为“至少两个”。
其中,客户端可以是手机(mobile phone)、平板电脑(pad)、笔记本电脑以及个人计算机(personal computer,PC)等计算机设备。该客户端也可以是云上的服务进程。路由设备可以是交换机或路由器等设备。控制节点和工作节点都可以是独立的物理机,也可以是从云资源中虚拟化出来的虚拟机(virtual machine,VM)。
用户可以通过客户端向控制节点发布函数,控制节点会记录函数的信息,该函数的信息可以包括函数业务组、函数名,以及函数代码等,当然,该函数的信息也可以包括其他参数,不限于这里列举的函数业务组、函数名,以及函数代码。该函数业务组中会包括该函数所绑定的状态实例的名称,以及绑定该状态实例的其他函数的名称。
本申请实施例中,如图2A和图2B所示,控制节点上可以包括调度装置(functionstate scheduler),工作节点上可以包括消息管理装置(state message manager),路由设备上可以包括路由装置(routing),该调度装置、消息管理装置以及路由装置可以是一个实例(instance)或容器(container),可以通过软件分别在控制节点、工作节点以及路由设备上实现相应的功能。另外,该去服务器化系统中还可以包括地址管理装置,该地址管理装置也可以称为名字服务装置,该地址管理装置可以是一个独立的物理机,也可以是从云资源中虚拟化出来的虚拟机。该地址管理装置用于存放消息管理装置的地址。
图2A中每个工作节点上都配置一个消息管理装置,图2B中只在一些工作节点上配置了消息管理装置。实际上,本申请中的消息管理装置不限于配置在工作节点上,该消息管理装置还可以配置在控制节点上。另外,路由装置也可以不配置在路由设备上,而配置在客户端上。
另外,需要说明的是,图2A和图2B所示的去服务器化系统的示意图中只是以控制节点1和该控制节点下的工作节点的为例进行示意的,实际上,该去服务器化系统中还可以包括如图1所示的控制节点M、工作节点P到工作节点S,该控制节点M、工作节点P到工作节点S与上述消息管理装置、调度装置、路由装置以及地址管理装置的关系都可以参阅图2A和图2B中相应关系进行理解。
上述图2A和图2B所示的去服务器化系统可以管理有状态函数和状态实例,通过消息管理来实现多个有状态函数同一个状态实例的分时操作,下面结合图3介绍本申请实施例提供的消息管理的方法。
如图3所示,本申请实施例提供的消息管理的方法的一实施例包括:
101、客户端发起对第一有状态函数的调用请求。
该调用请求中包括第一状态实例的标识(state ID)和第一有状态函数的函数名。
有状态函数指的是该函数运行过程中的状态数据可以被保留,该函数下次运行时还可以操作该状态数据。状态数据指的是函数运行过程中的暂态数据或上下文数据。
状态数据包含于状态实例中,一个状态实例中的状态数据可以被修改,但状态实例的标识,也就是该状态实例的state ID不会变化。
102、路由装置接收该调用请求,获取与第一状态实例的标识对应的消息管理装置的地址。
该步骤102可以通过如下三种方式获取与第一状态实例的信息(state ID)对应的消息管理装置的地址(endpoint)。
第一种:从路由装置本地获取。
路由装置可以根据第一状态实例的标识查找本地是否存储第一状态实例的标识对应的消息管理装置的地址的对应关系,若本地存储有该对应关系,则可以查找到与该state ID对应的endpoint。
第二种:从地址管理装置获取。
地址管理装置用于存储state ID与endpoint的对应关系。
路由装置可以向地址管理装置发送state ID,地址管理装置根据该state ID,以及已存储的上述对应关系,确定与该state ID对应的endpoint。地址管理装置向路由装置发送该endpoint。
也可以是路由装置从地址管理装置获取该对应关系,然后自行确定与该state ID对应的endpoint。
第三种:从调度装置获取。
若第一种和第二种都无法获取与该state ID对应的endpoint,则说明state ID与endpoint的对应关系不存在,则路由装置可以向调度装置发送地址请求。该地址请求用于指示调度装置将该第一状态实例部署在第一工作节点上,并建立第一状态实例的标识与消息管理装置的地址的对应关系,该消息管理装置与该第一工作节点对应。该地址请求包括第一状态实例的标识(state ID),也可以包括第一有状态函数的函数名。
若地址请求中不包括第一有状态函数的函数名,则可以从多个工作节点中任意选择一个节点作为第一工作节点。
若地址请求中包括该第一有状态函数的函数名,则调度装置根据第一有状态函数的函数名确定该函数所属的函数业务组,以及该函数业务组内与函数相关的信息,如:该函数所绑定的状态实例,以及绑定该状态实例的其他函数的函数名。
调度装置可以对第一状态实例进行调度,将该第一状态实例调度到第一工作节点上,然后记录对应该第一工作节点的消息管理装置的地址与该第一状态实例的标识的对应关系。也就是调度装置确定了与第一状态实例的标识对应的消息管理装置的地址,该地址用于指示第一消息的接收方,也就是接收该第一消息的消息管理装置。
调度装置向地址管理装置发送第一状态实例的消息管理装置以及消息管理装置的地址,也就是调度装置向地址管理装置发送state ID与endpoint的对应关系。
调度装置也可以向路由装置返回该消息管理装置的地址(endpoint)。
103、路由装置向消息管理装置的地址指示的消息管理装置发送第一消息。
第一消息包括第一状态实例的标识和第一有状态函数的函数名,第一消息用于指示调度第一有状态函数操作第一状态实例。
104、消息管理装置接收第一消息,将第一消息存入与第一状态实例对应的第一消息队列。
第一消息队列还用于存储多个消息,多个消息中的每个消息用于指示一个有状态函数操作第一状态实例。
第一消息队列用于存储多个消息表示该第一消息队列可以存储多个消息,而不是当前存储多个消息。因为第一消息队列中的消息会出队列,所以一个时刻内,该第一消息队列中可能有一个消息,也可能有多个消息,也可以能一个消息都没有。
进入第一消息队列中的消息是按顺序排列的,按照先进先出的原则从第一消息队列中被调度出。
105、将第二消息,传递给第二消息对应的第二有状态函数,并运行第二消息对应的第二有状态函数操作处于空闲状态的第一状态实例。
第二消息为位于第一消息队列最前端的消息。第二消息位于第一消息队列的最前端表示该第二消息进入第一消息队列的时间早于第一消息队列中目前包含的其他消息。
该第二消息可以是在第一消息之前进入第一消息队列的。如果第一消息进入该第一消息队列时,该第一消息队列中没有消息,则该第二消息就是该第一消息,第二消息对应的第二有状态函数也就是第一有状态函数。
第一状态实例处于空闲状态表示该第一状态实例没有被其他与该第一状态实例有关联的有状态函数操作。
将第二消息传递给第二有状态函数后,该第二有状态函数才会对第一状态实例进行操作。
若第二消息与第一消息不是同一消息,在将第二消息,传递给所述第二消息对应的第二有状态函数之后,将位于第一消息队列最前端的第一消息,传递给第一有状态函数,并运行第一有状态函数操作处于空闲状态的第一状态实例。
上述方案中,针对通过地址管理装置得到state ID与endpoint的对应关系的过程如图4A所示:调度装置在调度状态实例和状态函数后,通过注册的方式,将状态实例的state ID与该状态实例所部署的消息管理装置的地址endpoint存储在地址管理装置中。在该state ID与endpoint的对应关系中,通过key:state ID就可以查找到对应的value:endpoint。路由装置会订阅地址管理装置的相关信息,获取stateid与endpoint的对应关系,通过stateid确定endpoint,也就是消息接收放,将消息转发到包含该状态实例的消息管理装置。如图4A中,将与状态实例1和状态实例2相关的消息转发到消息管理装置1,将与状态实例3和状态实例4相关的消息转发到消息管理装置2。
在每个消息管理装置中,针对每个状态实例都会维护一个消息队列,每个消息队列可以用对应状态实例的state ID来标识。如图4B所示,在消息管理装置1中,针对状态实例1有一个消息队列,用state 1来标识,针对状态实例2有一个消息队列,用state 2来标识。状态函数B和状态函数C按照state 1所标识的消息队列中消息的排列顺序,采用分时操作的方式操作状态实例1,状态函数E和状态函数F按照state 2所标识的消息队列中消息的排列顺序,采用分时操作的方式操作状态实例2。
本申请实施例提供的方案采用消息管理的方式控制不同有状态函数对第一状态实例的分时操作,第二有状态函数只有被调度第二消息后才会操作第一状态实例,同样,与该第一状态实例关联的其他有状态函数也只有被调度到相应的消息后才会操作该第一状态实例,避免了一个有状态函数操作状态实例时其他有状态函数占用资源等待,避免了资源浪费,提高了资源利用率。
本申请实施例中,若调度装置接收到地址请求,则表明第一状态实例还没有被部署到工作节点上。该地址请求用于指示调度装置为该第一状态实例分配消息管理装置,以及建立第一状态实例的标识和所分配的消息管理装置的地址的对应关系。
调度装置可以根据所管理的多个工作节点的负载信息、第一状态实例的大小,以及对该第一状态实例有操作权限的至少两个有状态函数的需求策略来确定用于部署第一状态实例的第一工作节点。
工作节点的负载信息指示工作节点上目前的负载情况,可以包括工作节点上函数部署的情况、中央处理单元(central processing unit,CPU)的占用率或空闲率,内存的占用率或空闲率中的至少一种。第一状态实例的大小表示第一状态实例的数据量,该数据量可以是在用户发布上述第一有状态函数或第二有状态函数时定义了这两个有状态函数与该第一状态实例的绑定关系,以及定义了该第一状态实例的大小,另外,还可以通过对已有的同类的状态实例进行收集评估来确定该第一状态实例的大小。对第一状态实例有操作权限的至少两个有状态函数的需求策略可以包括:该状态实例与对应的有状态函数是否需要部署在同一个工作节点上,对CPU的空闲率要求要达到第一阈值,或者,对内存的空闲率要达到第二阈值等。第一阈值和第二阈值都可以根据需求设定。
该过程可以参阅图5A和图5B所示的场景示意图进行理解。如图5A所示,有状态函数B和有状态函数C都可以操作状态实例1。如图5B所示,该调度装置所在的控制节点所管理的工作节点有4个,分别为工作节点1、工作节点2、工作节点3和工作节点4。其中,状态函数B和有状态函数C都部署在工作节点1上,状态函数D部署在工作节点2上,工作节点3的CPU的占用率只有30%,70%都处于空闲状态。工作节点4的内存的空闲率有80%。
如果工作节点1上的剩余内存能够存储该状态实例1,则较好的是将该状态实例1部署在工作节点1上,这样,有状态函数B和有状态函数C和状态实例1都位于同一个工作节点上,不需要跨工作节点操作状态实例1,可以减少通信开销。
如果工作节点1上的剩余内存不够存储该状态实例1,则需要从工作节点2、工作节点3和工作节点4上选择一个工作节点部署该状态实例1。如果需求策略指示对CPU的要求比较高,则可以选择工作节点3部署状态实例1,如果需求策略指示对内存的要求比较高,则可以选择工作节点4部署状态实例1。
另外,本申请实施例还提供了另一种工作节点选择方案,该选择方案中可以先对每个工作节点进行打分,从中选择打分最高的工作节点用来部署状态实例1。
为每个工作节点打分的过程可以采用如下关系式来计算:
上述关系式中,f(x)表示一个工作节点采用各种评估算法评估后的总分数,n表示评估算法的数量,α表示当前评估算法的比重,t(x)表示当前评估算法。
评估算法可以是与资源相关的算法(如:与CPU相关的算法,与内存相关的算法),与亲和性相关的算法(如:有状态函数与状态实例是否位于同一工作节点的算法等)。
采用上述关系式确定出每个工作节点的总分数,然后采用如下关系式从m个工作节点中选择总分数最大的工作节点。
上述关系式中,node表示被选中的节点,如:上述的第一工作节点。f(Cm)表示m个工作节点各自的总分数,max表示从m个工作节点中选择分数最大的工作节点用来部署第一状态实例。
该种通过计算总分数的第一工作节点的选择过程也可以描述为:第一工作节点是多个工作节点中总分数最高的工作节点,一个工作节点的总分数与工作节点的计算资源、存储资源或是否已部署至少两个状态函数相关。
若部署第一状态实例后,根据上述第一工作节点的选择过程,该第一状态实例与第一有状态函数没有在同一个工作节点上,可以确定第一有状态函数的迁移代价,以及第一状态实例的迁移代价,若第一有状态函数的迁移代价小于迁移第一状态实例的代价,则将第一有状态函数从第一状态函数当前所在的工作节点迁移到第一工作节点。
如果第二有状态函数与第一状态实例也没有在同一个工作节点上,也可以确定第二有状态函数的迁移代价,以及第一状态实例的迁移代价,若第二有状态函数的迁移代价小于迁移第一状态实例的代价,则将第二有状态函数从第二状态函数当前所在的工作节点迁移到第一工作节点。
迁移代价指的是因有状态函数迁移或者状态实例迁移所带来的资源消耗,如:传输资源消耗、状态实例因迁移而带来的加载负载(例如:加载时长)、有状态函数因迁移而带来的部署负载(例如:加载时长),另外,状态实例或有状态函数迁移时也可以考虑集群中各工作节点的资源情况。
上述迁移需要考量的因素用关系式可以表示为:y=f(x1,x2,x3)。
其中,x1表示状态实例的数据加载负载(data_migration_overhead),例如:加载时长。
x2表示有状态函数的函数部署负载(functions_deploy_overhead),例如:加载时长。
x3表示前集群的资源情况(resource)。
本申请实施例通过有状态函数的迁移代价以及对应的状态实例的迁移代价来确定是迁移数据(shipping data),还是迁移函数(shipping function)。这样,可以在使用较小迁移开销的情况下,就达到较好的系统性能。
y=f(data_migration_overhead数据加载负载(损耗,例如加载时长),functions_deploy_overhead函数部署负载(损耗,例如加载时长),resource当前集群的资源情况)。
上述描述了对第一消息队列的管理过程,如果消息管理装置还维护了其他状态实例的消息队列,则消息管理装置还用于:相对于第一消息队列,并行将位于第二消息队列最前端的第三消息,传递给第三有状态函数,并运行第三有状态函数操作处于空闲状态的第二状态实例,第二消息队列与第二状态实例对应。
该种可能的实施例中,一个消息管理装置可以管理多个消息队列,每个消息队列会对应一个状态实例,针对不同的状态实例的消息队列,可以采用并行调度的方式来调度不同队列中的消息,这样可以提高不同有状态函数对不同状态实例的操作效率。
可选地,消息管理装置还用于:在第一消息队列和第二消息队列中的消息都调度完毕后,并行将位于第三消息队列最前端的第四消息,传递给第四有状态函数,并运行第四有状态函数操作处于空闲状态的第一状态实例和第二状态实例,第三消息队列与第一状态实例和第二状态实例对应,第四有状态函数的调度顺序位于第一有状态函数、第二有状态函数和第三有状态函数之后。
该种可能的实施例中,第四有状态函数对第一状态实例和第二状态实例的组合实例有操作权限,而且,第四有状态函数在对第一状态实例和第二状态实例的操作顺序上位于第一有状态函数、第二有状态函数和第三有状态函数之后,则在调度完第一消息队列和第二消息队列中的消息后,才调度第三消息队列中的消息操作该组合实例。该种可能的实现方式提供了有状态函数多级管理的方式。
该过程可以参阅图5C进行理解。如图5C所示,有状态函数B和有状态函数C都可以操作状态实例1,有状态函数E和有状态函数F都可以操作状态实例2,有状态函数G可以操作状态实例1和状态实例2的组合实例。在操作顺序上,有状态函数G位于其他四个函数之后,状态实例1的消息队列用于state 1来标识,状态实例2的消息队列用于state 2来标识。状态实例1和状态实例2的组合实例的消息队列用state 12来标识。消息管理装置在调度消息时,针对state 1的消息队列和state 2的消息队列可以采用并行的调度方式来调度,针对state1的消息队列和state 2的消息队列中的每个消息队列中消息的调度规则,可以参阅上述实施例中第一消息队列的调度过程进行理解。在state 1的消息队列和state 2的消息队列中的消息都调度完毕后,才会调度state 12的消息队列中的消息G。
本申请实施例提供的去服务器化系统,以及消息管理的方法可以应用于多种应用场景中,下面将上述服务器化系统以及消息管理的方法结合在视频的场景中,对本申请的方案再进行介绍。
如图6所示,该视频场景中,总视频存储在对象存储服务器(object stroageservice,OBS)中,该总视频可以是直播的视频,也可以是一部电影、一集电视剧或者其他节目的数据集。在客户端请求一个总视频时,因为OBS中存储的视频的格式不能直接用于客户端,在客户端请求后,需要根据客户端的展示形式(如:极速、高清、超清等)对总视频进行处理。对视频处理过程中需要对总视频的码流进行切片(split),然后针对每个切片再进行转换(transfer,trans),最后再对所有切片进行合成(merge)。
上述切片过程需要运行切片函数(split function)来执行,转换过程需要运行转换函数(trans function)来执行,每个切片会对应一个转换函数,合成过程需要运行合成函数(merge function)来执行。
该场景中,每个视频切片和对应的转码视频切片可以理解为是一个状态实例。一个转换函数会对应一个状态实例,但切片函数以及合成函数与该转换函数都可以操作该状态实例。如图6中,该总视频的每个视频切片部署在工作节点中,与切片函数、转换函数和合成函数位于同一工作节点。针对每个视频切换会执行一次转换的过程,得到一个转码视频切片。例如:该总视频可以切分为视频切片1、视频切片2,…,视频切片x这x个视频切片,每个转换函数操作一次对应的视频切片,会得到x个转码视频切片,合成函数可以对这x个转码视频切片进行合成,然后再将转码合成视频存储到OBS中,x为大于2的整数。
上述每个视频切片是一个状态实例,该状态实例中的视频内容是可以被操作的,如被转换函数转码,得到转码视频切片,但该状态实例的标识是不变的,转换前和转换后,都可以通过state 01、state 02,…,state x来标识。
上述视频场景的消息管理方法的过程可以参阅图7进行理解。如图7所示,该视频场景的消息管理方法的过程可以包括:
201、客户端向路由装置发送调用请求。
该调用请求中包括的函数名(func_split),状态实例的标识(state 01)。
202、路由装置确定该调用请求的路由关系是否存在。
若存在,则跳过203至206,直接执行步骤207,若不存在,则执行步骤203。
203、路由装置向调度装置发送地址请求。
该地址请求中包括func_split和state 01。
204、调度装置部署该状态实例,并确定对应该状态实例的消息管理装置的地址。
该过程可以参阅前述实施例中步骤102中的第三种:从调度装置获取与该stateID对应的endpoint的方案进行理解。另外,关于部署状态实例以及部署状态实例后是否迁移split状态函数的过程也可以参阅前述实施例中图5A和图5B的相应示例进行理解。
205、调度装置向地址管理装置发送state 01与endpoint 1的对应关系,相应的,地址管理装置存储该state 01与endpoint 1的对应关系。
206、调度装置向路由装置发送state 01与endpoint 1的对应关系。
207、路由装置根据endpoint 1向对应的消息管理装置发送第一消息。
该第一消息中包括func_split和state 01。
208、采用队列管理的方式将第一消息放入state 01对应的消息队列。
209、消息管理装置从消息队列中调度出第一消息给切片函数。
如果本地(也就是该消息管理装置所在的工作节点)没有切片函数,可以在本地创建一个切片函数。
需要说明的是,本申请实施例并不强制split函数一定在本地,如果本地没有split函数,消息管理装置通知调度装置随机创建一个split函数,或者使用现有已存在的split函数都可以实现本申请的流程。
关于步骤208和209的消息队列管理的内容可以参阅前述图3对应实施例的步骤104和105,以及图4A和图4B的相应描述进行理解,此处不再重复描述。
210、运行切片函数将总视频进行切片。
211、运行切片函数完成切片后,发起对转换函数实例1的调用请求。
该对转换函数实例1的调用请求包括func_trans和state 01。
接下来可以根据func_trans和state 01执行上述步骤202至210,不同的是,转换函数实例发生了变化。
因为每个转换函数实例对应一个状态实例,上述转换函数实例与状态实例的对应关系可以参阅表1进行理解。
表1:转换函数实例与状态实例的标识
转换函数实例 | 状态实例的标识 |
func_trans 1 | state 01 |
func_trans 2 | state 02 |
… | … |
func_trans x | state x |
因为转换函数实例1对应state 01,所以步骤211中只是函数实例发生了变化。在转换函数实例1完成相应的转换操作后,调用转换函数实例2,使用状态实例的标识state02,再重复执行上述步骤202至210的过程。以此类推,直到转换函数实例x完成对状态实例x的操作。然后执行步骤212。
212、运行转换函数实例x发起对合成函数的调用请求。
该对合成函数的调用请求包括func_merge和state 01-state x。
然后,根据func_merge和state 01-state x执行上述202至210的过程,完成状态实例至状态实例x中转码视频切片的合成。
本申请的该视频场景中,采用消息管理的方式控制不同有状态函数对第一状态实例的分时操作,第一有状态函数只有被调度第一消息后才准备操作第一状态实例的资源,进而操作该第一状态实例,避免了一个有状态函数操作状态实例时其他有状态函数占用资源等待,避免了资源浪费,提高了资源利用率。另外,可以根据函数的迁移代价以及状态实例的迁移代价确定迁移函数或者迁移状态实例,这样在使用较小迁移开销的情况下,就达到较好的系统性能。
本申请实施例中还提供了采用本申请的方案和业界的PyWren模型进行的机器学习的计算性能对比图。
如图8A所示,该对比图是本申请和业界的PyWren模型的测试开销(单位是美金)。从该图8A中可见,本申请完成1000次测试的资源开销是329,业界的PyWren模型完成1000次测试的资源开销是2105,可见,本申请在1000次测试的资源开销比业界的PyWren模型的资源开销降低了6倍。
如图8B所示,该对比图是本申请和业界的PyWren模型的单次任务完成时间(单位是秒s)。从该图8B中可见,本申请单次任务完成时间是140s,业界的PyWren模型单次任务完成时间是6190s,本申请完成单次任务比业界的PyWren模型完成单次任务快了44倍。
以上介绍了去服务器系统和消息管理的方法,下面结合附图介绍本申请实施例提供的消息管理装置和调度装置,该消息管理装置和调度装置都可以是一个计算机设备或者虚拟机。
如图9所示,本申请实施例提供的消息管理装置30的一实施例包括:
接收单元301,用于接收第一消息,第一消息用于指示调度第一有状态函数操作第一状态实例。
第一处理单元302,用于将接收单元301第一消息存入与第一状态实例对应的第一消息队列,第一消息队列用于存储多个消息,每个消息用于指示一个有状态函数操作第一状态实例。
第二处理单元303,用于将第二消息,传递给第二消息对应的第二有状态函数,并运行第二消息对应的第二有状态函数操作处于空闲状态的第一状态实例,其中,第二消息为位于第一消息队列最前端的消息。
本申请实施例提供的方案采用消息管理的方式控制不同有状态函数对第一状态实例的分时操作,第二有状态函数只有被调度第二消息后才会操作第一状态实例,同样,与该第一状态实例关联的其他有状态函数也只有被调度到相应的消息后才会操作该第一状态实例,避免了一个有状态函数操作状态实例时其他有状态函数占用资源等待,避免了资源浪费,提高了资源利用率。
可选地,第二处理单元303,还用于相对于第一消息队列,并行将位于第二消息队列最前端的第三消息,传递给第三有状态函数,并运行第三有状态函数操作处于空闲状态的第二状态实例,第二消息队列与第二状态实例对应。
可选地,第二处理单元303,还用于在第一消息队列和第二消息队列中的消息都调度完毕后,并行将位于第三消息队列最前端的第四消息,传递给第四有状态函数,并运行第四有状态函数操作处于空闲状态的第一状态实例和第二状态实例,第三消息队列与第一状态实例和第二状态实例对应,第四有状态函数的调度顺序位于第一有状态函数、第二有状态函数和第三有状态函数之后。
如图10所示,本申请实施例提供的调度装置40应用于服务器化系统,去服务器化系统还包括消息管理装置、路由装置和多个工作节点,该调度装置40的一实施例包括:
接收单元401,用于接收路由装置发送的地址请求,该地址请求包括第一状态实例的标识。
第一处理单元402,用于根据接收单元401接收的第一状态实例的标识,在多个工作节点中的第一工作节点上部署第一状态实例。
第二处理单元403,用于在第一处理单元402部署第一状态实例后,建立第一状态实例的标识与消息管理装置的地址的对应关系,消息管理装置与第一工作节点对应。
本申请实施例提供的方案,调度装置在部署第一状态实例时会结合多个工作节点的负载信息、第一状态实例的大小,以及至少两个有状态函数的需求策略,这样可以提高去服务器系统的性能。
可选地,第一处理单元402,还用于将部署在第二工作节点上的第一有状态函数,迁移到第一工作节点上,第一有状态函数的迁移代价小于第一状态实例的迁移代价。
可选地,地址请求中还包括第一有状态函数的函数名,第一工作节点是根据多个工作节点的负载信息、第一状态实例的大小,以及至少两个有状态函数的需求策略确定的,至少两个有状态函数位于与第一有状态函数的函数名相关联的函数业务组中。
可选地,地址请求中还包括第一有状态函数的函数名,第一工作节点是多个工作节点中总分数最高的工作节点,一个工作节点的总分数与工作节点的计算资源、存储资源或是否已部署至少两个状态函数相关,至少两个有状态函数位于与第一有状态函数的函数名相关联的函数业务组中。
可选地,去服务器化系统还包括地址管理装置,发送单元404,用于向地址管理装置发送第一状态实例的标识与第一工作节点对应的消息管理装置的地址的对应关系。
以上所描述的消息管理装置30和调度装置40可以参阅前述方法实施例部分的相应描述进行理解,此处不做重复赘述。
图11所示,为本申请的实施例提供的计算机设备50的一种可能的逻辑结构示意图。该计算机设备可以是上述消息管理装置30或调度装置40,计算机设备50包括:处理器501、通信接口502、存储器503以及总线504。处理器501、通信接口502以及存储器503通过总线504相互连接。在本申请的实施例中,处理器501用于对计算机设备50的动作进行控制管理,例如,处理器501用于执行图3的方法实施例中101至105的步骤,以及图7中的方法实施例中的201至212的步骤,通信接口502用于支持计算机设备50进行通信。存储器503,用于存储计算机设备50的程序代码和数据。若存储器503中存储的是消息管理装置30所执行功能的程序代码和数据,则该计算机设备50中的通信接口502会执行上述接收单元301接收第一消息的功能,处理器501会执行上述第一处理器302和第二处理器303的功能。若存储器503中存储的是调度装置40所执行功能的程序代码和数据,则该计算机设备50中通信接口502会执行上述接收单元401的功能,处理器501会执行上述第一处理单元402和第二处理单元403的功能。
其中,处理器501可以是中央处理器单元,通用处理器,数字信号处理器,专用集成电路,现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框,模块和电路。处理器501也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,数字信号处理器和微处理器的组合等等。总线504可以是外设部件互连标准(PeripheralComponent Interconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示,图11中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
如图12所示,本申请实施例提供的计算机设备60的一种可能的逻辑结构示意图。该计算机设备60包括:硬件层601和VM层602,该VM层可以包括一个或多个VM。该硬件层601为VM提供硬件资源,支撑VM运行,该硬件层601包括处理器、通信接口以及存储器等硬件资源。当一个VM执行消息管理装置30的功能时,该硬件层的通信接口会执行上述接收单元301接收第一消息的功能,处理器会执行上述第一处理器302和第二处理器303的功能。当一个VM执行调度装置40的功能时,则该计算机设备50中通信接口会执行上述接收单元401的功能,处理器会执行上述第一处理单元402和第二处理单元403的功能。具体的不同的VM执行不同装置的功能的过程可以参阅上述图3至图7中的相应描述进行理解。
在本申请的另一实施例中,还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,当设备的处理器执行该计算机执行指令时,设备执行上述图3至图7中消息管理装置所执行的消息管理的方法。
在本申请的另一实施例中,还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机执行指令,当设备的处理器执行该计算机执行指令时,设备执行上述图3至图7中调度装置所执行的消息管理的方法。
在本申请的另一实施例中,还提供一种计算机程序产品,该计算机程序产品包括计算机执行指令,该计算机执行指令存储在计算机可读存储介质中;当设备的处理器执行该计算机执行指令时,设备执行上述图3至图7中消息管理装置所执行的消息管理的方法。
在本申请的另一实施例中,还提供一种计算机程序产品,该计算机程序产品包括计算机执行指令,该计算机执行指令存储在计算机可读存储介质中;当设备的处理器执行该计算机执行指令时,设备执行上述图3至图7中调度装置所执行的消息管理的方法。
在本申请的另一实施例中,还提供一种芯片系统,该芯片系统包括处理器,该处理器用于支持进程间通信的装置实现上述图3至图7中消息管理装置所执行的消息管理的方法。在一种可能的设计中,芯片系统还可以包括存储器,存储器,用于保存消息管理装置必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他分立器件。
在本申请的另一实施例中,还提供一种芯片系统,该芯片系统包括处理器,该处理器用于支持进程间通信的装置实现上述图3至图7中调度装置所执行的消息管理的方法。在一种可能的设计中,芯片系统还可以包括存储器,存储器,用于保存调度装置必要的程序指令和数据。该芯片系统,可以由芯片构成,也可以包含芯片和其他分立器件。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请实施例的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请实施例所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请实施例各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上,仅为本申请实施例的具体实施方式,但本申请实施例的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请实施例揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请实施例的保护范围之内。因此,本申请实施例的保护范围应以权利要求的保护范围为准。
Claims (23)
1.一种去服务器化系统,其特征在于,包括:消息管理装置;
所述消息管理装置用于:
接收第一消息,所述第一消息用于指示调度第一有状态函数操作第一状态实例;
将所述第一消息存入与所述第一状态实例对应的第一消息队列,所述第一消息队列用于存储多个消息,每个所述消息用于指示一个有状态函数操作所述第一状态实例;
将第二消息,传递给所述第二消息对应的第二有状态函数,并运行所述第二消息对应的所述第二有状态函数操作处于空闲状态的所述第一状态实例,其中,所述第二消息为位于所述第一消息队列最前端的消息。
2.根据权利要求1所述的去服务器化系统,其特征在于,所述去服务器化系统还包括路由装置、调度装置和多个工作节点,
所述调度装置用于:
接收所述路由装置发送的地址请求,所述地址请求包括所述第一状态实例的标识;
根据所述第一状态实例的标识,在所述多个工作节点中的第一工作节点上部署所述第一状态实例;
建立所述第一状态实例的标识与所述消息管理装置的地址的对应关系,所述消息管理装置与所述第一工作节点对应。
3.根据权利要求2所述的去服务器化系统,其特征在于,
所述调度装置还用于:
将部署在第二工作节点上的所述第一有状态函数,迁移到所述第一工作节点上,所述第一有状态函数的迁移代价小于所述第一状态实例的迁移代价。
4.根据权利要求2或3所述的去服务器化系统,其特征在于,所述地址请求中还包括所述第一有状态函数的函数名;
所述第一工作节点是根据所述多个工作节点的负载信息、所述第一状态实例的大小,以及至少两个有状态函数的需求策略确定的,所述至少两个有状态函数位于与所述第一有状态函数的函数名相关联的函数业务组中;或者,
所述第一工作节点是所述多个工作节点中总分数最高的工作节点,一个工作节点的总分数与所述工作节点的计算资源、存储资源或是否已部署至少两个状态函数相关,所述至少两个有状态函数位于与所述第一有状态函数的函数名相关联的函数业务组中。
5.根据权利要求1-4任一项所述的去服务器化系统,其特征在于,
所述消息管理装置还用于:
相对于所述第一消息队列,并行将位于第二消息队列最前端的第三消息,传递给所述第三有状态函数,并运行所述第三有状态函数操作处于空闲状态的第二状态实例,所述第二消息队列与所述第二状态实例对应。
6.根据权利要求5所述的去服务器化系统,其特征在于,
所述消息管理装置还用于:
在所述第一消息队列和所述第二消息队列中的消息都调度完毕后,并行将位于第三消息队列最前端的第四消息,传递给所述第四有状态函数,并运行所述第四有状态函数操作处于空闲状态的第一状态实例和第二状态实例,所述第三消息队列与所述第一状态实例和所述第二状态实例对应,所述第四有状态函数的调度顺序位于所述第一有状态函数、所述第二有状态函数和所述第三有状态函数之后。
7.根据权利要求2-4任一项所述的去服务器化系统,其特征在于,所述去服务器化系统还包括地址管理装置;
所述调度装置还用于:
向所述地址管理装置发送所述第一状态实例的标识与所述消息管理装置的地址的对应关系;
所述地址管理装置存储所述对应关系。
8.根据权利要求7所述的去服务器化系统,其特征在于,
所述路由装置还用于:
接收客户端对所述第一有状态函数的调用请求,所述调用请求包括所述第一状态实例的标识和所述第一有状态函数的函数名;
获取与第一状态实例的标识对应的所述消息管理装置的地址;
向所述消息管理装置的地址指示的所述消息管理装置发送所述第一消息。
9.根据权利要求8所述的去服务器化系统,其特征在于,
所述路由装置用于:
从所述调度装置获取所述与所述第一状态实例的标识对应的所述消息管理装置的地址;或者,
从所述地址管理装置获取与第一状态实例的标识对应的所述消息管理装置的地址。
10.根据权利要求2-9任一项所述的去服务器化系统,其特征在于,所述消息管理装置位于所述多个工作节点中的一个工作节点上,所述调度装置位于所述去服务器化系统的控制节点上。
11.一种消息管理的方法,其特征在于,包括:
接收第一消息,所述第一消息用于指示调度第一有状态函数操作第一状态实例;
将所述第一消息存入与所述第一状态实例对应的第一消息队列,所述第一消息队列用于存储多个消息,每个所述消息用于指示一个有状态函数操作所述第一状态实例;
将第二消息,传递给所述第二消息对应的第二有状态函数,并运行所述第二消息对应的所述第二有状态函数操作处于空闲状态的所述第一状态实例,其中,所述第二消息为位于所述第一消息队列最前端的消息。
12.根据权利要求11所述的方法,其特征在于,所述方法还包括:
相对于所述第一消息队列,并行将位于第二消息队列最前端的第三消息,传递给所述第三有状态函数,并运行所述第三有状态函数操作处于空闲状态的第二状态实例,所述第二消息队列与所述第二状态实例对应。
13.根据权利要求12所述的方法,其特征在于,所述方法还包括:
在所述第一消息队列和所述第二消息队列中的消息都调度完毕后,并行将位于第三消息队列最前端的第四消息,传递给所述第四有状态函数,并运行所述第四有状态函数操作处于空闲状态的第一状态实例和第二状态实例,所述第三消息队列与所述第一状态实例和所述第二状态实例对应,所述第四有状态函数的调度顺序位于所述第一有状态函数、所述第二有状态函数和所述第三有状态函数之后。
14.一种消息管理的方法,其特征在于,所述方法应用于去服务器化系统,所述去服务器化系统包括消息管理装置、路由装置、调度装置和多个工作节点,所述方法包括:
接收所述路由装置发送的地址请求,所述地址请求包括第一状态实例的标识;
根据所述第一状态实例的标识,在所述多个工作节点中的第一工作节点上部署所述第一状态实例;
建立所述第一状态实例的标识与所述消息管理装置的地址的对应关系,所述消息管理装置与所述第一工作节点对应。
15.根据权利要求14所述的方法,其特征在于,所述方法还包括:
将部署在第二工作节点上的所述第一有状态函数,迁移到所述第一工作节点上,所述第一有状态函数的迁移代价小于所述第一状态实例的迁移代价。
16.根据权利要求14或15所述的方法,其特征在于,所述地址请求中还包括所述第一有状态函数的函数名;
所述第一工作节点是根据所述多个工作节点的负载信息、所述第一状态实例的大小,以及至少两个有状态函数的需求策略确定的,所述至少两个有状态函数位于与所述第一有状态函数的函数名相关联的函数业务组中;或者,
所述第一工作节点是所述多个工作节点中总分数最高的工作节点,一个工作节点的总分数与所述工作节点的计算资源、存储资源或是否已部署至少两个状态函数相关,所述至少两个有状态函数位于与所述第一有状态函数的函数名相关联的函数业务组中。
17.根据权利要求14-16任一项所述的方法,其特征在于,所述去服务器化系统还包括地址管理装置,所述方法还包括:
向所述地址管理装置发送所述第一状态实例的标识与所述消息管理装置的地址的对应关系。
18.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求11-13任一项所述的方法。
19.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求14-17任一项所述的方法。
20.一种计算设备,其特征在于,包括处理器和存储有计算机程序的计算机可读存储介质;
所述处理器与所述计算机可读存储介质耦合,所述计算机程序被所述处理器执行时实现如权利要求11-13任一项所述的方法。
21.一种计算设备,其特征在于,包括处理器和存储有计算机程序的计算机可读存储介质;
所述处理器与所述计算机可读存储介质耦合,所述计算机程序被所述处理器执行时实现如权利要求14-17任一项所述的方法。
22.一种芯片系统,其特征在于,包括处理器,所述处理器被调用用于执行如权利要求11-13任一项所述的方法。
23.一种芯片系统,其特征在于,包括处理器,所述处理器被调用用于执行如权利要求14-17任一项所述的方法。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010823536.9A CN114077504A (zh) | 2020-08-13 | 2020-08-13 | 一种消息管理的方法、装置及去服务器化系统 |
EP21855093.7A EP4191413A4 (en) | 2020-08-13 | 2021-03-23 | MESSAGE MANAGEMENT METHOD, APPARATUS AND SERVERLESS SYSTEM |
PCT/CN2021/082229 WO2022033037A1 (zh) | 2020-08-13 | 2021-03-23 | 一种消息管理的方法、装置及去服务器化系统 |
US18/168,203 US20230195546A1 (en) | 2020-08-13 | 2023-02-13 | Message Management Method and Apparatus, and Serverless System |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010823536.9A CN114077504A (zh) | 2020-08-13 | 2020-08-13 | 一种消息管理的方法、装置及去服务器化系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114077504A true CN114077504A (zh) | 2022-02-22 |
Family
ID=80247460
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010823536.9A Pending CN114077504A (zh) | 2020-08-13 | 2020-08-13 | 一种消息管理的方法、装置及去服务器化系统 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20230195546A1 (zh) |
EP (1) | EP4191413A4 (zh) |
CN (1) | CN114077504A (zh) |
WO (1) | WO2022033037A1 (zh) |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102904961A (zh) * | 2012-10-22 | 2013-01-30 | 浪潮(北京)电子信息产业有限公司 | 一种云计算资源调度方法及系统 |
CN105187327A (zh) * | 2015-08-14 | 2015-12-23 | 广东能龙教育股份有限公司 | 一种分布式消息队列中间件 |
US10361985B1 (en) * | 2016-09-22 | 2019-07-23 | Amazon Technologies, Inc. | Message processing using messaging services |
CN108121608A (zh) * | 2016-11-29 | 2018-06-05 | 杭州华为数字技术有限公司 | 一种队列调度方法以及节点设备 |
US10733018B2 (en) * | 2018-04-27 | 2020-08-04 | Paypal, Inc. | Systems and methods for providing services in a stateless application framework |
US20190377604A1 (en) * | 2018-06-11 | 2019-12-12 | Nuweba Labs Ltd. | Scalable function as a service platform |
CN110401696B (zh) * | 2019-06-18 | 2020-11-06 | 华为技术有限公司 | 一种去中心化处理的方法、通信代理、主机以及存储介质 |
-
2020
- 2020-08-13 CN CN202010823536.9A patent/CN114077504A/zh active Pending
-
2021
- 2021-03-23 WO PCT/CN2021/082229 patent/WO2022033037A1/zh unknown
- 2021-03-23 EP EP21855093.7A patent/EP4191413A4/en active Pending
-
2023
- 2023-02-13 US US18/168,203 patent/US20230195546A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
EP4191413A4 (en) | 2023-11-01 |
EP4191413A1 (en) | 2023-06-07 |
WO2022033037A1 (zh) | 2022-02-17 |
US20230195546A1 (en) | 2023-06-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3073374B1 (en) | Thread creation method, service request processing method and related device | |
CN115328663B (zh) | 基于PaaS平台进行资源调度的方法、装置、设备和存储介质 | |
CN106371894B (zh) | 一种配置方法、装置和数据处理服务器 | |
US11347546B2 (en) | Task scheduling method and device, and computer storage medium | |
CN107577534A (zh) | 一种资源调度方法及装置 | |
CN114327843A (zh) | 任务调度方法及装置 | |
CN111427675A (zh) | 一种数据处理方法、装置以及计算机可读存储介质 | |
CN114168302A (zh) | 任务调度方法、装置、设备及存储介质 | |
CN115167996A (zh) | 调度方法及装置、芯片、电子设备及存储介质 | |
CN114546587A (zh) | 一种在线图像识别服务的扩缩容方法及相关装置 | |
CN114625533A (zh) | 分布式任务调度方法、装置、电子设备及存储介质 | |
JP2008107966A (ja) | 計算機システム | |
US11042413B1 (en) | Dynamic allocation of FPGA resources | |
CN111338769A (zh) | 一种数据处理方法、装置及计算机可读存储介质 | |
CN116069493A (zh) | 一种数据处理方法、装置、设备以及可读存储介质 | |
CN112073532B (zh) | 一种资源分配的方法及装置 | |
Wu et al. | ABP scheduler: Speeding up service spread in docker swarm | |
CN110955461A (zh) | 计算任务的处理方法、装置、系统、服务器和存储介质 | |
CN114077504A (zh) | 一种消息管理的方法、装置及去服务器化系统 | |
CN115964152A (zh) | Gpu资源调度方法、设备和存储介质 | |
CN115941709A (zh) | 一种基面向多可用区存储的用户协同方法及系统和存储介质 | |
CN107562510B (zh) | 一种应用实例的管理方法及管理设备 | |
CN113254143B (zh) | 虚拟化网络功能网元编排调度方法、装置和系统 | |
US11797342B2 (en) | Method and supporting node for supporting process scheduling in a cloud system | |
CN112015515B (zh) | 一种虚拟网络功能的实例化方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |