Method and apparatus for micro-service message scheduling, electronic device and storage medium
Patent Information
- Application Number
- CN202111265281.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-10-28
- Publication Date
- 2026-08-18
- Estimated Expiration
- 2041-10-28
AI Technical Summary
[0003]随着微服务化架构的逐步演进,系统的单体架构逐渐演变为分布式,以及微服务架构,很多现有的任务调度平台已经不能满足业务系统的需求
[0034] The microservice message scheduling method, apparatus, electronic device, and storage medium provided by this invention greatly accelerate program operation speed and response time by decoupling business logic through RabbitMQ, while the introduction of ZooKeeper can centrally register and manage multiple distributed services, and ensure server call load balancing by utilizing factors such as the call status of a single service cluster, thereby making greater use of system resources.
Smart Images

Figure CN116048826B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet applications, and specifically to a method, apparatus, electronic device, and storage medium for microservice message scheduling. Background Technology
[0002] Due to the distributed microservice decomposition of the system, multiple logical operations within a single business unit are separated into independent service logics and remote microservice calls are used. Different services may have different communication protocols, requiring management of the scheduling of each microservice. Under high server load, it is possible that only some of the multiple logical operations within a single business unit will succeed, which involves the issue of distributed transaction consistency. It is necessary to ensure data consistency and microservice scheduling efficiency under such circumstances.
[0003] As microservice architectures evolve, monolithic systems gradually transform into distributed systems and then into microservice architectures. Many existing task scheduling platforms can no longer meet the needs of business systems. In a distributed architecture, automatic management and scheduling optimization of various services are required. However, with the continuous increase in traffic, server processor and memory usage may become excessively high, leading to slow communication and data processing between services. This is highly likely due to timeouts in some logic or connections within the monolithic business application. This results in data incompleteness, and proactive problem detection and troubleshooting are difficult, weakening the overall system's robustness and concurrency resistance. Summary of the Invention
[0004] To address the problems existing in the prior art, the present invention provides a method, apparatus, electronic device, and storage medium for microservice message scheduling.
[0005] In a first aspect, the present invention provides a method for microservice message scheduling, comprising:
[0006] Based on the request information corresponding to each logical operation of a single business, a single encapsulated message body is determined for each single logical operation and added to the RabbitMQ message queue.
[0007] Based on the message bodies corresponding to different logical operations in the RabbitMQ message queue, determine the required microservice cluster;
[0008] Based on the pre-configuration information in the ZooKeeper center, the optimal microservice provider in the microservice cluster is determined according to the optimal rules, which serves as the optimal microservice scheduling scheme for the single logical operation.
[0009] The single business unit includes one main logic operation and multiple auxiliary logic operations.
[0010] Optionally, the method further includes:
[0011] If there are multiple concurrent single-unit services, then based on the Hyperf framework, multi-threading is enabled to process all message bodies of the RabbitMQ message queue in parallel.
[0012] In this context, all message bodies in the RabbitMQ message queue are encapsulated from the request information of each logical operation. These logical operations include all main logical operations and all auxiliary logical operations corresponding to the multiple concurrent single-unit services.
[0013] Optionally, after determining a single encapsulated message body based on the request information corresponding to each logical operation of a single business and adding it to the RabbitMQ message queue, the method further includes:
[0014] Determine the configuration information of the message body corresponding to the main logic operation of the single business, and the configuration information of the message bodies corresponding to the multiple auxiliary logic operations of the single business;
[0015] The configuration information refers to the correspondence between the message body and the program interface.
[0016] Optionally, the method further includes:
[0017] When the monolithic service is triggered, based on the configuration information of each message body in the RabbitMQ message queue, as well as the program interfaces corresponding to the main logic operation and multiple auxiliary logic operations of the monolithic service, the corresponding program is called to execute the message body.
[0018] The parameters of each message body of the individual service are stored in the database;
[0019] Based on the execution results of each message body in the RabbitMQ message queue, the corresponding message status is recorded in the database, and the RabbitMQ message queue is updated.
[0020] Optionally, the step of recording the corresponding message status in the database based on the execution result of each message body in the RabbitMQ message queue, and updating the RabbitMQ message queue, includes:
[0021] If the execution result is a failure, the message body is removed from the RabbitMQ message queue and added to the RabbitMQ delayed queue.
[0022] Based on a pre-set time interval and maximum number of repetitions, the message body in the RabbitMQ delayed queue is repeatedly executed, and the corresponding message status is recorded in the database;
[0023] If the execution result of the message body fails when the maximum number of repetitions is reached, the message body is removed from the RabbitMQ delayed queue, added to the RabbitMQ dead letter queue, and an alarm mechanism is triggered.
[0024] Optionally, the preset time interval is set in an incremental manner according to requirements.
[0025] Optionally, the optimal rule may be any one or a combination of the following:
[0026] Monitor service health, service request volume, and memory usage.
[0027] Secondly, the present invention provides a microservice message scheduling apparatus, comprising:
[0028] The queue determination module is used to determine a single, encapsulated message body based on the request information corresponding to each logical operation of a single business, and add it to the RabbitMQ message queue.
[0029] The microservice cluster determination module is used to determine the required microservice cluster based on the message bodies corresponding to different logical operations in the RabbitMQ message queue.
[0030] The microservice determination module is used to determine the optimal microservice provider in the microservice cluster based on the pre-configuration information in the ZooKeeper center and according to the optimal rules, as the optimal microservice scheduling scheme for the single logical operation.
[0031] The single business unit includes one main logic operation and multiple auxiliary logic operations.
[0032] Thirdly, the present invention provides an electronic device including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the microservice message scheduling method described in the first aspect.
[0033] Fourthly, the present invention provides a processor-readable storage medium storing a computer program for causing the processor to perform the steps of the microservice message scheduling method described in the first aspect.
[0034] The microservice message scheduling method, apparatus, electronic device, and storage medium provided by this invention greatly accelerate program operation speed and response time by decoupling business logic through RabbitMQ, while the introduction of ZooKeeper can centrally register and manage multiple distributed services, and ensure server call load balancing by utilizing factors such as the call status of a single service cluster, thereby making greater use of system resources. Attached Figure Description
[0035] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0036] Figure 1 This is a flowchart illustrating the microservice message scheduling method provided by the present invention;
[0037] Figure 2 This is a schematic diagram of the overall process of the microservice message scheduling method provided by the present invention;
[0038] Figure 3 This is a schematic diagram of the microservice message scheduling device provided by the present invention;
[0039] Figure 4 This is a schematic diagram of the physical structure of the electronic device provided by the present invention. Detailed Implementation
[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0041] The following is combined Figures 1-4 The present invention describes a method, apparatus, electronic device, and storage medium for microservice message scheduling.
[0042] Figure 1 This is a flowchart illustrating the microservice message scheduling method provided by the present invention. Figure 1 As shown, the method includes:
[0043] Step 101: Based on the request information corresponding to each logical operation of a single business, determine the encapsulated single message body for each logical operation and add it to the RabbitMQ message queue.
[0044] Step 102: Determine the required microservice cluster based on the message bodies corresponding to different logical operations in the RabbitMQ message queue;
[0045] Step 103: Based on the pre-configuration information in the ZooKeeper center, determine the optimal microservice provider in the microservice cluster according to the optimal rules, and use it as the optimal microservice scheduling scheme for the single logical operation.
[0046] The single business unit includes one main logic operation and multiple auxiliary logic operations.
[0047] Specifically, ZooKeeper is a distributed service architecture primarily used to solve data management problems frequently encountered in distributed applications. It maintains a tree-like file system data structure, allowing you to create file nodes in the ZooKeeper file system and monitor changes to the content of those nodes.
[0048] RabbitMQ is a distributed message queue. With a RabbitMQ server, the message sender does not need to know the message receiver's address, but only the RabbitMQ server address to send a message. Through RabbitMQ's message routing mechanism, the message receiver can accurately receive the message from the message sender.
[0049] A message is data transmitted between applications. Messages can be very simple, such as containing only a text string, or more complex, possibly containing embedded objects.
[0050] A message queue is a communication method between applications. Messages can be sent and immediately returned, with the messaging system ensuring reliable message delivery. Message publishers only need to publish messages to RabbitMQ without needing to determine or know who will retrieve them next, and message consumers retrieve messages from RabbitMQ without needing to know who published them. Thus, neither the publisher nor the consumer needs to be aware of the other's existence.
[0051] RabbitMQ is used for storing and forwarding messages in distributed systems, and it performs well in terms of ease of use, scalability, and high availability. Specific features include:
[0052] 1. Reliability
[0053] RabbitMQ uses several mechanisms to ensure reliability, such as persistence, delivery acknowledgments, and publish acknowledgments.
[0054] 2. Flexible Routing
[0055] Before messages enter the queue, they are routed through Exchanges. RabbitMQ provides several built-in Exchanges for typical routing functionality. For more complex routing, multiple Exchanges can be bound together, or custom Exchanges can be implemented through a plugin mechanism.
[0056] 3. Message Clustering
[0057] Multiple RabbitMQ servers can be grouped together to form a logical broker (agent or intermediary).
[0058] 4. Highly Available Queues
[0059] Queues can be mirrored across machines in a cluster, ensuring that the queue remains available even if some nodes fail.
[0060] 5. Multiple protocols
[0061] RabbitMQ supports multiple message queue protocols, such as STOMP (Simple (or Streaming) TextOriented Messaging Protocol) and MQTT (Message Queuing Telemetry Transport).
[0062] 6. Multilingual Clients
[0063] RabbitMQ supports almost all commonly used languages, such as Java, .NET, and Ruby.
[0064] 7. Management Interface (UI)
[0065] RabbitMQ provides an easy-to-use user interface that allows users to monitor and manage many aspects of the message broker.
[0066] 8. Tracing Mechanism
[0067] If a message is abnormal, RabbitMQ provides a message tracing mechanism so that users can find out what happened.
[0068] 9. Plugin System
[0069] RabbitMQ offers many plugins to extend its functionality in various ways, and users can also write their own plugins.
[0070] This invention decouples the logic of a monolithic business process using RabbitMQ. In other words, it breaks down the monolithic business logic into a main logic operation and multiple auxiliary logic operations. Taking user registration as an example, which also includes operations such as awarding coupons and points, the entire user registration monolithic business process is broken down into two main logic operations: user registration and obtaining the user's relevant personal information, and auxiliary logic operations: awarding coupons and points to the user during registration. The main logic operation can also be called the message producer, and the multiple auxiliary logic operations can be called the producer's consumers.
[0071] The user registration request information is encapsulated according to different logical operations to obtain corresponding message bodies, which are then stored in the database and delivered to the RabbitMQ message queue. The RabbitMQ message queue executes the message bodies corresponding to the main and auxiliary logical operations in parallel, which may require calling different microservice clusters.
[0072] The microservice cluster primarily serves to distribute capabilities by deploying the same application on multiple servers that provide the same service, forming a cluster that provides services to the outside world together through load balancing equipment.
[0073] In this invention, the routing addresses of each microservice provider in the microservice cluster are stored in ZooKeeper, and the connection of the connected microservice provider is determined by detecting the service communication heartbeat packet. If the connection is abnormal, that is, a certain microservice provider may be offline, an early warning function is provided to send relevant prompt information for users to refer to or view. Based on the early warning information, the problem point is found and the problematic part is repaired as soon as possible.
[0074] In addition, ZooKeeper centrally stores microservice clusters that provide the same microservice. These clusters include multiple provider routing addresses that offer the same microservice. Based on optimal rules, the address of the best microservice provider is selected to provide the corresponding microservice for the current message body. Furthermore, if a microservice provider experiences a service failure, an alarm is automatically triggered, and the address of that microservice provider is removed from the ZooKeeper central repository.
[0075] The request message of a single business can generate the corresponding main logic operation and multiple auxiliary logic operations through the above process. The relevant information of different logic operations is encapsulated into a message body and added to the RabbitMQ message queue according to the request message. The microservices that each message body needs to call are filtered in the ZooKeeper center based on the optimal rules, and the optimal microservice provider is selected to provide microservices to the message body.
[0076] The microservice message scheduling method provided by this invention greatly accelerates program operation speed and response time by decoupling business logic through RabbitMQ. The introduction of ZooKeeper enables centralized registration and management of multiple distributed services. By utilizing factors such as the call status of a single service cluster, the method ensures server call load balancing and can make greater use of system resources.
[0077] Optionally, the method further includes:
[0078] If there are multiple concurrent single-unit services, then based on the Hyperf framework, multi-threading is enabled to process all message bodies of the RabbitMQ message queue in parallel.
[0079] In this context, all message bodies in the RabbitMQ message queue are encapsulated from the request information of each logical operation. These logical operations include all main logical operations and all auxiliary logical operations corresponding to the multiple concurrent single-unit services.
[0080] Specifically, Hyperf is a high-performance, highly flexible progressive PHP coroutine framework with a built-in coroutine server and a large number of commonly used components. Its performance is significantly improved compared to traditional PHP-FPM-based frameworks. While providing ultra-high performance, it also maintains extremely flexible scalability. Standard components are all implemented based on PSR (PHP Standards Recommendations) standards. Based on a powerful dependency injection design, it ensures that most components or classes are replaceable and reusable.
[0081] For ultra-high speed, Swoole coroutines are used and extensive optimizations are made to the framework design to ensure ultra-high performance output.
[0082] For flexibility, based on Hyperf's powerful dependency injection components, all components are implemented based on the PSR standard contract and the contract defined by Hyperf, so that most components or classes within the framework are replaceable.
[0083] Based on these characteristics, Hyperf has a wide range of possibilities, such as implementing web services, gateway services, distributed middleware, microservice architecture, game servers, and the Internet of Things (IoT).
[0084] In this invention, when dealing with multiple concurrent single-client business requests using a single thread, there may still be situations where access volume surges, server processing is not timely, memory consumption is too high, and communication and data processing between services are slow. Therefore, the Hyperf framework is introduced to enable multiple processes to process all concurrent single-client business request information in parallel.
[0085] For example, if 1000 users initiate user registration requests simultaneously, each user request includes the main logic operation of user registration, as well as the auxiliary logic operation of awarding points and coupons. The Hyperf framework divides all user registration requests into 10 processes for processing, with each process handling 100 user registration requests, thereby balancing the load pressure of each process.
[0086] Furthermore, the Hyperf framework allows for finer-grained resource allocation, including multi-process, multi-thread, and multi-coroutine configurations. A process can contain multiple threads, and a thread can contain multiple coroutines. Multiple threads within the same process can execute concurrently. If one or more threads are blocked while waiting for I / O operations, other threads can still continue running. A thread can contain multiple coroutines; data sharing between different processes is difficult, while data sharing between different threads within the same process is relatively easy.
[0087] The microservice message scheduling method provided by this invention leverages the multi-process, multi-thread, and multi-coroutine processing capabilities of the Hyperf coroutine framework, along with concurrent processing capabilities, and combines RabbitMQ to decouple business logic, greatly accelerating program operation speed and response time. The introduction of ZooKeeper allows for centralized registration and management of multiple distributed services. By utilizing factors such as the call status of a single service cluster, server call load balancing is ensured, allowing for greater utilization of system resources.
[0088] Optionally, after determining a single encapsulated message body based on the request information corresponding to each logical operation of a single business and adding it to the RabbitMQ message queue, the method further includes:
[0089] Determine the configuration information of the message body corresponding to the main logic operation of the single business, and the configuration information of the message bodies corresponding to the multiple auxiliary logic operations of the single business;
[0090] The configuration information refers to the correspondence between the message body and the program interface.
[0091] Specifically, by setting up a configuration center, the main logical operations of a single business unit with multiple logical operations are registered as producers to the configuration center, and the auxiliary logical operations corresponding to the single business unit are registered as consumers to the configuration center. For example, user registration includes adding a user account and awarding coupons and points. Adding a user account corresponds to a custom program call interface A in the configuration center, awarding coupons corresponds to another custom program call interface B in the configuration center, and awarding points corresponds to another custom program call interface C in the configuration center. The relationship between program call interfaces A, B, and C is the same as the correspondence between user account conditions and awarding coupons and points in user registration.
[0092] When a single business is triggered, the pre-configured program call interface A, program call interface B and program call interface C can be called according to the multiple logical operation relationships of the single business.
[0093] The microservice message scheduling method provided by this invention leverages the multi-process, multi-threaded, and multi-coroutine processing capabilities of the Hyperf coroutine framework, along with its concurrent processing capabilities. Combined with RabbitMQ's decoupling of business logic, this significantly accelerates program computation speed and response time. Furthermore, the decomposition of business logic, persistent storage of RabbitMQ messages, and automatic resending mechanisms greatly enhance system stability and data consistency. The introduction of ZooKeeper allows for centralized registration and management of multiple distributed services, utilizing factors such as the call status of a single service cluster to ensure server call load balancing and maximize system resource utilization.
[0094] Optionally, the method further includes:
[0095] When the monolithic service is triggered, based on the configuration information of each message body in the RabbitMQ message queue, as well as the program interfaces corresponding to the main logic operation and multiple auxiliary logic operations of the monolithic service, the corresponding program is called to execute the message body.
[0096] The parameters of each message body of the individual service are stored in the database;
[0097] Based on the execution results of each message body in the RabbitMQ message queue, the corresponding message status is recorded in the database, and the RabbitMQ message queue is updated.
[0098] Specifically, when a single business request is triggered, the system automatically retrieves and calls the program call interface of the message producer corresponding to the pre-configured single business request in the configuration center, and obtains the program call interface of the associated consumer. That is, it first obtains the program call interface of the main logic operation corresponding to the single business request from the configuration center. Based on the association between the main logic operation and multiple auxiliary logic operations in the single business request, it obtains the program call interface of the corresponding auxiliary logic operation. Then, it encapsulates some parameters and information corresponding to each logic operation in the request information and stores them as message records in the database. The message records of the main logic operation and the message records of multiple auxiliary logic operations are associated. The request information and parameters of each logic operation of the single business request are encapsulated into a single message body and delivered to the RabbitMQ message queue. The execution result of each message body is recorded in the database, and the RabbitMQ message queue is updated according to the execution result of each message body. For example, message bodies with failed execution results are deleted from the RabbitMQ message queue and placed in other processing queues, updating the current RabbitMQ message queue.
[0099] The microservice message scheduling method provided by this invention leverages the multi-process, multi-threaded, and multi-coroutine processing capabilities of the Hyperf coroutine framework, along with its concurrent processing capabilities. Combined with RabbitMQ's decoupling of business logic, this significantly accelerates program computation speed and response time. Furthermore, the decomposition of business logic, persistent storage of RabbitMQ messages, and automatic resending mechanisms greatly enhance system stability and data consistency. The introduction of ZooKeeper allows for centralized registration and management of multiple distributed services, utilizing factors such as the call status of a single service cluster to ensure server call load balancing and maximize system resource utilization.
[0100] Optionally, the step of recording the corresponding message status in the database based on the execution result of each message body in the RabbitMQ message queue, and updating the RabbitMQ message queue, includes:
[0101] If the execution result is a failure, the message body is removed from the RabbitMQ message queue and added to the RabbitMQ delayed queue.
[0102] Based on a pre-set time interval and maximum number of repetitions, the message body in the RabbitMQ delayed queue is repeatedly executed, and the corresponding message status is recorded in the database;
[0103] If the execution result of the message body fails when the maximum number of repetitions is reached, the message body is removed from the RabbitMQ delayed queue, added to the RabbitMQ dead letter queue, and an alarm mechanism is triggered.
[0104] Specifically, if the execution result of a message body corresponding to the single business fails, the message body is removed from the RabbitMQ message queue and added to the RabbitMQ delayed queue.
[0105] The message body in the RabbitMQ delayed queue is repeatedly executed at a preset time interval (failure message retry interval) and a maximum number of repetitions, and the status of the message body is recorded in the database. If the maximum number of retryes is reached and the message body still fails to execute, the message body is removed from the RabbitMQ delayed queue, added to the RabbitMQ dead letter queue, and an alarm mechanism is triggered. This achieves automatic retransmission of the RabbitMQ delayed queue.
[0106] By visually displaying the execution status of all individual business logic operations through message records in the database, and combining this with RabbitMQ's dead-letter queue's custom automatic retransmission interval mechanism for failed messages, an alarm mechanism is triggered to remind manual intervention to resolve related issues. This ensures system stability and data consistency. ZooKeeper enables centralized management and scheduling of distributed services, and combined with the high-performance parallel processing capabilities of the Hyperf coroutine framework, significantly improves the overall system's processing response speed and eliminates system bottlenecks.
[0107] The microservice message scheduling method provided by this invention leverages the multi-process, multi-threaded, and multi-coroutine processing capabilities of the Hyperf coroutine framework, along with its concurrent processing capabilities. Combined with RabbitMQ's decoupling of business logic, this significantly accelerates program computation speed and response time. Furthermore, the decomposition of business logic, persistent storage of RabbitMQ messages, and automatic resending mechanisms greatly enhance system stability and data consistency. The introduction of ZooKeeper allows for centralized registration and management of multiple distributed services, utilizing factors such as the call status of a single service cluster to ensure server call load balancing and maximize system resource utilization.
[0108] Optionally, the preset time interval is set in an incremental manner according to requirements.
[0109] Specifically, in order to reduce the pressure on microservice processing and follow the principle of prioritizing new monolithic services, the preset time interval in the present invention is set in an increasing form according to requirements. That is, if the preset time for the first failure is A, the threshold time interval for the second failure is A + T, the preset time for the third failure is A + 2T, and so on. Here, T is an arbitrary unit of time. Of course, it may not be in the form of a geometric progression. For example, if the preset time for the first failure is A, the threshold time interval for the second failure is B, the preset time for the third failure is C, and so on. A < B < C, and B - A < C - B. The above is only an exemplary illustration and does not specifically limit the increasing form in the present invention.
[0110] The microservice message scheduling method provided by the present invention, through the characteristics of multi-process, multi-thread and multi-coroutine processing of the Hyperf coroutine framework, has concurrent processing capabilities, and combines RabbitMQ to decouple business logic, greatly accelerating the program operation speed and response time. At the same time, the decomposition of business logic, the persistent storage of RabbitMQ messages and the automatic resending mechanism, etc., all greatly enhance the stability of the system and the consistency of data. The introduction of zookeeper can centrally register and manage multiple distributed services, and use various factors such as the call situation of a single service cluster to ensure the load balancing of server calls and make greater use of system resources.
[0111] Optionally, the optimal rule is specifically any one or a combination of the following:
[0112] Service health, monitoring service request volume, and memory occupancy.
[0113] Specifically, the zookeeper center can automatically recommend the address of the optimal service provider according to the service health, monitoring service request volume, and memory occupancy of each microservice provider in the microservice group.
[0114] Among them, service health refers to whether the service is alive and can be normally accessed. Different service processes create temporary child nodes under zookeeper, and it is judged whether the corresponding service process is alive by whether the child node still exists in the zookeeper center. It can be understood that when the logical operation corresponding to the monolithic service is triggered, a corresponding service process will be allocated to process the message body corresponding to the logical operation. After the business logic of the message body is processed, the temporary child node no longer exists.
[0115] Monitoring service request volume refers to the number of requests for monolithic services.
[0116] The microservice message scheduling method provided by this invention leverages the multi-process, multi-threaded, and multi-coroutine processing capabilities of the Hyperf coroutine framework, along with its concurrent processing capabilities. Combined with RabbitMQ's decoupling of business logic, this significantly accelerates program computation speed and response time. Furthermore, the decomposition of business logic, persistent storage of RabbitMQ messages, and automatic resending mechanisms greatly enhance system stability and data consistency. The introduction of ZooKeeper allows for centralized registration and management of multiple distributed services, utilizing factors such as the call status of a single service cluster to ensure server call load balancing and maximize system resource utilization.
[0117] Figure 2 This is a schematic diagram of the overall process of the microservice message scheduling method provided by the present invention, as follows: Figure 2 As shown, when multiple individual business functions trigger corresponding requests, the specific process is as follows:
[0118] Step 1: Based on multiple individual business requests, determine the corresponding producers and consumers;
[0119] Step 2: For multiple individual business requests, enable multiple processes to process the corresponding RabbitMQ message queues in parallel.
[0120] Step 3: Encapsulate each logical operation in the above monolithic business request into a message body and deliver it to the RabbitMQ message queue;
[0121] Step 4: Based on the microservices that each message body in the RabbitMQ message queue needs to call, connect to ZooKeeper using the pre-configured ZooKeeper address;
[0122] Step 5: Determine the optimal microservice provider in the ZooKeeper center according to the optimal rules; alternatively, recommend idle service providers from the service address set in the ZooKeeper center based on service call information.
[0123] Step 6: The HyperF framework translates various communication protocols and calling methods into local method calls, returns the result set to the RabbitMQ message queue in Step 3, and adjusts the RabbitMQ message queue based on the returned result. After all consumer message bodies have been executed, the HyperF framework returns the call result.
[0124] The microservice message scheduling apparatus provided by the present invention will be described below. The microservice message scheduling apparatus described below can be referred to in correspondence with the microservice message scheduling method described above.
[0125] Figure 3This is a schematic diagram of the microservice message scheduling device provided by the present invention, as shown below. Figure 3 As shown, the device includes:
[0126] The queue determination module 301 is used to determine a single message body encapsulated as a unit based on the request information corresponding to each logical operation of a single business, and add it to the RabbitMQ message queue.
[0127] The microservice cluster determination module 302 is used to determine the required microservice cluster based on the message bodies corresponding to different logical operations in the RabbitMQ message queue.
[0128] The microservice determination module 303 is used to determine the optimal microservice provider in the microservice cluster based on the pre-configuration information in the ZooKeeper center and according to the optimal rules, as the optimal microservice scheduling scheme for the single logical operation.
[0129] The single business unit includes one main logic operation and multiple auxiliary logic operations.
[0130] Optionally, the device further includes a framework module 304, which is used to enable multi-threaded parallel processing of all message bodies of the RabbitMQ message queue based on the Hyperf framework if there are multiple concurrent single-unit services.
[0131] In this context, all message bodies in the RabbitMQ message queue are encapsulated from the request information of each logical operation. These logical operations include all main logical operations and all auxiliary logical operations corresponding to the multiple concurrent single-unit services.
[0132] Optionally, the queue determination module 301 is further configured to:
[0133] Determine the configuration information of the message body corresponding to the main logic operation of the single business, and the configuration information of the message bodies corresponding to the multiple auxiliary logic operations of the single business;
[0134] The configuration information refers to the correspondence between the message body and the program interface.
[0135] Optionally, the queue determination module 301 is further configured to:
[0136] When the monolithic service is triggered, based on the configuration information of each message body in the RabbitMQ message queue, as well as the program interfaces corresponding to the main logic operation and multiple auxiliary logic operations of the monolithic service, the corresponding program is called to execute the message body.
[0137] The parameters of each message body of the individual service are stored in the database;
[0138] Based on the execution results of each message body in the RabbitMQ message queue, the corresponding message status is recorded in the database, and the RabbitMQ message queue is updated.
[0139] Optionally, the queue determination module 301 is further configured to:
[0140] If the execution result is a failure, the message body is removed from the RabbitMQ message queue and added to the RabbitMQ delayed queue.
[0141] Based on a preset time interval and maximum number of repetitions, the message body in the RabbitMQ delayed queue is repeatedly executed, and the corresponding message status is recorded in the database;
[0142] If the execution result of the message body fails when the maximum number of repetitions is reached, the message body is removed from the RabbitMQ delayed queue, added to the RabbitMQ dead letter queue, and an alarm mechanism is triggered.
[0143] Optionally, the preset time interval is set in an incremental manner according to requirements.
[0144] Optionally, the optimal rule may be any one or a combination of the following:
[0145] Monitor service health, service request volume, and memory usage.
[0146] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. 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 units described above can be implemented in hardware or as software functional units.
[0147] 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 processor-readable storage medium. Based on this understanding, the technical solution 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 computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) 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, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0148] It should be noted that the apparatus provided in this embodiment of the invention can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Therefore, the parts and beneficial effects that are the same as those in the method embodiment will not be described in detail here.
[0149] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include: a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other via the communication bus 440. The processor 410 may call a computer program in the memory 430 to execute the steps of a microservice message scheduling method, such as including:
[0150] Based on the request information corresponding to each logical operation of a single business, a single encapsulated message body is determined for each single logical operation and added to the RabbitMQ message queue.
[0151] Based on the message bodies corresponding to different logical operations in the RabbitMQ message queue, determine the required microservice cluster;
[0152] Based on the pre-configuration information in the ZooKeeper center, the optimal microservice provider in the microservice cluster is determined according to the optimal rules, which serves as the optimal microservice scheduling scheme for the single logical operation.
[0153] The single business unit includes one main logic operation and multiple auxiliary logic operations.
[0154] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0155] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions, which, when executed by a computer, enable the computer to perform the steps of the microservice message scheduling method provided by the above methods, for example including:
[0156] Based on the request information corresponding to each logical operation of a single business, a single encapsulated message body is determined for each single logical operation and added to the RabbitMQ message queue.
[0157] Based on the message bodies corresponding to different logical operations in the RabbitMQ message queue, determine the required microservice cluster;
[0158] Based on the pre-configuration information in the ZooKeeper center, the optimal microservice provider in the microservice cluster is determined according to the optimal rules, which serves as the optimal microservice scheduling scheme for the single logical operation.
[0159] The single business unit includes one main logic operation and multiple auxiliary logic operations.
[0160] On the other hand, the present invention also provides a processor-readable storage medium storing a computer program for causing the processor to execute the steps of the microservice message scheduling method provided by the above methods, for example including:
[0161] Based on the request information corresponding to each logical operation of a single business, a single encapsulated message body is determined for each single logical operation and added to the RabbitMQ message queue.
[0162] Based on the message bodies corresponding to different logical operations in the RabbitMQ message queue, determine the required microservice cluster;
[0163] Based on the pre-configuration information in the ZooKeeper center, the optimal microservice provider in the microservice cluster is determined according to the optimal rules, which serves as the optimal microservice scheduling scheme for the single logical operation.
[0164] The single business unit includes one main logic operation and multiple auxiliary logic operations.
[0165] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).
[0166] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0167] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0168] 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 spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A method for microservice message scheduling, characterized in that, include: Based on the request information corresponding to each logical operation of a single business, a single encapsulated message body is determined for each single logical operation and added to the RabbitMQ message queue. Based on the message bodies corresponding to different logical operations in the RabbitMQ message queue, determine the required microservice cluster; Based on the pre-configured information from the ZooKeeper center, the optimal microservice provider in the microservice cluster is determined according to the optimal rules, which serves as the optimal microservice scheduling scheme for the single logical operation; wherein, the single business includes one main logical operation and multiple auxiliary logical operations; If there are multiple concurrent single-unit services, then based on the Hyperf framework, multi-threading is enabled to process all message bodies of the RabbitMQ message queue in parallel; wherein, all message bodies of the RabbitMQ message queue are encapsulated by the request information of each of the logical operations, and the logical operations include all main logical operations and all auxiliary logical operations corresponding to the multiple concurrent single-unit services. When the monolithic service is triggered, based on the configuration information of each message body in the RabbitMQ message queue, as well as the program interfaces corresponding to the main logic operation and multiple auxiliary logic operations of the monolithic service, the corresponding program is called to execute the message body. The parameters of each message body of the individual service are stored in the database; If the execution result of the message body is a failure, the message body is removed from the RabbitMQ message queue and added to the RabbitMQ delayed queue. Based on a preset time interval and maximum number of repetitions, the message body in the RabbitMQ delayed queue is repeatedly executed, and the corresponding message status is recorded in the database; If the execution result of the message body fails when the maximum number of repetitions is reached, the message body will be removed from the RabbitMQ delayed queue, added to the RabbitMQ dead letter queue, and an alarm mechanism will be triggered. The preset time interval is set in an incremental manner according to the requirements.
2. The microservice message scheduling method according to claim 1, characterized in that, After determining the encapsulated single message body, which is based on the request information corresponding to each logical operation of the single business and added to the RabbitMQ message queue, the method further includes: Determine the configuration information of the message body corresponding to the main logic operation of the single business, and the configuration information of the message bodies corresponding to the multiple auxiliary logic operations of the single business; The configuration information refers to the correspondence between the message body and the program interface.
3. The microservice message scheduling method according to claim 1, characterized in that, The optimal rule is specifically any one or a combination of the following: Monitor service health, service request volume, and memory usage.
4. A microservice message scheduling apparatus, characterized in that, include: The queue determination module is used to determine a single, encapsulated message body based on the request information corresponding to each logical operation of a single business, and add it to the RabbitMQ message queue. The microservice cluster determination module is used to determine the required microservice cluster based on the message bodies corresponding to different logical operations in the RabbitMQ message queue. The microservice determination module is used to determine the optimal microservice provider in the microservice cluster based on the pre-configuration information in the ZooKeeper center and according to the optimal rules, as the optimal microservice scheduling scheme for the single logical operation; wherein, the single business includes one main logical operation and multiple auxiliary logical operations; The framework module is used to enable multi-threaded parallel processing of all message bodies of the RabbitMQ message queue based on the Hyperf framework if there are multiple concurrent single-unit services. The message bodies of the RabbitMQ message queue are each encapsulated by the request information of each logical operation, and the logical operations include all main logical operations and all auxiliary logical operations corresponding to the multiple concurrent single-unit services. The queue determination module is also used to, when the single business is triggered, call the corresponding program to execute the message body based on the configuration information of each message body in the RabbitMQ message queue and the program interfaces corresponding to the main logic operation and multiple auxiliary logic operations of the single business; The parameters of each message body of the individual service are stored in the database; If the execution result of the message body is a failure, the message body is removed from the RabbitMQ message queue and added to the RabbitMQ delayed queue. Based on a preset time interval and maximum number of repetitions, the message body in the RabbitMQ delayed queue is repeatedly executed, and the corresponding message status is recorded in the database; If the execution result of the message body fails when the maximum number of repetitions is reached, the message body will be removed from the RabbitMQ delayed queue, added to the RabbitMQ dead letter queue, and an alarm mechanism will be triggered. The preset time interval is set in an incremental manner according to the requirements.
5. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the microservice message scheduling method according to any one of claims 1 to 3.
6. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the microservice message scheduling method according to any one of claims 1 to 3.
Citation Information
Patent Citations
Service processing method and device
CN109618119A
Remote procedure call processing method and system
CN112783672A