An event scheduling method, system, electronic device, and storage medium

Abstract

This invention discloses an event scheduling method, system, electronic device, and storage medium, comprising: when a business layer produces a request message, injecting a specific identifier of a target characteristic environment into the event attribute parameters of a first request message, and sending the modified first request message to a production component; the production component, based on the event attribute parameters of the first request message, converting the first request message into an MQ protocol message body including the specific identifier and writing it to a message middleware; a consumption component listening to the MQ protocol message body from the message middleware, converting the MQ protocol message body into a second request message carrying the specific identifier, and sending the second request message to the business layer; and the business layer routing the second request message to the target characteristic environment for consumption based on preset routing rules and the specific identifier. This ensures that request messages generated in the target characteristic environment are ultimately consumed in the target characteristic environment, i.e., that specific request messages are consumed by specific characteristic environments.

Description

Technical Field

[0001] This invention relates to the field of distributed systems technology, and in particular to an event scheduling method, system, electronic device, and storage medium. Background Technology

[0002] Message middleware is a crucial component in distributed systems, primarily addressing issues such as application decoupling, asynchronous messaging, and traffic shaping. It utilizes efficient and reliable message passing mechanisms for asynchronous data transmission and integrates distributed systems based on data communication. By providing a message middleware model and message passing mechanism, it can extend inter-process communication in distributed environments and is widely used in the microservices domain.

[0003] Currently, commonly used message middleware includes ActiveMQ, RabbitMQ, Kafka, and RocketMQ. Existing technologies generally connect to the message middleware service address via the TCP protocol, and the business service code uses relevant interfaces from third-party libraries to connect to the message middleware, produce messages, and consume messages. For example, in Go, Shopify / sarama is used to connect to Kafka.

[0004] In existing technologies, message middleware is primarily used through third-party libraries. Message producers and consumers in the business layer are directly coupled with this middleware, requiring developers to focus not only on their own business logic but also on the usage details of the middleware, increasing the burden on business development. Furthermore, during development, functional testing and verification are typically performed using specific environments. Due to the strong coupling between business services and the message middleware, the middleware allocates which messages a message consumer consumes; the service itself cannot decide which environment's messages it should accept. Additionally, the canary deployment method cannot ensure that specific messages are consumed by specific services, severely impacting development efficiency. Summary of the Invention

[0005] This invention provides an event scheduling method to solve the problem of event scheduling.

[0006] In a first aspect, the present invention provides an event scheduling method applied to an event scheduling system, the event scheduling system comprising a business layer, an event layer and a message middleware, the business layer comprising multiple feature environments with different identifiers, and the event layer comprising a production component and a consumption component;

[0007] The event scheduling method includes:

[0008] Step S1: When the business layer generates a request message, it injects a specific identifier of the target characteristic environment into the event attribute parameter of the first request message, and sends the modified first request message to the production component.

[0009] Step S2: The production component converts the first request message into an MQ protocol message body including the specific identifier based on the event attribute parameters of the first request message, and writes the MQ protocol message body into the message middleware;

[0010] Step S3: The consumer component listens to the MQ protocol message body from the message middleware, converts the MQ protocol message body into a second request message carrying the specific identifier, and sends the second request message to the business layer;

[0011] Step S4: The business layer routes the second request message to the target characteristic environment for consumption based on the preset routing rules and the specific identifier.

[0012] Secondly, the present invention provides an event scheduling system, including a business layer, an event layer and a message middleware, wherein the business layer includes multiple characteristic environments with different identifiers, and the event layer includes a production component and a consumption component.

[0013] The business layer is used to inject a specific identifier of the target characteristic environment into the event attribute parameters of the first request message when producing a request message, and send the modified first request message to the production component.

[0014] The production component is used to convert the first request message into an MQ protocol message body including the specific identifier based on the event attribute parameters of the first request message, and write the MQ protocol message body into the message middleware;

[0015] The consumption component is used to listen to the MQ protocol message body from the message middleware, convert the MQ protocol message body into a second request message carrying the specific identifier, and send the second request message to the business layer;

[0016] The business layer is used to route the second request message to the target characteristic environment for consumption based on preset routing rules and the specific identifier.

[0017] Thirdly, the present invention provides an electronic device, the electronic device comprising:

[0018] At least one processor; and

[0019] A memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the event scheduling method described in the first aspect of the present invention.

[0021] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the event scheduling method described in the first aspect of the present invention.

[0022] This invention provides an event scheduling method applied to an event scheduling system. The event scheduling system includes a business layer, an event layer, and a message middleware. The business layer includes multiple characteristic environments with different identifiers, and the event layer includes a production component and a consumption component. When producing a request message, the business layer injects a specific identifier of the target characteristic environment into the event attribute parameters of a first request message and sends the modified first request message to the production component. The production component converts the first request message into an MQ protocol message body including a specific identifier based on the event attribute parameters of the first request message and writes the MQ protocol message body into the message middleware. The consumption component listens for the MQ protocol message body from the message middleware, converts the MQ protocol message body into a second request message carrying a specific identifier, and sends the second request message to the business layer. The business layer routes the second request message to the target characteristic environment for consumption based on preset routing rules and the specific identifier.

[0023] First, it enables request messages generated in the target characteristic environment to be consumed in the target characteristic environment. In other words, it allows specific request messages to be consumed by message consumers in specific characteristic environments, and decouples the business layer from the message middleware. This allows business development to focus more on the business layer without having to spend too much energy on the underlying infrastructure resources such as message middleware, thereby improving development efficiency.

[0024] Second, compared to the existing technology where the request messages of the message middleware are directly sent to the business layer, this invention uses a consumer component to color the request messages of the message middleware (that is, to make the request messages carry a specific identifier), which non-intrusively realizes the purpose of custom event coloring of the request messages of the underlying message middleware to achieve custom route distribution. It can support characteristic environments, canary environments, and other unified management environments based on traffic identifiers.

[0025] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 This is a schematic diagram of the structure of an event scheduling system in the prior art provided by the present invention;

[0028] Figure 2 This is a schematic diagram of the structure of an event scheduling system provided in Embodiment 1 of the present invention;

[0029] Figure 3 This is a flowchart of an event scheduling method provided in Embodiment 1 of the present invention;

[0030] Figure 4 This is a schematic diagram illustrating the consumption of request messages with different identifiers in a specific environment, as provided in Embodiment 1 of the present invention.

[0031] Figure 5 This is a flowchart of an event scheduling method provided in Embodiment 2 of the present invention;

[0032] Figure 6 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0034] Enterprises typically have multiple primary environments, such as development, testing, gray-scale, and production environments. After requirements development is completed, R&D teams need to deploy services to these environments for functional integration testing and verification. Generally, R&D teams use the development environment for service functional self-verification. However, due to frequent changes in development environments, issues such as unstable code and incomplete service coverage arise, and overall environment instability can affect the efficiency and accuracy of functional verification. Therefore, based on the goal of having a stable environment for self-testing, integration testing, and deployment testing, and enabling multiple features to be performed simultaneously, the concept of a feature environment has emerged.

[0035] Multiple main environments can be set up in the business layer. Each main environment includes a single baseline environment, while feature environments may not exist, or there may be one or more. The specific definitions of related terms are as follows.

[0036] Main environment: The system built by a set of services / components that can provide complete business services is the boundary. Different environments are isolated in terms of data and network. Therefore, the accompanying drawings of this invention only show the various characteristic environments under the same main environment. The characteristic environment and benchmark environment mentioned below are all characteristic environments under the same main environment.

[0037] Baseline environment: A system that provides complete business services, built from relatively stable services / components.

[0038] A characteristic environment consists of at least one service / component, which can be a (message) consumer or (message) producer. Leveraging upstream services / components in the baseline environment, it provides complete business services to traffic with specific tags. An environment can have multiple characteristic environments, and the same service / component can exist in multiple characteristic environments. The identifiers of different characteristic environments are unique.

[0039] Figure 1 This invention provides a schematic diagram of the structure of a prior art event scheduling system, as shown below. Figure 1 As shown, in the prior art, the event scheduling system includes a business layer 100 and a message middleware 200. The business layer 100 includes multiple characteristic environments 110 with different identifiers. Each characteristic environment 110 includes multiple (message) producers and (message) consumers. Figure 1 (Not shown in the image) In existing technology, producers and consumers are directly connected to the address of message middleware 200. Producers send messages directly to the message middleware, and consumers listen for messages through the message middleware. Producers, consumers, and message middleware 200 are directly coupled, meaning business layer 100 is directly coupled to message middleware 200. Business developers not only need to focus on the business logic of business layer 100 itself but also on the usage details of message middleware 200, increasing the burden on business development. Furthermore, during the R&D process, functional testing and verification are generally completed through feature environment 110. Due to the strong coupling between feature environment 110 and message middleware 200, for consumers, the specific messages (requests) they consume are allocated by message middleware 200. Consumers themselves cannot decide which feature environment 110 produces which request messages to accept. Therefore, problems may arise. Figure 1 As shown, a request message with topic Tb produced in feature environment 1 is assigned to feature environment 2, while a request message with topic Tc produced in feature environment 2 is assigned to feature environment 1. This prevents specific messages from being consumed by specific feature environments, affecting the effectiveness of R&D testing and verification, and consequently impacting R&D efficiency.

[0040] The message middleware 200 has multiple message queues (hereinafter referred to as MQ). As the name suggests, MQ is essentially a queue. It operates on a FIFO (First In First Out) principle and stores messages. It is a cross-process communication mechanism used to pass messages between upstream and downstream processes.

[0041] Example 1

[0042] This invention provides an event scheduling method. This embodiment is applicable to situations where specific request messages need to be consumed in a specific environment during event scheduling. This method can be executed by an event scheduling system, which can be implemented in hardware and / or software and can be configured in an electronic device.

[0043] In this invention, the event scheduling method is applied to an event scheduling system. Figure 2 This is a schematic diagram of the structure of an event scheduling system provided in Embodiment 1 of the present invention, as shown below. Figure 2 As shown, the event scheduling system includes a business layer 100, an event layer 300, and a message middleware 200. The business layer 100 includes multiple feature environments 110 with different identifiers. Each feature environment 110 deploys producers and consumers. Figure 2 (Not shown in the image), the event layer 300 includes a production component 310 and a consumption component 320; there are multiple production components 310 and multiple consumption components 320.

[0044] Figure 3 A flowchart of an event scheduling method provided in Embodiment 1 of the present invention is shown below. Figure 3 As shown, the event scheduling method includes:

[0045] Step S1: When the business layer generates a request message, it injects the specific identifier of the target characteristic environment into the event attribute parameter of the first request message, and sends the modified first request message to the production component.

[0046] A request message includes a request header and a request body. Typically, communication between the business layer and the event layer uses the HTTP protocol. An HTTP request message mainly includes a request line, request headers, and a request body. In this embodiment, events are converted into HTTP request messages for processing and management.

[0047] The request line contains the request method, target URL, and protocol version.

[0048] The request header contains additional information about the request, represented as key-value pairs. Each key-value pair occupies one line, in the format HeaderName:HeaderValue. Request headers are commonly used to convey metadata about the request, authentication information, client information, etc.

[0049] The request body is the part of the HTTP protocol used to transmit data sent by the client to the server. It is an optional component of an HTTP request, used to pass parameters, content, or data required for the request to the server. It is commonly used with request methods such as POST and PUT to send data to the server. The format of the request body depends on the value of the Content-Type header. A common request body format, for example, is application / x-www-form-urlencoded: data is organized using key-value pairs, such as key1 = value1 & key2 = value2.

[0050] When the business layer generates request messages, it needs to construct a request message with the above structure to obtain the first request message. The target feature environment is the feature environment in which specific tests and verifications are to be performed. Therefore, when the business layer generates request messages, it injects the specific identifier of the target feature environment into the event attribute parameters of the first request message, so that the first request message includes the specific identifier of the target feature environment. Generally speaking, the specific identifier is a key value. After modification, the first request message is sent to the production component of the event layer.

[0051] It should be noted that each request message has a subject attribute, which is equivalent to the category of the request message. However, in this application, each request message is independent and each request message is a category. Therefore, the subject attribute of the request message is not emphasized.

[0052] Step S2: The production component converts the first request message into an MQ protocol message body including a specific identifier based on the event attribute parameters of the first request message, and writes the MQ protocol message body into the message middleware.

[0053] MQ (message queue) is a protocol for communication between the event layer (producer and consumer components) and the message queue in the message middleware. The MQ protocol message body is the data delivered by the producer component to the MQ in the message middleware for transmission. It consists of a message descriptor and a message body. Optionally, the MQ protocol used is TCP. The message descriptor describes the characteristics of the message, such as its priority, lifecycle, and message ID, while the message body contains the user data. In an MQ system, the message body is a crucial component of the message, containing the original data to be transmitted.

[0054] In this invention, the communication protocol between the business layer and the event layer differs from the communication protocol between the event layer and the message middleware. Therefore, to send the first request message to the message middleware, the first request message must undergo data format conversion to obtain an MQ protocol message body, which is a message body that can be sent to the message middleware. The event attribute parameters of the first request message include a specific identifier. Therefore, the production component can convert the first request message into an MQ protocol message body including the specific identifier based on the event attribute parameters of the first request message. That is, the specific identifier in the event attribute parameters of the first request message is written into the MQ protocol message body to obtain an MQ protocol message body including the specific identifier. Typically, the specific identifier is written in a specific position in the MQ protocol message body. After modification, the MQ protocol message body is written into the MQ in the message middleware.

[0055] In an optional example, when the request message service layer produces a message, it also injects a specific identifier of the target characteristic environment into the request header of the first request message. Before step S2, the process further includes: the message production component determining whether there is a request message specific identifier in the request header of the first request message or whether there is no request message specific identifier in the event attribute parameters of the first request message. If yes, the specific identifier in the request header of the first request message is filled into the event attribute parameters of the first request message, and step S2 is executed. If no, step S2 is executed.

[0056] The event attribute parameter is the data in the message body.

[0057] When the request message service layer produces a message, it also injects a specific identifier of the target characteristic environment into the request header of the first request message. Therefore, both the request header and request body of the first request message can possess this specific identifier. Since the event attribute parameters are crucial parameters as they are responsible for transmitting the specific identifier in subsequent steps, the message production component can also verify the specific identifier in the event attribute parameters before implementing step S2. If it is not present, it will be supplemented based on the specific identifier in the request header to ensure that the event attribute parameters include the specific identifier, enabling the event to be effectively executed.

[0058] Step S3: The consumer component listens for the MQ protocol message body from the message middleware, converts the MQ protocol message body into a second request message carrying a specific identifier, and sends the second request message to the business layer.

[0059] Each message has a topic attribute. When the production component receives a request message, it writes the request message to the corresponding topic in the MQ. The consumer component subscribes to the corresponding topic from the MQ to listen to the data of the corresponding topic.

[0060] In this context, a subscription is a named configuration rule that determines how messages are delivered to the user.

[0061] Therefore, the message middleware acts as a storage space. The producer component stores messages in the message middleware, and the consumer component reads messages from it. The consumer component can read the MQ protocol message body converted from the first request message. Because the communication protocols between the consumer component and the business layer, and between the consumer component and the message middleware, are different, the MQ protocol message body needs to be format-converted to obtain the second request message. It should be noted that during the format conversion, an empty request message structure is obtained. The message component needs to fill in information into the request message structure based on the content of the MQ protocol message to obtain a complete and sendable second request message.

[0062] Because the request header of the resulting second request message will lack a specific identifier during the format conversion of the MQ protocol message body, the consumer component, upon listening to the MQ protocol message body, can still parse out the specific identifier within it. Based on this identifier, the second request message can be colored—that is, the specific identifier can be filled into the request header of the second request message. Since the message middleware lacks event coloring routing capabilities, this solution only requires combining the functionality of the event layer and the existing message middleware, without intrusive modifications to the underlying infrastructure layer's message middleware, to achieve the relevant event coloring routing.

[0063] Specifically, the consumer component can be configured with interceptors. These interceptors parse specific identifiers from the MQ protocol message body. These interceptors are gRPC interceptors, specifically client-side and server-side interceptors. Interceptors can preemptively process the data in a request before receiving or initiating it, and then forward it to the designated service for processing and response. In this embodiment, the consumer component can be configured with a client-side interceptor. After converting the consumed message according to the protocol, before initiating a callback to the business consumer, the client-side interceptor retrieves the specific identifier of the event attribute parameters and populates it into the second request message.

[0064] Step S4: The business layer routes the second request message to the target characteristic environment for consumption based on preset routing rules and specific identifiers.

[0065] The second request message carries a specific identifier. The business layer, based on preset routing rules and the specific identifier, routes the second request message to the target characteristic environment for consumption. This ensures that request messages produced by a specific characteristic environment are ultimately consumed by that specific characteristic environment; that is, specific request messages are consumed by specific characteristic environments. The routing rules are the rules for distributing request messages carrying identifiers to various consumers within the characteristic environment. In event-layer mode, message producers and consumers are no longer directly associated with the message middleware. Instead, they indirectly complete message production and consumption through the event layer, transforming the traditional event publishing / subscription model into an RPC call and RPC callback model, and converting events into HTTP requests for flow and management.

[0066] Figure 4 This is a diagram illustrating the consumption of request messages with different identifiers in a specific environment, such as... Figure 4 As shown, the feature environment includes one base environment and two feature environments, identified as X and Y respectively. Therefore, the two feature environments are referred to as Feature Environment X and Feature Environment Y. The base environment includes a complete service: consumer a and ad. Feature environment X includes consumers a / c, and feature environment Y includes consumers b / d. Consumer a depends on consumer b, and consumer b depends on consumers c / d. The arrows represent request messages with different tags. Only request messages with a specific tag will flow to the corresponding consumer in the corresponding feature environment. Request messages whose tags are not found or whose corresponding feature environment has no corresponding consumer will flow to the corresponding consumer in the base environment.

[0067] (1) Request message T2 is unmarked and will only circulate in the baseline environment;

[0068] (2) Request message T1 marked with X, its request to access consumer a / c will flow to consumer a / c in characteristic environment X according to the identifier X; the request marked with X to access consumer b / d will flow to consumer b / d in the base environment since consumer b / d does not exist in characteristic environment X.

[0069] (3) Request message T3 marked with Y, its request to access consumer a / c, will flow to consumer a / c in the base environment since consumer a does not exist in characteristic environment Y; request to access consumer b / d marked with Y will flow to consumer b / d in characteristic environment Y according to the identifier Y.

[0070] As can be seen, in a feature environment, only incremental deployment of services (consumers) is required. By customizing routing rules through traffic coloring and feature environments, request messages with specific identifiers can be transmitted in specific feature environments. Therefore, based on a stable baseline environment, the development and verification of functions only require incremental deployment of new version services in the feature environment. Function verification can be completed by carrying specific tags on request messages, without affecting the stable baseline environment. This achieves the ability to manage the environment in a unified manner based on identifiers, which greatly improves development efficiency.

[0071] It should be noted that the processes of generating, formatting, sending, and reading the request message and the MQ protocol message body can all be regarded as events.

[0072] In this embodiment, the event layer is used to decouple the business layer from the message middleware. Different types of message middleware often lack a universal description method and a common third-party library, meaning developers must adapt different processing logic for each type of event, hindering the portability and productivity of implementations from event data. Here, a new definition is used to describe traditional messages, converting the traditional message body into a unified and universal event format. The specific interaction with the underlying message middleware is handled by the production and consumption components in the event layer.

[0073] This invention provides an event scheduling method applied to an event scheduling system. The event scheduling system includes a business layer, an event layer, and a message middleware. The business layer includes multiple characteristic environments with different identifiers, and the event layer includes a production component and a consumption component. When producing a request message, the business layer injects a specific identifier of the target characteristic environment into the event attribute parameters of a first request message and sends the modified first request message to the production component. The production component converts the first request message into an MQ protocol message body including a specific identifier based on the event attribute parameters of the first request message and writes the MQ protocol message body into the message middleware. The consumption component listens for the MQ protocol message body from the message middleware, converts the MQ protocol message body into a second request message carrying a specific identifier, and sends the second request message to the business layer. The business layer routes the second request message to the target characteristic environment for consumption based on preset routing rules and the specific identifier. First, it enables request messages generated within a target characteristic environment to be consumed within that same environment. This means specific request messages can be consumed by message consumers within a specific characteristic environment, decoupling the business layer's direct dependency on the message middleware. This allows business development to focus more on the business layer without investing excessive effort in underlying infrastructure resources like message middleware, thus improving development efficiency. Second, compared to existing technologies where message middleware request messages are directly sent to the business layer, this invention uses a consumption component to color the message middleware request messages (ensuring they carry a specific identifier). This non-intrusive approach allows for custom event coloring of the underlying message middleware request messages, achieving custom routing and distribution. It supports characteristic environments, canaries, and other traffic-identified unified management environments.

[0074] The rules stipulate that both the sender and receiver must use a fixed-length message header, which must have a fixed composition and record information such as the length of the message body, so that the receiver can correctly parse the data sent by the sender.

[0075] Example 2

[0076] Figure 5 This is a flowchart of an event scheduling method provided in Embodiment 2 of the present invention. This embodiment refines the above-described Embodiment 1, as follows: Figure 5 As shown, the event scheduling method includes:

[0077] Step S1: When the business layer produces a message, it injects the specific identifier of the target characteristic environment into the event attribute parameter of the first request message, and sends the modified first request message to the production component.

[0078] Step S2 includes:

[0079] Step S2.1: The production component converts the first request message into the MQ protocol format to obtain the MQ protocol message body.

[0080] Step S2.2: Fill the event attribute parameters of the first request message into a specific position in the target parameter of the MQ protocol message body so that the target parameter includes a specific identifier.

[0081] The target parameter can be a Header parameter.

[0082] Step S2.3: Write the modified MQ protocol message body into the message middleware.

[0083] The production component provides gRPC service. Based on the configured connection message middleware address, it accepts event publishing requests (i.e., the first request message) from business producers, parses them into the message format of the corresponding protocol, and writes them to the message middleware to respond to the message producers at the business layer.

[0084] Step S3 includes:

[0085] Step S3.1: The consumer component listens for MQ protocol message bodies from the message middleware.

[0086] Step S3.2: Convert the MQ protocol message body into an event format to obtain the second request message.

[0087] Step S3.3: Fill the target parameters in the MQ protocol message body into the event attribute parameters of the second request message.

[0088] Step S3.4: Parse the specific identifier from the specific position in the target parameters.

[0089] Step S3.5: Fill the specific identifier into the request header of the second request message.

[0090] Step S3.6: Send the modified second request message to the business layer.

[0091] The consumer component connects to the message middleware according to the configuration to register a consumer group to subscribe to relevant topics, parses the consumed messages into Event format, and sends them to the specified business consumer address via gRPC request, also known as message callback. Based on the response of the business consumer, it submits or retryes to complete the consumption of the event.

[0092] Step S4: The business layer routes the second request message to the target characteristic environment for consumption based on preset routing rules and specific identifiers.

[0093] To clearly illustrate the role of the event layer in the event scheduling process, the following example is used for explanation:

[0094] The specific process in the production of components is as follows:

[0095] Step 1: The production component sets up a server-side interceptor, which checks whether the event attribute parameters contain a traffic identifier before executing the write-to-MQ processing logic. If not, it parses the traffic identifier in the request header and fills it into the event attribute parameters.

[0096] Step 2: Convert the event format into a message body using the MQ protocol;

[0097] Step 3: Write the message body to the MQ.

[0098] The specific process in the consumer component is as follows:

[0099] Step 1: Register a consumer group to listen for messages on the corresponding topic;

[0100] Step 2: Convert the MQ protocol message body into event format;

[0101] Step 3: The consumer component sets up a client interceptor, which parses the target parameter (specific identifier) ​​from the event attribute parameter and fills it into the request header before sending the request (i.e., before consuming the callback business service);

[0102] Step 4: The consumer component calls back to the business service and waits for the business service to process and return the processing result. The return result can be success or failure (the failure information includes the retry strategy, which can be no retry, retry N times, infinite retry, etc.).

[0103] Step 5: Based on the processing result, if successful, mark the message consumption as complete and submit the message consumption to the MQ; if unsuccessful, execute the relevant logic according to the retry policy.

[0104] In this embodiment, the production component converts the first request message into an MQ protocol format to obtain an MQ protocol message body; it fills the event attribute parameters of the first request message into specific positions in the target parameters of the MQ protocol message body so that the target parameters include a specific identifier; it writes the modified MQ protocol message body into the message middleware, and the consumer component listens to the MQ protocol message body from the message middleware; it converts the MQ protocol message body into an event format to obtain a second request message; it fills the target parameters in the MQ protocol message body into the event attribute parameters of the second request message; it parses the specific identifier from specific positions in the target parameters; it fills the specific identifier into the request header of the second request message; and it sends the modified second request message to the business layer. By using the production and consumer components in the event layer to color events (request messages), specific request messages are consumed by message consumers in specific characteristic environments.

[0105] Optionally, the event layer also includes an inherent component and a controller component. The inherent component listens to the status and associated information of each production component. The associated information includes the service address of the message middleware connected to the production component, and the inherent component can receive and process all first request messages.

[0106] The controller component determines whether a production component is in a faulty state; if so, it designates the faulty production component as the target production component; and changes the service address of the target production component to the service address of the inherent component, so that the inherent component can replace the target production component. The inherent component can perform the functions of the target production component based on the service address, that is, it can replace the target production component in receiving the first request message, performing message format conversion, and sending the format-converted message to the corresponding message middleware.

[0107] The built-in component is Event-Link-Shared-Publisher, which exists as a fallback service, subscribing to all Publisher resources and receiving and processing publishing requests for all Topics.

[0108] Example 3

[0109] Figure 2 This is a schematic diagram of an event scheduling system provided in Embodiment 3 of the present invention. Figure 2 As shown, the event scheduling system includes a business layer 100, an event layer 300, and a message middleware 200. The business layer 100 includes multiple feature environments 110 with different identifiers, and the event layer 300 includes a production component 310 and a consumer component 312.

[0110] The business layer is used to inject a specific identifier of the target characteristic environment into the event attribute parameters of the first request message when producing a request message, and send the modified first request message to the production component.

[0111] The production component is used to convert the first request message into an MQ protocol message body including the specific identifier based on the event attribute parameters of the first request message, and write the MQ protocol message body into the message middleware;

[0112] The consumption component is used to listen to the MQ protocol message body from the message middleware, convert the MQ protocol message body into a second request message carrying the specific identifier, and send the second request message to the business layer;

[0113] The business layer is used to route the second request message to the target characteristic environment for consumption based on preset routing rules and the specific identifier.

[0114] Optionally, the business layer is further configured to inject a specific identifier of the target characteristic environment into the request header of the first request message when producing a message.

[0115] The production component is further configured to determine whether the first request message has a request header that carries the specific identifier and whether the first request message does not have the specific identifier in its event attribute parameters; if yes, the specific identifier in the request header of the first request message is filled into the event attribute parameters of the first request message, and based on the event attribute parameters of the first request message, the first request message is converted into an MQ protocol message body including the specific identifier, and the MQ protocol message body is written to the message middleware; if no, the first request message is converted into an MQ protocol message body including the specific identifier based on the event attribute parameters of the first request message, and the MQ protocol message body is written to the message middleware.

[0116] Optionally, the production component includes:

[0117] The first conversion module is used by the production component to convert the first request message into an MQ protocol format to obtain an MQ protocol message body.

[0118] The first filling module is used to fill the event attribute parameters of the first request message into a specific position in the target parameters of the MQ protocol message body, so that the target parameters include the specific identifier;

[0119] The writing module is used to write the modified MQ protocol message body into the message middleware.

[0120] Optionally, the consumption component includes:

[0121] The listening module is used by the consumer component to listen to the MQ protocol message body from the message middleware;

[0122] The second conversion module is used to convert the MQ protocol message body into an event format to obtain a second request message;

[0123] The second filling module is used to fill the target parameter in the MQ protocol message body into the event attribute parameter of the second request message;

[0124] The parsing module is used to parse the specific identifier from a specific position in the target parameters;

[0125] The third padding module is used to pad the specific identifier into the request header of the second request message;

[0126] The sending module is used to send the modified second request message to the service layer.

[0127] Optionally, the MQ protocol is the TCP protocol.

[0128] Optionally, the business layer and the event layer communicate using the HTTP protocol.

[0129] Optionally, the event layer further includes an inherent component and a controller component. The inherent component listens to the status and association information of each of the production components. The association information includes the service address of the message middleware to which the production component is connected. The inherent component is able to receive and process all the first request messages.

[0130] The controller component includes:

[0131] The judgment module is used to determine whether the production component is in a fault state; if so, the contents of the target production component determination module are executed.

[0132] A target production component determination module is used to identify the faulty production component as the target production component.

[0133] The replacement module is used to change the service address of the target production component to the service address of the inherent component, so that the inherent component replaces the target production component.

[0134] Optionally, the event layer includes a control plane. The control plane defines resources through a declarative API. The Kubernetes Controller is responsible for managing CRD resources, including resource verification and maintaining data consistency with the expected state, but does not directly participate in event production and publishing. Simultaneously, Kubernetes Webhooks are used to add admission control for CRD resources, primarily including operations such as creation, modification, and deletion. CRD resources specifically include: EventEngine, TopicBinding, Publisher, ConsumerBinding, and Subscriber.

[0135] EventEngine is an abstraction of message middleware instance information, mainly used to manage and describe access information, temporary failover information, etc. of message middleware instances.

[0136] TopicBinding is equivalent to the Topic concept in message queues, declaring the binding information between a Topic and an EventEngine. A Topic is carried by a TopicBinding. Publisher is the product of TopicBinding, automatically created based on the TopicBinding resource. Essentially, it combines Topic information and EventEngine information, and the final product is a set of Workload resources (including Deployment, Service, Configmap, HPA) that provide gRPC services.

[0137] ConsumerBinding is equivalent to the concept of ConsumerGroup in message middleware, that is, it declares the binding relationship between ConsumerGroup and Topic. A ConsumerGroup is carried by a ConsumerBinding.

[0138] Subscriber is a product of ConsumerBinding, automatically created based on ConsumerBinding resources. Essentially, it combines Topic information and ConsumerGroup information, and the final product is a set of Workload resources (including Deployment, Service, Configmap, HPA) that provide gRPC services.

[0139] Optionally, production components can be categorized into the following types:

[0140] (1) Exclusive type: For throughput considerations, only the publishing request of a single Topic is processed, and it is created by the control plane in the event layer. The control plane will automatically maintain a set of workload resources including Deployment / Service / ConfigMap / HPA resources based on the Publisher resources.

[0141] (2) Shared type: In order to save resources, the shared type Pub does not create Workload resources. Instead, it is created by the control plane. However, it only declares the binding relationship between Topic and EventEngine. The Event-Link-Shared-Publisher service handles the Topic publishing requests.

[0142] The premise of using inherent components as a fallback is that the status information of exclusive Pub resources is monitored and marked by the Controller to ensure that the service is functioning correctly.

[0143] The Event-Link-Shared-Publisher (an inherent component) can provide fallback in two ways, both based on changing the service discovery address. The specific method used depends on the business service itself.

[0144] Method 1: The EventLink (event layer) registry listens to all Publisher resources and records the service address and health status of the corresponding Publisher resources. Business producers register their topics and MQ addresses with the registry to obtain the appropriate Pub (production component) address to send to. The registry returns a service address to the business producer. Normally, this is the service address for an exclusive Pub. If the exclusive Pub service fails or becomes unavailable, the registry sends a new address—the Event-Link-Shared-Publisher address—to the business service, thus providing a fallback and ensuring that message production is not affected. Once the exclusive Pub service recovers, the registry sends the exclusive Pub address back to the business service. However, this method requires the business service to actively listen for and update the received address promptly.

[0145] Method 2: The Controller service automatically generates routing configurations based on the health status of all Publisher resources. Specifically, the routing configuration matches requests sent to the Event-Link-Shared-Publisher service address. If the request header contains the corresponding Topic and EventEngine information, it is sent to the corresponding exclusive Pub service address; otherwise, it is sent to the Event-Link-Shared-Publisher service address. Business services uniformly send requests to the Event-Link-Shared-Publisher service address. If the exclusive Pub is running normally, business requests will be routed to the exclusive Pub service address; if there is a failure or other unavailability, the controller will update the routing configuration and remove the service address of that Pub, so business requests will ultimately be routed to the Event-Link-Shared-Publisher service address. However, this method requires business producers to actively fill the request header with Topic and EventEngine information.

[0146] Optionally, the operation and maintenance management of message middleware instances is generally handled by the operation and maintenance DBA, who configures alarms or manually observes the operation of the message middleware through the management platform provided by the cloud provider, and performs backup and synchronization of the message middleware instances through the management platform or scripts. The whole process is relatively labor-intensive.

[0147] Failover is a systemic, complex, and crucial issue. If business services use message middleware in a traditional way, service crashes will occur if the message middleware instance fails, requiring waiting for fault recovery or modification of the message middleware instance address.

[0148] The EventLink layer provides temporary failover capabilities at the message middleware instance level, allowing a temporary switch to a backup instance after a message middleware instance fails. However, switching between two instances cannot fully guarantee message ordering. Different failure consumption strategies can be configured in TopicBinding for different topics.

[0149] The specific fault consumption strategy is as follows:

[0150] At most once strategy: For topics with high time-sequence requirements, the order of messages needs to be strictly guaranteed. During failover, Sub will filter messages based on the timestamp of the event and discard some messages that violate the time-sequence.

[0151] At least once strategy: For topics with high integrity requirements, unless the business service itself allows idempotent operations, the Sub will ensure message integrity through message replay after a failover.

[0152] Failover rejection strategy: For topics with high timeliness and integrity requirements, most systems cannot meet this requirement, so failover is not performed.

[0153] Default strategy: For topics with low requirements for timing and integrity, where the order and completeness of messages have no impact on business operations, you can simply switch connection instances.

[0154] The specific implementation is as follows:

[0155] (1) Configure fault policies in the EventEngine resource in advance (such as backup instance address, automatic / manual switching, switching only producer Pub / switching only consumer Sub / switching both producer Pub and consumer Sub), and configure fault consumption policies in the TopicBinding resource. The corresponding ConsumerBinding resource will have the same fault consumption policy as the TopicBinding resource.

[0156] (2) The Eventlink health detection module performs health detection on message middleware instances. When a message middleware instance is unhealthy, it sends an alarm and triggers EventEngine resource changes.

[0157] (3) Changes to EventEngine resources will trigger changes to Pub and Sub configurations. All associated Pub and Sub will connect to specific message middleware instances and execute corresponding consumption strategies based on the latest configuration and in conjunction with the fault consumption strategy, thereby completing the failover.

[0158] The event scheduling system provided in this embodiment of the invention can execute the event scheduling method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0159] Example 4

[0160] Figure 6 A schematic diagram of an electronic device 40 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0161] like Figure 6 As shown, the electronic device 40 includes at least one processor 41 and a memory, such as a read-only memory (ROM) 42 or a random access memory (RAM) 43, communicatively connected to the at least one processor 41. The memory stores computer programs executable by the at least one processor. The processor 41 can perform various appropriate actions and processes based on the computer program stored in the ROM 42 or loaded into the RAM 43 from storage unit 48. The RAM 43 may also store various programs and data required for the operation of the electronic device 40. The processor 41, ROM 42, and RAM 43 are interconnected via a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0162] Multiple components in electronic device 40 are connected to I / O interface 45, including: input unit 46, such as keyboard, mouse, etc.; output unit 47, such as various types of monitors, speakers, etc.; storage unit 48, such as disk, optical disk, etc.; and communication unit 49, such as network card, modem, wireless transceiver, etc. Communication unit 49 allows electronic device 40 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0163] Processor 41 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 41 performs the various methods and processes described above, such as event scheduling methods.

[0164] In some embodiments, the event scheduling method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 40 via ROM 42 and / or communication unit 49. When the computer program is loaded into RAM 43 and executed by processor 41, one or more steps of the event scheduling method described above may be performed. Alternatively, in other embodiments, processor 41 may be configured to execute the event scheduling method by any other suitable means (e.g., by means of firmware).

[0165] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0166] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0167] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0168] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0169] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0170] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0171] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0172] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An event scheduling method, characterized in that, This is applied to an event scheduling system, which includes a business layer, an event layer, and a message middleware. The business layer includes multiple feature environments with different identifiers. The event layer includes a production component and a consumption component. The event layer also includes an inherent component and a controller component. The inherent component monitors the status and association information of each production component. The association information includes the service address of the message middleware to which the production component is connected. The event scheduling method includes: Step S1: When the business layer generates a request message, it injects a specific identifier of the target characteristic environment into the event attribute parameter of the first request message, and sends the modified first request message to the production component. Step S2: The production component converts the first request message into an MQ protocol message body including the specific identifier based on the event attribute parameters of the first request message, and writes the MQ protocol message body into the message middleware; Step S3: The consumer component listens to the MQ protocol message body from the message middleware, converts the MQ protocol message body into a second request message carrying the specific identifier, and sends the second request message to the business layer; Step S4: The business layer routes the second request message to the target characteristic environment for consumption based on preset routing rules and the specific identifier; Step S2 includes: The production component converts the first request message into MQ protocol format to obtain an MQ protocol message body; The event attribute parameters of the first request message are filled into a specific position in the target parameters of the MQ protocol message body, so that the target parameters include the specific identifier; Write the modified MQ protocol message body into the message middleware; Step S3 includes: The consumer component listens for the MQ protocol message body from the message middleware; The MQ protocol message body is converted into an event format to obtain the second request message; The target parameter in the MQ protocol message body is filled into the event attribute parameter of the second request message; The specific identifier is parsed from a specific position in the target parameters; The specific identifier is populated into the request header of the second request message; The modified second request message is sent to the business layer.

2. The event scheduling method as described in claim 1, characterized in that, When producing messages, the business layer also injects a specific identifier of the target characteristic environment into the request header of the first request message; Before step S2, the following is also included: The production component determines whether the specific identifier is carried in the request header of the first request message or whether the specific identifier is not present in the event attribute parameters of the first request message. If so, fill the specific identifier in the request header of the first request message into the event attribute parameter of the first request message, and execute step S2; If not, proceed to step S2.

3. The event scheduling method as described in any one of claims 1-2, characterized in that, The MQ protocol is the TCP protocol.

4. The event scheduling method as described in any one of claims 1-2, characterized in that, The business layer and the event layer communicate using the HTTP protocol.

5. The event scheduling method as described in any one of claims 1-2, characterized in that, The inherent component is capable of receiving and processing all of the first request messages; The controller component determines whether the production component is in a fault state; If so, the faulty production component shall be used as the target production component; Change the service address of the target production component to the service address of the inherent component, so that the inherent component replaces the target production component.

6. An event scheduling system, characterized in that, It includes a business layer, an event layer, and a message middleware. The business layer includes multiple feature environments with different identifiers, and the event layer includes production components and consumption components. The business layer is used to inject a specific identifier of the target characteristic environment into the event attribute parameters of the first request message when producing a request message, and send the modified first request message to the production component. The production component is used to convert the first request message into an MQ protocol message body including the specific identifier based on the event attribute parameters of the first request message, and write the MQ protocol message body into the message middleware; The consumption component is used to listen to the MQ protocol message body from the message middleware, convert the MQ protocol message body into a second request message carrying the specific identifier, and send the second request message to the business layer; The business layer is used to route the second request message to the target characteristic environment for consumption based on preset routing rules and the specific identifier; The event scheduling system is used to execute the event scheduling method according to any one of claims 1-5.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the event scheduling method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the event scheduling method according to any one of claims 1-5.

Images