一种资源调度方法及装置与流程

本发明涉及数据处理领域，具体而言，涉及一种资源调度方法及装置。

背景技术：

目前市场上微服务开发模式大致分为springcloud体系和service-mesh体系，提供的能力主要包括：

注册中心，用于提供服务的注册和发现，健康检查，故障转移的功能。

熔断降级，在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，此种情况下需要整个服务机构具备故障隔离的能力，避免某个服务异常影响全局。

配置中心，随着微服务不断增多，每个服务器都有自己的对应的配置文件，配置文件太多不容易管理，需要抽离出来做单独的服务进行管理。

服务网关，为了简化前端的调用逻辑，提供轻量级网关，实现服务的认证，授权，路由，限流等逻辑能力。

链路跟踪，随着服务越来越多，服务之间的调用关系，某个请求的调用链，调用之间的耗时等都需要形成监控，以便更好的发现系统中的问题。

其他的诸如负载均衡，灰度发布等等能力。

在springcloud体系下，这些能力是需要侵入到系统内部的，以硬编码的方式提供能力，非java开发的系统无法使用。

鉴于每个系统都涉及到以上功能的开发，所以诞生了service-mesh一种新的解决方案。service-mesh方案提供了一种独立于原有应用系统运行的方式，通过sidecar的方式，在原有系统的宿主机上部署一套代理程序，接管该服务的出入流量，多个代理之间互相连接，形成一套网络通讯。所有的代理被中心端的控制面接管，控制面负责给代理分发限流，路由，鉴权，日志等等规则，代理端通过解析规则，代理转发原有系统的流量，实现了对原有系统的无侵入性，同时支持多种编程语言。service-mesh的出现，使得开发业务功能时，不需要考虑太多跟服务治理相关的内容，只需要专注于业务逻辑开发即可，极大的减少了开发复杂度。

上述微服务开发模式下，服务器资源利用率低。目前每个应用申请一个虚拟机或者物理机，但是中央处理器cpu使用率只有6％-12％，内存的利用率基本在50％以下，且异地灾备机房的使用率不高。随着新系统不断增多，机房难以容纳下更多的机器，使得企业不得已搭建异地机房，使得企业的成本不断上升。成果不能共享，目前各个系统独立开发，有一大部分功能都涉及重复开发，例如用户管理，权限管理，加密规则，邮件服务等等，每个系统都会开发一份，从全局视角来看，这部分工作涉及重复建设，且如果有升级需求的时候，波及的面比较广，给系统升级带来风险。

针对相关技术中微服务开发模式的服务器资源利用率低，且不能共享的问题，尚未提出解决方案。

技术实现要素：

本发明实施例提供了一种资源调度方法及装置，以至少解决相关技术中微服务开发模式的服务器资源利用率低，且不能共享的问题。

根据本发明的一个实施例，提供了一种资源调度方法，应用于平台，包括：

将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；

通过所述多个函数对所述微服务的接口进行部署；

根据所述多个函数进行资源调度。

可选地，通过所述多个函数对所述微服务的接口进行部署包括：

接收完成编辑后上传的所述多个函数的函数代码，并获取上传所述多个函数时选择的运行时框架；

根据所述函数代码与对应的所述运行时框架生成所述多个函数，并存储所述多个函数；

分别配置所述多个函数的运行时属性,完成所述多个函数的部署。

可选地，分别配置所述多个函数的运行时属性,完成所述多个函数的部署包括：

将所述多个函数中的每个函数的运行时属性抽象为一个功能对象；

对所述功能对象进行监控。

可选地，在分别配置所述多个函数的运行时属性,完成所述多个函数的部署之后，所述方法还包括：

接收通过对所述功能对象进行监控确定资源存在更新时触发的通知消息；

根据所述通知消息对所述多个函数进行更新。

可选地，在分别配置所述多个函数的运行时属性,完成所述多个函数的部署之后，所述方法还包括：

为所述多个函数设置初始化接口，通过所述初始化接口执行所述多个函数的函数代码，并生成所述多个函数的函数实例；

为所述多个函数设置调用接口，通过所述调用接口调用所述多个函数的函数实例；

为所述多个函数设置销毁接口，若所述多个函数中的目标函数在预设时间段内未被调用，通过所述销毁接口销毁所述目标函数初始化时的函数实例。

可选地，在通过所述多个函数对所述微服务的接口进行部署之后，所述方法还包括：

通过函数编排的功能，控制所述多个函数的部分函数协同完成一个或多个业务逻辑。

可选地，所述方法还包括：

接收检测到目标函数的运行时资源满足预设规则时发起的告警信息，其中，所述告警信息中携带有告警类型；

在所述告警类型为扩容告警的情况下，判断所述目标函数运行时函数实例的数量是否大于或等于预设阈值；

在判断结果为否的情况下，判断当前告警信息的发生频率是否大于预设频率阈值；

在判断结果为否的情况下，对所述目标函数进行扩容处理；

在所述告警类型为缩容告警的情况下，判断在预定时间内所述目标函数是否被访问；

在判断结果为否的情况下，对所述目标函数进行缩容处理。

可选地，在通过所述多个函数对所述微服务的接口进行部署之后，所述方法还包括：

接收触发提前调整所述多个函数的函数实例数量的触发指令；

根据所述触发指令对所述多个函数的使用情况进行分析；

在所述流量高峰发生前预设时间调整所述多个函数的函数实例数量。

可选地，在所述流量高峰发生前预设时间调整所述多个函数的函数实例数量之后，所述方法还包括：

接收调用所述多个函数的调用请求；

基于负载均衡，将所述调用请求路由到所述多个函数的函数实例中。

可选地，所述方法还包括：

当检测到目标函数实例出现宕机或不可用的情况下，生成一个新的函数实例；

将所述目标函数实例重路由到所述新的函数实例中。

根据本发明的另一个实施例，还提供了一种资源调度装置，应用于平台，包括：

封装模块，用于将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；

部署模块，用于通过所述多个函数对所述微服务的接口进行部署；

资源调度模块，用于根据所述多个函数进行资源调度。

可选地，所述部署模块包括：

获取子模块，用于接收完成编辑后上传的所述多个函数的函数代码，并获取上传所述多个函数时选择的运行时框架；

生成子模块，用于根据所述函数代码与对应的所述运行时框架生成所述多个函数，并存储所述多个函数；

配置子模块，用于分别配置所述多个函数的运行时属性,完成所述多个函数的部署。

可选地，所述配置子模块包括：

抽象单元，用于将所述多个函数中的每个函数的运行时属性抽象为一个功能对象；

监控单元，用于对所述功能对象进行监控。

可选地，所述装置还包括：

接收子模块，用于接收通过对所述功能对象进行监控确定资源存在更新时触发的通知消息；

更新子模块，用于根据所述通知消息对所述多个函数进行更新。

可选地，所述装置还包括：

执行子模块，用于为所述多个函数设置初始化接口，通过所述初始化接口执行所述多个函数的函数代码，并生成所述多个函数的函数实例；

调用子模块，用于为所述多个函数设置调用接口，通过所述调用接口调用所述多个函数的函数实例；

销毁子模块，用于为所述多个函数设置销毁接口，若所述多个函数中的目标函数在预设时间段内未被调用，通过所述销毁接口销毁所述目标函数初始化时的函数实例。

可选地，所述装置还包括：

控制模块，用于通过函数编排的功能，控制所述多个函数的部分函数协同完成一个或多个业务逻辑。

可选地，所述装置还包括：

第一接收模块，用于接收检测到目标函数的运行时资源满足预设规则时发起的告警信息，其中，所述告警信息中携带有告警类型；

第一判断模块，用于在所述告警类型为扩容告警的情况下，判断所述目标函数运行时函数实例的数量是否大于或等于预设阈值；

第二判断模块，用于在判断结果为否的情况下，判断当前告警信息的发生频率是否大于预设频率阈值；

扩容模块，用于在判断结果为否的情况下，对所述目标函数进行扩容处理；

第三判断模块，用于在所述告警类型为缩容告警的情况下，判断在预定时间内所述目标函数是否被访问；

缩容模块，用于在判断结果为否的情况下，对所述目标函数进行缩容处理。

可选地，所述装置还包括：

第二接收模块，用于接收触发提前调整所述多个函数的函数实例数量的触发指令；

分析模块，用于根据所述触发指令对所述多个函数的使用情况进行分析；

调整模块，用于在所述流量高峰发生前预设时间调整所述多个函数的函数实例数量。

可选地，所述装置还包括：

第三接收模块，用于接收调用所述多个函数的调用请求；

路由模块，用于基于负载均衡，将所述调用请求路由到所述多个函数的函数实例中。

可选地，所述装置还包括：

生成模块，用于当检测到目标函数实例出现宕机或不可用的情况下，生成一个新的函数实例；

重路由模块，用于将所述目标函数实例重路由到所述新的函数实例中。

根据本发明的又一个实施例，还提供了一种计算机可读的存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

通过本发明，将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；通过所述多个函数对所述微服务的接口进行部署；根据所述多个函数进行资源调度，可以解决相关技术中微服务开发模式的服务器资源利用率低，且不能共享的问题，将微服务封装为函数，统一管理微服务对应的多个函数，通过多个函数统一进行资源调度，提高了服务器资源利用率，且实现了开发结果可以共享的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例的资源调度方法的移动终端的硬件结构框图；

图2是根据本发明实施例的资源调度方法的流程图；

图3是根据本发明实施例的资源调度平台的示意图；

图4是根据本发明实施例的函数基础运行时的示意图；

图5是根据本发明实施例的函数运行时属性部署的示意图；

图6是根据本发明实施例的函数智能路由的示意图一；

图7是根据本发明实施例的函数智能路由的示意图二；

图8是根据本发明实施例的函数智能路由的示意图三；

图9是根据本发明实施例的函数智能路由的示意图四；

图10是根据本发明实施例的运维节点函数实例重路由的示意图一；

图11是根据本发明实施例的运维节点函数实例重路由的示意图二；

图12是根据本发明实施例的资源调度装置的框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

实施例1

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本发明实施例的资源调度方法的移动终端的硬件结构框图，如图1所示，移动终端可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)和用于存储数据的存储器104，可选地，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的资源调度方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(networkinterfacecontroller，简称为nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(radiofrequency，简称为rf)模块，其用于通过无线方式与互联网进行通讯。

在本实施例中提供了一种运行于上述移动终端或网络架构的资源调度方法，图2是根据本发明实施例的资源调度方法的流程图，如图2所示，应用于平台，该流程包括如下步骤：

步骤s202，将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；

步骤s204，通过所述多个函数对所述微服务的接口进行部署；

步骤s206，根据所述多个函数进行资源调度。

各个函数之间做到相互无依赖，可以做到函数的快速开发及测试。同时因为函数管理着数据，平台管理着函数，所以平台具备整合所有数据的能力，消除数据孤岛，可以助理企业更好的实现数字化转型。

通过上述步骤s202至s206，将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；通过所述多个函数对所述微服务的接口进行部署；根据所述多个函数进行资源调度，可以解决相关技术中微服务开发模式的服务器资源利用率低，且不能共享的问题，将微服务封装为函数，统一管理微服务对应的多个函数，通过多个函数统一进行资源调度，提高了服务器资源利用率，且实现了开发结果可以共享的效果。

本发明实施例中，上述步骤s202具体可以包括：接收完成编辑后上传的所述多个函数的函数代码，并获取上传所述多个函数时选择的运行时框架；根据所述函数代码与对应的所述运行时框架生成所述多个函数，并存储所述多个函数；分别配置所述多个函数的运行时属性,完成所述多个函数的部署，进一步的，将所述多个函数中的每个函数的运行时属性抽象为一个功能对象，对所述功能对象进行监控。

在一可选的实施例中，在分别配置所述多个函数的运行时属性,完成所述多个函数的部署之后，接收通过对所述功能对象进行监控确定资源存在更新时触发的通知消息；根据所述通知消息对所述多个函数进行更新，更新具体可以包括增加、删除、修改等。

在另一可选的实施例中，在分别配置所述多个函数的运行时属性,完成所述多个函数的部署之后，为所述多个函数设置初始化接口，通过所述初始化接口执行所述多个函数的函数代码，并生成所述多个函数的函数实例；为所述多个函数设置调用接口，通过所述调用接口调用所述多个函数的函数实例；为所述多个函数设置销毁接口，若所述多个函数中的目标函数在预设时间段内未被调用，通过所述销毁接口销毁所述目标函数初始化时的函数实例。

在另一可选的实施例中，在通过所述多个函数对所述微服务的接口进行部署之后，通过函数编排的功能，控制所述多个函数的部分函数协同完成一个或多个业务逻辑，在多个函数基础之上，提供函数编排的功能，使得多个函数可以协同完成各种业务逻辑，方便快速的打造适应市场变化的产品。例如，函数1对应的微服务是上传图像，函数2对应的微服务是打印图像，可以将函数1与函数2钢托函数编排，系统完成上传与打印图像。

本发明实施例中，基于智能调度系统，可以为函数提供动态伸缩的能力，在流量高峰动态申请计算资源，在洪峰退去的时候自动回收计算资源，从而做到服务器资源利用率的最大化，具体的，接收检测到目标函数的运行时资源满足预设规则时发起的告警信息，其中，所述告警信息中携带有告警类型；在所述告警类型为扩容告警的情况下，判断所述目标函数运行时函数实例的数量是否大于或等于预设阈值；在判断结果为否的情况下，判断当前告警信息的发生频率是否大于预设频率阈值；在判断结果为否的情况下，对所述目标函数进行扩容处理；在所述告警类型为缩容告警的情况下，判断在预定时间内所述目标函数是否被访问；在判断结果为否的情况下，对所述目标函数进行缩容处理，即根据告警信息进行扩缩容处理。

在一可选的实施例中，在自动扩缩容的能力之上，平台维护了一套预警感知的能力，即通过各函数的使用情况分析，以及外部活动的经验值，提前在洪峰到来前的预设时间(例如10分钟)内，通过上述接口，动态的调整函数实例个数，来满足大量的并发请求。该部分操作由运维人员手工发起，具体的，在通过所述多个函数对所述微服务的接口进行部署之后，接收触发提前调整所述多个函数的函数实例数量的触发指令；根据所述触发指令对所述多个函数的使用情况进行分析；在所述流量高峰发生前预设时间调整所述多个函数的函数实例数量。

在另一可选的实施例中，在所述流量高峰发生前预设时间调整所述多个函数的函数实例数量之后，接收调用所述多个函数的调用请求，基于负载均衡，将所述调用请求路由到所述多个函数的函数实例中。

在另一可选的实施例中，当检测到目标函数实例出现宕机或不可用的情况下，生成一个新的函数实例，具体可以通过kubernetes生成新的函数实例；将所述目标函数实例重路由到所述新的函数实例中。

本发明实施例构造一套集开发，测试，运行，运维于一身的综合性研发平台，平台将微服务细化到接口级别，即：每个微服务的接口都作为一个独立可运行的服务(以下简称函数)，部署在平台中。平台底层采用开源的kubernetes调度系统，所有的服务都运行在kubernetes的pod中。图3是根据本发明实施例的资源调度平台的示意图，如图3所示，函数是一个独立可以运行的个体，不依赖于其他函数，每个函数完成一个业务功能，通过注册，纳入到平台中管理起来，提供统一的访问入口以及自定义的触发器入口来访问该函数。因为对外暴露的是一个服务，所以只需要完成业务功能的开发即可，因此可以做到不依赖于编程语言。函数即可以用java实现，也可以使用nodejs实现，也可以用python实现，开发人员只需要按照不同语言的编写文档，开发出一个可以运行的函数出来即可。随着平台的不断丰富，未来将支持多种编程语言。

为了简化函数的开发，平台内置了一些基础的函数运行时(runtime)，例如java函数运行时需要jdk,某些函数需要spring框架，某些函数需要jetty框架，不同的函数有不同的需求，平台无法为所有的函数提供大而全的运行时支撑，只能提供一些相对较为基础的运行时框架。随着平台的能力提升，未来将覆盖全编程语言的运行时。目前提供的运行时信息用：

java-with-jetty提供了jetty运行时框架，开发人员可以直接使用jetty的能力进行输入和输出编程。

java-with-spring提供了spring运行时框架，开发人员可以直接使用spring的能力进行输入和输出编程。

nodejs-with-express提供了express运行时框架。

python-with-flask提供了flask运行时框架。

开发人员编写函数时，只需要下载合适的运行时基础sdk包，然后进行函数的编写，函数如果需要依赖其他的类库，可以直接和函数一起打包到zip压缩包中去，最终上传到平台保存。这里需要注意的是，基础的运行时信息无须打包，平台在运行时会自动拉取基础运行时镜像。zip包中的信息包括用户自行开发的函数信息以及函数运行时依赖的一些类库，资源等信息。

在此之上，基础运行时对外提供统一的超文本传输协议(hypertexttransferproctor，简称为http)通讯服务，监听固定的端口，接收外部的访问请求，平台为基础运行时抽取了三个接口：

函数初始化接口(init)。用于在运行时动态的加载用户编写的函数代码，减少函数冷启动时间。基础运行时启动之后，监听http端口，当接收到函数初始化请求时，会在指定目录下寻找用户编写的函数代码，通过动态加载机制，把函数加载到内存中，产生一个函数的示例或者一个可调用的对象。动态加载机制，在不同的运行时下，有不同的试下方式，在java下采用自定义classloader的方式加载，在c++下采用动态链接库的方式加载，在golang下采用plugins机制加载，在nodejs下可以直接require加载。

函数调用接口(invoke)。在函数初始化过后，函数的实例已经加载完毕，当接收到invoke请求时，函数将执行函数代码，处理输入和输出信息，将结果同步或者异步的方式返回给调用方。

函数销毁接口(destroy)，当函数在一定的时间段内没有被调用，函数初始化时的实例将会被平台自动销毁，在销毁前回调该url，开发人员可以实现该接口完成自定义的资源释放操作。

图4是根据本发明实施例的函数基础运行时的示意图，如图4所示，基础运行时提供的是runtime机制，而不是exec机制。两者的区别在于，exec模式是运行时生成函数实例，函数执行，函数销毁。这将导致每个函数被调用前都会有初始化和销毁的动作，会有一定的时间开销。而采用runtime机制之后，初始化和销毁仅仅执行一次，之后无论发起多少次调用，都将共享同一个函数实例，避免了多次无谓的初始化操作和销毁操作。同时因为函数实例被多个线程共享，开发时需要特别注意并发的问题。

平台提供多语言的编程软件开发工具包(softwaredevelopmentkit，简称为sdk)，开发人员首先下载sdk或者按照开发文档编写函数信息，请注意，这里的函数仅仅只需要完成一个业务功能的开发即可，如果一个应用需要多个接口，则需要开发多个函数来满足，而不是使用一个函数来实现全部功能。

开发人员选择自己擅长的编程技术，进行函数内容的编写，开发过程中如果需要依赖其他库，则需要提前下载好库文件，最终打包的时候将库文件信息和函数代码打在一个压缩包中。保证所需要的资源都能够在压缩包中被找到。

基础运行时提供了一些上下文信息，供函数使用。目前提供的上下文(context)信息有：

获取当前函数调用请求的唯一标识id；

获取函数使用的日志对象；

获取函数使用的授权信息；

获取函数的版本号，方法名称，作者等元信息；

获取客户端的请求信息，例如客户端ip，头信息等；

获取函数使用的环境变量；

不同语言的函数签名不同。

在java语言中，函数需要实现requesthandler接口或者requeststreamhandler接口，实现函数的内容即可。

在nodejs编程中，可以使用module.exports＝function(context,callback){}来编写代码。具体的实现需要参考开发文档。

在构建阶段，开发人员需要完成函数代码的编写，执行构建命令，不同的语言提供不同的构建方法，例如java中提供maven一键构建，其他语言提供集成开发环境(integrateddevelopmentenvironment，简称为ide)构建，最终将函数信息和依赖的库资源，图片等静态资源压缩成为一个zip包。至此开发工作完成。

从开发过程上来看，函数运行时的基础信息，由平台开发人员提供。

而开发一个函数所需要的步骤相对较少，只需要按照规范，填写函数内容既可。

对于企业来说，可以很轻松的开发出大量的实用函数。非常明显的缩短交付周期。

在函数编写完成之后，可以通过web控制台，命令行，和ide集成工具，将打好的zip包上传到平台，然后配置函数的运行时属性,从而完成函数的部署。

函数配置的运行时属性有：

函数的名称，用于标识当前用户下的唯一的函数名称；

函数的版本号，递增，用于描述当前函数的版本信息，用于灰度发布和版本回退；

函数的基础运行时环境，用于给函数提供运行时的支撑；

函数的标签，方便检索；

函数的描述信息，方便用户了解函数的用途；

函数的内存资源限制，标识允许使用的最大内存，超过该内存之后，函数会被杀死；

函数的环境变量，由用户自定义一些属性，供函数访问使用；

函数的运行时角色，定义了该函数可以被什么样的角色访问，用于权限控制；

函数的入口，指定zip包中函数的入口函数名称，平台运行时将以此为入口进行访问；

函数的最大实例数，指定了函数动态扩容的时候的最大值，无需指定最小值，默认是0；

函数的最大并发数，指定了一个函数可以同时支持的最大并发数量；

函数的最大执行时间，超过这个时间函数没有执行成功，会被平台杀死；

函数代码包，用户上传到云存储之后，返回的唯一标识码；

函数的执行计划，主要分别在于函数是否对冷启动时间敏感；

函数的负载均衡策略，主要用于函数实例的负载均衡。

以上属性，在平台中被抽象成为一个function对象，该对象描述了函数的所有的元信息，作为kubernetes的自定义资源类型的实现。最终序列化为json，保存到kubernetes的分布式存储组件etcd中。

平台启动的时候，会从etcd中获取自定义的crd资源对象，并通过kubernetes的listandwatch机制，对function对象进行监控，一旦资源在etcd里有更新，那么平台就会收到通知，对应执行addfunc,deletefunc,updatefunc的三个方法来进行函数的增加，删除，修改的处理操作。

平台发现有新增的function对象的时候，会提取function的对象信息，将以上的配置信息构建成为kubernetes里的一个deployment对象，然后提交给kubernetes调度运行起来。具体的转换规则是：

将函数的作者，用户名和版本号三个信息，绑定到一起形成deployment对象的name属性。

将函数的执行计划，环境变量，函数作者，命名空间，标签，描述信息，最大实例数，角色，入口，执行时间等属性，绑定到deployment对象的annotation属性，作为一些描述信息来使用。

deployment对象会构造两个容器，其中一个用来下载用户的自定义函数代码，另外一个用于在运行时拉起用户函数的实例。

1.下载容器为平台内置的容器，作用是和用户函数容器共享同一个pod，这样可以共享同一个数据卷，该容器作为用户容器的前置条件，首先启动一个http端口，接收外部下载的请求，然后读取请求参数，根据参数中的请求函数的信息，从云存储上把用户开发的函数代码压缩包下载到本地卷中，并解压。如果由于某些原因没有下载成功，可以尝试重试3次，如果依然不成功，则宣告该函数构建失败。

2.function的基础镜像信息与用户函数容器的image属性绑定，镜像拉取策略为ifnotpresent。

3.function的内存属性与deployment的resource属性绑定。

最终根据function的属性，构造出一个deployment对象，提交给kubernetes之后，该对象就会根据deployment的信息自动拉起用户函数的pod，从而让函数真正的运行起来，其中，pod是函数运行的载体，是一个集装箱，他有函数运行所需的所有资源，是kubernetes里调用的最小单元。函数最终会被导报称为一个pod，交给kubernetes平台。

图5是根据本发明实施例的函数运行时属性部署的示意图，如图5所示，在创建deployment的同时，平台也会为该deployment创建一个service对象和一个水平自动伸缩对象，service对象用于对外暴露函数的访问地址，同时提供简单负载均衡的能力。水平自动伸缩用于探测函数的使用资源，如果超过一定的资源限制之后，会自动的横向扩容，这些能力依赖kubernetes自身的能力。平台做的事情，就是把function对象转换为kubernetes里的控制器能够识别的数据结构。

函数在经过部署之后，已经可以在kubernetes中运行，平台为这些函数赋予了动态伸缩和智能路由的能力。

平台为函数实例构造了一个可靠的监控预警系统，度量函数容器实例的运行时资源，包括但不限于中央处理器(centralprocessingunit，简称为cpu)使用率，内存利用率，错误访问率，超时访问率，错误访问次数，超时访问次数，总耗时时间等。该类监控信息通过开源软件prometheus来抓取数据，并进行实时分析。当被监控数据，到达了预先制定的阈值或者满足指定的规则之后，会自动触发altertmanager来进行告警处理。在告警策略里，平台会根据不同类型的告警，做出相应的扩缩容动作。触发规则采用prometheus自带的promql来完成。

平台接收到prometheus扩容告警之后，做一下判断：

当前告警的函数运行时实例数是否达到最大值，超过最大值之后，本次扩容请求拒绝。

判断当前告警信息发生的频率，是否在预期之内，如果超越预期阈值(可配置)，则需要进行人工处理，来决定是否需要扩容，还是异常导致的非法扩容。

计算目标副本数量，通过监控信息和实际运行时需要，计算出来合理的副本数量。

修改kubernetes中函数对应deployment的副本数量，达到扩容的目的。

平台启动后台线程，监听所有的函数实例，当函数实例在2分钟内没有访问的情况下，会调用kubernetes的api，直接修改函数对应的deployment的副本数量为0，释放所有的计算资源。

当函数实例数量为0的时候，下次请求进入的时候，会首先调整实例数量为1，从而拉起函数实例来使用。

在自动扩缩容的能力之上，平台维护了一套预警感知的能力，即通过各函数的使用情况分析，以及外部活动的经验值，提前在洪峰到来前的10分钟内，通过上述接口，动态的调整函数实例个数，来满足大量的并发请求。该部分操作由运维人员手工发起。

平台管理着所有函数的实例副本，在外部访问调用的时候，首先进入智能路由节点，该节点通过一系列的规则计算，选择出最合适运行本次访问请求的函数实例进行转发，完成负载均衡的目的。

平台支持的路由策略有：随机转发、顺序轮询、连接池负载、就近路由等。

图6是根据本发明实施例的函数智能路由的示意图一，如图6所示，随机转发，将调用请求随机发送到某一个函数实例上。

图7是根据本发明实施例的函数智能路由的示意图二，如图7所示，顺序轮询，将调用请求按照递增求余的方式选择一个函数实例。

图8是根据本发明实施例的函数智能路由的示意图三，如图8所示，连接池负载，原理同数据库连接池，首先从函数实例中选择一个尚未被使用的函数实例进行随机转发，然后标记该函数的使用状态为“使用中”，下次请求到来时，不再选择使用“使用中”的函数实例，从而选择尚未使用的函数实例。如果所有的函数实例都处于“使用中”的状态，则函数请求进入等待状态，直到函数使用状态变更后，再次唤醒，从而路由到合适的函数实例上。

图9是根据本发明实施例的函数智能路由的示意图四，如图9所示，就近路由，选择与请求发出方最为接近的函数实例运行。

函数在创建的时候应该指定一种负载策略，在运行时平台会判断，当前函数实例支持的最大并发数量，如果当前并发超过阈值，则本次请求直接需要加入到事件队列，等待出队。在等待队列充满之后，直接进行降级处理。

函数实例配置完成之后，已经可以在平台中调度运行，平台支持给函数设置不同的触发器，通过不同的方式来调用该函数。目前平台提供的触发器有：

通过应用程序编程接口(applicationprogramminginterface，简称为api)触发，即通过http或者https的方式请求函数url触发；

通过定时任务触发，可以配置cron表达式，与linux相同的规则；

通过消息队列触发，通过从消息队列中获取到消息之后，调用函数实例。

针对api触发方式，平台维护了各个函数和路由的对应关系，通过自定义kubernetes的crd(customresourcedefinition)的httptrigger方式来实现，原理同function对象一致。平台监听httptrigger的变化，发现有增加，删除，修改的时候，重新建立路由的绑定关系，存储到路由表中。待请求到来的时候，从路由表中获取请求路径对应的函数实例的路径，从而完成数据转发。

针对定时任务触发的方式，平台提供了cron表达式，支持范围触发，周期触发，定时触发等。通过自定义kubernetes的crd的timetrigger的方式来实现。监听timetrigger的变化，一旦有变化，则重建cron表达式和函数的绑定关系，停止旧的cron表达式，开启新的表达式。

针对消息队列的触发方式，平台给指定的消息队列增加订阅，当收到消息的时候，从消息中解析出调用的函数的信息，然后平台构造出标准的api请求方式，后续调用方式同api触发方式。

运维阶段，平台构建在kubernetes基础之上，通过deployment的方式进行管理，当函数实例出现宕机或者不可用的情况下，kubernetes会自动拉起一个新的函数实例。

在灰度发布情况下，可以通过对触发器配置流量比例的方式来进行，图10是根据本发明实施例的运维节点函数实例重路由的示意图一，如图10所示，平台配置触发器的属性，增加流量比例规则，例如10％到v2版本，90％到v1版本。

图11是根据本发明实施例的运维节点函数实例重路由的示意图二，如图11所示，函数访问请求流量全部打到平台的router节点上，然后router节点根据触发器配置的比例，通过加权随机的算法，将路由按照比例分配到不同的函数实例上，通过函数实例的智能路由算法，再进行负载均衡。

在实际企业的生产中，一个函数并不能完整的完成一个业务功能，更多的情况是需要多个函数通过流程编排的方式，协同工作，完成一个业务功能。平台支持通过可视化编辑流程文件的方式来完成。以下称为函数工作流。

函数工作流负责编排目前已经有的函数信息，通过api触发器的方式访问函数。平台目前采用的是xml格式的描述文件，描述了函数的调用关系。

平台提供了11种类型的节点，未来随着平台的演进，会提供更多类型的节点：

1，start、end节点，表示流程的开始和结束

2，succeed，fail节点，表示流程的成功终止和异常终止

3，task节点，表示要调用的是平台中的函数，通过api的方式触发4，wait节点，表示当前节点需要等待一段时间之后再继续运行

5，choice节点，表示当前节点需要进行一段运算，得到结果之后决定向哪个分支流转

6，parallel节点，表示当前是一个并发执行的节点，可以同时调用多个任务，多个任务的协同关系可以有all,any，以及自定义的回调函数来协同。分别表示当子任务全部结束时，任意一个子任务结束时，以及特定状态下的时候，parallel节点继续向下运行。

7，catch节点表示流程的回退策略，当遇到特定的异常的情况下，捕获到异常，根据不同的异常，选择不同的分支节点处理。

8，retry表示节点如果出现异常的情况下，可以选择的重试策略

9，map表示当前任务进行mapreduce任务切分，这里需要指定切分的规则函数

10，childflow表示当前任务是一个子流程，子流程是一个完整的工作流任务。

11，human表示是一个人工节点，需要人工介入之后，流程才能得以继续运行。

各个节点之间通过json的数据结构传递上下文信息。函数工作流在执行的时候接收完整的json输入请求，将json传递给第一个流程节点，上一个节点的输出值作为第二个节点的输入值，依次进行流程传递，直到流程终止，最后一个节点的输出值，作为整个流程的输出值。

各个节点可以对输入和输出的数据进行增加，修改删除等操作，平台提供了jsonpath的描述语言进行处理。

各个节点之间支持分布式事务的编排方式，各个节点的调用采用完全异步的方式运行，每一个流程的执行步骤都被纳入到平台中进行管理，每一个步骤的运行时元信息，都被平台记录，例如工作流的开始时间，节点运行时间，每个节点的输入参数，每个节点的输出参数，每个节点的耗时情况，异常情况等，都会记录到平台数据库中，方便监控和查询。平台提供在线的可视化执行过程跟踪，每执行一个节点，web控制台都可以收到平台发出的流程消息，从而可以实时的更新工作流的状态节点，给用户一个进度提示。

本发明实施例，由于平台提供了动态扩缩容机制和智能路由机制，使得系统的边界变得模糊，不再需要针对每个系统申请服务器，而是在运行时动态的为函数申请计算资源。这样一来，平台就可以利用全企业的计算资源，极大的降低企业的成本。由于函数集中管理，不同用户编写的函数可以被其他用户访问调用，达到了企业组织级共享的效果。函数单独开发，独立运行，对其他项目或者服务没有依赖，可以单独调试和单元测试，为快速开发和测试提供了极大的方便。平台管理着函数，函数管理着数据，相当于平台管理着企业的数据，通过流程编排的方式，很轻易的就可以提前企业的数据，为数字化转型提供数字支撑。通过流程编排的方式，发布一个新的业务，只需要通过可视化的编辑即可完成，充分利用现有的函数的能力，组合出不同的业务模式出来，适应市场的快速变化。智能路由，提供函数实例间的动态路由，负载均衡，以及连接池策略等。智能扩缩容，在自动扩缩容基础之上，利用大数据分析以及人工经验值，提前扩容，极大的降低了函数的冷启动时间。函数工作流编排，提供全异步高性能的编排引擎，扩展的jsonpath表达式操控数据，通过可视化编辑的方式开发业务逻辑。

实施例2

根据本发明的另一个实施例，还提供了一种资源调度装置，应用于平台，图12是根据本发明实施例的资源调度装置的框图，如图12所示，包括：

封装模块122，用于将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；

部署模块124，用于通过所述多个函数对所述微服务的接口进行部署；

资源调度模块126，用于根据所述多个函数进行资源调度。

可选地，所述部署模块124包括：

获取子模块，用于接收完成编辑后上传的所述多个函数的函数代码，并获取上传所述多个函数时选择的运行时框架；

生成子模块，用于根据所述函数代码与对应的所述运行时框架生成所述多个函数，并存储所述多个函数；

配置子模块，用于分别配置所述多个函数的运行时属性,完成所述多个函数的部署。

可选地，所述配置子模块包括：

抽象单元，用于将所述多个函数中的每个函数的运行时属性抽象为一个功能对象；

监控单元，用于对所述功能对象进行监控。

可选地，所述装置还包括：

接收子模块，用于接收通过对所述功能对象进行监控确定资源存在更新时触发的通知消息；

更新子模块，用于根据所述通知消息对所述多个函数进行更新。

可选地，所述装置还包括：

执行子模块，用于为所述多个函数设置初始化接口，通过所述初始化接口执行所述多个函数的函数代码，并生成所述多个函数的函数实例；

调用子模块，用于为所述多个函数设置调用接口，通过所述调用接口调用所述多个函数的函数实例；

销毁子模块，用于为所述多个函数设置销毁接口，若所述多个函数中的目标函数在预设时间段内未被调用，通过所述销毁接口销毁所述目标函数初始化时的函数实例。

可选地，所述装置还包括：

控制模块，用于通过函数编排的功能，控制所述多个函数的部分函数协同完成一个或多个业务逻辑。

可选地，所述装置还包括：

第一接收模块，用于接收检测到目标函数的运行时资源满足预设规则时发起的告警信息，其中，所述告警信息中携带有告警类型；

第一判断模块，用于在所述告警类型为扩容告警的情况下，判断所述目标函数运行时函数实例的数量是否大于或等于预设阈值；

第二判断模块，用于在判断结果为否的情况下，判断当前告警信息的发生频率是否大于预设频率阈值；

扩容模块，用于在判断结果为否的情况下，对所述目标函数进行扩容处理；

第三判断模块，用于在所述告警类型为缩容告警的情况下，判断在预定时间内所述目标函数是否被访问；

缩容模块，用于在判断结果为否的情况下，对所述目标函数进行缩容处理。

可选地，所述装置还包括：

第二接收模块，用于接收触发提前调整所述多个函数的函数实例数量的触发指令；

分析模块，用于根据所述触发指令对所述多个函数的使用情况进行分析；

调整模块，用于在所述流量高峰发生前预设时间调整所述多个函数的函数实例数量。

可选地，所述装置还包括：

第三接收模块，用于接收调用所述多个函数的调用请求；

路由模块，用于基于负载均衡，将所述调用请求路由到所述多个函数的函数实例中。

可选地，所述装置还包括：

生成模块，用于当检测到目标函数实例出现宕机或不可用的情况下，生成一个新的函数实例；

重路由模块，用于将所述目标函数实例重路由到所述新的函数实例中。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

实施例3

本发明的实施例还提供了一种计算机可读的存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

s1，将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；

s2，通过所述多个函数对所述微服务的接口进行部署；

s3，根据所述多个函数进行资源调度。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(read-onlymemory，简称为rom)、随机存取存储器(randomaccessmemory，简称为ram)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

实施例4

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

s1，将微服务的每个接口封装为一个函数，得到封装后的多个函数，其中，每个所述函数为可独立运行的服务，用于完成一个业务功能；

s2，通过所述多个函数对所述微服务的接口进行部署；

s3，根据所述多个函数进行资源调度。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。