Event processing method and apparatus

Abstract

This application provides an event handling method and apparatus, relating to the field of computers. The event handling method includes: first, obtaining a code version invocation rule for indicating the version of code handling the event, wherein the code version includes multiple versions; then, determining a target code version for handling the event from the multiple versions according to the code version invocation rule; and finally, handling the event through a first instance created based on the target code version. This ensures that each event can be handled efficiently and accurately by an instance of a suitable code version, improving the success rate of event handling.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to event processing methods and apparatus. Background Technology

[0002] With cloud computing platforms providing increasingly powerful computing and storage capabilities, and the widespread application of technologies such as virtualization and containerization, the management and utilization of server resources have become more efficient and flexible. At the same time, internet applications are increasingly favoring microservice architectures, breaking down applications into multiple small, independent services to improve scalability and flexibility. Against this backdrop, serverless architecture has emerged.

[0003] Serverless architecture represents a cloud computing execution model. Its core meaning is not "serverless," but rather a user-centric approach that allows users to focus solely on the application's functionality. When deploying applications, users don't need to worry about the specific server on which they are deployed or what virtualization technology is used. Serverless architecture typically integrates front-end Function as a Service (FaaS) and back-end as a Service (BaaS) and widely adopts event-driven programming and microservice architecture. The event-driven mechanism is implemented by associating serverless functions with triggers: when a specific event occurs, the trigger retrieves the event and activates the corresponding instance to handle it. The specific operation of the trigger depends on the type of event, such as a Hypertext Transfer Protocol (HTTP) request, database content change, or timer triggering.

[0004] Currently, the success rate of instance event handling in serverless architecture is relatively low. Summary of the Invention

[0005] This application provides an event handling method and apparatus to improve the success rate of instance event handling.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] Firstly, an event handling method is provided. This method is applied to a second node in a server that has the ability to manage instances. For example, the second node can be a virtual network function manager. The execution subject of this method can be the second node, a component or device applied to the second node (e.g., a processor, chip, or chip system), or a logical module or software capable of implementing all or part of the functions of the second node. The event handling method includes: first, instructing the code version invocation rule for handling the event, wherein the code version invocation rule indicates the version of the code handling the event, and the code version includes multiple versions; then, determining the target code version for handling the event from the multiple versions according to the code version invocation rule; and finally, handling the event through a first instance created based on the target code version.

[0008] In the first aspect, the second node determines the target code version for handling events from multiple versions based on the code version calling rules, and then handles events through the first instance created based on the target code version, ensuring that each event can be handled efficiently and accurately by the appropriate code version, thereby improving the success rate of event handling.

[0009] In one possible design, multiple versions include a first version and a second version. The target code version is the first version. Code version invocation rules are used to indicate that the number of first versions processing events is a first proportion, and the number of second versions processing events is a second proportion. The method may further include: updating the code version invocation rules if the success rate of processing events through the first instance is higher than a first threshold, wherein the first proportion is increased in the updated code version invocation rules. Optionally, the first version includes the current version, and the second version includes historical versions.

[0010] In this design, the above steps enable intelligent adjustment of instance load and optimization of version iteration. Specifically, the second node can statistically analyze the success rate of events handled by the first instance created based on the new version of the code over a period of time. When this success rate exceeds a preset first threshold, it indicates that the first instance has strong stability. At this point, the proportion of events it handles will be increased (i.e., the first proportion will be increased), thereby utilizing resources more effectively and improving the overall system's processing capacity and efficiency. Optionally, when the first version includes the current version and the second version includes historical versions, this mechanism also supports version iteration optimization. When instances created by the new version exhibit higher stability, the system will gradually phase out instances of the old version, achieving a smooth system upgrade.

[0011] In one possible design, the method may further include: determining the first instance from the created instances. In another possible interpretation, the created instances may also be referred to as existing instances, historical instances, etc.

[0012] This design avoids creating the same instance repeatedly by selecting the first instance from the existing ones, thus saving computing resources and time. Furthermore, if an existing instance meets the current requirements, directly selecting that instance allows for faster startup and operation, improving system responsiveness.

[0013] In one possible design, the method may also include: creating a first instance based on the code of the target code version.

[0014] In this design, by creating the first instance based on the target code version, it can be ensured that the code running on the first instance is the latest or specified version.

[0015] In one possible design, the method may further include: obtaining event information of an event, wherein the code version invocation rule is used to indicate the code version corresponding to the event information; determining the target code version for handling the event from multiple versions according to the code version invocation rule, including: determining the target code version for handling the event from multiple versions according to the code version invocation rule and the event information.

[0016] In this design, once the second node successfully obtains the event information, it can select the corresponding target code version to handle the event based on that information. This mechanism not only ensures that each event can be handled efficiently and accurately by the appropriate code version, but also provides greater flexibility in version management, facilitating the gradual introduction of new versions or version upgrades without compromising system stability.

[0017] In one possible design, the code version invocation rules include: the characteristics of each version of the code and the event scope information that each version of the code is responsible for handling.

[0018] In this design, by clearly defining the code characteristics and corresponding event scope information of each version, it is possible to determine which events should be handled by which versions of the code.

[0019] In one possible design, the method may further include: obtaining first subscription information, wherein the first subscription information is used to indicate a first path; and in the event that the event processing via the first instance fails, sending first response information based on the first path indicated by the first subscription information, wherein the first response information is used to indicate that the event processing via the first instance failed.

[0020] In this design, through the steps described above, the second node can react quickly and notify relevant parties when event processing fails. This helps stakeholders understand the status of event processing in a timely manner and take appropriate measures. Furthermore, this mechanism improves system reliability because it ensures that the system proactively notifies relevant parties when event processing fails.

[0021] In one possible design, the events are those of serverless applications.

[0022] This design is capable of handling events in serverless applications.

[0023] In one possible design, the method may further include: handling the event via a second instance if the event processing fails via the first instance, wherein the second instance is an instance created based on a code version other than the target code version.

[0024] In this design, by introducing a second instance as an alternative for event handling, the second node can reprocess the event if the first instance fails. This helps ensure that events are not lost or missed due to a single processing failure, thus improving the success rate of event handling.

[0025] Secondly, an event handling method is provided. This method is applied to a first node in a server that has the capability to manage the lifecycle of network services. For example, the first node can be a network function virtualization orchestrator. The execution subject of this method can be the first node, a component or device applied to the first node (such as a processor, chip, or chip system), or a logical module or software capable of implementing all or part of the functions of the first node. The event handling method includes: first, instructing the handling event to obtain a code version invocation rule, which indicates the version of the code handling the event, including multiple versions; then, sending the code version invocation rule.

[0026] In the second aspect, the first node provides the second node with the aforementioned code version invocation rules, allowing the second node to select a suitable code version to handle the event.

[0027] In one possible design, multiple versions include a first version and a second version, and a code version calling rule is used to indicate that the number of first versions handling events is a first proportion and the number of second versions handling events is a second proportion.

[0028] In this design, the utilization of server or computing resources can be optimized by specifying different processing ratios.

[0029] In one possible design, the first version includes the current version, and the second version includes historical versions.

[0030] In this design, when the first version includes the current version and the second version includes historical versions, this mechanism supports version iteration optimization. If the instances created by the current version exhibit higher stability, the system can gradually phase out instances of historical versions, achieving a smooth upgrade of the system.

[0031] In one possible design, code version invocation rules are used to indicate the code version corresponding to the event information of an event.

[0032] In this design, the code version invocation rules introduce event information, which ensures that each event is handled by the appropriate code version.

[0033] In one possible design, the code version invocation rules include: the characteristics of each version of the code and the event scope information that each version of the code is responsible for handling.

[0034] In this design, by clearly defining the code characteristics and corresponding event scope information of each version, it is possible to determine which events should be handled by which versions of the code.

[0035] In one possible design, the method may further include: obtaining first subscription information, wherein the first subscription information is used to indicate a first path, the first path pointing to a relevant party of the event; and sending the first subscription information.

[0036] In this design, the above steps provide the second node with first subscription information, which enables the second node to react quickly based on the first subscription information and notify the relevant parties when event processing fails.

[0037] Thirdly, an event handling method is provided. This method is applied to a second node in a server that has the ability to manage instances. For example, the second node can be a virtual network function manager. The execution subject of this method can be the second node, a component or device applied to the second node (such as a processor, chip, or chip system), or a logical module or software that can implement all or part of the functions of the second node. The event handling method includes: obtaining code version mapping information, which indicates the versions of related code used to handle events; the code versions include historical versions and the current version; and, if handling the event through a first instance created based on the current version of the code fails, handling the event through a second instance created based on the historical version of the code, wherein the first instance is an instance determined based on the first instance and the code version mapping information.

[0038] In this design, by introducing a second instance as an alternative for event handling, the second node can reprocess the event if the first instance fails. This helps ensure that events are not lost or missed due to a single processing failure, thus improving the success rate of event handling.

[0039] In one possible design, the code version mapping information includes: code characteristics of historical versions and code characteristics of the current version.

[0040] In this design, the code version mapping information includes code characteristics of historical versions and code characteristics of the current version, which can indicate the versions of code with related relationships.

[0041] In one possible design, the method may further include: determining a first instance and / or a second instance from the created instances. In another possible interpretation, the created instances may also be referred to as existing instances, historical instances, etc.

[0042] In this design, by identifying the first and / or second instance from already created instances, the repeated creation of identical instances can be avoided, thus saving computational resources and time. Furthermore, if an already created instance meets the current requirements, directly selecting that instance allows for faster startup and operation, improving system responsiveness.

[0043] In one possible design, the method may also include: creating a second instance based on a historical version of the code; and / or, creating a first instance based on the current version of the code.

[0044] In this design, creating a second instance using a historical version of the code ensures that the second instance runs the specified historical version of the code. Similarly, creating a first instance using the current version of the code ensures that the first instance runs the specified current version of the code.

[0045] In one possible design, the method may further include: obtaining second subscription information for indicating a second path; and, in the event of failure to process an event, sending second response information to the second path indicated by the second subscription information, wherein the second response information is used to indicate that the event processing failed through the first instance and / or the second instance.

[0046] In this design, through the steps described above, the second node can react quickly and notify relevant parties when event processing fails. This helps stakeholders understand the status of event processing in a timely manner and take appropriate measures. Furthermore, this mechanism improves system reliability because it ensures that the system proactively notifies relevant parties when event processing fails.

[0047] In one possible design, the events are those of serverless applications.

[0048] This design is capable of handling events in serverless applications.

[0049] In one possible design, the method may further include: sending a storage request for requesting the caching of event information.

[0050] In this design, by sending a storage request, the recipient of the request can promptly cache event information. By caching the event information, the system can quickly access this information when needed without having to retrieve or recalculate it. This optimizes the event handling process and reduces processing time.

[0051] Fourthly, an event handling method is provided. This method is applied to a first node in a server that has the capability to manage the lifecycle of network services. For example, the first node can be a network function virtualization orchestrator. The execution subject of this method can be the first node, a component or device applied to the first node (such as a processor, chip, or chip system), or a logical module or software that can implement all or part of the functions of the first node. The event handling method includes: first, obtaining code version mapping information, which indicates the versions of related code used to handle events; the code versions include historical versions and the current version; and then, sending the code version mapping information.

[0052] In the fourth aspect, the first node provides the second node with code version mapping information that indicates the versions of the code with the associated relationship, which can be used by the second node to process events.

[0053] In one possible design, the code version mapping information includes: code characteristics of historical versions and code characteristics of the current version.

[0054] In this design, the code version mapping information includes code characteristics of historical versions and code characteristics of the current version, which can indicate the versions of code with related relationships.

[0055] Fifthly, an event processing apparatus is provided for implementing the method described in any one of the first to fourth aspects. For example, the event processing apparatus may be a second node in the first or third aspect; or, the event processing apparatus may be a first node in the second or fourth aspect.

[0056] The event processing apparatus includes modules, units, or means corresponding to the implementation method. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the function.

[0057] In some possible designs, the event processing device may include a processing module and a transceiver module. The processing module can be used to implement the processing functions in any of the above aspects and any possible implementations. The transceiver module, also called a transceiver unit, is used to implement the sending and / or receiving functions in any of the above aspects and any possible implementations. The transceiver module may consist of transceiver circuitry, a transceiver, a transceiver unit, or a communication interface.

[0058] In some possible designs, the transceiver module includes a sending module and / or a receiving module, which are used to implement the sending or receiving functions in any of the above aspects and any possible implementations.

[0059] In a sixth aspect, this application provides a computing device cluster, the computing device cluster including at least one computing device, each of the at least one computing device including at least one processor and at least one memory, the at least one memory storing computer-readable instructions; the at least one processor executes the computer-readable instructions to cause the computing device cluster to perform the method described in any one of the possible designs of the first to fourth aspects.

[0060] In a seventh aspect, this application provides a computer program product containing instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method described in any one of the possible designs of the first to fourth aspects.

[0061] Eighthly, this application provides a computer-readable storage medium storing computer program instructions that, when executed by a cluster of computing devices, enable the cluster of computing devices to perform the method described in any one of the possible designs of the first to fourth aspects.

[0062] The technical effects of any of the design methods in aspects five through eight can be found in the technical effects of different design methods in aspects one through four, and will not be repeated here. Attached Figure Description

[0063] Figure 1 This application provides a schematic diagram of the structure of a distributed system according to an embodiment of the present application.

[0064] Figure 2 A schematic diagram of the structure of a network function virtualization system provided in this application embodiment;

[0065] Figure 3 A flowchart illustrating an event handling method provided in an embodiment of this application;

[0066] Figure 4This is a schematic diagram of an event handling scenario provided in an embodiment of this application;

[0067] Figures 5-6 A flowchart illustrating the event handling method provided in an embodiment of this application;

[0068] Figure 7 This is a schematic diagram of another event handling scenario provided in an embodiment of this application;

[0069] Figure 8 A flowchart illustrating another event handling method provided in an embodiment of this application;

[0070] Figure 9 This is a schematic diagram of the structure of an event processing device provided in an embodiment of this application;

[0071] Figure 10 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0072] Figure 11 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0073] Figure 12 This is a schematic diagram of another computing device cluster provided in an embodiment of this application. Detailed Implementation

[0074] The network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0075] Before introducing the embodiments of this application, some technologies involved in the embodiments of this application will be explained.

[0076] 1. Network Functions Virtualization (NFV): NFV is a technology that uses virtualization to implement network functions. It borrows from the architecture of general-purpose servers such as x86, encapsulating the functions of traditional network hardware devices such as routers, switches, firewalls, and load balancers into independent modular software. This modular software can run on general-purpose hardware devices, thereby enabling diverse network functions.

[0077] The core concept of NFV is to decouple network functions from dedicated hardware devices, achieving separation of software and hardware. In this way, network functions no longer depend on specific hardware devices but can be implemented in software on general-purpose hardware. This decoupling not only reduces the cost of network equipment but also improves the flexibility and scalability of network functions.

[0078] 2. Virtual Network Functions (VNFs): VNFs are the core functional modules in the NFV architecture. They are responsible for implementing various network functions, such as data forwarding, IP configuration, and security policy enforcement. Through VNFs, operators can quickly deploy and adjust network functions according to business needs without replacing hardware equipment.

[0079] As described in the background technology introduction, serverless architecture can automatically adjust resource allocation according to actual business needs. When the volume of business requests increases, the platform will automatically increase the number of instances to meet the demand; when the demand decreases, the number of instances will also decrease accordingly, and can even be reduced to 0, meaning that no resources will be occupied when there are no business requests. This automatic scaling mechanism enables serverless services to utilize resources efficiently while reducing operating costs.

[0080] Compared to traditional VNF deployment methods, serverless applications employ an innovative deployment strategy: users directly provide code to achieve function-level instantiation. In serverless mode, code granularity is refined to the function level, with each function performing a single and clearly defined function. Using serverless mode for product development and deployment significantly accelerates code iteration speed and increases iteration frequency, enabling products to respond quickly to market demands and technological changes.

[0081] However, current technology systems and standards have shortcomings in the design of serverless application code update processes, resulting in low fault tolerance during serverless application (APP) code update processes. If the updated code becomes unusable, it will lead to event handling failures and a low success rate in event handling.

[0082] To address the aforementioned technical problems, this application provides an event handling method. The method provided in this application is described below with reference to the accompanying drawings.

[0083] The event handling method provided in this application can be applied to distributed systems, also known as distributed clusters, which are groups of interconnected computers or servers that work together to perform common tasks. The computers or servers in a distributed system are typically located in different physical locations and interconnected via a network. Distributed systems are commonly used to provide high availability, scalability, and fault tolerance for applications and services. In a distributed system, each computer or server can be called a node, and multiple nodes constitute the distributed system. For example, a distributed system can be as follows: Figure 1 As shown, Figure 1 This is a schematic diagram of the data access system provided in this application. The data access system includes a distributed system 100, which comprises a network device 130 and multiple server nodes: node 111, node 112, and node 113. Each server node is used to process a portion of the data in the distributed system 100, or to implement a portion of the functions of the distributed system. The server nodes communicate with the host (client) through a network or hardware communication channel. It should be understood that... Figure 1 This is merely an example provided in this embodiment; the distributed system 100 may include more or fewer server nodes, and this application does not limit this.

[0084] The distributed system 100 supports multiple hosts (also known as clients) to process and access files, data, etc., on the server node. These multiple hosts can include... Figure 1 As shown in the diagram of Host 1, Host 2, and Host 3, it is worth noting that the distributed system 100 can also support more or fewer hosts for data processing and access. Here, a host, also known as a client or user terminal, can be a computer running an application. This computer can be a physical machine or a virtual machine. For example, if the computer running the application is a physical computing device, this physical computing device can be a host or a terminal.

[0085] A terminal can also be called a terminal device, user equipment (UE), mobile station, mobile terminal, etc. Terminals can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, etc. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, transportation vehicles with wireless communication capabilities, communication modules, etc. The embodiments of this application do not limit the device form of the terminal. Terminals typically contain communication modules, circuits, or chips that perform corresponding communication functions. The terminal can also be configured with program instructions for performing the corresponding communication functions.

[0086] The embodiments of this application do not limit the device form of the terminal. The device used to implement the functions of the terminal can be the terminal itself; it can also be a device that supports the terminal in implementing the functions, such as a chip system. The device can be installed in the terminal or used in conjunction with the terminal. In the embodiments of this application, the chip system can be composed of chips or can include chips and other discrete devices. All or part of the functions of the terminal in this application can also be implemented by software functions running on hardware, or by virtualization functions instantiated on a platform (e.g., a cloud platform).

[0087] Besides the distributed clusters described above, the distributed clusters in this application embodiment can also be cloud servers, such as public cloud servers, private cloud servers, hybrid cloud servers, etc. Although a cloud server is not a traditional distributed cluster (because a cloud server is not a group of interconnected physical servers), it can be considered a virtual distributed cluster. This is because cloud servers are usually hosted on a hypervisor, which is a virtualization platform that allows multiple virtual machines to run on a single physical server. Each virtual machine is equivalent to a node, and multiple nodes constitute a distributed cluster.

[0088] For example, Network Functions Virtualization (NFV) systems can be deployed in distributed systems. NFV technology achieves flexibility and scalability by decoupling traditional network functions from dedicated hardware devices, encapsulating them into independent modular software, and running this software on general-purpose hardware. This architecture is well-suited for distributed cluster environments because distributed clusters can provide features such as high availability and load balancing, further enhancing the reliability and performance of NFV systems.

[0089] In a distributed cluster, NFV components (such as Virtual Network Functions (VNFs), management automation, and network orchestration (MANO)) can be deployed on multiple nodes to achieve resource sharing and load balancing. Furthermore, distributed clusters can provide failover and recovery mechanisms, ensuring that if a single node fails, other nodes can take over its work, thereby guaranteeing system continuity and stability.

[0090] For example, in 5G networks, NFV technology is widely used for virtualization of both core and edge networks. By virtualizing network elements in the mobile core network as VNFs and deploying them in a distributed cluster, cloud-based deployment of core network functions can be achieved. This not only improves network flexibility and scalability but also reduces operating and maintenance costs.

[0091] For example, such as Figure 2 As shown, a network function virtualization system may include the following components:

[0092] Network functions virtualization infrastructure (NFVI): NFVI is the underlying infrastructure of the network functions virtualization system, providing computing, storage, and network resources. These resources are encapsulated and managed through virtualization technology to support the deployment and operation of virtual network functions (VNFs).

[0093] VNFs (Virtual Network Functions): VNFs are software instances running on NFVI that implement the functions of traditional network devices such as firewalls, routers, and switches. VNF deployment and management are typically handled by the MANO framework. Furthermore, VNF instances are concrete implementations of VNFs, capable of performing specific network functions such as packet forwarding, routing decisions, and security policy enforcement. VNF instance deployment and management are more flexible, dynamically adjusting resource allocation and function configuration based on network needs, while leveraging server and virtualization technologies to significantly reduce capital expenditure compared to traditional hardware solutions. In addition, VNF instances are well-suited for automated and orchestration system management, automatically managing their lifecycle based on policies or network conditions.

[0094] Management Automation and Orchestration (MANO): MANO is one of the core components of a Network Functions Virtualization (NFV) system, responsible for the management and orchestration of VNF and NFVI resources. It typically includes three key components:

[0095] Network functions virtualization orchestrator (NFVO): Responsible for the lifecycle management of network services, coordinating the management of VNF and NFVI resources, and ensuring the optimal configuration of network services.

[0096] Virtual Network Functions Manager (VNFM): Responsible for the lifecycle management of VNFs, including VNF instantiation (i.e., creating VNF instances), configuration, monitoring, and troubleshooting.

[0097] Optionally, other components for managing the lifecycle of VNFs can also be deployed in the network function virtualization system, such as a serverless function management (SFM) or function management (FM). This application uses VNFM to illustrate the lifecycle management of VNFs as an example.

[0098] Virtualized Infrastructure Manager (VIM): Responsible for the management and allocation of NFVI resources, including the virtualization, monitoring, and optimization of compute, storage, and network resources.

[0099] Operation Support System / Business Support System (OSS / BSS): While not a core component of the NFV architecture, OSS / BSS are crucial systems for operators to conduct business operations and provide customer service. OSS is responsible for network operation and management, including network monitoring, fault handling, and resource management; BSS is responsible for business operation and customer management, including customer data management, billing management, and service activation. In the NFV architecture, OSS / BSS interfaces with hosts and MANO systems to automate and intelligently manage business operations.

[0100] Infrastructure Management Figure 2(Not shown in the image): This typically refers to the components or functions in the NFV architecture responsible for managing and monitoring NFVI. These include: Virtualization Infrastructure Management (VIM), Physical / Bare Metal Resource Management (PIM), Container Infrastructure Service Management (CISM), and Code Runtime Management (CRM), etc. The role of Infrastructure Management is to assist VNFM in creating and deleting instances of triggers and functions.

[0101] code repository Figure 2 (Not shown in the image): In the NFV architecture, the code repository is used to store code related to serverless applications. It supports features such as version control, collaborative development, and code review, helping to ensure software quality and maintainability.

[0102] trigger)( Figure 2 (Not shown in the image): Triggers in the NFV architecture are used to trigger corresponding operations or processes when specific events occur. Examples include event acquisition, triggering the creation of function instances, and performance optimization.

[0103] Functions play a core role in serverless architecture, executing specific business logic. They typically refer to serverless functions, which are pieces of code capable of performing specific tasks. This code can be written in various programming languages ​​and runs on serverless computing resources provided by cloud service providers. When a trigger successfully acquires an event and instantiates a function instance based on the function, the function instance (hereinafter referred to as the instance) executes the corresponding code logic according to the specific content of the event and ultimately returns the processing result.

[0104] Figure 2 The network function virtualization system shown is merely an example. In actual deployment, this network function virtualization system can contain more or fewer components, with no fixed limitations. Furthermore, multiple components in this system can be deployed on one or more nodes of the distributed system as needed. The combined application of network function virtualization systems and distributed clusters can fully leverage the flexibility and scalability of both, improving system reliability and performance.

[0105] In conjunction with the system described above, this application provides an event handling method. In this method, the target code version for handling events is determined from multiple versions according to code version calling rules, and then the event is handled by a first instance created based on the target code version. This ensures that each event can be handled efficiently and accurately by a suitable code version, thereby improving the success rate of event handling.

[0106] Another event handling method introduces code version mapping information. Based on this information, the versions of related code can be identified. If an instance of one version of the related code fails to process an event, the event can be reprocessed using an instance of another version of the related code. This helps ensure that events are not lost or missed due to a single processing failure, thus improving the success rate of event handling.

[0107] It should be noted that "sending information" in this application can be understood as one device sending information to another device, or it can also be understood as one logical module within a device sending information to another logical module. For example, "server node sending information" can be understood as a server node sending information to another device (such as a host), or it can be understood as logical module 1 in the server node sending information to logical module 2 in the server node.

[0108] In this application, "receiving information" can be understood as one device receiving information from another device, or it can also be understood as a logical module within a device receiving information from another logical module. For example, "server node receiving information" can be understood as the server node receiving information from another device (such as a host), or it can be understood as logical module 1 in the server node receiving information from logical module 2 in the server node.

[0109] In this application, phrases such as "sending information to... (e.g., a host)" or related illustrations in the accompanying drawings can be understood as the destination of the information being a host. This can include sending information directly or indirectly to a host. Similarly, phrases such as "receiving information from... (e.g., a host)," "receiving information from... (e.g., a host)," or "receiving information sent by (e.g., a host)," or related illustrations in the accompanying drawings, can be understood as the source of the information being a host. This can include receiving information directly or indirectly from a host. Information may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be interpreted similarly and will not be elaborated further here.

[0110] In the following embodiments of this application, the message names between network elements, the names of parameters, or the names of information are just examples. Other names may be used in other embodiments, and the event handling method provided in this application does not specifically limit them.

[0111] It is understood that in the embodiments of this application, each network element may execute some or all of the steps in the embodiments of this application. These steps or operations are merely examples, and the embodiments of this application may also execute other operations or variations thereof. Furthermore, the steps may be executed in different orders as presented in the embodiments of this application, and it is not necessary to execute all the operations in the embodiments of this application.

[0112] It is understood that this application uses multiple server nodes as the execution entities for the interaction illustration, but this application does not limit the execution entities for the interaction illustration. The method executed by the server node in this application can also be executed by a module applied to the server node (e.g., a chip, chip system, or processor), or by a logical node, logical module, or software that can implement all or part of the functions of the server node. This application embodiment does not specifically limit this.

[0113] Figure 3 A flowchart illustrating the event handling method provided in an embodiment of this application is shown. Figure 3 As shown, the method may include the following steps:

[0114] S301, the first node obtains the code version call rules.

[0115] The first node is a server-side node with network service lifecycle management capabilities; for example, the first node may be deployed with NFVO. The first node can obtain the code version invocation rules from a third node that stores these rules. For example, the third node may be OSS / BSS. The code version invocation rules stored on the third node may be sent to the third node by the host.

[0116] Code version invocation rules are used to indicate the version of the code that handles the event. The code version can include multiple versions. For example, these multiple versions can include historical versions and the current version of code from the same series that have an iterative relationship. Alternatively, these multiple versions can also include versions of different series of code that have the same functionality, without limitation.

[0117] The events described above can be identifiable occurrences triggered by system or user actions, typically representing a change in state or the execution of a specific operation. These events can be external requests (such as HTTP requests), changes in internal data (such as adding, deleting, or modifying database content), or time-based triggers (such as timer expiration).

[0118] In one possible design, the above events are events of serverless applications.

[0119] In one possible design, the code version invocation rule includes: the characteristics of each code version and the event scope information that each code version is responsible for handling. For example, the event scope information can be the proportion of events handled, and the code version invocation rule in this case can be as shown in Table 1:

[0120] Table 1

[0121]

[0122] The scenarios shown in Table 1 can be as follows: Figure 4 As shown, version V1.0.0 handles 80% of the event handling, while version V2.0.0 handles 20%. The number of features (i.e., features V1.0.0 and V2.0.0) and the proportion of event handling handled by these versions are illustrative examples. In practice, other designs are possible, such as having more features or different proportions of event handling.

[0123] In another example, the event scope information to be processed can be the identification information of the event requester (e.g., an Internet Protocol (IP) address). In this case, the code version invocation rules can also be as shown in Table 2:

[0124] Table 2

[0125]

[0126] The example in Table 2 above illustrates the scenario with the characteristics of two versions of the code. In actual implementation, there can be more versions of the code with different characteristics, without any restrictions.

[0127] In one possible interpretation, the code version calling rule can also be called the version mapping rule.

[0128] S302, the first node sends the code version invocation rules to the second node, and the second node receives the code version invocation rules from the first node accordingly.

[0129] The second node is a server-side node with instance management capabilities. For example, the second node could be a VNFM (Virtual Navier-Standard Machine). Once the first node obtains the code version invocation rules, it can provide these rules to the second node, allowing the second node to handle potential events based on the instances determined by the code version invocation rules.

[0130] S303, the second node determines the target code version to handle the event from multiple versions based on the code version calling rules.

[0131] When an event occurs, the second node can determine the target code version for handling the event from multiple versions based on the code version calling rules.

[0132] S304, the second node processes events through the first instance.

[0133] The first instance is created based on the target code version. After the second node determines the target code version used to handle the event, the event can be handled through the first instance. Specifically, when handling events through the first instance, event processing can be implemented based on the event information obtained by the trigger. The second node can instruct the trigger to send the obtained event information to the first instance, and then the first instance will handle the event based on the event information.

[0134] Event information can include various types of information, such as event type (used to identify the type or category of the event, such as HTTP request, database update, file upload, scheduled task trigger, etc.), event source (the source or origin that triggers the event, which may include a specific interface, database table, file storage service, timer, etc.), event data (specific data or information closely related to the event, such as parameters in an HTTP request, new data values ​​in a database update, file content in a file upload, etc.), and event time (the specific timestamp of the event, used to accurately record the moment the event occurred).

[0135] Optionally, the first instance can be determined by the second node from among the already created instances. In other words, the first instance is selected from available instances, such as idle instances or instances capable of handling multiple events simultaneously. By determining the first instance from among the already created instances, the duplicate creation of instances can be avoided, thereby saving computing resources and time. Furthermore, if an already created instance meets the current requirements, directly selecting that instance can lead to faster startup and operation, improving system response speed.

[0136] Optionally, the second node can also create the first instance based on the target code version via infrastructure management. Referring to the previous introduction to infrastructure management, the second node can obtain the computing and storage resources needed to create the first instance, thereby creating and running the first instance. In other words, the first instance is a newly created instance in this case. Creating the first instance based on the target code version ensures that the code running on the first instance is the latest or a specified version.

[0137] Preferably, the second node can first determine from the already created instances whether there exists an available instance capable of handling events, created based on the target code version. If so, it is used as the first instance; otherwise, the first instance is created based on the code of the target code version.

[0138] In this embodiment, the second node determines the target code version for handling events from multiple versions according to the code version calling rules, and then processes the events through the first instance created based on the target code version, ensuring that each event can be processed efficiently and accurately by the appropriate code version, thereby improving the success rate of event processing.

[0139] In one possible design, the method may optionally further include the following step S305:

[0140] S305, if the success rate of the second node in processing events through the first instance is higher than the first threshold, update the code version call rules.

[0141] In the updated code version invocation rules, the first proportion is increased. The multiple versions of the code mentioned above can include a first version (e.g., the version represented by V1.0.0 in Table 1) and a second version (e.g., the version represented by V2.0.0 in Table 2). The target code version is the first version. When the event scope information responsible for handling is the proportion of event handling, the code version invocation rules are used to indicate that the number of first versions handling events is the first proportion (e.g., 80% as shown in Table 1) and the number of second versions handling events is the second proportion (e.g., 20% as shown in Table 1).

[0142] The second node can calculate the success rate of events processed by the first instance over a period of time. When the calculated success rate is higher than the first threshold (which can be flexibly designed; for example, the first threshold can be set to 70%), it indicates that the first instance has strong stability and reliability, and the proportion of events it is responsible for can be increased, that is, the first proportion can be increased.

[0143] In one possible design, the first version includes the current version (which can be understood as the new version), and the second version includes historical versions (which can be understood as the old version). In this scenario, it indicates that the first instance created based on the new version of the code is more stable and can increase the proportion of events it is responsible for, gradually replacing the instances created by the old version of the code.

[0144] In one possible design, the second node can also feed back the success rate to the host through the first and third nodes, and the host can then determine whether to update the code version calling rules based on the success rate.

[0145] In this embodiment, the above steps achieve intelligent adjustment of instance load and optimization of version iteration. Specifically, the second node can statistically analyze the success rate of events handled by the first instance created based on the new version of the code over a period of time. When this success rate is higher than a preset first threshold, it indicates that the first instance has strong stability. At this time, the proportion of events it is responsible for will be increased (i.e., the first proportion will be increased), thereby utilizing resources more effectively and improving the overall system's processing capacity and efficiency. Simultaneously, this mechanism also supports version iteration optimization. When instances created with the new version exhibit higher stability, the system will gradually phase out instances of the old version, achieving a smooth system upgrade. This process not only improves the system's reliability and stability but also embodies the concept of automated operation and maintenance. By reducing manual intervention, it lowers operation and maintenance costs and improves operation and maintenance efficiency and response speed.

[0146] In one possible design, optionally, prior to step S303, the method further includes the following step S306:

[0147] S306, the second node obtains the event information.

[0148] The code version invocation rule is used to indicate the code version corresponding to the event information. In the scenario described in Table 2, the event category information to be handled can be the identification information of the event requester. In this case, the event information obtained by the second node includes the identification information of the event requester, so that the second node can determine the event category to be handled corresponding to the event information.

[0149] S303 at this time may include: determining the target code version for handling the event from multiple versions based on code version calling rules and event information.

[0150] Once the second node obtains the event information, it can determine the target code version used to process the event. For example, taking the scenario shown in Table 2, assuming the event information obtained by the second node is source IP: 10.81.213.XXX, and the code version corresponding to source IP: 10.81.213.XXX has the characteristic V2.0.0, then the determined target code version used to process the event is the code version based on V2.0.0.

[0151] In this embodiment, after the second node successfully obtains the event information, it can select the corresponding target code version to process the event based on the event information. This mechanism not only ensures that each event can be processed efficiently and accurately by a suitable code version, but also gives version management greater flexibility, facilitating the gradual introduction of new versions or version upgrades without compromising system stability. It also optimizes the utilization of system resources and avoids unnecessary resource waste.

[0152] In one possible design, the method may also optionally include the following steps S307-S309:

[0153] S307, the second node obtains the first subscription information.

[0154] The first subscription information indicates a first path, which points to the relevant parties of the event. This first path is used to notify the relevant parties (e.g., the first node, the event initiating host, etc.) of the failure to process the event through the first instance. For example, the first subscription information can be a callback uniform resource locator (callback URL).

[0155] For example, the second node can obtain the aforementioned first subscription information from the first node; that is, the first node can send the first subscription information to the second node. The first node can also obtain the aforementioned first subscription information from a relevant party to the event (e.g., a host). During the event triggering process, the relevant party will pass the first subscription information as part of the event or as an additional parameter to the first node. The transmission of the first subscription information can be achieved in various ways, such as parameters in an HTTP request, the message body in a messaging system, etc., without limitation.

[0156] The execution order of steps S307 and S302 is not restricted.

[0157] S308, if the second node fails to process the event through the first instance, it sends the first response information based on the first path indicated by the first subscription information.

[0158] The first response information is used to indicate that the event processing through the first instance failed.

[0159] In this embodiment, through the above steps, the second node can react quickly and notify relevant parties when event processing fails. This helps relevant parties to understand the status of event processing in a timely manner and take appropriate measures. Furthermore, this mechanism improves system reliability because it ensures that the system proactively notifies relevant parties when event processing fails.

[0160] In one possible design, the method may also optionally include step S309:

[0161] S309, if the second node fails to process the event through the first instance, it processes the event through the second instance.

[0162] The second instance is an instance created based on a code version other than the target code version. For example, taking the scenario shown in Table 1 as an example, assuming the first instance is an instance created based on the target code version V1.0.0, then the second instance can be an instance created based on the code version V2.0.0.

[0163] In this embodiment, by introducing a second instance as an alternative for event processing, the second node can reprocess the event if the first instance fails. This helps ensure that events are not lost or missed due to a single processing failure, thus improving the success rate of event processing.

[0164] The above communication method will be further explained below with a specific example.

[0165] In this example, the above communication method is applied to a network function virtualization system. In this case, the third node can be OSS / BSS (this embodiment uses OSS as an example), the first node can be NFVO, and the second node can be VNFM. At this time, as... Figure 5 As shown, the communication method may include:

[0166] S501, OSS sends a request to NFVO to update the serverless application, and NFVO receives the request from OSS to update the serverless application.

[0167] In this scenario, the serverless application used to handle events needs to be updated, introducing a new version of the serverless application's code. At this point, the user host can send a request to NFVO to update the serverless application via OSS. The request includes: the new version of the code, code characteristics (name, version), code version invocation rules, and optionally a callback URL (including, for example, the first subscription information from step S307 above).

[0168] S502, NFVO performs integrity and validity checks on requests to update serverless applications.

[0169] The integrity and validity check includes a series of checks, such as verifying the request format, the integrity and signature of the code package, the uniqueness and validity of code characteristics, the accuracy of version mapping rules, the validity of user permissions and authentication information, and (optionally) the format and reachability of the callback URL. In addition, NFVO may perform dependency and compatibility checks to ensure compatibility between the new version of the code and existing systems. Through these comprehensive checks, NFVO ensures that the request is legitimate, valid, and secure. If all checks pass, the request is accepted and processed; otherwise, an error message is returned and the request is rejected.

[0170] S503, NFVO saves new version code to the code repository according to code characteristics.

[0171] Code characteristics typically include key information such as the code's name and version. These characteristics are used to uniquely identify and distinguish different code versions, ensuring that the correct code can be accurately identified and used in the NFV environment. When the NFVO receives a new version of code, it categorizes it according to code characteristics (such as name and version) and then stores it in the code repository. This approach helps to quickly locate and retrieve specific versions of code, improving resource management efficiency. For an explanation of the code repository, please refer to the previous introduction to the code repository in the Network Functions Virtualization system; it will not be repeated here.

[0172] In one possible interpretation, "saving to the code repository" could also be called "sending to the code repository," without restriction.

[0173] The code characteristics used for saving can be either the code characteristics carried in the request to update the serverless application in step S501 (referred to as external characteristics), or a simplified code characteristic newly assigned by NFVO (referred to as internal characteristics). Subsequently, in the NFV environment, NFVO can use either external or internal characteristics to retrieve the corresponding code.

[0174] S504, NFVO sends the above-mentioned request to update the serverless application to VNFM, and correspondingly, VNFM receives the above-mentioned request to update the serverless application from NFVO.

[0175] Based on this step, VNFM obtains the code version calling rules, the details of which can be found in step S301.

[0176] In S505, VNFM assigns a subscription identifier (sub ID) to requests for updating serverless applications and sends the subscription identifier back to NFVO in the update response.

[0177] When VNFM receives a request to update a serverless application, it assigns a unique subscription identifier to that request. This identifier is used to uniquely identify and track the request, ensuring accurate differentiation and response when processing multiple update requests. After assigning the sub-ID, VNFM generates an update response containing that subscription identifier as a formal response to the request, indicating that the request has been received and processed. Subsequently, VNFM sends the update response to NFVO so that NFVO can use the subscription identifier to track and manage the request to update the serverless application.

[0178] S506, NFVO sends an update response to OSS / BSS.

[0179] The update response includes a subscription identifier for the request to update the serverless application. The purpose of NFVO in sending an update response to OSS / BSS is to notify OSS / BSS of the processing status and result of the update request. By including the subscription identifier, NFVO ensures that OSS / BSS can accurately identify and track the update request, thereby facilitating subsequent management and operations.

[0180] S507, trigger to obtain event information.

[0181] This event information pertains to events handled by the serverless application. For a description of the event information, please refer to step S304.

[0182] Specifically, the event source can be the event information from step S306 above, for example, the event information is source IP: 10.81.213.XXX.

[0183] S508, the trigger sends a request message to the VNFM, and the VNFM receives the request message from the trigger.

[0184] The request message is used to determine which instance to use to process the event. The request message may optionally carry some event information, such as the source IP: 10.81.213.XXX, to assist VNFM in selecting an instance.

[0185] S509, VNFM determines the target code version used to handle the event based on the code version calling rules.

[0186] The explanation of this step can be found in the corresponding explanations in steps S301-S303, and will not be repeated here.

[0187] If VNFM determines that there is no available instance created based on the target code version in the system, the method may also optionally include the following step S510:

[0188] S510, VNFM triggers the creation of the first instance of code based on the target code version.

[0189] The first instance is created based on the target code version. VNFM can create the first instance through infrastructure management. After the target code version for handling events is determined in the second node, events can be handled through the first instance. For details, please refer to step S304.

[0190] S511, VNFM sends instance information to trigger, and correspondingly, trigger receives instance information from VNFM.

[0191] The instance information includes the first instance ID and routing information pointing to the first instance. This helps the trigger send information to the first instance.

[0192] S512, the trigger sends event information to the first instance based on the instance information, and the first instance receives the event information from the trigger.

[0193] The explanation of the event information can be found in step S507. After receiving the event information, the first instance can process the event by explaining the principle in step S304.

[0194] In this application, steps S507-S512 can be repeated to process multiple events.

[0195] Optionally, when the VNFM detects that the first instance processing event has failed, the method may also optionally include the following steps S513-S515:

[0196] S513 sends a failure notification message to OSS based on the callback URL and sub ID.

[0197] The failure notification message includes first response information, the description of which is referred to in step S308. Step S513 will be explained using OSS as an example of the failure notification message recipient. More specifically, the recipient of the failure notification message may need to be determined based on the actual system design and the callback URL. For example, if the callback URL points to OSS, it will be sent directly to OSS; if the callback URL points to another node, it will be sent to the corresponding node.

[0198] S514, VNFM sends alternative instance information to trigger, and correspondingly, trigger receives alternative instance information from VNFM.

[0199] The alternative instance information includes the second instance ID and routing information pointing to the second instance. This helps the trigger send information to the second instance.

[0200] S515, the trigger sends event information to the second instance based on the alternative instance information, and the second instance receives the event information from the trigger.

[0201] The explanation of the event information can be found in step S507. After receiving the event information, the second instance can process the event according to the principle explained in step S309.

[0202] In an alternative, as an alternative to steps S508-S509, VNFM may also send the code version invocation rules to the trigger. After the trigger obtains the event information in step S507, the trigger determines the target code version to be used to handle the event according to the code version invocation rules and notifies VNFM of the determined target code version.

[0203] As can be seen from the above description, this application, from the perspective of improving the success rate of event processing, determines the target code version for handling events from multiple versions according to the code version calling rules in the second node, and then handles events through the first instance created based on the target code version, ensuring that each event can be handled efficiently and accurately by the appropriate code version, thereby improving the success rate of event processing.

[0204] This application also designs an event handling method that enables an alternative instance (hereinafter referred to as the second instance) to handle the event after the current instance (hereinafter referred to as the first instance) fails to handle the event, so as to improve the success rate of event handling. Figure 6 A flowchart illustrating this event handling method is shown. For example... Figure 6 As shown, the method may include the following steps:

[0205] S601, the second node obtains code version mapping information.

[0206] The process of the second node obtaining code version mapping information is similar to that in steps S301-S302. The second node can obtain code version mapping information from the first node, while the first node obtains its code version mapping information from the third node. For details, please refer to the descriptions of steps S301-S302.

[0207] Code version mapping information is used to indicate versions of related code, including historical versions and the current version. For example, code version mapping information can be as shown in Table 3, including code characteristics of historical versions and code characteristics of the current version.

[0208] Table 3

[0209] Code characteristics APP1, V1.0.0 APP1, V2.0.0

[0210] The code characteristics of the historical version are APP1, V1.0.0, and the code characteristics of the current version are APP1, V2.0.0.

[0211] S602, if the second node fails to process the event through the first instance, it processes the event through the second instance.

[0212] Among them, such as Figure 7 As shown, when an event needs to be processed, the second node can, by default, first use the first instance to handle the event. Then, if handling the event through the first instance fails, the event is handled through the second instance. The second instance is the instance corresponding to the first instance, determined by the second node based on code version mapping information and the first instance. In other words, there is a relationship between the version of the code used to create the first instance and the version of the code used to create the second instance.

[0213] The first instance is created based on the current version of the code (e.g., APP1, V2.0.0), and the second instance is created based on a historical version of the code (e.g., APP1, V1.0.0). The second instance can be understood as a backup instance or a candidate instance.

[0214] Similar to the first instance in step S304, the first instance in step S602 can be determined by the second node from the already created instances. Alternatively, the second node can also create the first instance through infrastructure management based on the code of the target code version. Preferably, the second node can first determine from the already created instances whether there is an available instance capable of handling events, created based on the target code version. If so, it is used as the first instance; otherwise, the first instance is created based on the code of the target code version. For a detailed explanation, please refer to the description of step S304, which will not be repeated here.

[0215] Similarly, the second instance can also be determined from the already created instances. In other words, the second instance is selected from available instances, such as idle instances or instances capable of handling multiple events simultaneously. Alternatively, the second node can also be created through infrastructure management based on a historical version of the code. In other words, the second instance is a newly created instance.

[0216] In this embodiment, code version mapping information is introduced. Based on the code version mapping information, the versions of related code can be determined. When an instance of one version of the related code (e.g., the first instance) fails to process an event, the event can be reprocessed using an instance of another version of the related code (e.g., the second instance). This helps ensure that events are not lost or missed due to a single processing failure, thus improving the success rate of event processing.

[0217] In one possible design, the method may also optionally include the following steps S603-S604:

[0218] S603, the second node obtains the second subscription information.

[0219] Similar to the first subscription information in step S307, the second subscription information is used to indicate a second path, which is used to notify relevant parties (e.g., the first node, the event initiating host, etc.) of the failure to process the event through the first instance. For example, the second subscription information could be a callback URL.

[0220] For example, the second node can obtain the aforementioned second subscription information from the first node; that is, the first node can send the second subscription information to the second node. The first node can obtain the aforementioned second subscription information from a relevant party to the event (e.g., a host). During the event triggering process, the relevant party will pass the second subscription information as part of the event or as an additional parameter to the first node. The transmission of the second subscription information can be achieved in various ways, such as parameters in an HTTP request, the message body in a messaging system, etc., without limitation.

[0221] S604, if the second node fails to process the event, it sends a second response message based on the second path indicated by the second subscription information.

[0222] The second response information is used to indicate that the event processing failed through the first instance and / or the second instance.

[0223] In one possible interpretation, "sending the second response information based on the second path indicated by the second subscription information" can also be referred to as "sending the second response information through the second path indicated by the second subscription information".

[0224] In this embodiment, through the above steps, the second node can react quickly and notify relevant parties when event processing fails. This helps relevant parties to understand the status of event processing in a timely manner and take appropriate measures. Furthermore, this mechanism improves system reliability because it ensures that the system proactively notifies relevant parties when event processing fails.

[0225] In one possible design, prior to step S602, the method may optionally include the following steps S605-S606:

[0226] S605, the second node sends a storage request to the trigger, and the trigger receives the storage request from the second node accordingly.

[0227] This storage request is used to request event information needed for cached event processing. This is for use by the second instance if the first node fails to process the event through the first instance. A description of the event information can be found in step S304.

[0228] S606, the trigger responds to storage requests and caches event information.

[0229] The cached event information can be used by the second instance when processing events.

[0230] Optionally, when the second node detects that it has successfully processed the event through the first instance or the second instance, it can send a release request to the trigger. This release request is used to request the trigger to release the cached event information, thereby reducing the amount of data cached by the trigger.

[0231] In this embodiment, by caching event information, the system can quickly access this information when needed without having to re-acquire or recalculate it. This optimizes the event processing flow and reduces processing time.

[0232] The above communication method will be further explained below with a specific example.

[0233] In this example, the above communication method is applied to a network function virtualization system. In this case, the third node can be OSS, the first node can be NFVO, and the second node can be VNVNFM. At this time, as... Figure 8 As shown, the communication method may include:

[0234] S801, OSS sends a request to NFVO to update the serverless application, and NFVO receives the request from OSS to update the serverless application.

[0235] In this scenario, the serverless application used to handle events needs to be updated, introducing a new version of the serverless application's code. At this point, the user host can send a request to NFVO to update the serverless application via OSS. The request includes: the new version of the code, code characteristics (name, version), code version mapping information, and optionally a callback URL (including, for example, the second subscription information from step S603 above).

[0236] For code version mapping information, please refer to the explanation in step S601.

[0237] S802, NFVO performs integrity and validity checks on requests to update serverless applications.

[0238] The integrity and validity check includes a series of checks, such as verifying the request format, the integrity and signature of the code package, the uniqueness and validity of code characteristics, the accuracy of version mapping rules, the validity of user permissions and authentication information, and (optionally) the format and reachability of the callback URL. In addition, NFVO may perform dependency and compatibility checks to ensure compatibility between the new version of the code and existing systems. Through these comprehensive checks, NFVO ensures that the request is legitimate, valid, and secure. If all checks pass, the request is accepted and processed; otherwise, an error message is returned and the request is rejected.

[0239] S803, NFVO saves new version code to the code repository according to code characteristics.

[0240] For an explanation of this step, please refer to the explanation of step S503.

[0241] S804, NFVO sends the above-mentioned request to update the serverless application to VNFM, and correspondingly, VNFM receives the above-mentioned request to update the serverless application from NFVO.

[0242] Based on this step, VNFM obtains the code version mapping information, which can be referred to in step S601 for details.

[0243] S805, VNFM sends a storage request to the trigger, and the trigger receives the storage request from VNFM accordingly.

[0244] This storage request is used to request event information needed for cached event processing. This is so that if the first node fails to process the event through the first instance, it can use the second instance to process the event.

[0245] In S806, VNFM assigns a subscription identifier (sub ID) to requests for updating serverless applications and sends the subscription identifier back to NFVO in the update response.

[0246] For an explanation of this step, please refer to the explanation of step S505.

[0247] S807, NFVO sends an update response to OSS.

[0248] The update response includes the subscription identifier of the request to update the serverless application.

[0249] S808, trigger to obtain event information.

[0250] This event information pertains to events handled by the serverless application. For a description of the event information, please refer to step S304.

[0251] S809, the trigger sends a request message to the VNFM, and the VNFM receives the request message from the trigger.

[0252] The request message is used to determine which instance to use to handle the event.

[0253] S810, VNFM sends instance information to the trigger, and the trigger receives the instance information from VNFM accordingly.

[0254] In VNFM, by default, events are first handled by the first instance of the current version. This instance information includes the first instance ID and routing information pointing to that first instance. This helps the trigger send information to the first instance.

[0255] Optionally, if VNFM determines that there is no available existing instance created based on the current version in the system, the method may also optionally include the following step S811:

[0256] S811, VNFM triggers the creation of the first instance based on the current version of the code.

[0257] VNFM can create the first instance based on the current version of the code through infrastructure management.

[0258] S812, the trigger sends event information to the first instance based on the instance information, and the first instance receives the event information from the trigger.

[0259] Once the first instance receives the event information, it can process the event by explaining the principle in step S304.

[0260] S813, when the VNFM detects that the first instance processing event has failed, the VNFM sends alternative instance information to the trigger, and the trigger receives the alternative instance information from the VNFM accordingly.

[0261] The alternative instance information includes the second instance ID and routing information pointing to the second instance. This helps the trigger send information to the second instance.

[0262] S814, the trigger sends event information to the second instance based on the alternative instance information, and the second instance receives the event information from the trigger.

[0263] Once the second instance receives the event information, it can process the event according to the principle explained in step S602.

[0264] Optionally, when the VNFM detects that the first instance processing event has failed, the method may further include the following step S815:

[0265] S815 sends a failure notification message to OSS based on the callback URL and sub ID.

[0266] The failure notification message includes the second response information from step S604. This step is illustrated using OSS as the recipient of the failure notification message. More specifically, the recipient of the failure notification message may need to be determined based on the actual system design and the callback URL. For example, if the callback URL points to OSS, it is sent directly to OSS; if the callback URL points to another node, it is sent to the corresponding node.

[0267] As can be seen from the above description, in the event handling method provided in this application, Scheme 1 introduces code version calling rules, allowing multiple versions of code to run in parallel within the system. This ensures that each event can be handled efficiently and accurately by the appropriate code version, improving the success rate of event handling. Optionally, the scope of events handled by each version of code is limited, reducing the impact on the system when problems occur in some versions of code.

[0268] In the event handling method provided in this application, Scheme 2 also introduces code version mapping information. Based on the code version mapping information, the versions of the code with a relationship can be determined. When an instance of one version of the code with a relationship fails to process the event, the event can be reprocessed by an instance of another version of the code with a relationship. This helps to ensure that the event is not lost or missed due to a single processing failure, and improves the success rate of event handling.

[0269] In this application, Scheme 1 and / or Scheme 2 can be flexibly selected to process the event. For example, when the event occurs frequently, Scheme 1 can be used to process the event, and when the event occurs infrequently, Scheme 2 can be used to process the event.

[0270] It is understood that the event handling method proposed in the embodiments of this application is also applicable to chip systems. Specifically, the chip system of the server node (e.g., the first node and the second node) and / or the host is provided with a memory unit for storing the corresponding information for implementing the event handling method of the embodiments of this application (e.g., code version calling rules, code version mapping information, etc.). Based on the corresponding information, the processor, in conjunction with a radio frequency / antenna module with transceiver functions, interacts with the other side to implement the event handling method of the embodiments of this application.

[0271] The foregoing mainly describes the solution provided by the embodiments of this application from the perspective of the execution logic of each step. It is understood that each node, such as a network device, includes corresponding hardware structures and / or software modules to execute each function in order to achieve the above-mentioned functions. Those skilled in the art should readily recognize that, in conjunction with the algorithm steps of the examples described in the embodiments disclosed herein, the method of the embodiments of this application can be implemented in hardware, software, or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software-driven hardware manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0272] This application embodiment can divide the network device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0273] Figure 9 A structural diagram of an event processing device 900 is shown, which is applied to a first node or a second node. Figure 9 Each module in the illustrated device performs the function of the corresponding step in the method embodiment and achieves its corresponding technical effect. The beneficial effects of each module performing the steps can be found in the description of the corresponding steps in the method embodiment, and will not be repeated here. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The event processing device may include a transceiver module 910 and a processing module 920.

[0274] For example, when the event processing device is applied to the second node, the transceiver module 910 is used to obtain the code version invocation rule for indicating the version of the code for processing the event, the version of the code includes multiple versions; the processing module 920 is used to determine the target code version for processing the event from the multiple versions according to the code version invocation rule, and to process the event through a first instance created based on the target code version.

[0275] In one possible design, multiple versions include a first version and a second version. The target code version is the first version. Code version invocation rules are used to indicate that the number of first-version events processed is a first proportion, and the number of second-version events processed is a second proportion. Processing module 920 is used to update the code version invocation rules if the success rate of processing events through the first instance is higher than a first threshold. In the updated code version invocation rules, the first proportion is increased. Optionally, the first version includes the current version, and the second version includes historical versions.

[0276] In one possible design, processing module 920 is used to determine the first instance from the already created instances.

[0277] In one possible design, processing module 920 is used to create the first instance of code based on the target code version.

[0278] In one possible design, the transceiver module 910 is used to acquire event information of an event, wherein the code version invocation rule is used to indicate the code version corresponding to the event information; the processing module 920 is specifically used to determine the target code version for processing the event from multiple versions according to the code version invocation rule and the event information.

[0279] In one possible design, the transceiver module 910 is used to obtain first subscription information, wherein the first subscription information is used to indicate a first path; in the event that the event processing through the first instance fails, a first response information is sent based on the first path indicated by the first subscription information, wherein the first response information is used to indicate that the event processing through the first instance failed.

[0280] In one possible design, the processing module 920 is used to process the event via a second instance if the event processing via the first instance fails, wherein the second instance is an instance created based on a code version other than the target code version.

[0281] In another embodiment, the transceiver module 910 is configured to obtain code version mapping information indicating the version of code with an association relationship, the code being used to process events, and the version of the code including historical versions and the current version; the processing module 920 is configured to process events using a second instance created based on historical versions of code if processing events by a first instance created based on the current version of the code fails.

[0282] In one possible design, processing module 920 is used to determine a second instance from the already created instances.

[0283] In one possible design, processing module 920 is used to create a second instance based on a historical version of the code.

[0284] In one possible design, the transceiver module 910 is configured to acquire second subscription information indicating a second path; and in the event of failure to process an event, to send second response information to the second path indicated by the second subscription information, wherein the second response information is used to indicate that the event processing failed through the first instance and / or the second instance.

[0285] In one possible design, the transceiver module 910 is used to send a storage request for requesting to cache the event information.

[0286] In another example, when the event handling device is applied to the second node, the transceiver module 910 is used to obtain a code version invocation rule for indicating the version of the code that handles the event, the code version including multiple versions; and then, the code version invocation rule is sent.

[0287] In one possible design, the transceiver module 910 is also used to obtain first subscription information, wherein the first subscription information is used to indicate a first path, the first path pointing to the relevant party of the event; and to send the first subscription information.

[0288] In another embodiment, the transceiver module 910 is configured to obtain code version mapping information indicating the version of code with an association relationship, the code being used to process events, and the version of the code including historical versions and the current version; and then, to send the code version mapping information.

[0289] Each of the modules described above can be implemented in software or hardware. For example, the implementation of transceiver module 910 will be described below. Similarly, the implementation of processing module 920 can be referenced to that of transceiver module 910.

[0290] As an example of a software functional unit, the transceiver module 910 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, the transceiver module 910 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0291] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0292] As an example of a hardware functional unit, the transceiver module 910 may include at least one computing device, such as a server. Alternatively, the transceiver module 910 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0293] The transceiver module 910 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the transceiver module 910 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the transceiver module 910 can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0294] It should be noted that, in other embodiments, the transceiver module 910 can be used to execute any step in the event handling method, and the processing module 920 can be used to execute any step in the event handling method. The steps implemented by the transceiver module 910 and the processing module 920 can be specified as needed. The transceiver module 910 and the processing module 920 respectively implement different steps in the event handling method to realize all the functions of the event handling device.

[0295] This application also provides a computing device 100. For example... Figure 10 As shown, the computing device 100 includes a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other via the bus 102. The computing device 100 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 the computing device 100.

[0296] Bus 102 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 10 The bus 104 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 104 may include a path for transmitting information between various components of the computing device 100 (e.g., memory 106, processor 104, communication interface 108).

[0297] The processor 104 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).

[0298] Memory 106 may include volatile memory, such as random access memory (RAM). Processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0299] The memory 106 stores executable program code, which the processor 104 executes to implement the functions of the aforementioned transceiver module 910 and processing module 920, thereby implementing the event handling method. That is, the memory 106 stores instructions for executing the event handling method.

[0300] Alternatively, the memory 106 stores executable code, which the processor 104 executes to implement the functions of the aforementioned event handling device, thereby implementing the event handling method. That is, the memory 106 stores instructions for executing the event handling method.

[0301] The communication interface 103 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 100 and other devices or communication networks.

[0302] This application also provides 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.

[0303] like Figure 11 As shown, the computing device cluster includes at least one computing device 100. The memory 106 of one or more computing devices 100 in the computing device cluster may store the same instructions for executing event processing methods.

[0304] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing event handling methods. In other words, a combination of one or more computing devices 100 can jointly execute the instructions for executing event handling methods.

[0305] It should be noted that the memories 106 in different computing devices 100 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the event processing device. That is, the instructions stored in the memories 106 of different computing devices 100 can implement the functions of one or more modules in the transceiver module 910 and the processing module 920.

[0306] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 12 One possible implementation is shown. For example... Figure 12 As shown, two computing devices 100A and 100B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 106 in computing device 100A stores instructions for performing the functions of the transceiver module 910. Simultaneously, the memory 106 in computing device 100B stores instructions for performing the functions of the processing module 920.

[0307] Figure 12 The connection method between the computing device clusters shown can be based on the needs of the event handling method provided in this application, and therefore considers that the functions implemented by the processing module 920 are executed by the computing device 100B.

[0308] It should be understood that Figure 12 The functions of the computing device 100A shown can also be performed by multiple computing devices 100. Similarly, the functions of the computing device 100B can also be performed by multiple computing devices 100.

[0309] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 11 and Figure 12 The connection method of the computing device cluster. The difference is that the memory 106 of one or more computing devices 100 in the computing device cluster can store the same instructions for executing event processing methods.

[0310] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing event handling methods. In other words, a combination of one or more computing devices 100 can jointly execute the instructions for executing event handling methods.

[0311] It should be noted that the memory 106 in different computing devices 100 within the computing device cluster can store different instructions for executing some functions of the data detection system. That is, the instructions stored in the memory 106 of different computing devices 100 can implement the functions of the event processing device.

[0312] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute an event handling method, or an event processing mechanism.

[0313] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital multipurpose optical disc), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform an event processing method, or instruct the computing device to perform an event processing method.

[0314] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

[0315] It should be understood that in the embodiments of this application, "at least one (item)" refers to one or more, "more than one" refers to two or more, "at least two (items)" refers to two or three or more, and "and / or" is used to describe the association relationship of related objects, indicating that there can be three relationships. For example, "A and / or B" can represent: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple. It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A. For example, B can be determined based on A. It should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Furthermore, the term "connection" in the embodiments of this application refers to various connection methods, such as direct or indirect connections, to achieve communication between devices; the embodiments of this application do not impose any limitations on this.

[0316] Unless otherwise specified, the term "transmission" in the embodiments of this application refers to bidirectional transmission, encompassing the actions of sending and / or receiving. Specifically, "transmission" in the embodiments of this application includes sending data, receiving data, or both sending and receiving data. In other words, data transmission here includes uplink and / or downlink data transmission. Data may include channels and / or signals; uplink data transmission refers to uplink channel and / or uplink signal transmission, and downlink data transmission refers to downlink channel and / or downlink signal transmission. The terms "network" and "system" in the embodiments of this application refer to the same concept; a communication system is a communication network.

[0317] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0318] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0319] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0320] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device, such as a microcontroller, chip, or processor, to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0321] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, etc.) containing computer-usable program code.

[0322] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0323] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0324] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0325] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

[0326] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An event handling method, characterized in that, The method includes: Obtain code version invocation rules, wherein the code version invocation rules are used to indicate the version of the code that handles the event, and the code version includes multiple versions; The target code version for handling the event is determined from the plurality of versions according to the code version invocation rules; The event is handled by a first instance, which is an instance created based on the target code version.

2. The method according to claim 1, characterized in that, The multiple versions include a first version and a second version, the target code version is the first version, and the code version calling rule is used to indicate that the number of the first version processing events is a first proportion and the number of the second version processing events is a second proportion. The method further includes: If the success rate of processing the event through the first instance is higher than a first threshold, the code version invocation rule is updated, wherein the first proportion is increased in the updated code version invocation rule.

3. The method according to claim 1 or 2, characterized in that, The method further includes: The first instance is determined from the already created instances.

4. The method according to claim 1 or 2, characterized in that, The method further includes: The first instance is created based on the code of the target code version.

5. The method according to claim 2, characterized in that, The first version includes the current version, and the second version includes historical versions.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain event information of the event, wherein the code version invocation rule is used to indicate the code version corresponding to the event information; The step of determining the target code version for handling the event from the plurality of versions according to the code version invocation rules includes: The target code version for handling the event is determined from the plurality of versions based on the code version invocation rules and the event information.

7. The method according to any one of claims 1-6, characterized in that, The code version invocation rules include: the characteristics of each version of the code and the event scope information that each version of the code is responsible for handling.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Obtain first subscription information, wherein the first subscription information is used to indicate a first path; In the event that the event fails to be processed through the first instance, a first response message is sent to the first path indicated by the first subscription information, wherein the first response message is used to indicate that the event failed to be processed through the first instance.

9. The method according to any one of claims 1-8, characterized in that, The events described are for serverless applications.

10. The method according to any one of claims 1-9, characterized in that, The method further includes: If the event fails to be handled by the first instance, the event is handled by the second instance, wherein the second instance is an instance created based on a code version other than the target code version.

11. An event handling method, characterized in that, The method includes: Obtain code version mapping information, wherein the code version mapping information is used to indicate the versions of code with an association relationship, the code is used to process events, and the version of the code includes historical versions and the current version; If the event fails to be handled by the first instance, the event is handled by the second instance, wherein the first instance is an instance determined based on the first instance and the code version mapping information, the first instance is an instance created based on the current version of the code, and the second instance is an instance created based on the historical version of the code.

12. The method according to claim 11, characterized in that, The code version mapping information includes: code characteristics of historical versions and code characteristics of the current version.

13. The method according to claim 11 or 12, characterized in that, The method further includes: Identify the first instance and / or the second instance from the already created instances.

14. The method according to claim 11 or 12, characterized in that, The method further includes: The second instance is created based on the historical version of the code, and / or the first instance is created based on the current version of the code.

15. The method according to any one of claims 11-14, characterized in that, The method further includes: Obtain second subscription information, wherein the second subscription information is used to indicate a second path; In the event of failure to process the event, a second response message is sent to the second path indicated by the second subscription information, wherein the second response message is used to indicate that the event failed to be processed through the first instance and / or the second instance.

16. The method according to any one of claims 11-15, characterized in that, The events described are for serverless applications.

17. The method according to any one of claims 11-16, characterized in that, The method further includes: Send a storage request, wherein the storage request is used to request the caching of event information of the event.

18. An event handling method, characterized in that, The method includes: Obtain code version invocation rules; wherein, the code version invocation rules are used to indicate the version of the code that handles the event, and the code version includes multiple versions; Send the code version invocation rules.

19. The method according to claim 18, characterized in that, The multiple versions include a first version and a second version, and the code version calling rule is used to indicate that the number of the first version for processing the event is a first proportion and the number of the second version for processing the event is a second proportion.

20. The method according to claim 19, characterized in that, The first version includes the current version, and the second version includes historical versions.

21. The method according to any one of claims 18-20, characterized in that, The code version invocation rule is used to indicate the code version corresponding to the event information of the event.

22. The method according to any one of claims 18-21, characterized in that, The code version invocation rules include: the characteristics of each version of the code and the event scope information that each version of the code is responsible for handling.

23. The method according to any one of claims 18-22, characterized in that, The method further includes: Obtain first subscription information, wherein the first subscription information is used to indicate a first path, the first path pointing to the relevant party of the event; Send the first subscription information.

24. An event handling method, characterized in that, The method includes: Obtain code version mapping information, wherein the code version mapping information is used to indicate the versions of code with an association relationship, the code is used to process events, and the version of the code includes historical versions and the current version; Send the code version mapping information.

25. The method according to claim 24, characterized in that, The code version mapping information includes: code characteristics of historical versions and code characteristics of the current version.

26. An event processing device, characterized in that, It includes a module that performs the method as described in any one of claims 1-10; or, it includes a module that performs the method as described in any one of claims 11-17; or, it includes a module that performs the method as described in any one of claims 18-23; or, it includes a module that performs the method as described in any one of claims 24-25.

27. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-25.

28. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1-25.

29. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1-25.

Images