Method and device for configuring virtual event machine and node device based on cloud computing

Abstract

The present invention aims to provide a method, apparatus, node device, and computer-readable storage medium for configuring a virtual event machine (vEM) at a cloud computing-based node device. The node device creates a corresponding first vEM for a first application pod and allocates corresponding physical EM resources to the first vEM in the current node device. Embodiments of the present invention introduce a virtual event machine to separate EM resources from applications, eliminating the need to change external resources and network connections during expansion. Furthermore, expansion is transparent to remote peers. Since the number of EMs is reduced, inter-EM communication is changed to intra-EM communication, which also improves efficiency. Since applications run as lightweight clients, application-level recovery, restart, and migration are faster.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing, and in particular to a technology for configuring a virtual event machine at a node device based on cloud computing. Background Art

[0002] Event Machine (EM) is a framework and architectural abstraction for event-driven, multi-core-optimized processing concepts originally developed for network data planes. It provides simple programming concepts for scalable and dynamically load-balanced multi-core applications with a very low-overhead run-to-completion principle.

[0003] Events, queues, and execution objects (EOs), as well as schedulers and dispatchers, form the main elements of the EM concept. An event is an application-specific data segment, such as a message or network packet, that describes work and what needs to be done. Figure 1 As shown in Figure 1, all processing within the EM must be triggered by an event 101. Events 101 are sent to an asynchronous, application-specific EM event queue (EQ, EventQueue) 102. The dispatcher loop is run by a single thread on each core within the EM instance. Here, "core" refers to a core or a thread on a multithreaded core. The dispatcher 105 on each core interfaces with the scheduler 103 and requests processing of an event 101. The scheduler 103 then evaluates the status of all EM event queues 102 and provides the highest-priority available event to the requesting dispatcher 105. The requested event queue forms the dispatch queue 104. The dispatcher 105 then locates the EO 106 to which the EQ from which the current event 101 originates belongs and finally calls the registered receive function of that EO 106 to pass the event 101 for processing. After the event 101 is processed and the receive function of that EO 106 returns, the dispatcher 105 on that core requests another event 101 from the scheduler 103 and passes it to the corresponding EO 106. The above scenario occurs in parallel across all cores running the EM instance. Therefore, when the dispatcher 105 on a core requests more work, the scheduler 103 can make a separate decision for each event 101, as events 101 originating from a particular queue 102 can be provided to any core for processing. In other words, this is dynamic load balancing on a per-event basis.

[0004] EM, as an event-driven real-time scheduler, has been widely used in the telecommunications field. For example, EM is widely used in all real-time applications in 5G products, specifically CP-RT (Control Plane Realtime Application), L2-RT (Layer Two Realtime Application), L1 (Layer 1 Application), and L2-NRT (Layer Two Non-Realtime Application), which are deployed with corresponding execution objects with receive functions. An EO has an associated event queue group (EQG, EventQueueGroup), which defines a subset of cores to run for that EQ. Events are the only way to obtain processing time for an EO and are run by a single-threaded EM dispatcher on each core defined in the EQG. The EM dispatcher calls the EO receive function for each event. Summary of the Invention

[0005] The present invention aims to provide a method, apparatus, node device and computer-readable storage medium for configuring a virtual event machine (vEM) at a node device based on cloud computing.

[0006] According to one aspect of the present invention, a method for configuring a virtual event machine (vEM) at a cloud computing-based node device is provided, wherein the node device creates a corresponding first vEM for a first application pod and allocates corresponding physical EM resources to the first vEM in the current node device.

[0007] According to one aspect of the present invention, a device for configuring a virtual event machine (vEM) at a cloud computing-based node device is also provided. The device is configured to create a corresponding first vEM for a first application pod and allocate corresponding physical EM resources to the first vEM in the current node device.

[0008] According to one aspect of the present invention, a cloud computing-based node device for configuring a virtual event machine (vEM) is provided. The node device includes at least one memory and at least one processor. The memory stores computer code. When the computer code is executed by the processor, the following steps are performed: creating a corresponding first vEM for a first application pod and allocating corresponding physical EM resources to the first vEM in the current node device.

[0009] According to one aspect of the present invention, a computer-readable storage medium is provided, storing computer code. When executed by a cloud computing node device or a processor thereof, the computer code performs the following steps: creating a corresponding first virtualized embedded system (vEM) for a first application pod and allocating corresponding physical EM resources to the first vEM in the current node device.

[0010] The present invention can be used in later vRAN versions to support scalability and flexible deployment.

[0011] This invention can be used for 5G URLLC features. Latency is a key requirement for URLLC. Since separated vEMs are located on the same physical EM, inter-chain communication between vEMs is actually communication within the same EM, which can significantly reduce the transmission delay of the EM chain.

[0012] The present invention can be used for elastic RAN when different vBBU (virtual Base band Unit) slices are to be deployed.

[0013] When the performance load changes, different cell Pods will be scaled in / out. The present invention can be used in vRAN cells as service scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Other features, objects and advantages of the present invention will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0015] Figure 1 A conceptual diagram of EM in the prior art is shown;

[0016] Figure 2 An exemplary architecture diagram of a base station in the cloud is shown in the prior art;

[0017] Figure 3 A schematic diagram illustrating an architecture of an EM service provided according to various embodiments of the present invention is shown;

[0018] Figure 4 A flow chart of a method for configuring a vEM at a cloud computing-based node device according to an embodiment of the present invention is shown;

[0019] Figure 5 A schematic diagram showing vEM and EM services according to an example of the present invention;

[0020] Figure 6 A schematic diagram showing vEM and physical EM resource mapping according to an example of the present invention;

[0021] Figure 7A schematic diagram illustrating application pod expansion according to an example of the present invention.

[0022] The same or similar reference numerals in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0023] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0024] Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments of the present invention are described as devices represented by block diagrams and processes or methods represented by flow charts. Although the flow charts describe the operating process of the present invention as sequential processing, many of the operations therein can be implemented in parallel, concurrently, or simultaneously. In addition, the order of each operation can be rearranged. The process of the present invention can be terminated when its operations are completed, but can also include additional steps not shown in the flow charts. The process of the present invention can correspond to methods, functions, procedures, subroutines, subprograms, etc.

[0025] The methods illustrated by the flowcharts and the devices illustrated by the block diagrams discussed below may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments that perform the necessary tasks may be stored in a machine or computer-readable medium such as a storage medium. (One or more) processors may perform the necessary tasks.

[0026] Similarly, it will also be understood that any flow charts, flow diagrams, state transition diagrams, and the like represent various processes that can be fully described as program code stored in a computer-readable medium and thereby executed by a computing device or processor, whether or not such computing device or processor is explicitly shown.

[0027] As used herein, the term "storage medium" may refer to one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic RAM, kernel memory, magnetic disk storage media, optical storage media, flash memory devices, and / or other machine-readable media for storing information. The term "computer-readable medium" may include, but is not limited to, portable or fixed storage devices, optical storage devices, and various other media capable of storing and / or containing instructions and / or data.

[0028] A code segment can represent a procedure, function, subroutine, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures, or program descriptions. A code segment can be coupled to another code segment or hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. can be passed, forwarded, or transmitted via any suitable means, including shared memory, message passing, token passing, network transmission, etc.

[0029] The specific structural and functional details disclosed herein are merely representative and are for the purpose of describing exemplary embodiments of the present invention. However, the present invention may be embodied in many alternative forms and should not be construed as being limited to only the embodiments set forth herein.

[0030] It should be understood that although the terms "first," "second," and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used solely to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the exemplary embodiments. The term "and / or" as used herein includes any and all combinations of one or more of the listed associated items.

[0031] The terms used herein are intended only to describe specific embodiments and are not intended to limit exemplary embodiments. Unless the context clearly indicates otherwise, the singular forms "a", "an", "an item" used herein are also intended to include the plural. It should also be understood that the terms "comprise" and / or "include" used herein specify the presence of stated features, integers, steps, operations, units and / or components, and do not preclude the presence or addition of one or more other features, integers, steps, operations, units, components and / or combinations thereof.

[0032] It should also be noted that, in some alternative implementations, the functions / actions mentioned may occur in a different order than that indicated in the accompanying drawings. For example, two figures shown in succession may actually be performed substantially simultaneously or may sometimes be performed in the reverse order, depending on the functions / actions involved.

[0033] Figure 2 FIG. 1 shows an exemplary architecture diagram of an all-in-cloud base station (BTS) in the prior art.

[0034] Cloud-based RAN (Radio Access Network) requires containerization to achieve efficient automation and cloud-native compatibility. Cloud-native network functions (CNFs) refer to containerized VNFs (Virtual Network Functions). Because each pod / container does not have an operating system (OS) instance, they are extremely lightweight. This lightweight design makes CNFs easy to deploy and offer high storage efficiency. Containers also provide fast software startup and deployment.

[0035] The Cloud RAN plan runs vDU (Virtual Distributed Unit) and vCU (Virtual Centralized Unit) in the same cloud environment (i.e. Kubernetes + Helm stack) in a completely container-based manner.

[0036] The current architecture has two main problems:

[0037] 1. EM is released together with the application

[0038] In current vRAN scenarios, an EM can only be used by one application, and EM deployment is coupled to that application. EM resources, such as EM core masks and EM queue groups, are hard-coded by the application's EO. This is inflexible. Changing traffic volume, which requires changes in CPU and network resources, requires recompiling images and redefining pod deployments.

[0039] 2. Difficulty in scaling in / out

[0040] Although the scaled-out EM provides the same services, it cannot share the previous logical resources, such as EM ID and external IP.

[0041] In the case of scale-out, with multiple instances of the same application, external connectivity becomes more complex.

[0042] Applications require a new EM dispatcher to distribute events to multiple instances of the same application.

[0043] Maximized static deployment can lead to core density issues.

[0044] To address the above issues, various embodiments of the present invention improve cloud EM use cases, aiming to ensure that application container images do not include platform services, but rather provide EM services as part of the platform. Figure 3 EM 310 provides EM services 320 as a platform, on which APP1 EO 330, APP2 EO 340, APP3 EO0 350, and APP3 EO1 360 run. Applications and event machines can then be decoupled and published separately. This also enables flexible deployment, as different applications can independently request EM resources based on different dimensions.

[0045] EM will be released as an infrastructure platform and can be used by multiple application basic components (also known as Pods), which can be dynamically allocated and bound to EM resources. Since EM will run as a platform service and a defined standard service API, it can be easily used by multiple tenants.

[0046] However, because the EM API and EM software are open source, the EM API cannot be changed to maintain forward compatibility. Furthermore, the application software must be used on both classic and cloud products, and extensive changes to the application code are also prohibited.

[0047] To maintain the EM API unchanged and minimize the impact on applications, various embodiments of the present invention introduce the concept of a virtual event machine (vEM). To support App Pod expansion, various embodiments of the present invention also introduce the concept of an expansion group. Therefore, various embodiments of the present invention have the following advantages:

[0048] 1. Separate EM and application publishing

[0049] The EM API has logical resource dependencies, such as CPU ID and event machine ID, which couple the application and event machine together.

[0050] Various embodiments of the present invention introduce a virtual event machine to separate EM resources from applications.

[0051] 2. Smooth and automatic expansion

[0052] If the solution of the present invention is not adopted, each time an EM expansion occurs, new resources need to be reserved. Using new resources and a new event machine, the remote peer of the application program will also notice the expansion.

[0053] By introducing vEM, the embodiments of the present invention do not require changes to external resources and network connections during expansion, and the expansion is transparent to the remote peer.

[0054] 3. Efficient resource utilization

[0055] When an application is published with EM, each image requires at least one CPU resource, although in practice only half of the CPU cores are sufficient.

[0056] According to embodiments of the present invention, less than one CPU resource is possible.

[0057] In addition, since the number of EMs is reduced, inter-EM communication is changed to intra-EM communication, which also improves efficiency.

[0058] 4. Flexible deployment

[0059] When applications are deployed with EMs, different EMs cannot share logical resources. Therefore, each EM must be configured individually. External connectivity also needs to be considered.

[0060] According to various embodiments of the present invention, external connections can be simplified.

[0061] 5. Rapid recovery, restart, and migration

[0062] Because applications run as lightweight clients, application-level recovery, restart, and migration will be faster.

[0063] Event machines are used by real-time applications where latency and efficiency are key KPIs. When the EM and application execution objects are separated, no new overhead should be introduced into the system.

[0064] In various embodiments of the present invention, the EM service runs on k8s, including providing an EM service API and allocating EM resources.

[0065] Figure 4 A flow chart of a preferred embodiment of the present invention is shown, which specifically illustrates a process for configuring a vEM at a cloud computing-based node device.

[0066] Here, those skilled in the art should understand that the embodiments of the present invention are not limited to various real-time applications in 5G products, but can be applied to various node devices in cloud computing, as long as the node device is configured as an EM node.

[0067] like Figure 4 As shown, in step 410, the EM node creates a corresponding first vEM for the first application pod and allocates corresponding physical EM resources in the current node device for the first vEM.

[0068] For reference Figure 5Each EM node is configured with an EM pod and therefore has an EM node ID and an EM pod ID. Furthermore, each EM node is also configured with an EM communication module to communicate with the APP pod and other EM nodes via the EM management interface (EM service API). When an EM pod is initially created, all EM distributors are idle.

[0069] The EM API is only a logical concept that can be deployed on any EM node. All EM nodes provide EM services to applications via the EM service API.

[0070] Figure 5 Two EM nodes are exemplarily shown in FIG. The node with EMnodeid 0 provides EM services for APP 1 and APP 2, and the node with EMnodeid 1 provides EM services for APP 3.

[0071] Continue reading Figure 4 and Figure 5 In the following description, the current node is described as the EM node with node ID 0. In step 410, the current EM node creates a corresponding first vEM for the first application pod and allocates corresponding physical EM resources to the first vEM in the current node device.

[0072] Specifically, according to one embodiment of the present invention, the current EM node creates a first vEM for the first application pod.

[0073] Still refer to Figure 5 For example, for APP 1-0 pod, the current EM node creates the corresponding vEM 0 for it and allocates corresponding physical EM resources to vEM 0, including EM distributor 0.

[0074] For another example, for APP 2-0 pod, the current EM node creates a corresponding vEM 1 for it and allocates corresponding physical EM resources to vEM 1, including EM distributor 1-2.

[0075] After creating vEM for APPpod, the current EM node calls the EM service API to return relevant virtual resource identification information of vEM to APPpod, for example, returning vEMid of vEM0, virtual core identification information (vCoreid) and virtual QG identification information (vQGid) allocated to vEM0 to APP1-0pod.

[0076] From the application's perspective, the EM service API remains unchanged. Only the previous EM kernel mask is replaced with the vEM kernel mask, which is invisible to the application. Throughout the EO lifecycle, all EM service APIs remain unchanged.

[0077] vEM can be used to hide the real EM to obtain all the benefits of virtualization. Since all EM APIs used by the application do not change at all, the application can be migrated from the original Pod to the vEM environment with minimal changes.

[0078] Each application publishes an execution object group as a dynamic library. When an app pod is created, it includes this execution object library and then requests the creation of the corresponding vEM from the EM node through the EM service API. This is configurable, for example, using a YAML configuration file, for flexible deployment.

[0079] The application specifies the path to the EO library so that vEM can obtain and run the EO later.

[0080] The EM service selects a suitable node with an EM pod deployed and loads the EO in the APP pod to the selected EM node. If it is the first time to load the EO, vEM will create the EO and its queue group (QG).

[0081] When the first vEM is created, the current node loads the EO in the first application pod and allocates a queue group QG for the EO.

[0082] The execution object in the first application pod is loaded in the first vEM, and the current node maps the virtual EM resources allocated by the first vEM to the first application pod to the physical EM resources to run the execution object on the physical EM resources.

[0083] The virtual EM resources include, for example, virtual queue groups and virtual cores of the execution object. The current node maps the virtual queue groups of the execution object to queue groups in the physical EM resources, and maps the virtual cores of the execution object to cores in the physical EM resources.

[0084] For reference Figure 6 EO 0-3 is loaded into vEM 1, and vQG 0-2 and vCore 0-1 are allocated to it. These virtual EM resources are mapped to QG 1-3 and Core 1-2 in the physical EM resources.

[0085] Here, an application can specify the number of dedicated cores it requires, which determines the number of virtual cores and physical cores allocated to it. Figure 5 In the example, the number of dedicated cores specified by APP1 is 1, and the corresponding number of EM distributors is 1, such as allocating EM distributor 0. The number of dedicated cores specified by APP2 is 2, and the corresponding number of EM distributors is 2, such as allocating EM distributor 1-2.

[0086] Return to Reference Figure 4, according to one embodiment of the present invention, Figure 4 The process shown may further include step 412 (not shown). In step 412, when the first application pod exits, the EM node releases the first vEM. Here, a yaml configuration file may also be used.

[0087] Still refer to Figure 5 For example, when the APP2-0 pod exits, EMpod 0 releases vEM2 and stops EO4 running on vEM2.

[0088] Return to Reference Figure 4 According to another embodiment of the present invention, a scaling group is introduced to help APP pods scale. The scaling group includes one or more pods of the same application, and each application pod in the scaling group has the same EO image. Figure 4 The illustrated process may further include step 414 (not shown). In step 414, when the pod of the first application is expanded, the current node creates a corresponding second vEM for the second pod of the first application newly added to the expansion group and allocates corresponding physical EM resources to the second vEM.

[0089] Still refer to Figure 5 For example, the APP1 expansion group includes the APP1-0 pod and the APP1-1 pod. vEM0 has been created for the APP1-0 pod, and vEM2 has been created for the APP1-0 pod on the current node. The APP1-0 pod and the APP1-1 pod have the same EO images, namely, EO0, EO1, and EO2. vEM0 and vEM2 also run the same EO instances, namely, EO0, EO1, and EO2.

[0090] Furthermore, when an AppPod in a scaling group exits, its corresponding vEM is released. If the vEM is the last vEM in the scaling group, the EO in the scaling group is terminated. If the vEM is not the last vEM in the scaling group, the EO running on the released vEM is removed.

[0091] Here, different pods of the same application belong to the same scaling group, which is newly introduced to facilitate apppod scaling. Each application pod in the scaling group is deployed on its own vEM, but these vEMs run on the same physical EM. Therefore, all application pods in the same scaling group can perform load sharing without being noticed.

[0092] From an application perspective, the EM API remains unchanged, meaning the EO software remains the same in cloud or traditional settings. Using the EM service API during pod creation and decommissioning has minimal impact. Because EM resources are configurable, changing the configuration enables flexible application deployments.

[0093] From the EM perspective, a global event machine is used instead of separate event machines. Therefore, a virtual EM concept is needed to isolate EM resources for different applications.

[0094] See Figure 5 , the APP2 Pod is allocated two cores of EM resources. Since core 0 of the EM Pod was already allocated to the APP1 Pod, the APP2 Pod is allocated cores 1 and 2. The EM core mask returned to the APP2 Pod is still 0x3 with a vEMid of 1, so APP2 does not notice that the physical EM is shared with other applications.

[0095] If the APP1-0 Pod is overloaded, you can scale up an APP1-1 Pod to balance the load. APP1-0 and APP1-1 share the same EO image, meaning the same execution targets are used between the APP1-0 and APP1-1 Pods. In this case, during the startup of the APP1-1 Pod, core 3 is assigned to the App1-1 Pod. The logical EM core ID is 0x1, and the vEM ID is 2. However, EO-0,1,2 can run on cores 0 and 3, which are managed by the EM service.

[0096] Figure 6 This section describes the components provided by the vEM. For applications, the kernel and queue group APIs are resource dependencies. Therefore, the vEM provides vCore IDs and vQGs to applications. The vEM also maps vCores to physical cores and vQGs to physical QGs. This mapping enables multiple vEMs to run on a single physical EM. To applications, these vEMs appear independent and have their own resources. However, in reality, EM resources are shared within the vEM.

[0097] Figure 7 This example illustrates an example of a scaling group based on the present invention. In this scenario, App1 and App2 are deployed on the same node, and the CN server is a remote server located across the network. Traffic from the CN server is first sent to the App1 pod and then passed to the App2 pod. Assume that the App1-0 pod is overloaded and the App1-1 pod needs to be scaled out.

[0098] If this specification is not implemented, the steps are:

[0099] 1. Assign a new EM ID to App1-1;

[0100] 2. Create App1-1;

[0101] 3. Pass the new EM ID to App2-0;

[0102] 4. App2-0 needs to follow some rules to separate traffic to different App1 pods;

[0103] 5. Assign a new IP address to App1-1.

[0104] 6. Pass the new App1 IP to the CN server

[0105] 7. The CN server needs to follow some rules to separate traffic to different App1 pods.

[0106] To implement the present invention, the steps become:

[0107] 1. Allocate vEM resources.

[0108] 2. Create App1-1.

[0109] 3. Since the new vEM is on the same physical EM, the EM ID and IP address can be the same as App1-0.

[0110] Some abbreviations and explanations used in the present invention are listed below.

[0111]

[0112]

[0113] It should be noted that the present invention can be implemented in software and / or a combination of software and hardware, for example, can be implemented using an application specific integrated circuit (ASIC), a general purpose computer or any other similar hardware device. In one embodiment, the software program of the present invention can be executed by a processor to implement the steps or functions described above. Similarly, the software program of the present invention (including related data structures) can be stored in a computer-readable recording medium, for example, a RAM memory, a magnetic or optical drive or a floppy disk and similar devices. In addition, some steps or functions of the present invention can be implemented using hardware, for example, as a circuit that cooperates with a processor to perform each step or function.

[0114] Furthermore, at least a portion of the present invention may be implemented as a computer program product, such as computer program instructions, which, when executed by a computing device, can invoke or provide the method and / or technical solution according to the present invention through the operation of the computing device. The program instructions for invoking / providing the method of the present invention may be stored in a fixed or removable recording medium, and / or transmitted via a data stream in a broadcast or other signal-carrying medium, and / or stored in a working memory of a computing device that operates according to the program instructions.

[0115] It is obvious to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-restrictive, and the scope of the invention is defined by the appended claims rather than the above description, and it is intended that all changes that fall within the meaning and scope of the equivalent elements of the claims be included in the present invention. Any figure marks in the claims should not be regarded as limiting the claims involved. In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in the system claim may also be implemented by one unit or device through software or hardware. Words such as first, second, etc. are used to indicate names and do not indicate any particular order.

Claims

1. A method for configuring a virtual event machine (vEM) at a node device based on cloud computing, wherein: The method comprises the following steps: Creating a corresponding first vEM for the first application pod and allocating corresponding physical EM resources in the current node device to the first vEM; in, Loading the execution object in the first application pod in the first vEM, mapping the virtual EM resources allocated by the first vEM to the first application pod to the physical EM resources, so as to run the execution object on the physical EM resources; The virtual EM resource includes a virtual queue group and a virtual core of the execution object; wherein the virtual queue group of the execution object is mapped to the queue group in the physical EM resource, and the virtual core of the execution object is mapped to the core in the physical EM resource.

2. The method according to claim 1, wherein The method further includes: Create the first application pod, which includes the execution object library.

3. The method according to claim 1, wherein The method further includes: Return relevant virtual resource identification information of the first vEM to the first application pod.

4. The method according to claim 1, wherein The method further includes: When the first application pod exits, the first vEM is released.

5. The method according to claim 1, wherein A scaling group includes one or more pods of the same application. Each application pod in the scaling group has the same execution object image. When the pod of the first application is expanded, a corresponding second vEM is created for the second pod of the first application newly added in its expansion group, and corresponding physical EM resources are allocated to the second vEM in the current node device.

6. The method according to claim 5, wherein: The method further comprises the following steps: When a pod in the scaling group of the first application exits, its corresponding vEM is released, wherein: - If the vEM is the vEM corresponding to the last pod in the expansion group, terminate the execution object of the first application; - If the vEM is not the vEM corresponding to the last pod in the expansion group, remove the execution object running on the vEM.

7. The method according to claim 1, wherein Each node device is configured with an EM pod; in, When determined as the EM node of the first application pod, interact with the first application pod through the EM management interface.

8. An apparatus for configuring a virtual event machine (vEM) at a node device based on cloud computing, wherein: The device is used to: Creating a corresponding first vEM for the first application pod and allocating corresponding physical EM resources in the current node device to the first vEM; in, Loading the execution object in the first application pod in the first vEM, mapping the virtual EM resources allocated by the first vEM to the first application pod to the physical EM resources, so as to run the execution object on the physical EM resources; The virtual EM resource includes a virtual queue group and a virtual core of the execution object; wherein the virtual queue group of the execution object is mapped to the queue group in the physical EM resource, and the virtual core of the execution object is mapped to the core in the physical EM resource.

9. A cloud computing-based node device for configuring a virtual event machine (vEM), the node device comprising at least one memory and at least one processor, wherein the memory stores computer code, and when the computer code is executed by the processor, the following steps are performed: Creating a corresponding first vEM for the first application pod and allocating corresponding physical EM resources in the current node device to the first vEM; in, Loading the execution object in the first application pod in the first vEM, mapping the virtual EM resources allocated by the first vEM to the first application pod to the physical EM resources, so as to run the execution object on the physical EM resources; The virtual EM resource includes a virtual queue group and a virtual core of the execution object; wherein the virtual queue group of the execution object is mapped to the queue group in the physical EM resource, and the virtual core of the execution object is mapped to the core in the physical EM resource.

10. A computer-readable storage medium having computer code stored therein, wherein when the computer code is executed by a cloud computing-based node device or a processor thereof, the following steps are performed: Creating a corresponding first vEM for the first application pod and allocating corresponding physical EM resources in the current node device to the first vEM; in, Loading the execution object in the first application pod in the first vEM, mapping the virtual EM resources allocated by the first vEM to the first application pod to the physical EM resources, so as to run the execution object on the physical EM resources; The virtual EM resource includes a virtual queue group and a virtual core of the execution object; wherein the virtual queue group of the execution object is mapped to the queue group in the physical EM resource, and the virtual core of the execution object is mapped to the core in the physical EM resource.

Images