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

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

Info

Publication number
WO2023066053A1
WO2023066053A1 PCT/CN2022/124173 CN2022124173W WO2023066053A1 WO 2023066053 A1 WO2023066053 A1 WO 2023066053A1 CN 2022124173 W CN2022124173 W CN 2022124173W WO 2023066053 A1 WO2023066053 A1 WO 2023066053A1
Authority
WO
WIPO (PCT)
Prior art keywords
serverless
baas
application
target
information
Prior art date
Application number
PCT/CN2022/124173
Other languages
English (en)
French (fr)
Inventor
胡锐
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2023066053A1 publication Critical patent/WO2023066053A1/zh

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services

Definitions

  • the embodiments of the present application relate to but are not limited to the field of cloud-native technologies, for example, a method for processing a service request, a network device, and a computer-readable storage medium.
  • serverless serverless technology is an important component of cloud-native technology.
  • serverless technology means that users create and run software applications and services in cloud servers, and users do not need to care about the content related to the IT facilities involved.
  • the embodiment of the present application provides a service request processing method, a network device, and a computer-readable storage medium, which can reduce the time-consuming for the first startup of a serverless application and meet the service processing timeliness requirement of the serverless application.
  • the embodiment of the present application provides a service request processing method, which is applied to a serverless application management device in a serverless serverless architecture.
  • the serverless architecture also includes an application programming interface API gateway, and the method includes: receiving the The serverless request information sent by the API gateway, wherein the serverless request information is obtained by the API gateway from a received service request, and the service request is a service request for an instance of a serverless application; according to the serverless
  • the request information determines that there is no instance of the serverless application in the serverless architecture, determine the target application information corresponding to the serverless application according to the serverless request information, and the backend matching the serverless application That is, service BaaS target information; start the BaaS proxy component corresponding to the BaaS target information according to the BaaS target information; activate the Serverless application according to the target application information and the BaaS proxy component, so that: the Serverless application is in When receiving the service request sent by the API gateway, establish service interaction with a target BaaS through the BaaS proxy
  • the embodiment of the present application provides a service request processing method, which is applied to a serverless architecture
  • the serverless architecture includes a serverless application management device and an API gateway
  • the method includes: the API gateway receives the service request Obtaining Serverless request information in the server, and sending the Serverless request information to the Serverless application management device, wherein the service request is a service request for an instance of the Serverless application; the Serverless application management device receives the Serverless request information, And when it is determined from the Serverless architecture according to the Serverless request information that there is no instance of the Serverless application, determine the target application information corresponding to the Serverless application according to the Serverless request information, and, with the The BaaS target information matched by the Serverless application; the serverless application management device starts the BaaS proxy component corresponding to the BaaS target information according to the BaaS target information, and activates the Serverless according to the target application information and the BaaS proxy component application, so that: when the serverless application receives the service request sent by the API gateway
  • the embodiment of the present application also provides a network device, including: a memory, a processor, and a computer program stored on the memory and operable on the processor, when the processor executes the computer program to implement the following: The service request processing method described in the first aspect and the second aspect.
  • the embodiment of the present application also provides a computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are used to execute the service request processing methods as described in the first aspect and the second aspect .
  • FIG. 1 is a schematic diagram of a Serverless architecture for executing a service request processing method provided by an embodiment of the present application
  • Fig. 2 is a schematic diagram of the principle of Serverless provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram of an interface of a serverless application orchestrator provided by an embodiment of the present application
  • FIG. 4 is a flowchart of a service request processing method provided by an embodiment of the present application.
  • FIG. 5 is a flowchart of determining target application information and BaaS target information in a service request processing method provided by an embodiment of the present application
  • Fig. 6 is a flow chart before starting the BaaS agent component in the business request processing method provided by one embodiment of the present application;
  • FIG. 7 is a schematic diagram of a cloud function call in the related art.
  • FIG. 8 is a flow chart of activating a Serverless application in a service request processing method provided by an embodiment of the present application
  • FIG. 9 is a schematic diagram of a BaaS proxy component provided by an embodiment of the present application.
  • Fig. 10 is an execution flowchart of a service request processing method provided by another embodiment of the present application.
  • Fig. 11 is an execution flowchart of determining target application information and BaaS target information by the serverless application management device in the service request processing method provided by an embodiment of the present application;
  • Fig. 12 is a flow chart of activating the Serverless application by the Serverless application management device in the service request processing method provided by one embodiment of the present application;
  • Fig. 13 is a flow chart before the serverless application management device starts the BaaS proxy component in the service request processing method provided by an embodiment of the present application.
  • This application provides a service request processing method, network equipment, and computer-readable storage medium.
  • the target application information and the backend i.e. Service (Backend as a Service, BaaS) target information, so that the Serverless application can be started for the first time according to the target application information, and when the Serverless application is started for the first time, the Serverless application can use the BaaS proxy component corresponding to the BaaS target information and
  • the target BaaS establishes service interaction and realizes the parallel operation of serverless applications and BaaS proxy components, thereby reducing the time spent on the first startup of serverless applications and meeting the business processing timeliness requirements of serverless applications.
  • FIG. 1 is a schematic diagram of a serverless architecture for executing a service request processing method provided by an embodiment of the present application.
  • the serverless architecture includes, but is not limited to: a serverless application management device and an API gateway, where the API gateway, as an interface in the serverless architecture, can receive service requests from external personnel or systems, and the serverless application management device serves as The control terminal in the serverless architecture can cooperate with other components in the serverless architecture to realize lifecycle management, and information interaction can be realized between the serverless application management device and the API gateway.
  • the API gateway can query the application address and forward the process through the serverless application management device information etc.
  • the serverless technology can be divided into two parts, one part is function as a service (Function as a Service, FaaS), which has no service function function, and the other part is BaaS, which has object storage, Service functions such as cloud database, message queue, gateway interface, and Redis cache, etc., integrate various services, for example, including but not limited to Kafka service, MySQL service, Redis service, and other specific services; among them, the serverless application under the serverless technology
  • FaaS Function as a Service
  • BaaS which has object storage
  • Service functions such as cloud database, message queue, gateway interface, and Redis cache, etc.
  • Step S101 the business developer completes the development of the non-service function
  • Step S102 The business developer uploads the non-service function to the function warehouse of the cloud platform;
  • Step S103 sending the external request to the application programming interface API gateway
  • Step S104 the cloud platform deploys and activates the corresponding cloud function
  • Step S105 the cloud function accesses the BaaS of the cloud platform during the initialization process, obtains relevant service information, and completes the initialization of its own state;
  • Step S106 The cloud function completes the processing of external requests according to its own business logic, and returns relevant results.
  • the Serverless architecture can be applied to Kubeless, but is not limited to it.
  • Kubeless is a Serverless framework based on the Kubernetes cloud platform, which allows the deployment of a small amount of code without worrying about the underlying infrastructure pipeline, and can use Kubernetes resources to provide automatic expansion and API routing. , monitoring, and troubleshooting functions.
  • the Serverless architecture can also be applied to architectures such as Knative cloud platform and OpenFaaS cloud platform; since the application architectures in the above-mentioned embodiments are well known to those skilled in the art Therefore, in order to avoid redundancy, the following embodiments are mainly described in the case of Kubeless.
  • the Serverless architecture may also include, but not limited to, a BaaS proxy component, where the BaaS proxy component may be set between an instance of the Serverless application and the BaaS, as a service proxy of the Serverless application instance, for managing the BaaS-related
  • the connection pool provides a connection channel for Serverless applications to access BaaS.
  • the Serverless architecture may also include, but not limited to, a serverless application orchestrator and a serverless application warehouse.
  • the serverless application orchestrator is mainly used by deployment personnel.
  • the deployment personnel use the serverless application orchestrator to write and deploy Serverless The blueprint of the application, and upload the deployed blueprint and the corresponding serverless application to the serverless application warehouse; Serverless functions in .
  • the steps for a deployer to write a blueprint are as follows:
  • Step S201 the deployer accesses the interface of the serverless application orchestrator shown in FIG. 3 through a web browser;
  • Step S202 Click the upload button to upload the serverless application to the serverless application warehouse
  • Step S203 Select the icon of the BaaS proxy component required by the serverless application from the "BaaS proxy component selection area" of the serverless application orchestrator, for example, select the Kafka service in Figure 3, and drag it to the "blueprint editing area" of the serverless application orchestrator ";
  • Step S204 After selecting the BaaS proxy component in the "Blueprint Editing Area" of the Serverless Application Orchestrator, fill in the relevant properties of the BaaS proxy component in the "BaaS Service Attribute Editing Area" of the Serverless Application Orchestrator, for example, edit and fill in in Figure 3 Attributes can be but not limited to connection pool size, subject and consumer group ID, etc.;
  • Step S205 Determine whether there are BaaS proxy components that have not been programmed, and if so, go to step S203, otherwise go to step S206;
  • Step S206 After verifying that the written blueprint is correct, click the "Publish” button, and the blueprint will be published to the serverless application repository for storage.
  • the serverless application management device, API gateway, serverless application orchestrator, serverless application warehouse, and BaaS agent component in the serverless architecture may respectively include a memory and a processor, wherein the memory and the processor may be connected through a bus or in other ways.
  • memory can be used to store non-transitory software programs and non-transitory computer-executable programs.
  • the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage devices.
  • the memory optionally includes memory located remotely from the processor, and these remote memories may be connected to the processor via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
  • serverless architecture shown in Figure 1 does not constitute a limitation to the embodiment of the present application, and may include more or less components than those shown in the illustration, or combine some components, or different components layout.
  • the serverless application management device, API gateway, serverless application orchestrator, serverless application warehouse, and BaaS proxy component can respectively call their stored resource sharing programs to execute business request processing methods.
  • Figure 4 is a flowchart of a service request processing method provided by an embodiment of the present application, which can be but not limited to be applied to the Serverless application management device in the Serverless architecture shown in the embodiment of Figure 1, the service request The processing method includes but not limited to steps S300 to S600.
  • Step S300 Receive the serverless request information sent by the API gateway, wherein the serverless request information is acquired by the API gateway from the received service request, and the service request is a service request for an instance of the serverless application.
  • the API gateway when the API gateway receives a service request, it extracts the serverless request information from the service request and sends this information to the serverless application management device. It can be seen that the API gateway is equivalent to being triggered by a service request The serverless request information will be sent only after the next time, which can reduce the probability of the API gateway sending the serverless request information by mistake and improve the working stability of the API gateway.
  • serverless request information reflects the requirements for serverless applications, and can be presented in the form of access address, access content, etc.
  • the business request can also include but not limited to other relevant information, such as external personnel or necessary parameters carried by system customization information, control information, and related feature information, etc., which are not limited in this embodiment.
  • Step S400 When it is determined from the serverless architecture according to the serverless request information that there is no serverless application instance, determine the target application information corresponding to the serverless application and the BaaS target information matching the serverless application according to the serverless request information.
  • the Serverless application when it is determined from the Serverless architecture according to the Serverless request information that there is no instance of the Serverless application, it means that the Serverless application has not been started before, so the Serverless application needs to be started for the first time.
  • the target application information is used to further determine the Serverless application, and at the same time, the target BaaS required by the Serverless application is further determined by determining the BaaS target information, so as to further establish an interactive relationship between the Serverless application and the target BaaS.
  • step S400 includes but not limited to steps S410 to S420.
  • Step S410 Obtain target blueprint information corresponding to the Serverless application from the Serverless application repository according to the Serverless request information;
  • Step S420 Determine target application information corresponding to the Serverless application and BaaS target information matching the Serverless application according to the target blueprint information.
  • the blueprint can be obtained from the serverless application warehouse, and then the target blueprint information corresponding to the serverless application can be extracted according to the blueprint, and the target can be analyzed Determine the target application information and BaaS target information based on the blueprint information (such as the selection of Kafka services shown in Figure 3, and the attributes set for the Kafka services: connection pool size, subject and consumer group ID, etc.), so as to further establish Serverless The interaction between the application and the target BaaS.
  • the blueprint information such as the selection of Kafka services shown in Figure 3, and the attributes set for the Kafka services: connection pool size, subject and consumer group ID, etc.
  • the corresponding target blueprint information, target application information and BaaS target information in the blueprint will also be determined.
  • the target blueprint information, target application information and BaaS target information are extracted, which is not limited in this embodiment.
  • Step S500 Start the BaaS proxy component corresponding to the BaaS target information according to the BaaS target information.
  • the BaaS proxy component corresponding to the BaaS target information is activated to enable the BaaS proxy component to establish interaction with the BaaS.
  • the BaaS proxy component is associated with the Serverless application, the BaaS proxy is pre-started. The component enables the Serverless application to directly connect to the BaaS through the BaaS proxy component when it is started for the first time, which is beneficial to reduce the time spent on the first startup of the Serverless application.
  • step S510 is also included before step S500 .
  • Step S510 When it is detected that the BaaS proxy component corresponding to the BaaS target information is unavailable, create a connection pool resource for the BaaS proxy component, and the connection pool resource is used to provide an interaction path between the BaaS proxy component and the target BaaS, wherein, Target BaaS corresponds to BaaS target information.
  • the corresponding BaaS proxy component that can be directly used at present cannot be detected, it indicates that the connection pool resource of the corresponding BaaS proxy component is insufficient or missing, because the connection pool resource is used to provide the connection between the BaaS proxy component and the target BaaS Therefore, in this case, by creating a connection pool resource for the BaaS proxy component, the BaaS proxy component transitions from the unavailable state to the available state, so that it can establish an interactive connection with the BaaS, and because the first The connection pool resource is created for the BaaS proxy component during the startup process, so when the BaaS proxy component is started later, the BaaS proxy component in the available state can be directly applied, which is very convenient and reliable.
  • Step S600 activate the serverless application according to the target application information and the BaaS proxy component, so that: when the serverless application receives the service request sent by the API gateway, establish service interaction with the target BaaS through the BaaS proxy component to process the service request.
  • the target application information and the BaaS target information can be determined based on the Serverless request information carried in the service request, so that the Serverless application can be started for the first time according to the target application information , and when the serverless application is started for the first time, the serverless application can use the BaaS proxy component corresponding to the BaaS target information to establish service interaction with the target BaaS, so as to realize the parallel operation of the serverless application and the BaaS proxy component, thereby reducing the first It takes less time to start the first time and meets the business processing timeliness requirements of serverless applications.
  • FIG. 7 is a schematic diagram of cloud function calls in related technologies, from which it can be seen that: the time for each call to a local function Both are 5ms, and the time to call the cloud function for the first time reaches hundreds of milliseconds to several seconds.
  • step S600 includes but not limited to steps S610 to S620.
  • Step S610 according to the target application information and the BaaS proxy component, establish a target application instance corresponding to the Serverless application;
  • Step S620 In the case of receiving the serverless application sent by the serverless application repository, activate the serverless application according to the target application instance.
  • the relevant content of the Serverless application including serverless functions, serverless programs, etc., have been set up, so that the Serverless application can be deployed in the target application instance, so that the Serverless application can be directly activated through the target application instance.
  • the target application example can be one or more POD instances corresponding to Serverless applications, and each POD instance includes several containers to deploy Serverless applications separately; BaaS proxy components can be applied to corresponding POD instances, but are not limited to In other words, the serverless application and BaaS proxy components can be initialized in one POD instance, which is beneficial to reduce the difficulty of initialization and save resource space in actual application scenarios.
  • serverless application establishes service interaction with the target BaaS through the following steps:
  • the serverless application sends a call service request to the BaaS proxy component, so that the BaaS proxy component establishes a connection with the target BaaS according to the call service request and receives the BaaS target service sent by the target BaaS according to the call service request; wherein, the call service request is made by the serverless application according to A business request is generated.
  • the serverless application when the serverless application receives the service request forwarded by the API gateway, the serverless application can further convert the service request into an invocation service request for the target BaaS, so that the BaaS proxy component can communicate with the target BaaS by invoking the service request. Establish a connection, and then make it receive the BaaS target service sent by the target BaaS according to the call service request, so as to realize the interactive connection between the serverless application and the target BaaS, so that the serverless application can process the business request according to the BaaS target service provided by the target BaaS Easy and reliable handling.
  • a FaaS development software development kit (Software Development Kit, SDK) can be provided in a serverless application, but not limited to, where the FaaS development SDK can be provided to business developers for business development, and provides access at runtime
  • the BaaS capability of the Kubernetes cloud platform in other words, can use the FaaS development SDK to send invocation service requests to BaaS proxy components. In actual application scenarios, this can reduce the difficulty of logical connection between Serverless applications and BaaS proxy components, and has a good practicality.
  • the logic for managing the BaaS connection part is extracted from the serverless application into a separate BaaS proxy component, so that the BaaS proxy component and the serverless application can be started at the same time.
  • the composition of the BaaS proxy component can be divided into two parts: one is the Dispatcher, which is responsible for the distribution of call service requests; the other is the Plugin, which is responsible for handling the connection management with BaaS. Dispatcher provides a gRPC interface to the outside world.
  • Dispatcher Since gRPC is a general protocol, it has its corresponding SDK in mainstream development languages, which simplifies the difficulty of developing FaaS applications for different languages.
  • Dispatcher After Dispatcher receives the external invocation service request, Dispatcher will parse the header information in the gRPC information, and forward the invocation service request to a specific BaaS plugin according to the header information (for example, it can be but not limited to Kafka plugin, MySQL plugin, Redis plugin and other specific BaaS plugins, etc.), and then the specific BaaS Plugin forwards the call service request to the back-end BaaS to complete the interaction between the FaaS application and the BaaS.
  • a specific BaaS plugin for example, it can be but not limited to Kafka plugin, MySQL plugin, Redis plugin and other specific BaaS plugins, etc.
  • multiple Serverless applications can share the BaaS-related Kafka service, MySQL service, and Redis service, multiple Serverless can be connected on the BaaS proxy component at the same time, which can further reduce the delay when multiple Serverless applications process the first request.
  • Figure 10 is a flow chart of a service request processing method provided by another embodiment of the present application, which can be but not limited to be applied to the Serverless architecture shown in the embodiment of Figure 1, the service request processing method includes but not It is limited to steps S700 to S900.
  • Step S700 The API gateway obtains the serverless request information from the received service request, and sends the serverless request information to the serverless application management device, wherein the service request is a service request for an instance of the serverless application;
  • Step S800 The serverless application management device receives the serverless request information, and determines the target application information corresponding to the serverless application according to the serverless request information when it is determined from the serverless architecture according to the serverless request information that there is no serverless application instance, and, with BaaS target information matched by Serverless application;
  • Step S900 The serverless application management device starts the BaaS proxy component corresponding to the BaaS target information according to the BaaS target information, and activates the serverless application according to the target application information and the BaaS proxy component, so that: the serverless application receives the service request sent by the API gateway In this case, service interaction is established with the target BaaS through the BaaS proxy component to process business requests.
  • the serverless application management device can determine the target application information and BaaS target information based on the serverless request information carried in the service request, and then realize the first Start the Serverless application for the first time, and when starting the Serverless application for the first time, the Serverless application can use the BaaS proxy component corresponding to the BaaS target information to establish service interaction with the target BaaS, so as to realize the parallel operation of the Serverless application and the BaaS proxy component, thereby reducing the cost of Serverless It takes time to start the application for the first time, meeting the business processing timeliness requirements of serverless applications.
  • the serverless application management device determines the target application information corresponding to the serverless application according to the serverless request information in step S800, and the BaaS target information matching the serverless application” includes but is not limited to step S810.
  • Step S810 The serverless application management device obtains the target blueprint information corresponding to the serverless application from the serverless application warehouse according to the serverless request information, and determines the target application information corresponding to the serverless application and the BaaS target matching the serverless application according to the target blueprint information information.
  • step S900 “the serverless application management device activates the serverless application according to the target application information and the BaaS proxy component" in step S900 includes but is not limited to step S910 .
  • Step S910 The serverless application management device establishes a target application instance corresponding to the serverless application according to the target application information and the BaaS proxy component, and activates the serverless application according to the target application instance when receiving the serverless application sent by the serverless application warehouse.
  • step S900 before the "the serverless application management device activates the BaaS proxy component corresponding to the BaaS target information according to the BaaS target information" in step S900 also includes but is not limited to step S920.
  • Step S920 When the serverless application management device detects that the BaaS proxy component corresponding to the BaaS target information is unavailable, create a connection pool resource for the BaaS proxy component, and the connection pool resource is used to provide the interaction between the BaaS proxy component and the target BaaS path.
  • the execution subject of the business request processing method in this embodiment is a Serverless architecture
  • the execution subject of the service request processing method in the above embodiment is the serverless application management device in the Serverless architecture, so for the specific implementation of the service request processing method in this embodiment, you can refer to the specific implementation of the service request processing method in the above embodiment In an embodiment, in order to avoid redundancy, the specific implementation manner of the service request processing method in this embodiment will not be repeated here.
  • IoT In the IoT industry, the amount of data transmitted by IoT devices is small, and data transmission is often performed at fixed time intervals, so low-frequency request scenarios are often involved. For example: an IoT application runs only once per minute, and each run takes 50ms, which means that the CPU usage is only 0.1%/hour, or 1000 identical applications can share computing resources. Under the serverless architecture, users can purchase 100 ms of resources per minute to meet computing needs, which can effectively solve efficiency problems and reduce usage costs.
  • the Industrial Internet of Things built by a company is used to manage various devices in its production process, some of which have a high degree of automation and can work well by themselves most of the time, but at some point , these devices need to interact with the general control program for various devices deployed on the Kubernetes cloud platform, and the real-time requirements are high.
  • Step S1001 the device sends a request to the API gateway of the Kubernetes cloud platform
  • Step S1002 the API gateway accesses the serverless application management device to further obtain the access address of the serverless application;
  • Step S1003 The serverless application management device judges that there is currently no master serverless application instance that can process the requested service according to the request parameters of the API gateway;
  • Step S1004 The serverless application management device obtains the blueprint corresponding to the master control serverless application program from the serverless application warehouse according to the request parameter of the API gateway;
  • Step S1005 The serverless application management device obtains information about the master serverless application program and dependent MySQL services by analyzing the blueprint;
  • Step S1006 The serverless application management device starts the corresponding MySQL service agent according to the MySQL component information on which the master control serverless application program depends.
  • the MySQL service agent will simultaneously create a connection pool with MySQL and set related attributes when starting;
  • Step S1007 The serverless application management device starts a new POD instance according to the master serverless application program information and the corresponding MySQL service agent information;
  • Step S1008 After the master control serverless application program and its corresponding MySQL service agent are started, the API gateway forwards the request to the master control serverless application program instance;
  • Step S1009 the master control serverless application sends a request to call the MySQL service through the FaaS development SDK;
  • Step S1010 the request for invoking the MySQL service will be sent to its corresponding MySQL service agent, and the MySQL service agent uses its existing MySQL connection pool to interact with the MySQL service and perform business processing.
  • Multi-access Edge Computing often encounter sudden bursts of terminal application requests, such as flash sales of products, hot news, or grabbing red envelopes during the Spring Festival. Applications are required to be quickly deployed to multiple MEC sites, and serverless technology is just suitable for such a scenario. Serverless applications can be quickly deployed to MEC sites and activated by using the lightweight features of serverless.
  • An e-commerce company placed its seckill application in the Kubernetes-based MEC edge cloud network of a telecom operator. When the seckill starts, a large number of requests will flood in to be processed.
  • Step S1101 the device sends a request to the API gateway of the Kubernetes cloud platform
  • Step S1102 the API gateway accesses the serverless application management device to further obtain the access address of the serverless application;
  • Step S1103 The serverless application management device judges that there is currently no instance of the seckill serverless application that can process the requested service according to the request parameters of the API gateway;
  • Step S1104 The serverless application management device obtains the blueprint corresponding to the seckill serverless application program from the serverless application warehouse according to the request parameter of the API gateway;
  • Step S1105 the serverless application management device obtains the seckill serverless application information and the information of the dependent Redis service by analyzing the blueprint;
  • Step S1106 The serverless application management device starts the corresponding Redis service agent according to the Redis component information on which the seckill serverless application program depends, and the Redis service agent will simultaneously create a connection pool with Redis and set related attributes when starting;
  • Step S1107 the serverless application management device starts a new POD instance according to the seckill serverless application information and the corresponding Redis service agent information;
  • Step S1108 After the Seckill Serverless application and its corresponding Redis service agent are started, the API Gateway forwards the request to the Seckill Serverless application instance;
  • Step S1109 The seckill serverless application sends a request to call the Redis service through the FaaS development SDK;
  • Step S1110 The request for invoking the Redis service will be sent to its corresponding Redis service agent, and the Redis service agent uses its existing Redis connection pool to interact with the Redis service and perform business processing.
  • a short video platform needs to live broadcast a special event. Since it is impossible to predict how many on-demand viewers will access the video, the content of transcoding and traffic expansion can be processed through Serverless technology without considering concurrency and traffic expansion. .
  • Step S1201 the device sends a request to the API gateway of the Kubernetes cloud platform
  • Step S1202 the API gateway accesses the serverless application management device to further obtain the access address of the serverless application;
  • Step S1203 The serverless application management device judges that there is currently no instance of the video-on-demand serverless application that can handle the requested service according to the request parameters of the API gateway;
  • Step S1204 The serverless application management device obtains the blueprint corresponding to the video-on-demand serverless application program from the serverless application warehouse according to the request parameter of the API gateway;
  • Step S1205 The serverless application management device obtains the video-on-demand serverless application program information and the information of the dependent Kafka service by analyzing the blueprint;
  • Step S1206 The serverless application management device starts the corresponding Kafka service agent according to the Kafka component information on which the video-on-demand serverless application program depends, and the Kafka service agent will simultaneously create a connection pool with Kafka when starting, and set related attributes;
  • Step S1207 The serverless application management device starts a new POD instance according to the video-on-demand serverless application program information and the corresponding Kafka service agent information;
  • Step S1208 After the video-on-demand serverless application and its corresponding Kafka service agent are started, the API gateway forwards the request to the instance of the video-on-demand serverless application;
  • Step S1209 the video-on-demand serverless application sends a request to call the Kafka service through the FaaS development SDK;
  • Step S1210 The request for invoking the Kafka service will be sent to its corresponding Kafka service proxy, and the Kafka service proxy uses its existing Kafka connection pool to interact with the Kafka service for business processing.
  • an embodiment of the present application also provides a network device, which includes: a memory, a processor, and a computer program stored in the memory and operable on the processor.
  • the processor and memory can be connected by a bus or other means.
  • the non-transitory software programs and instructions required to realize the service request processing methods of the above-mentioned embodiments are stored in the memory, and when executed by the processor, the service request processing methods of the above-mentioned embodiments are executed, for example, executing the above-described Figure 4 Method steps S300 to S600 in, method steps S410 to S420 in Fig. 5, method steps S510 in Fig. 6, method steps S610 to S620 in Fig. 8, method steps S700 to S900 in Fig. 10, Fig. 11 Method step S810, method step S910 in FIG. 12, method step S920 in FIG. 13, method steps S1001 to S1010, method steps S1101 to S1110 or method steps S1201 to S1210.
  • the device embodiments described above are only illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • an embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are executed by a processor or a controller, for example, by the above-mentioned Execution by a processor in the device embodiment can cause the processor to execute the service request processing method in the above embodiment, for example, execute the method steps S300 to S600 in FIG. 4 and the method steps S410 to S410 in FIG. 5 described above.
  • the embodiment of this application includes: a business request processing method, which is applied to a serverless application management device in a serverless architecture.
  • the serverless architecture also includes an API gateway and a serverless application warehouse.
  • the method includes: receiving serverless request information sent by the API gateway, wherein the serverless request The information is obtained by the API gateway from the service request received, and the service request is a service request for an instance of the serverless application; if it is determined from the serverless architecture that there is no instance of the serverless application according to the serverless request information, it is determined according to the serverless request information
  • the target application information corresponding to the Serverless application, and the BaaS target information matching the Serverless application start the BaaS proxy component corresponding to the BaaS target information according to the BaaS target information; activate the Serverless application according to the target application information and the BaaS proxy component, so that: Serverless When the application receives the service request sent by the API gateway, it establishes service interaction with the target BaaS through the BaaS proxy component to process
  • the target application information and the BaaS target information can be determined based on the Serverless request information carried in the service request, so that the first time can be realized according to the target application information.
  • the serverless application can use the BaaS proxy component corresponding to the BaaS target information to establish service interaction with the target BaaS, and realize the parallel operation of the serverless application and the BaaS proxy component, thereby reducing the serverless application It takes time to start the first time and meet the business processing timeliness requirements of serverless applications.
  • Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, tape, magnetic disk storage or other magnetic storage devices, or can Any other medium used to store desired information and which can be accessed by a computer.
  • communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种业务请求处理方法、网络设备及计算机可读存储介质，其中，方法包括：接收由API网关发送的Serverless请求信息，Serverless请求信息由API网关从业务请求中获取，业务请求为对Serverless应用的实例的服务请求(S300)；在根据Serverless请求信息从Serverless架构中确定不存在Serverless应用的实例的情况下，根据Serverless请求信息确定目标应用信息和BaaS目标信息(S400)；根据BaaS目标信息启动与BaaS目标信息对应的BaaS代理组件(S500)；根据目标应用信息和BaaS代理组件激活Serverless应用，使得Serverless应用在接收到业务请求的情况下，通过BaaS代理组件与目标BaaS建立服务交互以处理业务请求(S600)。

Description

业务请求处理方法、网络设备及计算机可读存储介质
相关申请的交叉引用
本申请基于申请号为202111216218.7、申请日为2021年10月19日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请实施例涉及但不限于云原生技术领域，例如涉及一种业务请求处理方法、网络设备及计算机可读存储介质。
背景技术
随着云计算技术的不断发展，越来越多的企业将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目标信息。
第三方面，本申请实施例还提供了一种网络设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面和第二方面所述的业务请求处理方法。
第四方面，本申请实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行如第一方面和第二方面所述的业务请求处理方法。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。
图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请求信息可以确定目标应用信息和后端即服务(Backend as a Service,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服务交互，进行业务处理。
示例三：
移动互联网应用经常会面对突发流量场景，例如：移动应用的通常流量情况是QPS 20，但每隔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。
本申请实施例包括：业务请求处理方法，应用于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应用的业务处理时效要求。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于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中任意一项所述的业务请求处理方法。
PCT/CN2022/124173 2021-10-19 2022-10-09 业务请求处理方法、网络设备及计算机可读存储介质 WO2023066053A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111216218.7 2021-10-19
CN202111216218.7A CN116016644A (zh) 2021-10-19 2021-10-19 业务请求处理方法、网络设备及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2023066053A1 true WO2023066053A1 (zh) 2023-04-27

Family

ID=86021596

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/124173 WO2023066053A1 (zh) 2021-10-19 2022-10-09 业务请求处理方法、网络设备及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN116016644A (zh)
WO (1) WO2023066053A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116743585A (zh) * 2023-08-10 2023-09-12 中国电子投资控股有限公司 一种基于云原生的多租户api网关服务暴露系统及方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190075154A1 (en) * 2017-09-01 2019-03-07 Futurewei Technologies, Inc. Warm start technique for cloud-hosted functions
US10572315B1 (en) * 2016-08-29 2020-02-25 Amazon Technologies, Inc. Application programming interface state management
US20200081745A1 (en) * 2018-09-10 2020-03-12 Nuweba Labs Ltd. System and method for reducing cold start latency of serverless functions
US20200213279A1 (en) * 2018-12-21 2020-07-02 Futurewei Technologies, Inc. Mechanism to reduce serverless function startup latency
CN111541760A (zh) * 2020-04-20 2020-08-14 中南大学 基于无服务器雾计算系统架构的复杂任务分配方法
CN113296792A (zh) * 2020-07-10 2021-08-24 阿里巴巴集团控股有限公司 存储方法、装置、设备、存储介质和系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10572315B1 (en) * 2016-08-29 2020-02-25 Amazon Technologies, Inc. Application programming interface state management
US20190075154A1 (en) * 2017-09-01 2019-03-07 Futurewei Technologies, Inc. Warm start technique for cloud-hosted functions
US20200081745A1 (en) * 2018-09-10 2020-03-12 Nuweba Labs Ltd. System and method for reducing cold start latency of serverless functions
US20200213279A1 (en) * 2018-12-21 2020-07-02 Futurewei Technologies, Inc. Mechanism to reduce serverless function startup latency
CN111541760A (zh) * 2020-04-20 2020-08-14 中南大学 基于无服务器雾计算系统架构的复杂任务分配方法
CN113296792A (zh) * 2020-07-10 2021-08-24 阿里巴巴集团控股有限公司 存储方法、装置、设备、存储介质和系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116743585A (zh) * 2023-08-10 2023-09-12 中国电子投资控股有限公司 一种基于云原生的多租户api网关服务暴露系统及方法
CN116743585B (zh) * 2023-08-10 2023-11-07 中国电子投资控股有限公司 一种基于云原生的多租户api网关服务暴露系统及方法

Also Published As

Publication number Publication date
CN116016644A (zh) 2023-04-25

Similar Documents

Publication Publication Date Title
WO2020207267A1 (zh) 网络系统、镜像管理方法、设备及存储介质
US11645582B2 (en) Parameter sharing in federated learning
CN109358967B (zh) 一种me平台app实例化迁移方法及服务器
US10481921B2 (en) Cloud platform, application running method, and access network unit
CN113342478A (zh) 资源管理方法、设备、网络系统及存储介质
KR20180124419A (ko) 분산형 클라우드 기반 어플리케이션 실행 시스템, 이에 적용되는 장치 및 장치의 동작 방법
US11422865B2 (en) Dynamic workload migration to edge stations
US11627169B2 (en) Network-based Media Processing (NBMP) workflow management through 5G Framework for Live Uplink Streaming (FLUS) control
WO2023066053A1 (zh) 业务请求处理方法、网络设备及计算机可读存储介质
CN113301079B (zh) 一种数据的获取方法、系统、计算设备及存储介质
US20130132590A1 (en) Managing Session Data of a Composite Service Session in a Communication Network
US11645109B2 (en) Managing failures in edge computing environments
CN115865874A (zh) 一种会议消息推送方法、会议服务端及电子设备
US20230283695A1 (en) Communication Protocol for Knative Eventing's Kafka components
US20200153749A1 (en) Biased selection of dedicated physical connections to provider network
WO2023001083A1 (zh) 服务提供方法、系统、网关、设备和存储介质
CN107948337B (zh) 电子文件传输方法、装置、系统及计算机可读存储介质
Rocha et al. CNS-AOM: design, implementation and integration of an architecture for orchestration and management of cloud-network slices
EP4000239B1 (en) 3rd generation partnership project (3gpp) framework for live uplink streaming (flus) sink capabilities determination
CN112187916B (zh) 一种跨系统的数据同步方法与装置
CN113783963A (zh) 数据传输方法、服务器节点、网关设备、网络系统
WO2023078234A1 (zh) 基于分布式云网络的控制代码执行的方法、设备及系统
Femminella et al. An edge abstraction layer enabling federated and hierarchical orches‑tration of CCAM services in 5G and beyond net‑works
CN114510282B (zh) 一种自动化应用的运行方法、装置、设备以及存储介质
CN113114560B (zh) 司机端即时通信方法、司机端和司乘系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22882663

Country of ref document: EP

Kind code of ref document: A1