WO2025162296A1 - Cloud service request processing method and system - Google Patents

Abstract

The present application relates to the technical field of cloud services, and discloses a cloud service request processing method and system. The cloud service request processing system comprises an interaction component, a plug-in framework, plug-in management components and at least one plug-in. The interaction component is used for acquiring a cloud service request sent by a tenant and providing the cloud service request for the plug-in framework, the cloud service request being used for requesting a server to provide a cloud service for the tenant; the plug-in framework is used for operating on the basis of the cloud service request and sending a plug-in access request to the plug-in management components, wherein the plug-in access request indicates access to a first plug-in used for processing the cloud server request, and the first plug-in is one of the at least one plug-in; the plug-in management components are used for accessing the first plug-in on the basis of the plug-in access request to obtain access results, and feeding back the access results to the plug-in framework; and the plug-in framework is further used for obtaining a processing result for the cloud service request on the basis of the access results. The present application ensures the operation security and stability of the plug-in framework.

Description

Cloud service request processing method and system

This application claims priority to Chinese patent application No. 202410137693.2, filed on January 31, 2024, with the invention name “Management system for cloud service plug-ins”, and priority to Chinese patent application No. 202410231608.9, filed on February 29, 2024, with the invention name “Cloud service request processing method and system”, the entire contents of which are incorporated by reference into this application.

Technical Field

The present application relates to the field of cloud service technology, and in particular to a cloud service request processing method and system.

Background Art

In the cloud service field, when a tenant needs a server to provide cloud services, they can send a cloud service request to the server through their client. After receiving the cloud service request, the server can process the cloud service request and provide cloud services to the tenant based on the processed cloud service request.

Currently, servers typically use plugin frameworks and plugins to process cloud service requests. For example, servers using sidecar proxies to process cloud service requests typically use plugin frameworks and plugins. Plugins used by plugin frameworks are statically linked to the plugin framework.

In this case, if you need to modify the plug-in, such as dynamically loading or updating the plug-in, you need to restart the entire plug-in framework after modifying the plug-in, which will affect the business that is relying on the plug-in framework.

Summary of the Invention

This application provides a cloud service request processing method and system. This application isolates the plug-in framework from the framework, so that the plug-in framework and plug-ins do not affect each other, ensuring the security and stability of the plug-in framework operation. The technical solutions provided by this application are as follows:

In a first aspect, the present application provides a cloud service request processing system. The cloud service request processing system is deployed in a server managed by a cloud management platform. The cloud management platform is used to manage the infrastructure for providing cloud services. The infrastructure includes multiple servers. The cloud service request processing system includes: an interactive component, a plug-in framework, a plug-in management component, and at least one plug-in associated with the plug-in framework. The interactive component is used to obtain the cloud service request sent by the tenant and provide the cloud service request to the plug-in framework. The cloud service request is used to request the server to provide cloud services to the tenant; the plug-in framework is used to run based on the cloud service request and send a plug-in access request to the plug-in management component. The plug-in access request indicates access to a first plug-in used to process cloud server requests. The first plug-in is one of at least one plug-in; the plug-in management component is used to access the first plug-in based on the plug-in access request, obtain an access result, and feedback the access result to the plug-in framework; the plug-in framework is also used to obtain a processing result for the cloud service request based on the access result.

In the process of processing cloud service requests by the cloud service request processing system, since the plug-in is managed by the plug-in management component, when the plug-in needs to be run, the plug-in framework needs to first send a plug-in access request to the plug-in management component. After receiving the plug-in access request, the plug-in management component accesses the plug-in based on the plug-in access request. In this way, the operation of the plug-in framework and the operation of the plug-in belong to different processes, which is equivalent to achieving isolation between the plug-in framework and the plug-in, so that the plug-in framework and the plug-in will not affect each other, ensuring the security and stability of the plug-in framework operation. When a tenant needs to modify a plug-in, such as dynamically loading or updating a plug-in, there is no need to restart the entire plug-in framework, so that the behavior of modifying the plug-in will not affect the plug-ins managed by other plug-in management components, and will not affect the tenant business that relies on the other plug-ins to run. Similarly, when a plug-in runs abnormally, it will not affect the plug-in framework, and will not affect the plug-ins managed by other plug-in management components associated with the plug-in framework.

In one possible implementation, the cloud service request processing system further includes an access proxy component. The plug-in framework is specifically configured to send plug-in access requests to the access proxy component, which in turn causes the access proxy component to send plug-in access requests to the plug-in management component. When interaction between the plug-in framework and the plug-in management component is implemented through the access proxy component, the access proxy component isolates the plug-in framework from the plug-in management component. If a plug-in fails to start or encounters an error during operation, the plug-in management component returns an error message to the access proxy component without causing any problems with the access proxy component or affecting the plug-in framework, thereby further ensuring the security and stability of the plug-in framework's operation.

In one possible implementation, the interaction component is further configured to obtain a tenant's plugin loading request and forward the plugin loading request to the plugin management component, the plugin loading request instructing the loading of a first plugin; the plugin management component is further configured to load the first plugin based on the plugin loading request. Because the first plugin is loaded by the plugin management component, the operation of the plugin framework and the operation of the plugin are separate processes, effectively isolating the plugin framework from the plugin. This ensures that the plugin loading process does not affect the operation of the plugin framework, and furthermore, the plugin loading process does not affect other plugins managed by the plugin management component, thus enabling dynamic loading of plugins.

In one possible implementation, the cloud service request processing system further includes: another plug-in management component. In this case, the plug-in management component is specifically configured to: send a plug-in acquisition request to the plug-in registration component based on the plug-in loading request, the plug-in acquisition request indicating the acquisition of a first plug-in, the plug-in registration component being used to store all plug-ins required to process cloud service requests; receive a plug-in acquisition response from the plug-in registration component, the plug-in acquisition response carrying indication information of another plug-in management component, or the plug-in acquisition response carrying indication information of the storage address of the first plug-in in the plug-in registration component; and acquire the first plug-in based on the indication in the plug-in acquisition response, and load the first plug-in.

When the plug-in management component downloads the executable code of the first plug-in from the other plug-in management components, it can reduce the download pressure of the plug-in registration component and reduce the network traffic of the plug-in registration component. The more plug-in management components the cloud service request processing system includes, the more obvious this effect is.

In one possible implementation, the plug-in management component is further used to: obtain an update request indicating an update to the first plug-in; obtain an updated version of the first plug-in from other plug-in management components based on the update request, or obtain an updated version from the plug-in registration component; and update the first plug-in based on the updated version.

When the plug-in management component downloads the updated version of the first plug-in from the other plug-in management components, it can reduce the download pressure of the plug-in registration component and reduce the network traffic of the plug-in registration component. When the cloud service request processing system includes more plug-in management components, this effect is more obvious.

In a possible implementation, the update request is sent by the plug-in registration component. For example, after storing the updated version of the first plug-in, the plug-in registration component spontaneously sends an update request to the plug-in management component to prompt the plug-in management component to update the first plug-in.

In another implementation, the update request is sent by the interaction component to the plug-in registration component. For example, the interaction component can receive a plug-in update instruction from a tenant and, after receiving the tenant's plug-in update instruction, send an update request to the plug-in management component based on the plug-in update instruction. The plug-in update instruction is used to instruct an update of the first plug-in.

In one possible implementation, the plug-in management component is further used to send an update notification to the first plug-in before the plug-in management component updates the first plug-in based on the updated version, the update notification indicating that the first plug-in needs to be updated; the first plug-in is further used to provide the plug-in management component with running information of the first plug-in based on the update notification; the plug-in management component is further used to store the running information; the plug-in management component is further used to provide the first plug-in with running information after the plug-in management component updates the first plug-in based on the updated version; the first plug-in is further used to run based on the running information.

Before updating the first plug-in, the running information of the first plug-in is saved through the plug-in management component, so that after the update of the first plug-in is completed, the first plug-in can continue to run according to the running state before the update, and the running state of the first plug-in before and after the update can be guaranteed to be continuous, so that tenants and businesses are unaware of the update process.

In one possible implementation, when a plug-in management component downloads the executable code of a first plug-in from another plug-in management component, the plug-in management component and the other plug-in management component are used to manage plug-ins belonging to the same tenant. This allows plug-in management components belonging to the same tenant to download the executable code of each other's plug-ins, while plug-in management components belonging to different tenants cannot download the executable code of each other's plug-ins, thereby ensuring the isolation of plug-ins between different tenants.

In one possible implementation, the transmission delay between other plug-in management components and the plug-in management component is shorter than the transmission delay between the plug-in registration component and the plug-in management component. This allows the plug-in management component to download the executable code of the first plug-in locally, shortening the time it takes to load the first plug-in, thereby shortening the preparation time of the first plug-in and reducing tenant access delays.

In one possible implementation, the plugin registration component includes a system registration subcomponent and a tenant registration subcomponent. The cloud service request processing system registration subcomponent is used to store the executable code of the cloud service request processing system plugin, while the tenant registration subcomponent is used to store the executable code of the tenant plugin. Tenants do not have access to the cloud service request processing system registration subcomponent. This allows for separate management of system plugins and tenant plugins, and sets a higher security level for system plugins to prevent malicious tenants from tampering with trusted system plugins, thereby ensuring the security of system plugins.

In one possible implementation, the cloud service request processing system is used to process cloud service requests from multiple tenants. The cloud service request processing system includes multiple plug-in management components corresponding to the multiple tenants. The plug-in management components are used to manage the plug-ins belonging to the corresponding tenants, and all plug-ins managed by any plug-in management component belong to the same tenant. That is, each tenant has its own plug-in management component. The plug-in management component owned by any tenant is used to manage the plug-ins belonging to the tenant, and the plug-in management components belonging to different tenants are used to manage the plug-ins of different tenants. In this way, since different plug-in management components run in different processes, the plug-ins managed by different plug-in management components belong to different processes, which achieves isolation between plug-ins belonging to different tenants, making it impossible for a plug-in of one tenant to access the plug-ins of other tenants, thereby improving access security in a multi-tenant situation.

In one possible implementation, a plug-in framework is used to process cloud service requests from multiple cloud services. Cloud service requests for a target cloud service are processed by running the plug-in framework and the corresponding plug-in for the target cloud service, which can be any of the multiple cloud services. In this case, multiple cloud services share the plug-in framework, and by dynamically loading the plug-in associated with the plug-in framework, the plug-in framework's startup memory usage is minimal, and the time required to load plug-ins is shortened, thereby reducing the impact on user access latency.

In one possible implementation, the cloud service request processing system includes multiple plug-in frameworks and at least one plug-in management component belonging to the same tenant, and the multiple plug-in frameworks are used to implement the same function. In response to the cloud service request processing system including a plug-in management component of the same tenant, multiple plug-in frameworks share one plug-in management component. At this time, the plug-in management component is shared by different plug-in frameworks in the server. In this case, since the calls of multiple plug-in frameworks to the plug-ins managed by the shared plug-in management component are all recorded by the plug-in management component, the status of the multiple plug-in frameworks can be guaranteed to be unified. In response to the cloud service request processing system including multiple plug-in management components of the same tenant, at least some of the multiple plug-in frameworks use one plug-in management component separately. At this time, the plug-in framework has exclusive use of the plug-in management component.

In a second aspect, the present application provides a cloud service request processing method. The cloud service request processing method is applied to a cloud service request processing system. The cloud service request processing system is deployed in a server managed by a cloud management platform. The cloud management platform is used to manage the infrastructure for providing cloud services. The infrastructure includes multiple servers. The cloud service request processing system includes: an interactive component, a plug-in framework, a plug-in management component, and at least one plug-in associated with the plug-in framework. The cloud service request processing method includes: the interactive component obtains the cloud service request sent by the tenant and provides the cloud service request to the plug-in framework, the cloud service request is used to request the server to provide cloud services to the tenant; the plug-in framework runs based on the cloud service request and sends a plug-in access request to the plug-in management component, the plug-in access request indicates access to a first plug-in used to process cloud server requests, the first plug-in being one of at least one plug-in; the plug-in management component accesses the first plug-in based on the plug-in access request, obtains an access result, and feeds back the access result to the plug-in framework; the plug-in framework obtains a processing result for the cloud service request based on the access result.

In one possible implementation, the cloud service request processing system also includes: an access proxy component, and the plug-in framework sends a plug-in access request to the plug-in management component, including: the plug-in framework sends a plug-in access request to the access proxy component, so that the access proxy component sends a plug-in access request to the plug-in management component.

In one possible implementation, before the plug-in management component accesses the first plug-in based on the plug-in access request, the cloud service request processing method also includes: the interactive component obtains the tenant's plug-in loading request and forwards the plug-in loading request to the plug-in management component, where the plug-in loading request indicates loading the first plug-in; the plug-in management component loads the first plug-in based on the plug-in loading request.

In one possible implementation, the cloud service request processing system further includes: other plug-in management components. The plug-in management component loads the first plug-in based on the plug-in loading request, including: the plug-in management component sends a plug-in acquisition request to the plug-in registration component based on the plug-in loading request, the plug-in acquisition request instructing to acquire the first plug-in, and the plug-in registration component is used to store all plug-ins required to process the cloud service request; the plug-in management component receives a plug-in acquisition response sent by the plug-in registration component, the plug-in acquisition response carries indication information of other plug-in management components, or the plug-in acquisition response carries indication information of the storage address of the first plug-in in the plug-in registration component; the plug-in management component acquires the first plug-in based on the indication of the plug-in acquisition response and loads the first plug-in.

In one possible implementation, after the plug-in management component loads the first plug-in, the cloud service request processing method further includes: the plug-in management component obtains an update request indicating an update to the first plug-in; the plug-in management component obtains an updated version of the first plug-in from other plug-in management components based on the update request, or obtains the updated version from the plug-in registration component; and the plug-in management component updates the first plug-in based on the updated version.

In one possible implementation, the update request is sent by the plug-in registration component; or, the cloud service request processing method also includes: the interaction component obtains the tenant's plug-in update indication, and sends an update request to the plug-in management component based on the plug-in update indication, where the plug-in update indication is used to indicate an update to the first plug-in.

In one possible implementation, before the plug-in management component updates the first plug-in based on the updated version, the cloud service request processing method further includes: the plug-in management component sending an update notification to the first plug-in, the update notification indicating that the first plug-in needs to be updated; the first plug-in providing the plug-in management component with operating information of the first plug-in based on the update notification; and the plug-in management component storing the operating information. After the plug-in management component updates the first plug-in based on the updated version, the cloud service request processing method further includes: the plug-in management component providing the operating information to the first plug-in; and the first plug-in running based on the operating information.

In a possible implementation, the plug-in management component and other plug-in management components are used to manage plug-ins of the same tenant.

In a possible implementation, the transmission delay between other plug-in management components and the plug-in management component is smaller than the transmission delay between the plug-in registration component and the plug-in management component.

In one possible implementation, the plug-in registration component includes a system registration sub-component and a tenant registration sub-component. The cloud service request processing system registration sub-component is used to store the executable code of the cloud service request processing system plug-in, and the tenant registration sub-component is used to store the executable code of the tenant plug-in. The tenant does not have access to the cloud service request processing system registration sub-component.

In one possible implementation, the cloud service request processing system is used to process cloud service requests from multiple tenants. The cloud service request processing system includes multiple plug-in management components corresponding to the multiple tenants. The plug-in management components are used to manage plug-ins belonging to the corresponding tenants, and all plug-ins managed by any plug-in management component belong to the same tenant.

In one possible implementation, the plug-in framework is used to process cloud service requests for multiple cloud services, and processing cloud service requests for a target cloud service is achieved by running the plug-in framework and a plug-in corresponding to the target cloud service, where the target cloud service is any one of the multiple cloud services.

In one possible implementation, the cloud service request processing system includes multiple plug-in frameworks and at least one plug-in management component belonging to the same tenant. The multiple plug-in frameworks are used to implement the same function. In response to the cloud service request processing system including a plug-in management component of the same tenant, the multiple plug-in frameworks share a plug-in management component. In response to the cloud service request processing system including multiple plug-in management components of the same tenant, at least some of the multiple plug-in frameworks use a plug-in management component separately.

In a third aspect, the present application provides a computing device comprising a memory and a processor, wherein the memory stores program instructions, and the processor executes the program instructions to implement the system provided in the first aspect of the present application and any possible implementation thereof.

In a fourth aspect, the present application provides a computing device cluster, comprising multiple computing devices, wherein the multiple computing devices include multiple processors and multiple memories, wherein the multiple memories store program instructions, and the multiple processors execute the program instructions, so that the computing device cluster implements the system provided in the first aspect of the present application and any possible implementation thereof.

In a fifth aspect, the present application provides a computer-readable storage medium, which is a non-volatile computer-readable storage medium. The computer-readable storage medium includes program instructions. When the program instructions are executed on a computing device, the computing device implements the system provided in the first aspect of the present application and any possible implementation thereof.

In a sixth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to implement the system provided in the first aspect of the present application and any possible implementation thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of a plug-in provided in an embodiment of the present application, wherein the plug-in is statically compiled into the binary of the plug-in framework;

FIG2 is a schematic diagram of a structure of an implementation scenario involved in a cloud service request processing method provided in an embodiment of the present application;

FIG3 is a schematic diagram of the deployment of basic resources in a data center provided by an embodiment of the present application;

FIG4 is a schematic diagram of a cloud service request processing system provided in an embodiment of the present application;

FIG5 is a flow chart of a cloud service request processing method executed by a cloud service request processing system provided in an embodiment of the present application;

FIG6 is a schematic diagram of another cloud service request processing system provided in an embodiment of the present application;

FIG7 is a flowchart of another cloud service request processing system performing a cloud service request processing method provided by an embodiment of the present application;

FIG8 is a flowchart of loading a first plug-in provided in an embodiment of the present application;

FIG9 is a schematic diagram of another cloud service request processing system provided in an embodiment of the present application;

10 is a flowchart of a plug-in management component loading a first plug-in based on a plug-in loading request provided by an embodiment of the present application;

FIG11 is a flowchart of updating a first plug-in provided in an embodiment of the present application;

12 is a flowchart of a plug-in management component updating a first plug-in based on an updated version provided by an embodiment of the present application;

FIG13 is a schematic diagram of another cloud service request processing system provided in an embodiment of the present application;

FIG14 is a flowchart of an L7 data plane calling plug-in provided in an embodiment of the present application;

FIG15 is a flowchart of a plug-in loading method provided in an embodiment of the present application;

FIG16 is a flowchart of an update plug-in provided in an embodiment of the present application;

FIG17 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

FIG18 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

FIG19 is a schematic diagram of the structure of another computing device cluster provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

To facilitate understanding, the technology and background involved in the embodiments of this application are first introduced below.

A cloud data center is an internet-based network that provides operational maintenance facilities and related service systems for centralized data collection, storage, processing, and transmission. Conceptually, it can be understood as a public, commercial Internet "computer room." It also provides a professional information technology (IT) service and is a critical infrastructure for the IT industry. A cloud data center is not only a service concept but also a network concept. It forms part of the network infrastructure, much like backbone and access networks, providing high-end data delivery and high-speed access services.

Plug-ins: After a software project is developed and its application is delivered for use, adding new functionality often requires integrating it into the existing application without modifying it. This is known as plug-inization, and the functional module used to implement the new functionality is called a plug-in. Plug-ins significantly reduce the coupling between functional modules, facilitate independent maintenance of each module, and improve the efficiency of software project maintenance and updates. A plug-in must rely on the application to function; it cannot function properly on its own.

A plug-in framework is a basic functional module within a plug-in application. A plug-in framework can be considered a reusable design for an entire or partial application. Another definition states that a plug-in framework is an application skeleton that can be customized by application developers. For example, a plug-in framework is an architecture formed by extracting the common parts of software in a specific field during the development of a software project. It is responsible for implementing the more basic functions of an application, such as downloading, installing, loading, and uninstalling plug-ins. For example, in the field of cloud computing, the common parts of multiple cloud services can be extracted into a plug-in framework. Any of the multiple cloud services can be implemented by running the plug-in framework and the plug-in of any cloud service.

Currently, as shown in Figure 1, plugins (such as the C++ plugin and cgo plugin in Figure 1) are statically compiled into the plugin framework binary. Therefore, if a tenant modifies a plugin, such as dynamically loading or updating it, the entire plugin framework must be restarted, impacting tenants' services that rely on the plugin framework. Furthermore, the existing plugin framework image must be replaced with a new one that uses the plugin framework.

For example, with the increasing application of service mesh technology in cloud computing, when deploying cloud services, the non-functional service governance logic of distributed applications in cloud service architectures is increasingly being separated from business processes and moved to sidecar processes outside the process. This provides inter-service connectivity, security, flow control, grayscale release, and observation capabilities in a non-invasive manner, achieving lightweight business and service governance infrastructure. In the cloud service field, the sidecar proxy can be used to intercept cloud service requests sent by tenants. Cloud service requests are used to request servers to provide cloud services to tenants. The sidecar proxy then processes the cloud service request and provides the processed cloud service request to the cloud service executor (such as a server). Taking Layer 7 (L7) governance as an example, the sidecar proxy's processing of cloud service requests includes load balancing cloud service requests, limiting the flow of cloud service requests, and observing the call chain and call time of cloud services.

The sidecar proxy processes cloud service requests using a plugin framework and plugins. In this context, the sidecar is also called a sidecar proxy. When the sidecar proxy implements Layer 7 governance, it is also called an L7 proxy or L7 data plane. The sidecar supports a variety of plugins to handle customer connections and requests. Plugins are available in native languages, such as C++ and CGO. Plugins must be statically linked to the sidecar before use. Therefore, once compiled, the C++ and CGO plugins available to the sidecar are fixed. If a tenant modifies a plugin, they must upload a new proxy image and replace the existing sidecar proxy. This requires a sidecar proxy restart and can impact ongoing tenant services. Furthermore, when the plugin framework is shared by multiple cloud services, since plugins are statically linked to the framework, a plugin failure in one cloud service can cause issues across the entire plugin framework, impacting other cloud services that share the same plugin framework. Similarly, when the plugin framework is shared by multiple tenants, a plugin failure in one tenant can cause issues across the entire plugin framework, impacting access by other tenants that share the same plugin framework. For example, in a Layer 4 (L4)/Layer 7 (L7) separation model, the L7 agent will be centrally deployed and elastically expanded. Each L7 agent can be accessed by multiple tenants, and each tenant's custom C++ plug-in is statically linked directly to the L7 agent. Because the plug-in is statically linked to the L7 agent, it cannot be dynamically updated. In addition, due to the large size of the executable code of the L7 agent plug-in, it takes a long time to load the plug-in. During the operation of the L7 agent, if a tenant's plug-in is unstable, it will cause the entire L7 agent to crash, affecting the access of other tenants, and the scope of the explosion is uncontrollable.

Based on this, an embodiment of the present application provides a cloud service request processing method and system. The cloud service request processing system is deployed in a server managed by a cloud management platform. The cloud management platform is used to manage the infrastructure that provides cloud services. The infrastructure includes multiple servers. The cloud service request processing method and system are used to process cloud service requests. The cloud service request is used to request the server to provide cloud services to tenants. The cloud service request processing system includes: an interactive component, a plug-in framework, at least one plug-in associated with the plug-in framework, and a plug-in management component. The process of the cloud service request processing system processing the cloud service request includes: the interactive component obtains the cloud service request sent by the tenant and provides the cloud service request to the plug-in framework; the plug-in framework runs based on the cloud service request and sends a plug-in access request to the plug-in management component, the plug-in access request indicates access to a first plug-in used to process cloud server requests, the first plug-in being one of at least one plug-in; the plug-in management component accesses the first plug-in based on the plug-in access request, obtains an access result, and feeds back the access result to the plug-in framework; the plug-in framework obtains a processing result for the cloud service request based on the access result.

In the cloud service request processing system, since the plug-in is managed by the plug-in management component, when the plug-in needs to be run, the plug-in framework needs to first send a plug-in access request to the plug-in management component. After receiving the plug-in access request, the plug-in management component accesses the plug-in based on the plug-in access request. In this way, the operation of the plug-in framework and the operation of the plug-in belong to different processes, which is equivalent to achieving isolation between the plug-in framework and the plug-in, so that the plug-in framework and the plug-in will not affect each other, ensuring the security and stability of the plug-in framework operation. When a tenant needs to modify a plug-in, such as dynamically loading or updating a plug-in, there is no need to restart the entire plug-in framework, so that the behavior of modifying the plug-in will not affect the plug-ins managed by other plug-in management components, and thus will not affect the tenant business that relies on the other plug-ins to run. Similarly, when a plug-in runs abnormally, it will not affect the plug-in framework, and will not affect the plug-ins managed by other plug-in management components associated with the plug-in framework.

This article provides a detailed introduction to the technical solution of this application from multiple perspectives, including implementation scenarios, method flow, hardware devices, and software devices.

The following first illustrates the application scenarios of the embodiments of the present application.

Figure 2 is a structural diagram of an implementation scenario involving a cloud service request processing method provided in an embodiment of the present application. As shown in Figure 2, the implementation environment includes: a data center 1 and a client 2. A communication connection can be established between the data center 1 and the client 2 through a network. Optionally, the network can be the Internet or other networks, which is not limited in the embodiment of the present application. Tenants can interact with the data center 1 through the client 2. For example, the tenant can send information such as a cloud service request to the data center 1 through the client 2. The data center 1 is used to respond based on the information sent by the client 2 to the data center 1.

A large amount of infrastructure owned by the cloud service provider is deployed in the data center 1, such as computing resources, storage resources, and network resources. For example, computing resources can be computing devices (such as servers, etc.) that can provide computing capabilities. As shown in Figure 2, the data center 1 includes a cloud management platform and infrastructure (not shown in Figure 2). The cloud management platform and the infrastructure are connected through the internal network of the data center. The cloud management platform is used to manage the infrastructure. The infrastructure is used to provide public cloud services. The basic settings include multiple servers. Cloud services can be optionally deployed in the server. Tenants can send cloud service requests to the server through the client 2 they use, and the server can process the cloud service request and provide cloud services based on the processed cloud service request. For example, the server can process the cloud service request through the cloud service request processing method provided in the embodiment of the present application.

The cloud management platform can be divided into the following logical functionalities: tenant console, computing management service, network management service, storage management service, authentication service, and image management service. The tenant console provides an interface or application program interface (API) to interact with tenants. The computing management service is used to manage servers running virtual instances and bare metal servers. The network management service is used to manage network services (such as gateways, firewalls, etc.). The storage management service is used to manage storage services (such as data bucket services). The authentication service is used to manage tenant accounts and passwords. The image management service is used to manage the images of virtual instances.

In the implementation scenario shown in Figure 2, multiple servers are deployed in a data center. The server consists of a hardware layer and a software layer. The hardware layer is the standard configuration of the server. The hardware layer deploys hardware devices such as processors, memory, network cards, disks, and buses. The software layer includes the operating system installed and running on the server. The operating system of the virtual machine is called the host operating system. The host operating system runs a virtual machine manager (also called a hypervisor). The role of the virtual machine manager is to implement computing virtualization, network virtualization, and storage virtualization for the virtual machine, and is responsible for managing the virtual machine.

The cloud management platform client runs within the virtual machine manager. The cloud management platform client receives control plane commands from the cloud management platform, creates virtual instances on servers based on these commands, and manages the virtual instances throughout their lifecycle. For example, the cloud management platform client monitors the hardware resource usage of the server in real time and reports this information to the cloud management platform. When the cloud management platform confirms the creation of a virtual instance on a server, it sends a virtual instance creation command to the cloud management platform client on that server. Upon receiving this command, the cloud management platform client creates the virtual instance on that server. This allows tenants to create, manage, log in to, and operate virtual instances in the data center through the cloud management platform.

Servers can be used to run virtual machines of varying specifications. Virtual machine specifications are categorized as general-purpose computing, memory-optimized, and ultra-large memory, with each type further defined. After a tenant selects a virtual machine specification, the cloud management platform selects a server in the data center that supports that specification, determines if the server has sufficient available hardware resources, and then creates a virtual machine with that specification on that server. Configuring servers through the cloud management platform allows for analysis and planning of server hardware resources. Based on the server's hardware performance, computing products corresponding to the physical hardware can be planned, such as virtual machines of varying specifications, to meet the differentiated needs of different tenants. Furthermore, the performance differences between virtual machines of varying specifications can enable differentiated pricing strategies. For example, virtual instances with high performance specifications can be sold at a higher price, while those with standard performance specifications can be sold at a lower price, allowing tenants to purchase virtual instances on demand.

In one implementation, as shown in Figure 3, the location of basic resources within a data center can be described using cloud resource deployment regions and availability zones (AZs). Tenants can optionally deploy cloud services based on resources in specific regions and AZs. Regions are defined based on geographic location and network latency. Within a region, the same resource pool is used, which can be understood as sharing public services such as elastic compute, block storage, object storage, virtual private cloud (VPC) networks, Elastic Internet Protocol (EIP) addresses, and images. Regions are categorized as general regions and dedicated regions. General regions provide general cloud services to public tenants. Dedicated regions are dedicated regions that carry the same type of business or provide services to specific tenants. A region typically includes multiple AZs. AZs within a region are connected by high-speed fiber optic cables to meet tenants' needs for building high-availability systems across AZs. An AZ is a collection of one or more data centers, as shown in Figure 3. Compute, network, and storage resources within an AZ are logically divided into multiple clusters.

Tenants can send instructions to the cloud management platform through the client 2 they use to create, manage, log in and operate virtual instances in the server, and use the cloud services provided by the virtual instances. For example, the cloud management platform can provide an access interface. The access interface can be optionally provided in the form of an interface or an API. Tenants can operate the client to remotely access the access interface to register a cloud account and password on the cloud management platform, and use the cloud account and password to log in to the cloud management platform. The cloud management platform can also authenticate the cloud account and password. After successful authentication, the tenant can further select and pay to purchase a virtual instance of specific specifications (processor, memory, disk) on the cloud management platform. After the tenant successfully pays for the virtual instance, the cloud management platform provides the tenant with the remote login account and password of the purchased virtual instance. The tenant can use the remote login account and password to remotely log in to the virtual instance on the client, install and run the tenant's application in the virtual instance, and implement the tenant's business through the application.

Client 2 may be a computer, a personal computer, a laptop computer, a mobile phone, a smart phone, a tablet computer, a cloud host, a portable mobile terminal, a multimedia player, an e-book reader, a wearable device, a smart home appliance, an artificial intelligence device, a smart wearable device, a smart vehicle-mounted device or an Internet of Things device, etc.

In one implementation, the cloud service request processing method provided in the embodiment of the present application can be implemented by running an executable program on a computing device in the data center 1. Optionally, the cloud service request processing method provided in the embodiment of the present application can be optionally applied to a cloud service request processing system. The cloud service request processing system is deployed in a server managed by a cloud management platform. The cloud service request processing system can implement the cloud service request processing method provided in the embodiment of the present application by running the executable program of the cloud service request processing method provided in the embodiment of the present application. Moreover, the executable program that implements the cloud service request processing method can be optionally presented in the form of an application installation package. After the server installs the application installation package, it can implement the cloud service request processing method provided in the embodiment of the present application by running the executable program therein.

It should be understood that the above content is an exemplary description of the implementation scenario of the cloud service request processing method provided in the embodiment of the present application, and does not constitute a limitation on the implementation scenario of the cloud service request processing method. A person of ordinary skill in the art will know that as business needs change, its implementation scenario can be adjusted according to application requirements. For example, the present application can be applied to all application scenarios of service grid transparent proxy, and the embodiment of the present application does not make specific limitations on it. Moreover, when the cloud service request processing method provided in the embodiment of the present application is applied to other scenarios, the executable program of the method can also be presented in the form of an application installation package or in other ways, and the embodiment of the present application does not list them one by one.

The following describes the cloud service request processing system provided by an embodiment of the present application and the implementation process of the cloud service request processing method thereof. The cloud service request processing system is deployed in a server managed by a cloud management platform and is used to process cloud service requests. The cloud service request is used to request the server to provide cloud services to tenants. Figure 4 is a schematic diagram of a cloud service request processing system provided by an embodiment of the present application. As shown in Figure 4, the cloud service request processing system 10 includes: an interactive component 101, a plug-in framework 102, a plug-in management component 103 and at least one plug-in 104 associated with the plug-in framework 102. As shown in Figure 5, the implementation process of the cloud service request processing system executing the cloud service request processing method includes:

Step 501: The interactive component obtains a cloud service request sent by a tenant and provides the cloud service request to the plug-in framework. The cloud service request is used to request a server to provide cloud services to the tenant.

When a tenant needs to use a cloud service, they can perform a specified operation on their client to trigger a cloud service request. The client can then submit the cloud service request to the server providing the cloud service. After the client submits the cloud service request to the server, the interaction component can retrieve the cloud service request. In one implementation, the cloud service request processing system is part of the cloud service provision system. In this case, the interaction component is a component of the cloud service provision system, and all requests sent by the tenant to the cloud service provision system are received by the interaction component. In another implementation, the cloud service request processing system is not part of the cloud service provision system. For example, when the cloud service provision system is deployed on a server, the server also hosts the cloud service request processing system. All requests sent to the cloud service provision system can optionally be processed by the cloud service request processing system before being sent to the cloud service provision system. In this case, the interaction component can intercept requests sent by the tenant to the cloud service provision system. For example, the interaction component intercepts cloud service requests sent by the tenant to the cloud service provision system. The cloud service request is triggered when a tenant needs to use cloud services by performing a specified operation on the client used by the tenant. The cloud service request is used to instruct the cloud service provision system deployed in the server to provide cloud services to the tenant.

Optionally, according to different cloud service requirements, cloud service requests may also be processed by other systems in advance. For example, the cloud service request processing system of the present application and the other system may be systems that process cloud server requests according to different goals, and the processing process of the cloud service request by the other system needs to be executed before the processing process of the cloud service request processing system. In this case, the cloud service request received by the interactive component has been processed by the other system. For example, in the L4/L7 separation mode, assuming that the cloud service request needs to be processed by the L4 proxy first, and then the L7 proxy processes the processed cloud service request, the cloud service request received by the interactive component is the cloud service request processed by the L4 proxy.

During the cloud service request processing system's processing of a cloud service request, the plug-in framework needs to run based on the cloud service request and, during this process, invoke the plug-in to process the cloud service request. Based on the plug-in's processing results, the plug-in framework can obtain the cloud service request processing system's processing results. Therefore, after receiving the cloud service request, the interactive component needs to provide the cloud service request to the plug-in framework so that the plug-in framework can process it. In one possible implementation, the interactive component can optionally serve as an input component of the cloud service request processing system.

Step 502: The plug-in framework runs based on the cloud service request and sends a plug-in access request to the plug-in management component, where the plug-in access request indicates access to a first plug-in for processing the cloud server request, where the first plug-in is one of the at least one plug-in.

After the plug-in framework obtains the cloud service request, it can run based on the cloud service request and call the plug-in during the running process. In the present application, since the plug-in management component is used to manage the plug-in, the plug-in framework calls the plug-in to send a plug-in access request to the plug-in management component through the plug-in framework, and then the plug-in management component accesses the plug-in based on the plug-in access request. For example, with the development of service grid technology, the non-functional service governance logic of many cloud services has been stripped from the business process to the external car process. When the non-functional service governance logic is used to process the cloud service request, the non-functional service governance logic can be implemented by the cloud service request processing system, the plug-in framework of the system is used to implement the basic functions of the non-functional service governance logic, and the plug-in of the system is used to implement the additional functions of the non-functional service governance logic. For a certain cloud service, its non-functional service governance logic can be implemented by running the plug-in framework and at least part of the plug-in of the plug-in framework. In one implementation, the plug-in framework can obtain a correspondence between a plug-in management component and the plug-ins it manages. When the plug-in framework determines that it needs to access a first plug-in, it can determine the plug-in management component that manages the first plug-in based on the correspondence and send a plug-in access request to the plug-in management component. The first plug-in can be a system-owned plug-in (i.e., a system plug-in) or a plug-in provided to a tenant (i.e., a tenant plug-in, such as a tenant-defined plug-in). This embodiment of the present application does not specifically limit this.

In this application, a plug-in framework can be used to process cloud service requests for one or more cloud services. When the plug-in framework is used to process cloud service requests for a specific cloud service, the plug-in framework and corresponding plug-in must be executed to process the cloud service request for that cloud service. The corresponding plug-in is a plug-in that implements a specified processing function. When the plug-in framework is used to process cloud service requests for multiple cloud services, processing cloud service requests for a target cloud service is achieved by running the plug-in framework and the plug-in corresponding to the target cloud service. The target cloud service is any one of the multiple cloud services. The plug-in corresponding to the target cloud service is a plug-in that processes cloud service requests for the target cloud service and implements the specified processing function. For example, in service mesh technology, if the basic functionality of the non-functional service governance logic of multiple cloud services is the same, this basic functionality is used to process cloud service requests for multiple cloud services, and this basic functionality can be implemented by the same plug-in framework. Furthermore, the plug-in framework is configured with multiple plug-ins, each corresponding to a plurality of cloud services. The plug-in corresponding to a particular cloud service is used to implement additional functionality of the non-functional service governance logic of that cloud service. In this case, multiple cloud services share the same plugin framework and dynamically load the plugins associated with it. This reduces the startup memory footprint of the plugin framework and the time it takes to load plugins, minimizing the impact on user access latency. Furthermore, because the underlying non-functional service governance logic for multiple cloud services is implemented by the same plugin framework, this deployment approach is also known as centralized plugin framework deployment.

Similarly, the cloud service request processing system can be used to process cloud service requests from one or more tenants. In this case, the cloud service request processing system accordingly includes multiple plug-in management components corresponding to the multiple tenants. Each plug-in management component is used to manage plug-ins belonging to the corresponding tenant, and all plug-ins managed by any plug-in management component belong to the same tenant. That is, each tenant has its own plug-in management component. The plug-in management component owned by any tenant is used to manage plug-ins belonging to that tenant, and plug-in management components belonging to different tenants are used to manage plug-ins belonging to different tenants. In this way, since different plug-in management components run in different processes, plug-ins managed by different plug-in management components belong to different processes, achieving isolation between plug-ins belonging to different tenants. This prevents a plug-in from one tenant from accessing plug-ins from other tenants, thereby improving access security in a multi-tenant environment. For example, by isolating plug-ins belonging to different tenants, plug-ins belonging to malicious tenants can be isolated from plug-ins belonging to other tenants. This prevents malicious tenants from damaging plug-ins from other tenants, reduces the security risk of plug-ins, and helps ensure the safe operation of plug-ins.

In addition, the cloud service request processing system may optionally include multiple plug-in frameworks and at least one plug-in management component belonging to the same tenant. The multiple plug-in frameworks are configured to implement the same functionality. In response to the cloud service request processing system including multiple plug-in management components belonging to the same tenant, at least some of the multiple plug-in frameworks independently utilize a single plug-in management component. When a plug-in framework independently utilizes a single plug-in management component, the plug-in frameworks have exclusive access to the plug-in management component. In response to the cloud service request processing system including a plug-in management component belonging to the same tenant, the multiple plug-in frameworks may share a single plug-in management component. For example, a server may deploy multiple plug-in frameworks and a plug-in management component belonging to the same tenant. In this case, the plug-in management component is shared by different plug-in frameworks within the server. In this case, since calls to plug-ins managed by the shared plug-in management component by multiple plug-in frameworks are all recorded by the plug-in management component, the unified state of the multiple plug-in frameworks can be ensured. Optionally, shared memory may be used to store information indicating whether the plug-in management component has been started and the address information of the plug-in management component, enabling the plug-in management component to be shared by different plug-in frameworks.

It should be noted that the plug-ins of the cloud service request processing system usually include system plug-ins and tenant plug-ins. The plug-in management component that manages the system plug-in is also called the system plug-in management component. The tenant plug-in is also called the tenant plug-in management component. The system plug-in is the plug-in that comes with the cloud service request processing system and has higher security and stability. The tenant plug-in is the plug-in uploaded by the tenant, and its security and stability performance are slightly worse. Therefore, the plug-in framework can still optionally access the plug-in that comes with the system through the in-process access of the plug-in framework, and the plug-in framework can optionally access the tenant plug-in through the plug-in management component. At this time, since the system plug-in can be called by the plug-in framework through the function address, the access to the system plug-in is in-process access, which can ensure higher plug-in performance.

In one possible implementation, as shown in FIG6 , the cloud service request processing system 10 further includes: an access proxy component 105. At this time, the interaction between the plug-in framework 102 and the plug-in management component 103 can be implemented through the access proxy component 105. For example, the plug-in framework sends a plug-in access request to the plug-in management component, including: the plug-in framework sends a plug-in access request to the access proxy component, and the access proxy component sends a plug-in access request to the plug-in management component. Then, as shown in FIG7 , step 502 includes steps 5021 and 5022. Step 5021, the plug-in framework runs based on the cloud service request and sends a plug-in access request to the access proxy component. Step 5022, the access proxy component sends a plug-in access request to the plug-in management component. It should be noted that, as shown in FIG6 , since the system plug-in has high security and stability, the interaction between the plug-in framework 102 and the system plug-in management component 103 is optional and does not need to be implemented through the access proxy component 105.

The plug-in framework sends a plug-in access request to the access proxy component. From the perspective of the plug-in framework, its implementation method is basically the same as the method of the existing plug-in framework accessing the plug-in. In one possible implementation method, the access proxy component and the plug-in framework are functional modules running in the same process. At this time, the communication between the plug-in framework and the access proxy component is intra-process communication. For example, the access proxy component is a stub. The access proxy component sends a plug-in access request to the plug-in management component. The access proxy component is required to first parse the plug-in access request sent by the plug-in framework into a data packet, and then determine the plug-in that the plug-in framework instructs to access according to the instructions of the data packet, and then determine the plug-in management component that manages the plug-in, and then send the plug-in access request to the plug-in management component. Among them, the plug-in access request can indicate the first plug-in that the plug-in framework requests to access and the methods and related parameters therein. In one possible implementation method, the access proxy component sends a plug-in access request to the plug-in management component, which is equivalent to converting the plug-in access request sent by the plug-in framework into a socket request, and then sending the socket request to the plug-in management component. It can be implemented through interprocess communication (IPC) or shared memory (SHM). For example, interprocess communication can be implemented using UNIX domain sockets (UDS), which is an IPC mechanism developed on the socket framework. In this way, in order to access the plug-in through the access proxy component, the improvement to the plug-in framework mainly involves modifying the plug-in framework's call extension to the access proxy component. The modification to the plug-in framework is relatively small, which can reduce the development pressure on plug-in framework developers. In addition, when the interaction between the plug-in framework and the plug-in management component is implemented through the access proxy component, the access proxy component isolates the plug-in framework from the plug-in management component. When the plug-in fails to start or an error occurs during operation, the plug-in management component will return information indicating the execution error to the access proxy component without causing any problems with the access proxy component or affecting the plug-in framework, thereby ensuring the security and stability of the plug-in framework operation.

Step 503: The plug-in management component accesses the first plug-in based on the plug-in access request, obtains an access result, and feeds back the access result to the plug-in framework.

After the plug-in management component obtains the plug-in access request, it can determine the first plug-in and the method and related parameters therein that the plug-in framework requests to access, and then access the first plug-in based on them. After the plug-in management component obtains the access result of the first plug-in, it needs to feedback the access result to the plug-in framework. When the cloud service request processing system includes an access proxy component, the plug-in management component can also feedback the access result to the plug-in framework through the access proxy component. For example, the plug-in management component feeds back the access result to the plug-in framework, including: the plug-in management component sends the access result to the access proxy component, and the access proxy component sends the access result to the plug-in framework. As shown in Figure 7, step 503 includes steps 5031 and 5032. Step 5031, the plug-in management component accesses the first plug-in based on the plug-in access request, obtains the access result, and sends the access result to the access proxy component. Step 5032, the access proxy component sends the access result to the plug-in framework. For its implementation method, please refer to the relevant description in step 502, which will not be repeated here.

Step 504: The plug-in framework obtains a processing result for the cloud service request based on the access result.

After obtaining the access result of the first plug-in, the plug-in framework can obtain the processing result of the cloud service request based on the access result. For example, depending on the plug-in framework's different processing procedures for cloud service requests, the plug-in framework can use the access result as the processing result of the cloud service request. Alternatively, after receiving the processing result, the plug-in framework needs to perform an operation based on the processing result and use the operation result as the processing result of the cloud service request.

In the process of processing cloud service requests by the cloud service request processing system, since the plug-in is managed by the plug-in management component, when the plug-in needs to be run, the plug-in framework needs to first send a plug-in access request to the plug-in management component. After receiving the plug-in access request, the plug-in management component accesses the plug-in based on the plug-in access request. In this way, the operation of the plug-in framework and the operation of the plug-in belong to different processes, which is equivalent to achieving isolation between the plug-in framework and the plug-in, so that the plug-in framework and the plug-in will not affect each other, ensuring the security and stability of the plug-in framework operation. When a tenant needs to modify a plug-in, such as dynamically loading or updating a plug-in, there is no need to restart the entire plug-in framework, so that the behavior of modifying the plug-in will not affect the plug-ins managed by other plug-in management components, and will not affect the tenant business that relies on the other plug-ins to run. Similarly, when a plug-in runs abnormally, it will not affect the plug-in framework, and will not affect the plug-ins managed by other plug-in management components associated with the plug-in framework.

Before using the first plug-in, the plug-in management component needs to load the first plug-in first. The implementation process of loading the first plug-in is described below. As shown in Figure 8, the implementation process of loading the first plug-in includes the following steps:

Step 801: The interaction component obtains a tenant's plug-in loading request and forwards the plug-in loading request to the plug-in management component. The plug-in loading request indicates loading a first plug-in.

When a tenant needs to use the first plug-in to process a cloud service request, he can perform a specified operation on the client he uses to trigger a plug-in loading request indicating that the first plug-in should be loaded. The client can provide the plug-in loading request to the server used to provide the cloud service. After the client provides the plug-in loading request to the server, the interactive component can obtain the plug-in loading request. Since the plug-in is managed by the plug-in management component, and the management includes loading the plug-in, after the interactive component obtains the plug-in loading request, it needs to forward the plug-in loading request to the plug-in management component so that the plug-in management component loads the first plug-in based on the plug-in loading request. In one implementation, the plug-in framework can obtain the correspondence between the plug-in management component and the plug-in it manages. When the plug-in framework determines that the first plug-in needs to be loaded, it can determine the plug-in management component that manages the first plug-in based on the correspondence, and send a plug-in loading request to the plug-in management component.

Step 802: The plug-in management component loads the first plug-in based on the plug-in loading request.

After receiving a plugin load request, the plugin management component can load the first plugin based on the plugin load request. Because the first plugin is loaded by the plugin management component, the plugin framework and the plugin run in different processes, effectively isolating the plugin framework from the plugin. This ensures that the plugin loading process does not affect the plugin framework's operation, and thus does not affect other plugins managed by the plugin management component, enabling dynamic plugin loading.

After obtaining the plug-in loading request, the plug-in management component may first query whether it has cached the executable code of the first plug-in based on the plug-in loading request. When it has cached the executable code of the first plug-in, it loads the first plug-in based on the executable code of the first plug-in. When it does not cache the executable code of the first plug-in, it needs to obtain the executable code of the first plug-in first. In one possible implementation, the plug-in management component may obtain the executable code of the first plug-in from the plug-in registration component or other plug-in management components. The plug-in registration component is used to store all plug-ins required to process cloud service requests. At this time, as shown in Figure 9, the cloud service request processing system 10 also includes: other plug-in management components 103. The plug-in registration component may belong to the cloud service request processing system, or the plug-in registration component may be independent of the cloud service request processing system. For example, the plug-in registration component is a separate cloud service provided by the cloud management platform. Figure 9 is a schematic diagram of the plug-in registration component 20 being independent of the cloud service request processing system 10. At this time, as shown in Figure 10, its implementation process includes:

Step 8021: The plug-in management component sends a plug-in acquisition request to the plug-in registration component based on the plug-in loading request, where the plug-in acquisition request indicates acquiring the first plug-in.

Since the plug-in registration component is used to store all plug-ins required to process cloud service requests, when the plug-in management component does not cache the executable code of the first plug-in, the plug-in management component can first send a plug-in acquisition request to the plug-in registration component to obtain the acquisition address of the first plug-in. In order to facilitate the plug-in registration component to determine the plug-in that the plug-in management component needs to obtain, the plug-in acquisition request carries the indication information of the first plug-in. When the cloud service request processing system is started, the cloud service administrator can specify the access address of the plug-in registration component to the plug-in management component. After the plug-in management component obtains the plug-in loading request, it can send a plug-in acquisition request to the plug-in registration component based on the access address of the plug-in registration component.

Before the plug-in management component sends a plug-in acquisition request to the plug-in registration component, if there is no communication connection between the plug-in management component and the plug-in registration component, the plug-in management component needs to establish a communication connection with the plug-in registration component first. The communication connection can be optionally a secure sockets layer (SSL) connection. In the process of establishing the communication connection, two-way security authentication is required between the plug-in management component and the plug-in registration component to ensure the security of the communication connection. For example, the plug-in registration component and the plug-in management component can issue security certificates to each other and verify each other's security certificates. In one implementation method, when the cloud service administrator loads the tenant configuration to the cloud service request processing system, the cloud service administrator also sends the tenant's security certificate to the plug-in framework. The security certificate can be forwarded by the access proxy component to the plug-in management component corresponding to the tenant. After receiving the security certificate, the plug-in management component can cache the security certificate for subsequent use.

Step 8022: The plug-in management component receives a plug-in acquisition response sent by the plug-in registration component. The plug-in acquisition response carries indication information of other plug-in management components, or the plug-in acquisition response carries indication information of the storage address of the first plug-in in the plug-in registration component.

After receiving the plugin acquisition component, the plugin registration component queries whether any other plugin management component has downloaded the executable code for the first plugin. If any other plugin management component has downloaded the executable code for the first plugin, the plugin registration component may prioritize providing the plugin management component with information indicating the other plugin management component. If no other plugin management component has downloaded the executable code for the first plugin, the plugin registration component provides the plugin management component with information indicating the storage address of the first plugin's executable code within the plugin registration component. This information may optionally be included in the plugin acquisition response to the plugin acquisition request. The other plugin management component may be deployed on the same server as the plugin management component, or located in the same network segment as the plugin management component. The plugin registration component prioritizes providing the plugin management component with information indicating the other plugin management component that has downloaded the executable code for the first plugin, enabling the plugin management component to preferentially download the executable code for the first plugin from these other plugin management components. This reduces the plugin registration component's download pressure and network traffic. This effect is more pronounced when the cloud service request processing system includes more plugin management components.

Optionally, when other plug-in management components have downloaded the executable code of the first plug-in, the indication information may optionally indicate other plug-in management components that are closest to the plug-in management component. This closest distance is manifested as the smallest transmission delay to the plug-in management component. Alternatively, the indication information may optionally indicate multiple other plug-in management components that are relatively close to the plug-in management component. For example, the indication information indicates multiple other plug-in management components, and the multiple other plug-in management components are sorted according to the distance to the plug-in management component. Furthermore, the distance from the plug-in management component to the other plug-in management components indicated by the indication information may optionally be smaller than the distance from the plug-in management component to the plug-in registration component. For example, the transmission delays from the multiple other plug-in management components to the plug-in management component are all smaller than the transmission delays from the remaining other plug-in management components to the plug-in management component, and are all smaller than the transmission delay from the plug-in management component to the plug-in registration component. In this way, it is convenient for the plug-in management component to download the executable code of the first plug-in nearby, shorten the time taken to load the first plug-in, and thereby shorten the preparation time of the first plug-in and reduce the access delay of the tenant.

When the cloud service request processing system includes multiple plug-in management components corresponding to multiple tenants, and any plug-in management component is used to manage plug-ins belonging to the corresponding tenant, and all plug-ins managed by any plug-in management component belong to the same tenant, the plug-in management component and the other plug-in management component are used to manage plug-ins belonging to the same tenant. In this way, plug-in management components belonging to the same tenant can download executable code for plug-ins from each other, while plug-in management components belonging to different tenants cannot download executable code for plug-ins from each other, thereby ensuring the isolation of plug-ins between different tenants.

Step 8023: The plug-in management component obtains the first plug-in based on the plug-in acquisition response indication, and loads the first plug-in.

After obtaining the instruction information carried in the plug-in acquisition response, the plug-in management component may obtain the executable code of the first plug-in based on the instruction in the instruction information. For example, the plug-in management component may download the executable code of the first plug-in from the other plug-in management components indicated by the instruction information. If the instruction information indicates multiple other plug-in management components, the plug-in management component may optionally select one of the other plug-in management components and download the executable code of the first plug-in from the selected other plug-in management component. For example, the selected other plug-in management component may be the one closest to the plug-in management component among the multiple other plug-in management components indicated in the instruction information. Alternatively, the selected other plug-in management component may be the one closest to the plug-in management component among the multiple other plug-in management components determined by the plug-in management component through detection. When the plug-in management component downloads the executable code of the first plug-in from the other plug-in management component or the plug-in registration component in accordance with the instruction information, the plug-in management component may also optionally send its security credentials to the other plug-in management component or the plug-in registration component to facilitate security verification of the plug-in management component by the other plug-in management component or the plug-in registration component. For example, the security credentials may be a token of the plug-in management component.

Among them, as shown in Figure 9, the plug-in registration component 20 optionally includes a system registration sub-component 201 and a tenant registration sub-component 202. The system registration sub-component 201 is used to store the executable code of the cloud service request processing system plug-in. Then the first sub-component is also called the system plug-in library. The tenant registration sub-component 202 is used to store the executable code of the tenant plug-in. Then the tenant registration sub-component 202 is also called the tenant plug-in library. Since the system plug-in has higher security and stability, it can be set that the tenant does not have access to the system registration sub-component 201, so as to manage the system plug-in and the tenant plug-in separately, and set the system plug-in to have a higher security level to prevent malicious tenants from tampering with the trusted system plug-in, thereby ensuring the security of the system plug-in.

After the plug-in management component loads the first plug-in, it may be necessary to update the first plug-in. The following describes the implementation process of updating the first plug-in. As shown in Figure 11, the implementation process of updating the first plug-in includes the following steps:

Step 1101: The plug-in management component obtains an update request instructing to update a first plug-in.

There are multiple ways to implement an update request. The present application uses two implementations as examples to illustrate these. In one implementation, the update request is sent by the plug-in registration component. For example, after storing an updated version of a first plug-in, the plug-in registration component spontaneously sends an update request to the plug-in management component to prompt the plug-in management component to update the first plug-in. For example, a tenant may upload an updated version of a first plug-in to the plug-in registration component. After receiving the updated version of the first plug-in, the plug-in registration component sends an update request to all plug-in management components that have loaded the first plug-in, prompting all plug-in management components to update the first plug-in. In this case, after the plug-in management component establishes a communication connection with the plug-in registration component, the communication connection can be maintained to facilitate the plug-in registration component sending the update request to the plug-in management component. In another implementation, the update request is sent by the interaction component to the plug-in registration component. For example, the interaction component can receive a plug-in update instruction from the tenant and, after obtaining the tenant's plug-in update instruction, send an update request to the plug-in management component based on the plug-in update instruction. The plug-in update instruction is used to indicate an update for the first plug-in. For example, a tenant can perform a specified operation on the client they use to trigger a plug-in update instruction. The client can then send the plug-in update instruction to the interaction component, which then prompts the plug-in management component to update the first plug-in through the plug-in update instruction. Optionally, regardless of which of the above implementations the update request uses, the update request can only indicate an update for the first plug-in. Alternatively, the update request also carries a download address for the updated version of the first plug-in. The update request can also carry the version number of the first plug-in to indicate the version of the first plug-in.

Step 1102: The plug-in management component obtains an updated version of the first plug-in from another plug-in management component based on the update request, or obtains an updated version from a plug-in registration component.

After receiving the update request, the plug-in management component needs to obtain the updated version of the first plug-in. The implementation logic for the plug-in management component to obtain the updated version of the first plug-in is similar to the logic for obtaining the executable code of the first plug-in before loading the first plug-in. That is, if another plug-in management component has downloaded the updated version of the first plug-in, the plug-in management component prioritizes downloading the updated version of the first plug-in from the other plug-in management component. If no other plug-in management component has downloaded the updated version of the first plug-in, the plug-in management component downloads the updated version of the first plug-in from the plug-in registration component. In this case, if the update request carries the download address of the updated version of the first plug-in, the download address can be the address of another plug-in management component that has downloaded the updated version of the first plug-in, or the download address of the updated version of the first plug-in stored in the plug-in registration component. If the update request only indicates an update for the first plug-in, the plug-in management component also needs to send a plug-in query request to the plug-in registration component to query the download address of the updated version of the first plug-in. Alternatively, the plug-in management component can send a query request to another plug-in management component with which it has a communication connection to inquire whether the other plug-in management component has downloaded the updated version of the first plug-in. The plug-in registration component can send a query response to the plug-in management component based on the query request. If another plug-in management component has downloaded an updated version of the first plug-in, the query response provides the plug-in management component with the address of the other plug-in management component that has downloaded the updated version of the first plug-in. If no other plug-in management component has downloaded an updated version of the first plug-in, the query response provides the plug-in management component with the storage address of the updated version of the first plug-in in the plug-in registration component. For the implementation process, please refer to the relevant description in step 802 and will not be repeated here.

It should be noted that after the plug-in management component receives the update request sent by the plug-in registration component, it can optionally determine whether the first plug-in needs to be updated according to a preset update policy. If it is determined that the first plug-in needs to be updated, step 1102 is executed. If it is determined that the first plug-in does not need to be updated, step 1102 is not executed.

Step 1103: The plug-in management component updates the first plug-in based on the updated version.

After obtaining the updated version of the first plug-in, the plug-in management component may update the first plug-in based on the updated version. Optionally, before the plug-in management component updates the first plug-in, the first plug-in may save its running state. After completing the update of the first plug-in, the plug-in may retrieve the running state and continue running based on the running state. In one implementation, as shown in Figure 12, the implementation process includes: Step 11031: Before the plug-in management component updates the first plug-in based on the updated version, the plug-in management component sends an update notification to the first plug-in, where the update notification indicates that the first plug-in needs to be updated. Step 11032: Based on the update notification, the first plug-in provides the plug-in management component with its running information. Step 11033: The plug-in management component stores the running information and updates the first plug-in based on the updated version. Step 11034: After the plug-in management component updates the first plug-in based on the updated version, the plug-in management component provides the running information to the first plug-in. Step 11035: The first plug-in runs based on the running information.

After the plug-in management component obtains the updated version of the first plug-in, it may optionally call back the plug-in preparation update function to the first plug-in. In response, if the first plug-in needs to save its own runtime information, it may call the plug-in management component's interface and provide the plug-in management component with the first plug-in's runtime information through this interface. After receiving this runtime information, the plug-in management component saves it. The plug-in management component then uninstalls the first plug-in and loads the updated version of the first plug-in, completing the update of the first plug-in. After completing the update of the first plug-in, the plug-in management component calls the restore callback of the updated first plug-in and, based on this restore callback, provides the saved runtime information to the updated first plug-in. After obtaining this runtime information, the updated first plug-in restores the state of the first plug-in before the update based on this runtime information. The runtime information indicates the runtime status of the first plug-in. As shown in Figure 13, the plug-in management component 103 includes a state cache module 1031 and a plug-in cache module 1032. The state cache module 1031 is used to store the plug-in's runtime information, and the plug-in cache module 1032 is used to cache the plug-in's executable code. Optionally, the running information may be stored in the form of key-value pairs (eg, key=value).

Before updating the first plug-in, the running information of the first plug-in is saved through the plug-in management component, so that after the update of the first plug-in is completed, the first plug-in can continue to run according to the running state before the update, and the running state of the first plug-in before and after the update can be guaranteed to be continuous, so that tenants and businesses are unaware of the update process.

Below, we take the L4/L7 separation mode, where the cloud service request processing system is implemented through the L7 proxy of the service grid as an example to illustrate the implementation process of this application.

In L4/L7 separation scenarios, the L7 proxy is typically a data plane proxy within a centralized hosting cluster, with each L7 processing cloud service requests from different tenants. The plugin framework of the cloud service request provisioning system in this application is implemented via the L7 data plane. The L7 data plane binary does not contain trusted system C++ plugins or tenant C++ plugins. When the L7 data plane is started, the cloud service administrator must specify the access address of the plugin registration component to the L7 data plane and issue the service grid's security certificate to the L7 data plane. If a system plugin management component is created in the L7 data plane, this security certificate can be cached in the system plugin management component. This allows the L7 data plane and the plugin registration component to perform bidirectional security authentication based on this security certificate when the L7 data plane queries and downloads plugins from the plugin registration component on demand. To load tenant C++ plugin configurations into the L7 data plane, the cloud service administrator must also issue the tenant certificate to the L7 data plane. If a tenant plugin management component is created in the L7 data plane, this tenant certificate can be cached in the tenant plugin management component. The tenant certificate is used for bidirectional verification between the tenant plug-in management component and the plug-in registration component when connecting to it. The system plug-in management component manages system C++ plug-ins. The tenant plug-in management component manages tenant C++ plug-ins. The system plug-in management component is launched during the startup of the L7 data plane. The system plug-in management component and the L7 data plane are co-processed. After loading the system C++ plug-in, the system plug-in management component can be called by the L7 data plane within the process using a function address for optimal performance.

As shown in Figure 14, when a tenant creates a container (pod), a cloud service for that tenant is created by the cloud management platform (see service in Figure 14). The cloud service's control plane integrates the L7 data plane configuration and sends the tenant configuration and tenant certificate to the L7 data plane. The tenant configuration indicates the C++ plug-in used by the tenant and its configuration information, enabling the L7 data plane to distinguish between system C++ plug-ins and tenant C++ plug-ins based on the tenant configuration. After the configuration is complete, the L7 data plane loads the system C++ plug-in. Before loading the system C++ plug-in, if the system plug-in management component has the system C++ plug-in's executable code cached, the system plug-in management component can directly load the system C++ plug-in based on that executable code. If the system plug-in management component does not have the system C++ plug-in's executable code cached, the system plug-in management component must establish an SSL connection with the plug-in registration component and download the system C++ plug-in's executable code through this SSL connection. Furthermore, the L7 data plane must create a stub access proxy component. If the tenant has not yet created a tenant plugin management component, the L7 data plane is responsible for creating one and specifying the access proxy component stub for subsequent communication with the tenant plugin management component. This communication can utilize inter-process communication technologies such as UDS and SHM. The L7 data plane also sends the tenant's certificate to the tenant plugin management component. The tenant plugin management component is responsible for retrieving and loading the tenant's C++ plugin. Before loading the tenant C++ plugin, if the tenant plugin management component has the tenant C++ plugin's executable code cached in it, the tenant plugin management component can directly load the tenant C++ plugin based on that executable code. If the tenant plugin management component does not have the tenant C++ plugin's executable code cached in it, the tenant plugin management component establishes an SSL connection with the plugin registration component and downloads the tenant C++ plugin's executable code through that SSL connection. After loading the tenant C++ plugin, the L7 data plane completes service configuration based on the loading results. After the L7 data plane receives a cloud service request, if a system C++ plugin is required to process the cloud service request, the L7 data plane calls the corresponding system C++ plugin to handle the cloud service request. If a tenant C++ plugin is required to process the cloud service request, the L7 data plane sends a plugin access request to the tenant plugin management component via the access proxy stub. The tenant plugin management component then calls the tenant C++ plugin and returns a call structure to the L7 data plane via the access proxy stub to process the cloud service request. If the plugin fails to start, the tenant plugin management component returns an error message to the access proxy stub. During communication with the plugin management component, the access proxy stub also performs operations such as serialization and deserialization on the communication messages, depending on the inter-process communication method used.

As can be seen from this implementation, each plugin management component manages plugins belonging to the same tenant. Connections with the plugin registration component also use the tenant's own certificate for security authentication, and tenant plugins are isolated from system plugins. This prevents malicious tenant plugins from contaminating system plugins or other tenant plugins, while also ensuring that crashes or malicious code in a tenant plugin will not affect the normal operation of the system plugin, other tenant plugins, or the L7 data plane.

As shown in Figure 15 , when a plug-in needs to be loaded, both the system plug-in management component and the tenant plug-in management component first check whether the plug-in's executable code already exists in the local cache. If the plug-in's executable code is not cached locally, it first establishes a secure connection with the plug-in registration component and uses this secure connection to query the plug-in. It then downloads the plug-in's executable code based on the response returned by the plug-in registration component. After downloading the plug-in's executable code, the plug-in management component can cache it and use it to load the plug-in. If another plug-in management component has already downloaded the plug-in's executable code, the response returned by the plug-in registration component includes information indicating the other plug-in management component. If the response includes information indicating multiple other plug-in management components, the plug-in management component can optionally select another plug-in management component based on the node address and subnet address. When downloading the plug-in's executable code from another plug-in management component, the plug-in management component establishes a communication connection with the other plug-in management component based on its address and, through this communication connection, downloads the plug-in's executable code from its cache. If no other plug-in management component has downloaded the executable code of the first plug-in, the plug-in registration component returns a response that includes information indicating the storage address of the first plug-in's executable code in the plug-in registration component. When the plug-in management component is a tenant plug-in management component, the other plug-in management component and the plug-in management component belong to the same tenant, thus ensuring isolation between plug-ins from different tenants. The plug-in management component and the plug-in registration component establish a connection using either a system certificate or a tenant certificate. For example, when the plug-in to be loaded is a tenant plug-in, the plug-in management component passes the tenant certificate to the plug-in registration component. The plug-in registration component uses the tenant certificate to determine the source tenant of the connection, that is, the tenant's identity. Based on this identity, it then filters plug-ins that do not belong to the tenant and provides the plug-in management component with the executable code of the plug-in to be loaded. Tenants can upload the plug-in's executable code to the plug-in registration component via the console, and this executable code carries tenant information. After receiving the executable code, the plug-in registration component can save the executable code based on the tenant information it carries. When the plug-in to be loaded is a tenant plug-in, the response returned by the plug-in registration component also includes the tenant's token. When the plug-in management component downloads the executable code of the plug-in from the plug-in registration component in accordance with the response, the plug-in management component may optionally send the token to the plug-in registration component so that the plug-in registration component can authenticate the tenant based on the token. Alternatively, the plug-in management component may not send the token to the plug-in registration component. In this case, the plug-in management component may send the tenant certificate to the plug-in registration component so that the plug-in registration component can authenticate the tenant based on the tenant certificate. When the plug-in registration management component authenticates the tenant, it may also register the plug-in management component. Similarly, when other plug-in management components need to download the executable code of the plug-in, their download process is also performed with reference to this implementation method.

According to the implementation process, the cloud service request processing system of the present application can not only realize the dynamic loading of plug-ins, but also ensure the plug-in download requirements of tenant isolation when the plug-in management component downloads the plug-in executable code from other nearby plug-in management components, and the other plug-in management components and the plug-in management component belong to the same user, thereby improving the download speed of plug-ins, reducing the preparation time of plug-ins, and reducing the network download traffic of plug-in registration components, thereby realizing the diversion of network download traffic of plug-in registration components. For example, when a new service is created for a tenant, a large number of plug-in management components need to download the executable code of the plug-in. At this time, by downloading the executable code of the plug-in from other nearby plug-in management components, the download traffic can be diverted.

As shown in Figure 16, when a tenant updates a plug-in version through the console, the plug-in registration component obtains the updated version, caches it, and updates the plug-in's related information, such as the latest version number. The plug-in registration component also sends an update notification to all plug-in management components that have downloaded the plug-in. After receiving the update notification, the plug-in management component can optionally determine whether to update the plug-in based on a preconfigured update policy. If the plug-in management component determines to retain the plug-in based on the update policy, it will not update the plug-in. If the plug-in management component determines to update the plug-in based on the update policy, it can query other connected plug-in management components belonging to the same tenant to see if they have already downloaded the updated version of the plug-in. If other plug-in management components have already downloaded the updated version of the plug-in, the plug-in management component will download the updated version directly from them. If none of the other plug-in management components have downloaded the updated version, the plug-in management component will download the updated version from the plug-in registration component or from other plug-in management components recommended by the plug-in management component. The plug-in will then be updated based on the updated version. In another scenario, the tenant can instruct the plug-in management component to update the plug-in through the console. For example, a tenant sends an update request to the Plugin Management component through the console. The Plugin Management component then sends a plugin update query request to the Plugin Registration component and downloads the updated plugin version based on the Plugin Registration component's response. The implementation of downloading the updated plugin version based on the response is described in the Plugin Management component's description of downloading the updated plugin version based on the update notification, and is not detailed here.

After the plug-in management component downloads the updated version of the plug-in, the plug-in management component can first call back the plug-in preparation update function to the plug-in. At this time, in response, if the first plug-in needs to save its own running information, the first plug-in can call the interface of the plug-in management component and provide the running information of the first plug-in to the plug-in management component through the interface. After receiving the running information, the plug-in management component saves it. Then the plug-in management component uninstalls the old version of the first plug-in and loads the updated version of the first plug-in to update the first plug-in. After completing the update of the first plug-in, the plug-in management component calls the recovery callback of the updated first plug-in and provides the saved running information to the updated first plug-in based on the recovery callback. After the updated first plug-in obtains the running information, it recovers to the state before the first plug-in was updated based on the running information.

In addition, after the plug-in management component establishes a connection with other plug-in management components of the same tenant, the connection can be used for mutual query and is not limited to being used only for sending messages from the plug-in management component that actively establishes the connection.

According to the implementation process, the cloud service request processing system of the present application supports plug-in upgrades during operation, and saves the operation information of the first plug-in through the plug-in management component, so that after the update of the first plug-in is completed, the first plug-in can continue to run according to the operation status before the update, and can ensure the continuity of the operation status of the first plug-in before and after the update, so that tenants and businesses are unaware of the update process.

As can be seen from the above, in the cloud service request processing system provided by this application, since plug-ins are managed by the plug-in management component, when a plug-in needs to be run, the plug-in framework must first send a plug-in access request to the plug-in management component. After receiving the plug-in access request, the plug-in management component then accesses the plug-in based on the plug-in access request. This ensures that the operation of the plug-in framework and the operation of the plug-in are separate processes, effectively isolating the plug-in framework from the plug-in. This prevents the plug-in framework and the plug-in from interfering with each other, ensuring the security and stability of the plug-in framework's operation. When a tenant needs to modify a plug-in, such as dynamically loading or updating a plug-in, there is no need to restart the entire plug-in framework. This ensures that the modification does not affect other plug-ins managed by the plug-in management component, and thus does not affect tenant services that rely on these other plug-ins. Similarly, when a plug-in fails to operate properly, it does not affect the plug-in framework or the plug-ins managed by other plug-in management components associated with the plug-in framework. For example, even if a tenant's plug-in crashes, it only causes the restart of the tenant's plug-in management component, without affecting access by other tenants or causing a restart of the L7 data plane.

It should be noted that the order of the steps in the cloud service request processing method provided in the embodiments of the present application can be adjusted appropriately, and the steps can be increased or decreased accordingly. The types and functions of the components included in the cloud service request processing can also be adjusted and increased or decreased appropriately. Any method that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application, and therefore will not be described in detail.

The interaction component 101, plug-in framework 102, plug-in management component 103, plug-in 104, access proxy component 105, and plug-in registration component 20 can all be implemented via software or hardware. By way of example, the implementation of the interaction component 101 will be described below using the interaction component 101 as an example. Similarly, the implementation of the plug-in framework 102, plug-in management component 103, plug-in 104, access proxy component 105, and plug-in registration component 20 can refer to the implementation of the interaction component 101.

As an example of a software functional unit, the interaction component 101 may include code running on a computing instance, wherein the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container.

As an example of a hardware functional unit, the interaction component 101 may include a computing device, such as a server. Alternatively, the interaction component 101 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

It should be noted that in other embodiments, any one of the interaction component 101, plug-in framework 102, plug-in management component 103, plug-in 104, access proxy component 105, and plug-in registration component 20 can be used to execute any step in the cloud service request processing method. The steps that the interaction component 101, plug-in framework 102, plug-in management component 103, plug-in 104, access proxy component 105, and plug-in registration component 20 are responsible for implementing can be specified as needed. By having the interaction component 101, plug-in framework 102, plug-in management component 103, plug-in 104, access proxy component 105, and plug-in registration component 20 respectively implement different steps in the cloud service request processing method, the full functionality of the cloud service request processing device is realized.

Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the various components described above can refer to the corresponding contents in the aforementioned method embodiments and will not be repeated here.

The following is an example of the basic hardware structure involved in the embodiments of the present application.

This application also provides a computing device 1700. As shown in Figure 17, computing device 1700 includes a bus 1702, a processor 1704, a memory 1706, and a communication interface 1708. Processor 1704, memory 1706, and communication interface 1708 communicate with each other via bus 1702. Computing device 1700 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 1700.

Bus 1702 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Buses can be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG17 shows a single line, but this does not imply a single bus or type of bus. Bus 1704 may include a path for transmitting information between various components of computing device 1700 (e.g., memory 1706, processor 1704, and communication interface 1708).

Processor 1704 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

The memory 1706 may include volatile memory, such as random access memory (RAM). The processor 1704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

Memory 1706 stores executable program code. Processor 1704 executes this executable program code to implement the functions of the aforementioned interaction component 101, plug-in framework 102, plug-in management component 103, plug-in 104, and access proxy component 105, thereby implementing the cloud service request processing method. In other words, memory 1706 stores instructions for executing the cloud service request processing method.

The communication interface 1703 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1700 and other devices or a communication network.

Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

As shown in Figure 18, the computing device cluster includes at least one computing device 1700. The memory 1706 in one or more computing devices 1700 in the computing device cluster may store the same instructions for executing the cloud service request processing method.

In some possible implementations, the memory 1706 of one or more computing devices 1700 in the computing device cluster may also store partial instructions for executing the cloud service request processing method. In other words, the combination of one or more computing devices 1700 can jointly execute the instructions for executing the cloud service request processing method.

It should be noted that the memory 1706 in different computing devices 1700 in the computing device cluster can store different instructions, each used to execute a portion of the functions of the cloud service request processing apparatus. In other words, the instructions stored in the memory 1706 in different computing devices 1700 can implement the functions of one or more modules in the interaction component 101, plug-in framework 102, plug-in management component 103, plug-in 104, and access proxy component 105.

In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network (WAN) or a local area network (LAN), etc. FIG19 shows a possible implementation. As shown in FIG19 , two computing devices 1700A and 1700B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1706 in the computing device 1700A stores instructions for executing the functions of the interaction component 101, the plug-in framework 102, the plug-in management component 103, the plug-in 104, and the access proxy component 105. At the same time, the memory 1706 in the computing device 1700B stores instructions for executing the functions of the plug-in registration component 20.

The connection method between the computing device clusters shown in Figure 19 can be considered to be that the cloud service request processing method provided by this application requires the plug-in registration component 20 to store a large number of plug-in executable programs, so it is considered to hand over the functions implemented by the plug-in registration component 20 to the computing device 1700B for execution.

It should be understood that the functionality of the computing device 1700A shown in FIG19 may also be implemented by multiple computing devices 1700. Similarly, the functionality of the computing device 1700B may also be implemented by multiple computing devices 1700.

The present application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection methods of the computing device clusters shown in Figures 18 and 19. However, the memory 1706 in one or more computing devices 1700 in this computing device cluster can store the same instructions for executing the cloud service request processing method.

In some possible implementations, the memory 1706 of one or more computing devices 1700 in the computing device cluster may also store partial instructions for executing the cloud service request processing method. In other words, the combination of one or more computing devices 1700 can jointly execute the instructions for executing the cloud service request processing method.

Embodiments of the present application also provide a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the cloud service request processing method.

The embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the cloud service request processing method, or instruct the computing device to execute the cloud service request processing method.

Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

It should be noted that the information (including but not limited to tenant device information, tenant personal information, etc.), data (including but not limited to data used for analysis, storage, display, etc.), and signals involved in this application are all authorized by the tenant or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the raw data and executable code involved in this application were obtained with full authorization.

In the embodiments of the present application, the terms "first," "second," and "third" are used for descriptive purposes only and should not be understood as indicating or implying relative importance. The term "at least one" refers to one or more, and the term "plurality" refers to two or more, unless otherwise expressly limited.

In this application, the term "and/or" simply describes an association between related objects, indicating that three possible relationships exist. For example, A and/or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" in this document generally indicates that the related objects are in an "or" relationship.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims (23)

A cloud service request processing system, characterized in that the system is deployed in a server managed by a cloud management platform, the cloud management platform is used to manage an infrastructure for providing cloud services, the infrastructure including a plurality of the servers, and the system includes: an interaction component, a plug-in framework, a plug-in management component, and at least one plug-in associated with the plug-in framework; The interaction component is used to obtain a cloud service request sent by the tenant and provide the cloud service request to the plug-in framework, wherein the cloud service request is used to request the server to provide cloud services to the tenant; The plug-in framework is configured to run based on the cloud service request and send a plug-in access request to the plug-in management component, wherein the plug-in access request indicates access to a first plug-in for processing the cloud server request, the first plug-in being one of the at least one plug-in; The plug-in management component is used to access the first plug-in based on the plug-in access request, obtain an access result, and feed back the access result to the plug-in framework; The plug-in framework is further configured to obtain a processing result for the cloud service request based on the access result. The system according to claim 1, wherein the system further comprises: an access proxy component; The plug-in framework is specifically configured to send the plug-in access request to the access proxy component, so that the access proxy component sends the plug-in access request to the plug-in management component. The system according to claim 1 or 2, characterized in that The interaction component is further configured to obtain a plug-in loading request from the tenant and forward the plug-in loading request to the plug-in management component, wherein the plug-in loading request indicates loading the first plug-in; The plug-in management component is further configured to load the first plug-in based on the plug-in loading request. The system according to claim 3, further comprising: another plug-in management component, wherein the plug-in management component is specifically configured to: Based on the plug-in loading request, sending a plug-in acquisition request to the plug-in registration component, wherein the plug-in acquisition request indicates acquisition of the first plug-in, and the plug-in registration component is used to store all plug-ins required to process the cloud service request; receiving a plug-in acquisition response sent by the plug-in registration component, wherein the plug-in acquisition response carries indication information of the other plug-in management component, or the plug-in acquisition response carries indication information of a storage address of the first plug-in in the plug-in registration component; Based on the indication of the plug-in acquisition response, the first plug-in is acquired and loaded. The system according to claim 4, wherein the plug-in management component is further configured to: Obtaining an update request for updating the first plug-in; Obtaining an updated version of the first plug-in from the other plug-in management component based on the update request, or obtaining the updated version from the plug-in registration component; The first plug-in is updated based on the updated version. The system according to claim 5, wherein the update request is sent by the plug-in registration component; Alternatively, the interaction component is further configured to obtain a plug-in update instruction of the tenant, and send the update request to the plug-in management component based on the plug-in update instruction, where the plug-in update instruction is used to instruct to update the first plug-in. The system according to claim 5 or 6, characterized in that The plug-in management component is further configured to send an update notification to the first plug-in before the plug-in management component updates the first plug-in based on the updated version, wherein the update notification indicates that the first plug-in needs to be updated; The first plug-in is further configured to provide the plug-in management component with the running information of the first plug-in based on the update notification; The plug-in management component is also used to store the operation information; The plug-in management component is further configured to provide the running information to the first plug-in after the plug-in management component updates the first plug-in based on the updated version; The first plug-in is further configured to run based on the running information. The system according to any one of claims 4 to 7, wherein the plug-in management component and the other plug-in management components are used to manage plug-ins of the same tenant. The system according to any one of claims 4 to 8, wherein a transmission delay between the other plug-in management components and the plug-in management component is less than a transmission delay between the plug-in registration component and the plug-in management component. The system according to any one of claims 4 to 9 is characterized in that the plug-in registration component includes a system registration sub-component and a tenant registration sub-component, the system registration sub-component is used to store the executable code of the system plug-in, and the tenant registration sub-component is used to store the executable code of the plug-in provided by the tenant, and the tenant does not have access to the system registration sub-component. The system according to any one of claims 1 to 10 is characterized in that the system is used to process cloud service requests of multiple tenants, the system includes multiple plug-in management components corresponding to the multiple tenants, the plug-in management components are used to manage plug-ins belonging to the corresponding tenants, and all plug-ins managed by any plug-in management component belong to the same tenant. The system according to any one of claims 1 to 11 is characterized in that the plug-in framework is used to process cloud service requests for multiple cloud services, and processing cloud service requests for a target cloud service is achieved by running the plug-in framework and the plug-in corresponding to the target cloud service, and the target cloud service is any one of the multiple cloud services. The system according to any one of claims 1 to 12 is characterized in that the system includes multiple plug-in frameworks and at least one plug-in management component belonging to the same tenant, the multiple plug-in frameworks are used to implement the same function, in response to the system including a plug-in management component of the same tenant, the multiple plug-in frameworks share the one plug-in management component, and in response to the system including multiple plug-in management components of the same tenant, at least some of the multiple plug-in frameworks use a plug-in management component separately. A cloud service request processing method, characterized in that the method is applied to a cloud service request processing system, wherein the system is deployed in a server managed by a cloud management platform, the cloud management platform is used to manage the infrastructure for providing cloud services, the infrastructure including multiple servers, the system including: an interaction component, a plug-in framework, a plug-in management component, and at least one plug-in associated with the plug-in framework, the method comprising: The interactive component obtains a cloud service request sent by the tenant and provides the cloud service request to the plug-in framework, wherein the cloud service request is used to request the server to provide cloud services to the tenant; The plug-in framework runs based on the cloud service request and sends a plug-in access request to the plug-in management component, wherein the plug-in access request indicates access to a first plug-in for processing the cloud server request, the first plug-in being one of the at least one plug-in; The plug-in management component accesses the first plug-in based on the plug-in access request, obtains an access result, and feeds back the access result to the plug-in framework; The plug-in framework obtains a processing result for the cloud service request based on the access result. The method according to claim 14, wherein the system further comprises: an access proxy component, wherein the plug-in framework sends a plug-in access request to the plug-in management component, comprising: The plug-in framework sends the plug-in access request to the access proxy component, so that the access proxy component sends the plug-in access request to the plug-in management component. The method according to claim 14 or 15, characterized in that before the plug-in management component accesses the first plug-in based on the plug-in access request, the method further comprises: The interaction component obtains the tenant's plug-in loading request and forwards the plug-in loading request to the plug-in management component, where the plug-in loading request indicates loading the first plug-in; The plug-in management component loads the first plug-in based on the plug-in loading request. The method according to claim 16, wherein the system further comprises: another plug-in management component, wherein the plug-in management component loads the first plug-in based on the plug-in loading request, including: The plug-in management component sends a plug-in acquisition request to the plug-in registration component based on the plug-in loading request, wherein the plug-in acquisition request indicates acquisition of the first plug-in, and the plug-in registration component is used to store all plug-ins required to process the cloud service request; The plug-in management component receives a plug-in acquisition response sent by the plug-in registration component, where the plug-in acquisition response carries indication information of the other plug-in management component, or the plug-in acquisition response carries indication information of a storage address of the first plug-in in the plug-in registration component; The plug-in management component obtains the first plug-in based on the indication of the plug-in acquisition response, and loads the first plug-in. The method according to claim 17, wherein after the plug-in management component loads the first plug-in, the method further comprises: The plug-in management component obtains an update request instructing to update the first plug-in; The plug-in management component obtains the updated version of the first plug-in from the other plug-in management component based on the update request, or obtains the updated version from the plug-in registration component; The plug-in management component updates the first plug-in based on the updated version. The method of claim 18, wherein the update request is sent by the plug-in registration component; Alternatively, the method further comprises: The interaction component obtains the plug-in update instruction of the tenant, and sends the update request to the plug-in management component based on the plug-in update instruction, where the plug-in update instruction is used to instruct to update the first plug-in. The method according to claim 18 or 19, wherein before the plug-in management component updates the first plug-in based on the updated version, the method further comprises: The plug-in management component sends an update notification to the first plug-in, where the update notification indicates that the first plug-in needs to be updated; The first plug-in provides the plug-in management component with the running information of the first plug-in based on the update notification; The plug-in management component stores the running information; After the plug-in management component updates the first plug-in based on the updated version, the method further includes: The plug-in management component provides the running information to the first plug-in; The first plug-in runs based on the running information. A computing device cluster, characterized in that it includes multiple computing devices, the multiple computing devices include multiple processors and multiple memories, the multiple memories store program instructions, and the multiple processors execute the program instructions, so that the computing device cluster implements the system described in any one of claims 1 to 13. A computer-readable storage medium, characterized in that it includes program instructions, which, when the program instructions are executed on a computing device, enable the computing device to implement the system described in any one of claims 1 to 13. A computer program product comprising instructions, characterized in that when the instructions are executed by a computing device cluster, the computing device cluster implements the system according to any one of claims 1 to 13.