CN116016644A - 业务请求处理方法、网络设备及计算机可读存储介质 - Google Patents

Abstract

本发明提供了一种业务请求处理方法、网络设备及计算机可读存储介质，其中，方法包括：接收由API网关发送的Serverless请求信息，Serverless请求信息由API网关从业务请求中获取，业务请求为对Serverless应用的实例的服务请求；在根据Serverless请求信息从Serverless架构中确定不存在Serverless应用的实例的情况下，根据Serverless请求信息确定目标应用信息和BaaS目标信息；根据BaaS目标信息启动与BaaS目标信息对应的BaaS代理组件；根据目标应用信息和BaaS代理组件激活Serverless应用，使得Serverless应用在接收到业务请求的情况下，通过BaaS代理组件与目标BaaS建立服务交互以处理业务请求。本发明实施例中，通过实现Serverless应用与BaaS代理组件的并行运行，能够降低Serverless应用的第一次启动耗时，满足Serverless应用的业务处理时效要求。

Description

业务请求处理方法、网络设备及计算机可读存储介质

技术领域

本发明实施例涉及但不限于云原生技术领域，尤其涉及一种业务请求处理方法、网络设备及计算机可读存储介质。

背景技术

随着云计算技术的不断发展，越来越多的企业将IT系统搬到了云上进行部署，同时为了降低系统在云上运行的成本和运维难度，越来越多系统在开发时会主动采用云原生技术，而无服务器Serverless技术作为云原生技术的重要构成，具体而言，Serverless技术是指用户在云服务器中创建和运行软件应用与服务，用户无需关心所涉及的IT设施相关的内容(如:管理、升级等)，其是IT架构进一步演化的产物，主要有以下特点：实现了细粒度的计算资源分配；不需要预先分配资源，无需配置和管理操作系统；具备真正意义上的高度扩容和弹性，支持按需伸缩；按需使用，按需计费。因此，Serverless技术在当前环境下被广泛采用。

目前，在Serverless技术下，为了减少业务程序在空闲时对云资源的占用，当没有业务请求时，将不会激活业务程序，而在接收到业务请求时，才由云平台将业务Serverless应用进行部署并激活，在这种情况下，对于以Serverless形态部署的应用，在处理第一个业务请求时会存在较大的时延，造成启动耗时变长，无法满足Serverless应用的业务处理时效要求。

发明内容

以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

本发明实施例提供了一种业务请求处理方法、网络设备及计算机可读存储介质，能够降低Serverless应用的第一次启动耗时，满足Serverless应用的业务处理时效要求。

第一方面，本发明实施例提供了一种业务请求处理方法，应用于无服务器Serverless架构中的Serverless应用管理装置，所述Serverless架构还包括应用程序编程接口API网关，所述方法包括：

接收由所述API网关发送的Serverless请求信息，其中，所述Serverless请求信息由所述API网关从接收到的业务请求中获取，所述业务请求为对Serverless应用的实例的服务请求；

在根据所述Serverless请求信息从所述Serverless架构中确定不存在所述Serverless应用的实例的情况下，根据所述Serverless请求信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的后端即服务BaaS目标信息；

根据所述BaaS目标信息启动与所述BaaS目标信息对应的BaaS代理组件；

根据所述目标应用信息和所述BaaS代理组件激活所述Serverless应用，使得：

所述Serverless应用在接收到由所述API网关发送的所述业务请求的情况下，通过所述BaaS代理组件与目标BaaS建立服务交互以处理所述业务请求，其中，所述目标BaaS对应于所述BaaS目标信息。

第二方面，本发明实施例提供了一种业务请求处理方法，应用于Serverless架构，所述Serverless架构包括Serverless应用管理装置和API网关，所述方法包括：

所述API网关从接收到的业务请求中获取Serverless请求信息，并向所述Serverless应用管理装置发送所述Serverless请求信息，其中，所述业务请求为对Serverless应用的实例的服务请求；

所述Serverless应用管理装置接收所述Serverless请求信息，并在根据所述Serverless请求信息从所述Serverless架构中确定不存在所述Serverless应用的实例的情况下，根据所述Serverless请求信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的BaaS目标信息；

所述Serverless应用管理装置根据所述BaaS目标信息启动与所述BaaS目标信息对应的BaaS代理组件，以及根据所述目标应用信息和所述BaaS代理组件激活所述Serverless应用，使得：

所述Serverless应用在接收到由所述API网关发送的所述业务请求的情况下，通过所述BaaS代理组件与目标BaaS建立服务交互以处理所述业务请求，其中，所述目标BaaS对应于所述BaaS目标信息。

第三方面，本发明实施例还提供了一种网络设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面和第二方面所述的业务请求处理方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行如第一方面和第二方面所述的业务请求处理方法。

本发明实施例包括：业务请求处理方法，应用于Serverless架构中的Serverless应用管理装置，Serverless架构还包括API网关和Serverless应用仓库，方法包括：接收由API网关发送的Serverless请求信息，其中，Serverless请求信息由API网关从接收到的业务请求中获取，业务请求为对Serverless应用的实例的服务请求；在根据Serverless请求信息从Serverless架构中确定不存在Serverless应用的实例的情况下，根据Serverless请求信息确定与Serverless应用对应的目标应用信息，以及，与Serverless应用匹配的BaaS目标信息；根据BaaS目标信息启动与BaaS目标信息对应的BaaS代理组件；根据目标应用信息和BaaS代理组件激活Serverless应用，使得：Serverless应用在接收到由API网关发送的业务请求的情况下，通过BaaS代理组件与目标BaaS建立服务交互以处理业务请求，其中，目标BaaS对应于BaaS目标信息。根据本发明实施例提供的方案，在确定不存在Serverless应用的实例的情况下，基于业务请求所携带的Serverless请求信息可以确定目标应用信息和BaaS目标信息，使得能够根据目标应用信息实现第一次启动Serverless应用，并且在第一次启动Serverless应用时，Serverless应用可以利用与BaaS目标信息对应的BaaS代理组件与目标BaaS建立服务交互，实现Serverless应用与BaaS代理组件的并行运行，从而能够降低Serverless应用的第一次启动耗时，满足Serverless应用的业务处理时效要求。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1是本发明一个实施例提供的用于执行业务请求处理方法的Serverless架构的示意图；

图2是本发明一个实施例提供的Serverless的原理示意图；

图3是本发明一个实施例提供的Serverless应用编排器的界面示意图；

图4是本发明一个实施例提供的业务请求处理方法的流程图；

图5是本发明一个实施例提供的业务请求处理方法中确定目标应用信息和BaaS目标信息的流程图；

图6是本发明一个实施例提供的业务请求处理方法中启动BaaS代理组件之前的流程图；

图7是相关技术中的云函数调用示意图；

图8是本发明一个实施例提供的业务请求处理方法中激活Serverless应用的流程图；

图9是本发明一个实施例提供的BaaS代理组件的示意图；

图10是本发明另一个实施例提供的业务请求处理方法的执行流程图；

图11是本发明一个实施例提供的业务请求处理方法中Serverless应用管理装置确定目标应用信息和BaaS目标信息的执行流程图；

图12是本发明一个实施例提供的业务请求处理方法中Serverless应用管理装置激活Serverless应用的流程图；

图13是本发明一个实施例提供的业务请求处理方法中Serverless应用管理装置启动BaaS代理组件之前的流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

需要注意的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

本发明提供了一种业务请求处理方法、网络设备及计算机可读存储介质，在确定不存在Serverless应用的实例的情况下，基于业务请求所携带的Serverless请求信息可以确定目标应用信息和后端即服务(BackendasaService,BaaS)目标信息，使得能够根据目标应用信息实现第一次启动Serverless应用，并且在第一次启动Serverless应用时，Serverless应用可以利用与BaaS目标信息对应的BaaS代理组件与目标BaaS建立服务交互，实现Serverless应用与BaaS代理组件的并行运行，从而能够降低Serverless应用的第一次启动耗时，满足Serverless应用的业务处理时效要求。

下面结合附图，对本发明实施例作进一步阐述。

如图1所示，图1是本发明一个实施例提供的用于执行业务请求处理方法的Serverless架构的示意图。

在图1的示例中，该Serverless架构包括但不限于：Serverless应用管理装置和API网关，其中，API网关作为Serverless架构中的接口，可以接收来自外部人员或系统的业务请求，Serverless应用管理装置作为Serverless架构中的控制端，可以配合Serverless架构中的其余部件实现生命周期管理，并且Serverless应用管理装置和API网关之间可以实现信息交互，例如，API网关通过Serverless应用管理装置查询应用地址、转发流程信息等。

在一实施例中，如图2所示，Serverless技术可以分为两部分内容，一部分为函数即服务(Function as a Service,FaaS),具有无服务函数功能，另一部分为BaaS，具有对象存储、云数据库、消息队列、网关接口以及Redis缓存等服务功能，集成各种服务，例如，可以包括但不限于为Kafka服务、MySQL服务、Redis服务以及其它特定服务等；其中，Serverless技术下的Serverless应用开发部署运行通用的工作流程如下：

步骤S101：业务开发人员完成无服务函数的开发；

步骤S102：业务开发人员将无服务函数上传到云平台的函数仓库中；

步骤S103：外部请求发送到应用程序编程接口API网关；

步骤S104：云平台将对应的云函数进行部署并激活；

步骤S105：云函数在初始化过程中访问云平台的BaaS，获取相关服务信息，完成自身状态的初始化；

步骤S106：云函数根据自身业务逻辑完成对外部请求的处理，并返回相关结果。

在一实施例中，Serverless架构可以但不限于应用于Kubeless中，Kubeless为基于Kubernetes云平台的一个Serverless框架，允许部署少量代码而无需担心底层基础架构管道，能够利用Kubernetes资源提供自动扩展、API路由、监控以及故障排除等功能，在另一实施例中，Serverless架构还可以但不限于应用于Knative云平台、OpenFaaS云平台等架构；由于上述各实施例中的应用架构属于本领域技术人员所熟知的，因此，为免冗余，下面各个实施例主要以应用于Kubeless的情况进行说明。

在另一实施例中，Serverless架构还可以包括但不限于BaaS代理组件，其中，BaaS代理组件可以设置于Serverless应用的实例和BaaS之间，作为Serverless应用实例的服务代理，用于管理与BaaS相关的连接池，提供Serverless应用访问BaaS的连接通道。

在另一实施例中，Serverless架构还可以包括但不限于Serverless应用编排器和Serverless应用仓库，Serverless应用编排器主要供部署人员进行使用，具体地，部署人员使用Serverless应用编排器编写部署Serverless应用的蓝图，并将部署完成的蓝图和对应的Serverless应用一同上传到Serverless应用仓库中；Serverless应用仓库主要用于存储蓝图、Serverless应用等，其中，Serverless程序对应于由部署人员上传到Serverless应用仓库中的Serverless函数。具体地，部署人员编写蓝图的步骤如下：

步骤S201：部署人员通过网络浏览器访问如图3所示的Serverless应用编排器的界面；

步骤S202：点击上传按钮，将Serverless应用上传到Serverless应用仓库中；

步骤S203：从Serverless应用编排器的“BaaS代理组件选择区”选择Serverless应用所需的BaaS代理组件的图标，例如，在图3中选择Kafka服务，并拖拉到Serverless应用编排器的“蓝图编辑区”；

步骤S204：在Serverless应用编排器的“蓝图编辑区”选择BaaS代理组件后，在Serverless应用编排器的“BaaS服务属性编辑区”填写其BaaS代理组件的相关属性，例如，在图3中编辑填写的属性可以但不限于为连接池大小、主体以及消费组ID等；

步骤S205：判断是否还存在没有编排的BaaS代理组件，若存在则跳转到步骤S203，否则进入到步骤S206；

步骤S206：检验编写的蓝图无误后，点击“发布”按钮，蓝图将被发布到Serverless应用仓库中进行保存。

Serverless架构中的Serverless应用管理装置、API网关、Serverless应用编排器、Serverless应用仓库以及BaaS代理组件均可以分别包括有存储器和处理器，其中，存储器和处理器可以通过总线或者其他方式连接。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本发明实施例描述的Serverless架构以及应用场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域技术人员可知，随着Serverless架构的演变和新应用场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。

本领域技术人员可以理解的是，图1中示出的Serverless架构并不构成对本发明实施例的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

在图1所示的Serverless架构中，Serverless应用管理装置、API网关、Serverless应用编排器、Serverless应用仓库以及BaaS代理组件可以分别调用其储存的资源共享程序，以执行业务请求处理方法。

基于上述Serverless架构的结构，提出本发明的业务请求处理方法的各个实施例。

如图4所示，图4是本发明一个实施例提供的业务请求处理方法的流程图，可以但不限于应用于如图1实施例所示的Serverless架构中的Serverless应用管理装置，该业务请求处理方法包括但不限于步骤S300至S600。

步骤S300：接收由API网关发送的Serverless请求信息，其中，Serverless请求信息由API网关从接收到的业务请求中获取，业务请求为对Serverless应用的实例的服务请求。

在一实施例中，API网关在接收到业务请求的情况下，才会从业务请求中提取Serverless请求信息并向Serverless应用管理装置发送此信息，可见API网关相当于是在受到业务请求的触发的情况下才会发送Serverless请求信息，这可以降低API网关误发送Serverless请求信息的概率，提高API网关的工作稳定性。

需要说明地是，Serverless请求信息体现对Serverless应用的需求，可以以访问地址、访问内容等进行呈现，业务请求中还可以包括但不限于其余相关信息，例如外部人员或系统自定义携带的必要参数信息、控制信息以及相关特征信息等，这在本实施例中并未限制。

步骤S400：在根据Serverless请求信息从Serverless架构中确定不存在Serverless应用的实例的情况下，根据Serverless请求信息确定与Serverless应用对应的目标应用信息，以及，与Serverless应用匹配的BaaS目标信息。

在一实施例中，当根据Serverless请求信息从Serverless架构中确定不存在Serverless应用的实例，则说明之前并未启动过Serverless应用，因此需要第一次启动Serverless应用，在这种情况下，通过确定目标应用信息以进一步确定Serverless应用，同时通过确定BaaS目标信息以进一步确定Serverless应用所需的目标BaaS，以便于进一步建立Serverless应用与目标BaaS之间的交互联系。

在图5的示例中，步骤S400包括但不限于步骤S410至S420。

步骤S410：根据Serverless请求信息从Serverless应用仓库中获取与Serverless应用对应的目标蓝图信息；

步骤S420：根据目标蓝图信息确定与Serverless应用对应的目标应用信息，以及，与Serverless应用匹配的BaaS目标信息。

在一实施例中，由于蓝图是由部署人员预先设定并上传到Serverless应用仓库中，因此可以从Serverless应用仓库中获取蓝图，进而根据蓝图提取得到与Serverless应用对应的目标蓝图信息，并解析目标蓝图信息而确定目标应用信息和BaaS目标信息(例如图3中所示的选择Kafka服务，以及，针对Kafka服务所设置的属性：连接池大小、主体以及消费组ID等)，以便于进一步建立Serverless应用与目标BaaS之间的交互联系。

需要说明的是，当部署人员上传的蓝图已经确定，则蓝图中所对应的目标蓝图信息、目标应用信息和BaaS目标信息也随之确定，对于本领域技术人员而言，可以根据实际应用场景来提取目标蓝图信息、目标应用信息和BaaS目标信息，这在本实施例中并未限制。

步骤S500：根据BaaS目标信息启动与BaaS目标信息对应的BaaS代理组件。

在一实施例中，在确定BaaS目标信息之后，通过启动与BaaS目标信息对应的BaaS代理组件，使得BaaS代理组件与BaaS建立交互，同时由于BaaS代理组件与Serverless应用相关联，因此预先启动BaaS代理组件，使得Serverless应用在第一次启动时能够直接通过BaaS代理组件来对接BaaS，从而有利于降低Serverless应用的第一次启动耗时。

在图6的示例中，步骤S500之前还包括但不限于步骤S510。

步骤S510：在检测到与BaaS目标信息对应的BaaS代理组件不可用的情况下，为BaaS代理组件创建连接池资源，连接池资源用于提供BaaS代理组件与目标BaaS之间的交互路径，其中，目标BaaS对应于BaaS目标信息。

在一实施例中，若检测不到当前可以直接利用的对应的BaaS代理组件，则说明对应的BaaS代理组件的连接池资源不足或者缺失，由于连接池资源用于提供BaaS代理组件与目标BaaS之间的交互路径，因此在这种情况下，通过为BaaS代理组件创建连接池资源，使得BaaS代理组件从不可用状态转换为可用状态，以便于其与BaaS建立交互连接，并且由于在第一次启动过程中即为BaaS代理组件创建连接池资源，因此在后续启动BaaS代理组件时，则可以直接应用处于可用状态下的BaaS代理组件，非常方便可靠。

步骤S600：根据目标应用信息和BaaS代理组件激活Serverless应用，使得：Serverless应用在接收到由API网关发送的业务请求的情况下，通过BaaS代理组件与目标BaaS建立服务交互以处理业务请求。

在一实施例中，在确定不存在Serverless应用的实例的情况下，基于业务请求所携带的Serverless请求信息可以确定目标应用信息和BaaS目标信息，使得能够根据目标应用信息实现第一次启动Serverless应用，并且在第一次启动Serverless应用时，Serverless应用可以利用与BaaS目标信息对应的BaaS代理组件与目标BaaS建立服务交互，实现Serverless应用与BaaS代理组件的并行运行，从而能够降低Serverless应用的第一次启动耗时，满足Serverless应用的业务处理时效要求。

需要说明的是，由于传统开发思想的影响，导致目前在开发Serverless应用时，习惯于将Serverless业务逻辑和BaaS相关的功能逻辑都放在一个应用中完成，即以串行的方式进行Serverless业务逻辑和BaaS相关的功能逻辑的运行，导致Serverless应用的冷启动时长增加，例如，如图7所示，图7是相关技术中的云函数调用示意图，从中可以看出：每次调用本地函数的时间均为5ms，而第一次调用云函数的时间则达到了百毫秒至数秒，只有当第二次及以后调用云函数才恢复到正常的5ms，这说明第一次调用云函数存在冷启动超时问题，而本实施例在Kubernetes云平台部署Serverless应用时，通过并行运行Serverless业务逻辑部分和BaaS处理部分，可以消除Serverless应用与BaaS之间的复杂初始化逻辑，从而降低Serverless应用在处理第一个业务请求的延迟。

在图8的示例中，步骤S600包括但不限于步骤S610至S620。

步骤S610：根据目标应用信息和BaaS代理组件，建立与Serverless应用对应的目标应用实例；

步骤S620：在接收到由Serverless应用仓库发送的Serverless应用的情况下，根据目标应用实例激活Serverless应用。

在一实施例中，通过在Kubernetes云平台建立与Serverless应用对应的目标应用实例，并且通过接收由Serverless应用仓库发送的Serverless应用，由于Serverless应用是由部署人员直接上传到Serverless应用仓库中的，因此，Serverless应用的相关内容，包括无服务函数、无服务器程序等，均已设置完成，从而可以将Serverless应用部署在目标应用实例之中，以便于直接地通过目标应用实例激活Serverless应用。

需要说明的是，目标应用示例可以是一个或多个与Serverless应用对应的POD实例，每个POD实例中包括若干容器以单独地部署Serverless应用；BaaS代理组件可以但不限于应用于相应的POD实例中，即，Serverless应用与BaaS代理组件可以在一个POD实例中进行初始化，在实际应用场景下有利于降低初始化难度且节省资源空间。

此外，Serverless应用与目标BaaS由以下步骤建立服务交互：

Serverless应用向BaaS代理组件发送调用服务请求，以使BaaS代理组件根据调用服务请求，与目标BaaS建立连接以及接收由目标BaaS根据调用服务请求发送的BaaS目标服务；其中，调用服务请求由Serverless应用根据业务请求生成。

在一实施例中，当Serverless应用接收到由API网关转发的业务请求，则Serverless应用可以将业务请求进一步地转化为针对目标BaaS的调用服务请求，从而通过调用服务请求使得BaaS代理组件与目标BaaS建立连接，进而使其接收由目标BaaS根据调用服务请求发送的BaaS目标服务，从而实现Serverless应用与目标BaaS之间的交互连接，以便于Serverless应用根据目标BaaS所提供的BaaS目标服务对业务请求进行方便、可靠地处理。

可以理解地是，Serverless应用中可以但不限于设置有FaaS开发软件开发工具包(Software Development Kit，SDK)，其中，FaaS开发SDK可提供给业务开发人员用于业务的开发，在运行时提供访问Kubernetes云平台的BaaS的能力，换言之，可以通过FaaS开发SDK向BaaS代理组件发送调用服务请求，在实际应用场景中，这能够降低Serverless应用与BaaS代理组件之间的逻辑化连接难度，具有良好的实用性。

需要说明的是，本发明实施例中，将管理BaaS连接部分的逻辑从Serverless应用中抽取到了单独的BaaS代理组件中，使得BaaS代理组件和Serverless应用可以同时启动，采用并行机制后，Serverless应用第一次启动时，能用更短的时间就可以处理外部的请求，特别是由于BaaS代理组件在满足Serverless应用的要求下可以被多个Serverless应用共用，这样就能进一步缩短时间。如图9所示，BaaS代理组件的构成可以分成两个部分：一是Dispatcher，负责调用服务请求的分发；二是Plugin，负责处理与BaaS的相关连接管理。Dispatcher对外提供gRPC的接口，由于gRPC是一个通用的协议，其在主流的开发语言中都有其对应的SDK，这样就可以简化为不同语言开发FaaS应用的难度。在Dispatcher接收到外部的调用服务请求后，Dispatcher会解析gRPC信息中的头部信息，根据头部信息将调用服务请求转发到具体的BaaS plugin(例如，可以但不限于为Kafka plugin、MySQL plugin、Redis plugin以及其它特定BaaS plugin等)，再由具体的BaaS Plugin将调用服务请求转发到后端的BaaS上，从而完成FaaS应用与BaaS的交互，例如，若存在多个Serverless应用可以共享BaaS相关的Kafka服务、MySQL服务和Redis服务时，则多个Serverless均可以同时在BaaS代理组件上进行对接，从而可以进一步降低多个Serverless应用在处理第一个请求时的延迟。

如图10所示，图10是本发明另一个实施例提供的业务请求处理方法的流程图，可以但不限于应用于如图1实施例所示的Serverless架构，该业务请求处理方法包括但不限于步骤S700至S900。

步骤S700：API网关从接收到的业务请求中获取Serverless请求信息，并向Serverless应用管理装置发送Serverless请求信息，其中，业务请求为对Serverless应用的实例的服务请求；

步骤S800：Serverless应用管理装置接收Serverless请求信息，并在根据Serverless请求信息从Serverless架构中确定不存在Serverless应用的实例的情况下，根据Serverless请求信息确定与Serverless应用对应的目标应用信息，以及，与Serverless应用匹配的BaaS目标信息；

步骤S900：Serverless应用管理装置根据BaaS目标信息启动与BaaS目标信息对应的BaaS代理组件，以及根据目标应用信息和BaaS代理组件激活Serverless应用，使得：Serverless应用在接收到由API网关发送的业务请求的情况下，通过BaaS代理组件与目标BaaS建立服务交互以处理业务请求。

在一实施例中，在确定不存在Serverless应用的实例的情况下，Serverless应用管理装置基于业务请求所携带的Serverless请求信息可以确定目标应用信息和BaaS目标信息，进而能够根据目标应用信息实现第一次启动Serverless应用，并且在第一次启动Serverless应用时，Serverless应用可以利用与BaaS目标信息对应的BaaS代理组件与目标BaaS建立服务交互，实现Serverless应用与BaaS代理组件的并行运行，从而能够降低Serverless应用的第一次启动耗时，满足Serverless应用的业务处理时效要求。

在图11的示例中，步骤S800中的“Serverless应用管理装置根据Serverless请求信息确定与Serverless应用对应的目标应用信息，以及，与Serverless应用匹配的BaaS目标信息”包括但不限于步骤S810。

步骤S810：Serverless应用管理装置根据Serverless请求信息从Serverless应用仓库中获取与Serverless应用对应的目标蓝图信息，并根据目标蓝图信息确定与Serverless应用对应的目标应用信息，以及，与Serverless应用匹配的BaaS目标信息。

在图12的示例中，步骤S900中的“Serverless应用管理装置根据目标应用信息和BaaS代理组件激活Serverless应用”包括但不限于步骤S910。

步骤S910：Serverless应用管理装置根据目标应用信息和BaaS代理组件，建立与Serverless应用对应的目标应用实例，以及在接收到由Serverless应用仓库发送的Serverless应用的情况下，根据目标应用实例激活Serverless应用。

在图13的示例中，步骤S900中的“Serverless应用管理装置根据BaaS目标信息启动与BaaS目标信息对应的BaaS代理组件”之前还包括但不限于步骤S920。

步骤S920：Serverless应用管理装置在检测到与BaaS目标信息对应的BaaS代理组件不可用的情况下，为BaaS代理组件创建连接池资源，连接池资源用于提供BaaS代理组件与目标BaaS之间的交互路径。

值得注意的是，由于本实施例中的业务请求处理方法与上述各实施例中的业务请求处理方法属于同一发明构思，区别仅在于本实施例中的业务请求处理方法的执行主体为Serverless架构，上述实施例中的业务请求处理方法的执行主体为Serverless架构中的Serverless应用管理装置，因此本实施例中的业务请求处理方法的具体实施方式，可以参照上述实施例中的业务请求处理方法的具体实施例，为避免冗余，本实施例的业务请求处理方法的具体实施方式在此不再赘述。

为了更清楚地阐述上述各个实施例的原理，以下给出业务请求处理方法的三种实际应用场景下的具体执行方式进行说明。

示例一：

在物联网行业中，物联网设备传输数据量小，且往往是以固定时间间隔进行数据传输，因此经常涉及低频请求场景。例如：物联网应用程序每分钟仅运行一次，每次运行50ms，这意味着CPU的使用率仅为0.1％/小时，或者说有1000个相同的应用可以共享计算资源。而在Serverless架构下，用户可以购买每分钟100ms的资源来满足计算需求，既能有效解决效率问题，也能降低使用成本。

针对物联网中的低频请求场景：

某企业构建的工业物联网，用于管理其生产流程中各种各样的设备，其中部分设备自身具有高度的自动化能力，在绝大多数的时间中可以自行良好的工作，但是在某些时刻，这些设备需要与部署在Kubernetes云平台上的针对各种设备的总控程序进行交互，而且实时性要求高。

实施环境说明：总控程序部署的Kubernetes环境，其硬件环境都采用了特殊的设备来搭建，造价昂贵，在kubernetes环境中能部署的总控程序的数量有限，因此采用Serverless技术来部署各种总控程序是一个合适的选择。

以该企业应用本发明为例，对本发明进行详细描述：

步骤S1001：此设备发送请求到Kubernetes云平台的API网关中；

步骤S1002：API网关访问Serverless应用管理装置，以进一步获取Serverless应用的访问地址；

步骤S1003：Serverless应用管理装置根据API网关的请求参数，判断当前没有可以处理请求服务的总控Serverless应用程序的实例；

步骤S1004：Serverless应用管理装置根据API网关的请求参数，从Serverless应用仓库中获取总控Serverless应用程序对应的蓝图；

步骤S1005：Serverless应用管理装置通过解析蓝图，获取总控Serverless应用程序信息和依赖的MySQL服务的信息；

步骤S1006：Serverless应用管理装置根据总控Serverless应用程序所依赖的MySQL组件信息去启动对应的MySQL服务代理，MySQL服务代理在启动时会同时创建与MySQL的连接池，并设置相关属性；

步骤S1007：Serverless应用管理装置根据总控Serverless应用程序信息和与其对应的MySQL服务代理的信息，启动一个新的POD实例；

步骤S1008：在总控Serverless应用程序和其对应的MySQL服务代理启动完成后，API网关将请求转发到总控Serverless应用程序的实例；

步骤S1009：总控Serverless应用程序通过FaaS开发SDK发送调用MySQL服务的请求；

步骤S1010：调用MySQL服务的请求会发送到其对应的MySQL服务代理，MySQL服务代理利用其已经存在的MySQL连接池去和MySQL服务交互，进行业务处理。

示例二：

在边缘计算技术(Multi-access Edge Computing，MEC)中部署的应用，经常会遇到终端应用请求的突然大爆发，例如：商品秒杀、热点新闻或者春节抢红包等，在这种情况下，就要求应用能快速的部署到多个MEC站点上，而Serverless技术恰好能适配这样的场景，利用Serverless轻量的特性将Serverless应用快速的部署到MEC站点中，并将其激活。

针对MEC快速扩容场景：

某电商将其秒杀的应用程序放置到了某电信运营商以Kubernetes为基础的MEC边缘云网络中，在秒杀开始时，会涌入大量的请求需要进行处理。

实施环境说明：在MEC边缘云场景中，由于资源有限而不能预先大规模的部署秒杀应用，因此采用Serverless技术来部署秒杀程序是一个合适的选择。

以该电商的MEC边缘云网络中使用本发明为例，对本发明进行详细描述：

步骤S1101：此设备发送请求到Kubernetes云平台的API网关中；

步骤S1102：API网关访问Serverless应用管理装置，以进一步获取Serverless应用的访问地址；

步骤S1103：Serverless应用管理装置根据API网关的请求参数，判断当前没有可以处理请求服务的秒杀Serverless应用程序的实例；

步骤S1104：Serverless应用管理装置根据API网关的请求参数，从Serverless应用仓库中获取秒杀Serverless应用程序对应的蓝图；

步骤S1105：Serverless应用管理装置通过解析蓝图，获取秒杀Serverless应用程序信息和依赖的Redis服务的信息；

步骤S1106：Serverless应用管理装置根据秒杀Serverless应用程序所依赖的Redis组件信息去启动对应的Redis服务代理，Redis服务代理在启动时会同时创建与Redis的连接池，并设置相关属性；

步骤S1107：Serverless应用管理装置根据秒杀Serverless应用程序信息和与其对应的Redis服务代理的信息，启动一个新的POD实例；

步骤S1108：在秒杀Serverless应用程序和其对应的Redis服务代理启动完成后，API网关将请求转发到秒杀Serverless应用程序的实例；

步骤S1109：秒杀Serverless应用程序通过FaaS开发SDK发送调用Redis服务的请求；

步骤S1110：调用Redis服务的请求会发送到其对应的Redis服务代理，Redis服务代理利用其已经存在的Redis连接池去和Redis服务交互，进行业务处理。

示例三：

移动互联网应用经常会面对突发流量场景，例如：移动应用的通常流量情况是QPS20，但每隔5分钟会有一个持续10s的QPS 200流量(10倍于通常流量)。传统架构下，企业必须扩展QPS 200的硬件能力来应对业务高峰，即使高峰时间仅占整个运行时间的4％。但在Serverless架构下，可以利用弹性扩展特性快速构建新的计算能力来满足当前需求，当度过业务高峰之后，资源能够自动释放，能够有效节省成本。

针对弹性扩展应对突发流量场景：

某短视频平台需要视频直播某次专场活动，由于无法预估会有多少点播的观众视频接入，因此可以把转码和流量扩容这部分内容通过Serverless技术来进行处理，无需考虑并发和流量扩容。

实施环境说明：由于无法评估点播观众接入的数量，因此不能在Kubernetes云平台中预先部署大量的程序，可以利用Serverless应用快速扩展的方式完成，但是此情况对扩张的速度要求很高，如果扩张不够迅速，会导致客户端迟缓，影响用户体验。

以该短视频APP使用本发明为例，对本发明进行详细描述：

步骤S1201：此设备发送请求到Kubernetes云平台的API网关中；

步骤S1202：API网关访问Serverless应用管理装置，以进一步获取Serverless应用的访问地址；

步骤S1203：Serverless应用管理装置根据API网关的请求参数，判断当前没有可以处理请求服务的视频点播Serverless应用程序的实例；

步骤S1204：Serverless应用管理装置根据API网关的请求参数，从Serverless应用仓库中获取视频点播Serverless应用程序对应的蓝图；

步骤S1205：Serverless应用管理装置通过解析蓝图，获取视频点播Serverless应用程序信息和依赖的Kafka服务的信息；

步骤S1206：Serverless应用管理装置根据视频点播Serverless应用程序所依赖的Kafka组件信息去启动对应的Kafka服务代理，Kafka服务代理在启动时会同时创建与Kafka的连接池，并设置相关属性；

步骤S1207：Serverless应用管理装置根据视频点播Serverless应用程序信息和与其对应的Kafka服务代理的信息，启动一个新的POD实例；

步骤S1208：在视频点播Serverless应用程序和其对应的Kafka服务代理启动完成后，API网关将请求转发到视频点播Serverless应用程序的实例；

步骤S1209：视频点播Serverless应用程序通过FaaS开发SDK发送调用Kafka服务的请求；

步骤S1210：调用Kafka服务的请求会发送到其对应的Kafka服务代理，Kafka服务代理利用其已经存在的Kafka连接池去和Kafka服务交互，进行业务处理。

另外，本发明的一个实施例还提供了一种网络设备，该设备包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序。

处理器和存储器可以通过总线或者其他方式连接。

实现上述实施例的业务请求处理方法所需的非暂态软件程序以及指令存储在存储器中，当被处理器执行时，执行上述各实施例的业务请求处理方法，例如，执行以上描述的图4中的方法步骤S300至S600、图5中的方法步骤S410至S420、图6中的方法步骤S510、图8中的方法步骤S610至S620、图10中的方法步骤S700至S900、图11中的方法步骤S810、图12中的方法步骤S910、图13中的方法步骤S920、方法步骤S1001至S1010、方法步骤S1101至S1110或方法步骤S1201至S1210。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

此外，本发明的一个实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令被一个处理器或控制器执行，例如，被上述设备实施例中的一个处理器执行，可使得上述处理器执行上述实施例中的业务请求处理方法，例如，执行以上描述的图4中的方法步骤S300至S600、图5中的方法步骤S410至S420、图6中的方法步骤S510、图8中的方法步骤S610至S620、图10中的方法步骤S700至S900、图11中的方法步骤S810、图12中的方法步骤S910、图13中的方法步骤S920、方法步骤S1001至S1010、方法步骤S1101至S1110或方法步骤S1201至S1210。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上是对本发明的较佳实施方式进行的具体说明，但本发明并不局限于上述实施方式，熟悉本领域的技术人员在不违背本发明精神的前提下还可作出种种的等同变形或替换，这些等同的变形或替换均包含在本发明权利要求所限定的范围内。

Claims (11)

1.一种业务请求处理方法，应用于无服务器Serverless架构中的Serverless应用管理装置，所述Serverless架构还包括应用程序编程接口API网关，所述方法包括：

接收由所述API网关发送的Serverless请求信息，其中，所述Serverless请求信息由所述API网关从接收到的业务请求中获取，所述业务请求为对Serverless应用的实例的服务请求；

在根据所述Serverless请求信息从所述Serverless架构中确定不存在所述Serverless应用的实例的情况下，根据所述Serverless请求信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的后端即服务BaaS目标信息；

根据所述BaaS目标信息启动与所述BaaS目标信息对应的BaaS代理组件；

根据所述目标应用信息和所述BaaS代理组件激活所述Serverless应用，使得：

所述Serverless应用在接收到由所述API网关发送的所述业务请求的情况下，通过所述BaaS代理组件与目标BaaS建立服务交互以处理所述业务请求，其中，所述目标BaaS对应于所述BaaS目标信息。

2.根据权利要求1所述的业务请求处理方法，其特征在于，所述Serverless架构还包括Serverless应用仓库；所述根据所述Serverless请求信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的BaaS目标信息，包括：

根据所述Serverless请求信息从所述Serverless应用仓库中获取与所述Serverless应用对应的目标蓝图信息；

根据所述目标蓝图信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的BaaS目标信息。

3.根据权利要求2所述的业务请求处理方法，其特征在于，所述根据所述目标应用信息和所述BaaS代理组件激活所述Serverless应用，包括：

根据所述目标应用信息和所述BaaS代理组件，建立与所述Serverless应用对应的目标应用实例；

在接收到由所述Serverless应用仓库发送的所述Serverless应用的情况下，根据所述目标应用实例激活所述Serverless应用。

4.根据权利要求1所述的业务请求处理方法，其特征在于，所述根据所述BaaS目标信息启动与所述BaaS目标信息对应的BaaS代理组件之前，还包括：

在检测到与所述BaaS目标信息对应的所述BaaS代理组件不可用的情况下，为所述BaaS代理组件创建连接池资源，所述连接池资源用于提供所述BaaS代理组件与所述目标BaaS之间的交互路径。

5.一种业务请求处理方法，应用于Serverless架构，所述Serverless架构包括Serverless应用管理装置和API网关，所述方法包括：

所述API网关从接收到的业务请求中获取Serverless请求信息，并向所述Serverless应用管理装置发送所述Serverless请求信息，其中，所述业务请求为对Serverless应用的实例的服务请求；

所述Serverless应用管理装置接收所述Serverless请求信息，并在根据所述Serverless请求信息从所述Serverless架构中确定不存在所述Serverless应用的实例的情况下，根据所述Serverless请求信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的BaaS目标信息；

所述Serverless应用管理装置根据所述BaaS目标信息启动与所述BaaS目标信息对应的BaaS代理组件，以及根据所述目标应用信息和所述BaaS代理组件激活所述Serverless应用，使得：

所述Serverless应用在接收到由所述API网关发送的所述业务请求的情况下，通过所述BaaS代理组件与目标BaaS建立服务交互以处理所述业务请求，其中，所述目标BaaS对应于所述BaaS目标信息。

6.根据权利要求5所述的业务请求处理方法，其特征在于，所述Serverless架构还包括Serverless应用仓库；所述Serverless应用管理装置根据所述Serverless请求信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的BaaS目标信息，包括：

所述Serverless应用管理装置根据所述Serverless请求信息从所述Serverless应用仓库中获取与所述Serverless应用对应的目标蓝图信息，并根据所述目标蓝图信息确定与所述Serverless应用对应的目标应用信息，以及，与所述Serverless应用匹配的BaaS目标信息。

7.根据权利要求6所述的业务请求处理方法，其特征在于，所述Serverless应用管理装置根据所述目标应用信息和所述BaaS代理组件激活所述Serverless应用，包括：

所述Serverless应用管理装置根据所述目标应用信息和所述BaaS代理组件，建立与所述Serverless应用对应的目标应用实例，以及在接收到由所述Serverless应用仓库发送的所述Serverless应用的情况下，根据所述目标应用实例激活所述Serverless应用。

8.根据权利要求5所述的业务请求处理方法，其特征在于，所述Serverless应用管理装置根据所述BaaS目标信息启动与所述BaaS目标信息对应的BaaS代理组件之前，还包括：

所述Serverless应用管理装置在检测到与所述BaaS目标信息对应的所述BaaS代理组件不可用的情况下，为所述BaaS代理组件创建连接池资源，所述连接池资源用于提供所述BaaS代理组件与所述目标BaaS之间的交互路径。

9.根据权利要求5所述的业务请求处理方法，其特征在于，所述Serverless应用与所述目标BaaS由以下步骤建立服务交互：

所述Serverless应用向所述BaaS代理组件发送调用服务请求，以使所述BaaS代理组件根据所述调用服务请求，与所述目标BaaS建立连接以及接收由所述目标BaaS根据所述调用服务请求发送的BaaS目标服务；其中，所述调用服务请求由所述Serverless应用根据所述业务请求生成。

10.一种网络设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至9中任意一项所述的业务请求处理方法。

11.一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行权利要求1至9中任意一项所述的业务请求处理方法。

Images