Blue-green deployment cooperation mechanism and device based on message-oriented middleware, electronic equipment and storage medium
By adding attribute identifiers to messages and dynamically adjusting the traffic ratio, the problems of message duplication and loss in blue-green deployments are solved, ensuring message consistency and reliability, reducing system latency and complexity, and improving system stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA MOBILE (SUZHOU) SOFTWARE TECH CO LTD
- Filing Date
- 2025-12-23
- Publication Date
- 2026-04-17
AI Technical Summary
During blue-green deployment, traffic switching in message middleware may lead to duplicate message consumption or loss, affecting data integrity and the accuracy of business logic. Existing technologies suffer from high complexity, high invasiveness, and increased latency.
By adding message attribute identifiers to messages, using message middleware for environment isolation, and performing verification on the production and consumption ends before traffic switching, the message ratio is dynamically adjusted. Combined with unique message identifiers and monitoring mechanisms, message consistency and reliability are ensured.
It enables smooth message switching, avoids duplicate consumption and loss, reduces system latency and complexity, and improves system stability and reliability.
Smart Images
Figure CN121887860A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and more particularly to a blue-green deployment collaboration mechanism, apparatus, electronic device, and storage medium based on message middleware. Background Technology
[0002] In distributed systems, message brokers such as RocketMQ play a crucial role in enabling asynchronous communication between services. To upgrade services without impacting system operation, enterprises typically employ a blue-green deployment strategy. This strategy gradually switches traffic from the blue environment to the green environment, aiming to reduce downtime and upgrade risks.
[0003] However, when blue-green deployment is applied to message middleware, the traffic switching phase during deployment may lead to duplicate message consumption or loss. This is because when messages are processed simultaneously in the blue and green environments, the system cannot guarantee message processing consistency, especially during critical traffic switching moments. This can result in messages being lost or consumed repeatedly between the blue and green environments, affecting data integrity and the accuracy of business logic. Summary of the Invention
[0004] To address the aforementioned technical issues, this disclosure provides a blue-green deployment collaboration mechanism, apparatus, electronic device, and storage medium based on message middleware.
[0005] Firstly, this disclosure provides a blue-green deployment collaboration mechanism based on message middleware, including: The message producer sends the first message to the message middleware. The first message carries a message attribute identifier, which is used to identify the blue-green deployment environment to which the first message belongs. The message middleware receives the first message and routes it to the corresponding message partition unit based on the message attribute identifier of the first message; The message consumer reads the first message from the message partition unit and determines whether to process the first message based on the blue-green deployment environment of the message consumer and the message attribute identifier of the first message.
[0006] Furthermore, according to the message middleware-based blue-green deployment collaboration mechanism of the first aspect of this disclosure, the message producer sends the first message to the message middleware, including: During the initial blue-green deployment, the message producer adds message attribute identifiers to the message based on the blue-green deployment environment of the message producer to obtain the first message; Send the first message to the message middleware.
[0007] Furthermore, according to the message middleware-based blue-green deployment collaboration mechanism of the first aspect of this disclosure, it also includes: When traffic switching begins, the message producer gradually increases the proportion of the first message in the corresponding green environment according to a preset time and a preset ratio. Before each increase in the message proportion, the green environment is verified. If the verification passes, then the operation to increase the message ratio will be executed; If the verification fails, the current message ratio of the first message will be rolled back to the previous message ratio. Once the green environment verification is successful, the operation of increasing the message ratio will continue.
[0008] Furthermore, according to the message middleware-based blue-green deployment collaboration mechanism of the first aspect of this disclosure, it also includes: Once the message ratio reaches 100% and the green environment verification is passed, the message attribute identifier of the first message generated by the message producer will be uniformly modified to the message attribute identifier corresponding to the green environment. The message selector on the message consumer side will be adjusted synchronously so that the message selector only reads the first message with the message attribute identifier corresponding to the green environment, thus completing the full traffic switch.
[0009] Furthermore, according to the message middleware-based blue-green deployment collaboration mechanism of the first aspect of this disclosure, it also includes: After the full traffic switch is completed, when running the green environment, monitor the key performance indicators and logging system of the message producer / consumer. If the key performance indicators exceed the preset threshold or the key logs of the logging system frequently malfunction, roll back the running status of the message producer and consumer to before the full traffic switch.
[0010] Furthermore, according to the message middleware-based blue-green deployment collaboration mechanism of the first aspect of this disclosure, the first message also includes a message unique identifier, which is generated based on a UUID.
[0011] Furthermore, according to the message middleware-based blue-green deployment collaboration mechanism of the first aspect of this disclosure, it also includes: Before processing the first message, the message consumer checks whether the first message has been successfully processed based on the message's unique identifier.
[0012] Secondly, this disclosure provides a blue-green deployment collaboration device based on message middleware, including: The message sending unit is configured to send the first message to the message middleware from the message producer. The first message carries a message attribute identifier, which is used to identify the blue-green deployment environment to which the first message belongs. The message routing unit is configured to receive the first message from the message middleware and route the first message to the corresponding message partition unit based on the message attribute identifier of the first message. The message processing unit is configured so that the message consumer reads the first message from the message partition unit and determines whether to process the first message based on the blue-green deployment environment of the message consumer and the message attribute identifier of the first message.
[0013] Thirdly, this disclosure provides an electronic device, including: a memory for storing computer-readable instructions; and a processor for executing the computer-readable instructions, causing the electronic device to perform a message middleware-based blue-green deployment collaboration mechanism as described in any embodiment of the first aspect.
[0014] Fourthly, this disclosure provides a non-transitory computer-readable storage medium for storing computer-readable instructions that, when executed by a processor, cause the processor to perform a message middleware-based blue-green deployment collaboration mechanism as described in any embodiment of the first aspect.
[0015] This disclosure provides a blue-green deployment collaboration mechanism, device, electronic device, and storage medium based on message middleware. By adding message attribute identifiers to messages when they are sent at the message producer end, messages are isolated in different environments. The message middleware routes messages based on the message attribute identifiers. In this way, the message consumer end can identify and process messages in specific environments through message attribute identifiers, avoiding message loss or duplicate consumption caused by environment confusion, and ensuring message consistency and reliability.
[0016] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description
[0017] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.
[0018] Figure 1 A flowchart illustrating a message middleware-based blue-green deployment collaboration mechanism provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating yet another message middleware-based blue-green deployment collaboration mechanism provided in this disclosure embodiment; Figure 3 A structural block diagram of a blue-green deployment collaboration device based on message middleware provided in this disclosure embodiment; Figure 4 A hardware block diagram of an electronic device provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this disclosure. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.
[0020] In distributed systems, message brokers such as RocketMQ play a crucial role in enabling asynchronous communication between services. To upgrade services without impacting system operation, enterprises typically employ a blue-green deployment strategy. This strategy gradually switches traffic from the blue environment to the green environment, aiming to reduce downtime and upgrade risks.
[0021] However, when blue-green deployment is applied to message middleware, the following problems exist: 1. During blue-green deployment, the traffic switching phase may lead to duplicate message consumption or loss. This is because when messages are processed simultaneously in the blue and green environments, the system cannot guarantee message processing consistency, especially during critical traffic switching moments. This can result in messages being lost or consumed repeatedly between the blue and green environments, affecting data integrity and the accuracy of business logic.
[0022] 2. Increased Latency: The dual-write strategy requires messages to be written simultaneously to both the old and new versions, which may increase message processing latency. This latency not only affects the system's real-time performance but may also degrade the user experience. The dual-write strategy may also cause performance bottlenecks, especially under high system load, where processing latency may increase significantly.
[0023] 3. High complexity: Existing blue-green deployment solutions typically involve complex operational steps and are highly intrusive to the system. This complexity not only increases the difficulty of deployment but may also lead to potential system failures and management challenges, making maintenance and management more difficult.
[0024] To address the aforementioned issues, a blue-green deployment collaboration mechanism based on message middleware is proposed.
[0025] Figure 1 This is a flowchart illustrating a blue-green deployment collaboration mechanism based on message middleware, provided in an embodiment of this disclosure.
[0026] like Figure 1 As shown, this message middleware-based blue-green deployment collaboration mechanism includes the following steps: Step 101: The message producer sends the first message to the message middleware. The first message carries a message attribute identifier, which is used to identify the blue-green deployment environment to which the first message belongs.
[0027] In one embodiment of this disclosure, blue-green deployment is a low-risk, no-downtime software version upgrade / deployment strategy. Its core logic is to achieve a smooth rollout of the new version (i.e., the green environment) by isolating and switching between two completely consistent operating environments (i.e., blue environment + green environment), avoiding business interruptions or data anomalies during the upgrade process. The message producer is a business service node deployed within the blue-green deployment environment (blue environment or green environment). Message middleware includes, but is not limited to, RocketMQ, Kafka, RabbitMQ, etc., and is an independently deployed message relay station. The message consumer is a business service node that receives and processes messages forwarded by the message middleware. A blue-green deployment environment refers to the message producer being deployed on either the blue environment or the green environment. The message producer generates a first message containing business data by adding message attribute identifiers to the message, and then sends this first message carrying the message attribute identifiers to the message middleware.
[0028] Step 102: The message middleware receives the first message and routes it to the corresponding message partition unit according to the message attribute identifier of the first message.
[0029] In one embodiment of this disclosure, a message partitioning unit refers to a queue on the message middleware used to store first messages belonging to different environments. Different message partitioning units are defined based on the message attribute identifier of the first message. At the message producer end, a first message is sent to the message middleware. The message middleware receives the first message, parses it, and identifies its message attribute identifier. Based on this identifier, the first messages belonging to different environments are sent to the corresponding message partitioning units.
[0030] Step 103: The message consumer reads the first message from the message partition unit and determines whether to process the first message based on the blue-green deployment environment of the message consumer and the message attribute identifier of the first message.
[0031] In one embodiment of this disclosure, the message consumer reads the first message from the message partition unit, and determines whether the first message is the same as its own blue-green deployment environment by combining its own blue-green deployment environment and the message attribute identifier of the first message. If they are the same, the first message is processed; if they are different, the first message is discarded or ignored.
[0032] In summary, based on the technical solutions provided in the embodiments of this disclosure, this disclosure isolates messages for different environments by adding message attribute identifiers when sending messages at the message producer end. The message middleware routes messages based on the message attribute identifiers, so that the message consumer end can identify and process messages in specific environments through the message attribute identifiers, avoiding message loss or duplicate consumption caused by environment confusion, and ensuring message consistency and reliability.
[0033] Furthermore, the message producer sends the first message to the message middleware, including: During the initial blue-green deployment, the message producer adds message attribute identifiers to the message based on the blue-green deployment environment of the message producer to obtain the first message; Send the first message to the message middleware.
[0034] Specifically, the initial blue-green deployment refers to the startup phase of the blue-green deployment. At this time, the system is in a state where the old version (blue environment) is running stably and the new version (green environment) has just been built. Only the blue environment handles 100% of the business traffic, while the green environment has just been deployed and has not yet been connected to real business traffic. During the initial blue-green deployment, the message producer automatically adds message attribute identifiers to messages carrying business data according to its own deployed environment (blue environment / green environment), obtains the first message, and sends the first message to the message middleware. During the initial blue-green deployment, this ensures that messages can be accurately assigned to the corresponding environment.
[0035] In summary, according to the technical solution provided in the embodiments of this disclosure, in the initial stage of blue-green deployment, the message producer automatically adds message attribute identifiers to messages and generates a first message to be sent to the message middleware through its own deployment environment (blue environment / green environment). This achieves the binding of messages with corresponding environments, ensuring that only the blue environment receives all business traffic in this stage, while the green environment does not access real business traffic. This avoids message mixing between the blue and green environments during the initial deployment from the source, ensuring the continuous and stable operation of the blue environment business, and laying the foundation for message isolation for subsequent green environment verification and traffic switching.
[0036] For example, taking RocketMQ as a message middleware, the message producer isolates messages by introducing message attribute identifiers (such as version_id) when sending messages. In this way, the message consumer can identify and process messages of specific versions.
[0037] Specific implementation steps: 1) Add version_id to the message to distinguish different deployment environments (blue environment / green environment), such as: message attribute identifier for blue environment: version_id=blue, message attribute identifier for green environment: version_id=green.
[0038] 2) Different environment control on the message production side: Before sending a message, the Producer selects an appropriate version_id based on its current deployment environment. When sending the message, the version_id is appended to the message to form the first message. Here, "version" corresponds to "environment".
[0039] Code example: 1.1.Messagemessage=newMessage("TopicVersion","TagA","OrderID001","HelloRocketMQ".getBytes()); 2.2. message.putUserProperty("version_id","green"); / / Specifies the version ID 3.3.producer.send(message); Upon receiving the first message, the message middleware parses it to obtain its version_id. Based on this version_id, it routes the first message to the appropriate queue (i.e., the aforementioned message partition unit) or consumer group. For example, a blue version message is routed to consumer group A, and a green version message is routed to consumer group B. The consumer needs to process the first message for different environments based on its version_id attribute. Here, "version" refers to the "environment."
[0040] For example, taking RocketMQ as a message middleware, when the message consumer receives a message, it determines whether to process the message by using message attribute identifiers (such as version_id).
[0041] Specific implementation steps: 1) When each "consumer" in the message consumption terminal starts up, it first determines its own environment.
[0042] 2) When consuming the first message, check the version_id to determine whether to process the first message. If the version_id does not match the current environment, skip the first message.
[0043] Code example: 1.DefaultMQPushConsumerconsumer=newDefaultMQPushConsumer("ConsumerGroupBlue"); 2.consumer.subscribe("TopicVersion"," "); 3.consumer.registerMessageListener(newMessageListenerConcurrently(){ 4.@Override 5.publicConsumeConcurrentlyStatusconsumeMessage(List <messageext>msgs,ConsumeConcurrentlyContextcontext){ 6. for(MessageExtmsg:msgs){ 7.StringversionId=msg.getUserProperty("version_id"); 8.if("blue".equals(versionId)){ 9. / / Handle blue version messages 10.processBlueVersionMessage(msg); 11.}else{ 12. / / Ignore or discard other versions of the message 13.} 14.} 15.returnConsumeConcurrentlyStatus.CONSUME_SUCCESS; 16.} 17.}); Figure 2 This is a flowchart illustrating another blue-green deployment collaboration mechanism based on message middleware provided in this embodiment of the disclosure.
[0044] like Figure 2 As shown, this message middleware-based blue-green deployment collaboration mechanism also includes the following steps: Step 201: When traffic switching begins, the message producer gradually increases the proportion of the first message in the corresponding green environment according to a preset time and a preset ratio. Before each increase in the message proportion, the green environment is verified.
[0045] In one embodiment of this disclosure, the preset time and preset ratio can be set according to actual business needs, such as every half hour or one hour, and the preset ratio can be 10% or 20%. When switching traffic between the blue environment and the green environment, the message producer can gradually increase the proportion of the first message sent to the green environment according to the preset time and the preset ratio. Before performing the increase operation, the green environment is verified, and the verification result serves as the basis for whether to continue adjusting the message ratio. Verification refers to performing a full-link check on the message processing capabilities, business stability, and data consistency of the green environment before each increase in the proportion of messages sent to the green environment.
[0046] The above verification standards can be adjusted according to actual business needs or experience, and this disclosure does not impose any restrictions on them.
[0047] For example, during the initial blue-green deployment, 100% of the traffic for the first message is directed to the blue environment. When the traffic switching begins, according to a preset time, the traffic for the first message is adjusted to 90% directed to the blue environment and 10% directed to the green environment at a preset ratio of 10%.
[0048] Furthermore, while performing step 201 above, the consumer adjusts the selector rules in the following way: New filtering rules are issued through the configuration center, and the consumer loads the rules and filters messages in real time.
[0049] For example, the filtering rules issued by the configuration center are based on message attribute identifiers, which clearly indicate that the message consumer receives messages from both environments (i.e., blue environment and green environment).
[0050] Step 202: If the verification passes, then perform the operation of increasing the message ratio.
[0051] In one embodiment of this disclosure, if the message processing capability, business stability, data consistency, etc. of the green environment all meet the passing criteria, the verification is deemed to have passed, and the operation of increasing the proportion of the first message sent to the green environment is executed.
[0052] Step 203: If the verification fails, roll back the current message ratio of the first message to the previous message ratio. After the green environment verification is passed, continue to perform the operation of increasing the message ratio.
[0053] In one embodiment of this disclosure, if any of the following criteria—message processing capability, business stability, or data consistency of the green environment—does not meet the passing standard, the verification is deemed unsuccessful. In this case, the current message ratio of the first message is rolled back to the previous message ratio. Once the green environment issue is resolved and the verification is passed again, the operation of increasing the message ratio will continue.
[0054] In summary, according to the technical solution provided in the embodiments of this disclosure, this disclosure achieves smooth migration of blue-green deployment traffic from the blue environment to the green environment by gradually increasing the message ratio of the first message corresponding to the green environment according to a preset time and ratio, coupled with full-link verification of the green environment before each increase, and a message ratio rollback mechanism when the verification fails.
[0055] Furthermore, the blue-green deployment collaboration mechanism based on message middleware also includes: Once the message ratio reaches 100% and the green environment verification is passed, the message attribute identifier of the first message generated by the message producer will be uniformly modified to the message attribute identifier corresponding to the green environment. The message selector on the message consumer side will be adjusted synchronously so that the message selector only reads the first message with the message attribute identifier corresponding to the green environment, thus completing the full traffic switch.
[0056] Specifically, during traffic switching, the proportion of messages sent to the green environment for the first message is adjusted to 100%. After the green environment verification is successful, the message attribute identifier of the first message generated by the message producer is uniformly modified to the message attribute identifier corresponding to the green environment, forcing all newly generated first messages to carry only the message attribute identifier corresponding to the green environment. Simultaneously, the message selector on the message consumer is adjusted so that it only reads the first message with the message attribute identifier corresponding to the green environment. This ensures that all message consumer selectors only read the first message carrying the green environment identifier, completing the complete switch of first message traffic from the blue environment to the green environment, thus achieving green environment deployment. For example, taking RocketMQ as the message middleware, during blue-green deployment, the routing strategy is gradually adjusted to gradually switch traffic from the blue environment to the green environment. At the same time, it is ensured that all messages in the blue environment are consumed before switching from the blue environment to the green environment.
[0057] Specific implementation: 1) Routing configuration: In the messaging system, traffic distribution between the blue and green environments can be gradually adjusted by modifying message routing policies or using specific message selectors.
[0058] 1. / / Specify the version when the producer sends the message 2. msg.putUserProperty("version_id","blue"); / / Initially, all values point to the blue environment. Here, "version" corresponds to the "environment".
[0059] 1. / / Consumers select a version when subscribing to messages 2.consumer.subscribe("TopicVersion",MessageSelector.bySql("version_id='blue'")); 2) Traffic allocation adjustment By dynamically adjusting the message's version_id attribute or modifying the consumer's selector, the proportion of messages pointing to the green version can be gradually increased. 1. / / In the initial stage, some traffic begins to be directed to the green version. 2. msg.putUserProperty("version_id","green"); / / Adjust the ratio, e.g., 10%:90% 1. / / Switch all traffic to the green version 2.consumer.subscribe("TopicVersion",MessageSelector.bySql("version_id='green'")); 3) Full switch Once the green version is verified to be correct, modify the version_id of all messages and adjust the selector for multiple consumers to complete the full switch.
[0060] 1. / / Switch all traffic to the green version 2.consumer.subscribe("TopicVersion",MessageSelector.bySql("version_id='green'")); In summary, according to the technical solution provided in the embodiments of this disclosure, after the proportion of the first message corresponding to the green environment reaches 100% and the verification is passed, this disclosure solidifies the green environment message attribute identifier of the first message on the production side and synchronously locks the message selector on the consumer side through collaborative operation. By using message middleware, the linkage and adaptation between the production side and the consumer side are realized. This not only ensures the smooth and uninterrupted switching process of blue-green deployment traffic, but also reduces the risk of business interruption and data chaos through multiple verification and fallback mechanisms, and finally achieves the safe and stable release of the green environment.
[0061] Furthermore, the aforementioned message middleware-based blue-green deployment collaboration mechanism also includes: After the full traffic switch is completed, when running the green environment, monitor the key performance indicators and logging system of the message producer / consumer. If the key performance indicators exceed the preset threshold or the key logs of the logging system frequently malfunction, roll back the running status of the message producer and consumer to before the full traffic switch.
[0062] Specifically, after the full traffic switch to the green environment is completed and the green environment is successfully published, during the operation of the green environment, key performance indicators and the log system of the message producer / consumer are monitored using monitoring tools (such as Prometheus combined with Grafana, or the monitoring system built into RocketMQ). If the key performance indicators exceed the preset threshold or the key logs of the log system frequently malfunction, the running status of the message producer and message consumer is rolled back to before the full traffic switch.
[0063] Key performance indicators (KPIs) for the message producer refer to quantifiable data (such as transmission TPS, transmission success rate, CPU utilization, etc.) that reflect the message producer's message sending capacity, communication stability with the message middleware, and its own resource load. Key logs for the message producer include, but are not limited to, environment identifiers, message IDs, and error type core fields, used to locate anomalies such as message sending failures, environment identifier injection anomalies, and resource overload. Key performance indicators (KPIs) for the message consumer refer to quantifiable data (such as consumption TPS, consumption success rate, message backlog, processing latency, etc.) that reflect the message consumer's message retrieval and processing capacity, business execution stability, message backlog, and its own resource load. Key logs for the message consumer include, but are not limited to, environment identifiers, message IDs, and error type core fields, used to locate anomalies such as message consumption failures, filtering rule anomalies, and duplicate consumption.
[0064] For example, frequent errors in critical logs refer to ≥30 occurrences of the same type of error log within 1 minute, or ≥100 cumulative errors within 5 minutes. Processing delays exceeding a preset threshold or message sending failure rates exceeding a certain percentage also apply.
[0065] In summary, based on the technical solutions provided in the embodiments of this disclosure, after the traffic is fully switched to the green environment, this disclosure utilizes monitoring tools to monitor the key performance indicators and log systems of the message production and consumption ends in real time. When an anomaly is detected, the production and consumption ends are rolled back to their operating state before the full switch, which further reduces the risk of business interruption and data chaos caused by sudden anomalies after the green environment is released, and comprehensively ensures the business continuity and stability of the entire blue-green deployment process.
[0066] Furthermore, the aforementioned blue-green deployment collaboration mechanism based on message middleware also includes: a unique message identifier, which is generated based on a UUID.
[0067] Specifically, during the rollback process, it is necessary to ensure idempotency of messages to prevent duplicate consumption or loss, which could lead to data inconsistency or errors. This disclosure achieves idempotency by designing a unique message identifier. During the generation of the first message at the message producer, a unique message identifier is added to the first message. For example, when producing messages, the message producer uses a UUID to generate a unique message identifier, ensuring that the message_id is unique for each message.
[0068] In summary, according to the technical solution provided in the embodiments of this disclosure, this disclosure achieves idempotency processing of messages by adding a unique identifier based on UUID when generating the first message at the message production end. This effectively avoids data inconsistency and business errors caused by duplicate consumption or loss of messages during the blue-green deployment rollback process, and further enhances the reliability and data accuracy of the blue-green deployment collaboration mechanism based on message middleware.
[0069] Furthermore, the aforementioned blue-green deployment collaboration mechanism based on message middleware also includes: before processing the first message, the message consumer queries whether the first message has been successfully processed based on the message's unique identifier.
[0070] Specifically, the message consumer maintains the processing status of each first message. This is primarily achieved by caching the unique identifiers of processed messages in a Redis database. Redis is a widely used distributed caching middleware, known for its low performance overhead and fast read capabilities, making it particularly suitable for high-concurrency scenarios such as order systems. When consuming the first message, the message consumer first checks the Redis database to see if the message_id of the first message is cached. If not, the first message is processed, and its success is recorded. If processing fails, the failure information is recorded, and a retry is initiated according to the retry policy. The first message is processed according to a preset retry policy (e.g., a maximum of 3 times, valid for 5 minutes). If a retry fails, the message is then added to a dead-letter queue (manual backup to prevent order message loss).
[0071] 1.publicvoidconsumeMessage(Messagemessage){ 2.StringmessageId=message.getMessageId(); 3. if(isProcessed(messageId)){ 4. return; / / Processed, return directly 5.} 6. 7.try{ 8. / / Message processing business logic 9.processBusinessLogic(message); 10. markAsProcessed(messageId); / / Mark as processed 11.}catch(Exceptione){ 12. handleFailure(messageId); / / Handle failure logic 13. / / Decide whether to retry based on the retry strategy. 14.if(shouldRetry(messageId)){ 15. retryMessage(message); 16.}else{ 17. sendToDeadLetterQueue(message); / / Send to the dead letter queue 18.} 19.} 20.} In summary, according to the technical solution provided in the embodiments of this disclosure, this disclosure caches the unique identifiers of processed messages in a Redis database, allowing the message consumer to verify whether the message has been successfully processed before processing the first message using the unique identifier. For messages that fail to be processed, a quantitative retry strategy is implemented, and after a retry fails, the message is transferred to a dead-letter queue for manual backup. This not only utilizes the low-overhead and fast-read characteristics of Redis to adapt to high-concurrency scenarios such as order systems, but also effectively avoids the problem of duplicate message consumption or loss during blue-green deployment, ensuring the idempotency of message consumption and the consistency of business data.
[0072] This disclosure also provides a blue-green deployment collaboration device based on message middleware.
[0073] Figure 3 A structural block diagram of a message middleware-based blue-green deployment collaboration device provided in this disclosure embodiment is shown below. Figure 3 As shown, the message middleware-based blue-green deployment collaboration device 300 includes: a message sending unit 301, a message routing unit 302, and a message processing unit 303.
[0074] In one exemplary embodiment, the message sending unit 301 is configured to send a first message to the message middleware from the message producer. The first message carries a message attribute identifier, which is used to identify the blue-green deployment environment to which the first message belongs. In one exemplary embodiment, the message routing unit 302 is configured to receive a first message from the message middleware and route the first message to the corresponding message partitioning unit according to the message attribute identifier of the first message; In one exemplary embodiment, the message processing unit 303 is configured to read the first message from the message partitioning unit and determine whether to process the first message based on the blue-green deployment environment of the message consumer and the message attribute identifier of the first message.
[0075] Figure 4 This is a hardware block diagram of an electronic device provided according to an embodiment of the present disclosure. The electronic device 400 according to an embodiment of the present disclosure includes at least a processor; and a memory for storing computer-readable instructions. When the computer-readable instructions are loaded and executed by the processor, the processor performs the message middleware-based blue-green deployment collaboration mechanism described in any of the preceding embodiments of the present disclosure.
[0076] Figure 4 The illustrated electronic device 400 specifically includes a central processing unit (CPU) 401, a graphics processing unit (GPU) 402, and a memory 403. These units are interconnected via a bus 404. The CPU 401 and / or GPU 402 can function as the aforementioned processor, and the memory 403 can function as the aforementioned memory storing computer-readable instructions. Furthermore, the electronic device 400 may also include a communication unit 405, a storage unit 406, an output unit 407, an input unit 408, and an external device 409, all of which are also connected to the bus 404.
[0077] Figure 5 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this disclosure. (As shown...) Figure 5 As shown, a computer-readable storage medium 500 according to an embodiment of this disclosure stores computer-readable instructions 501 thereon. When the computer-readable instructions 501 are executed by a processor, the message middleware-based blue-green deployment coordination mechanism described in any of the foregoing embodiments of this disclosure with reference to the above figures is executed. The computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, optical disk, magnetic disk, etc.
[0078] For the above, please refer to the appendix. Figure 1 - Appendix Figure 2 This disclosure describes in detail the message middleware-based blue-green deployment collaboration mechanism provided according to embodiments of the present disclosure. Compared with the prior art, the present disclosure has the following technical advantages: 1. Reduced risk of message loss and duplicate consumption: This disclosure proposes a message attribute isolation mechanism, using version_id to isolate and manage messages of different versions, avoiding message loss or duplicate consumption caused by version (i.e., environment) confusion. Existing technologies typically rely on simple traffic switching or version control, but are prone to message processing errors due to incompatibility between versions (blue environment and green environment). This disclosure ensures message consistency and reliability through fine-grained control at the message level.
[0079] 2. Reduced System Latency: Existing blue-green deployment schemes can cause latency during switchover, especially in large-scale systems. This disclosure, through an optimized version-aware routing strategy, dynamically adjusts routing paths based on traffic, ensuring messages reach the correct environment quickly and accurately during switchover. This optimization reduces latency issues caused by routing instability, making it particularly suitable for scenarios with high concurrency and low latency requirements.
[0080] 3. Improved System Stability: This disclosure avoids the risk of system instability or downtime that may occur due to a large-scale one-time switch in existing technologies by using a gradual traffic switching smooth transition scheme. More flexible version replacement is achieved by dynamically adjusting the traffic ratio. Furthermore, the automatic rollback mechanism can respond quickly when anomalies occur in the new version (i.e., the green environment), rolling back the traffic to the stable old version (blue environment), avoiding business interruption and impact, and significantly improving the system's high availability and fault recovery capabilities. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.
[0081] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.
[0082] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.
[0083] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.
[0084] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.
[0085] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.
[0086] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.
[0087] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.< / messageext>
Claims
1. A message middleware based blue-green deployment coordination mechanism, characterized in that, include: The message producer sends the first message to the message middleware. The first message carries a message attribute identifier, which is used to identify the blue-green deployment environment to which the first message belongs. The message middleware receives the first message and routes the first message to the corresponding message partition unit according to the message attribute identifier of the first message; The message consumer reads the first message from the message partition unit and determines whether to process the first message based on the blue-green deployment environment of the message consumer and the message attribute identifier of the first message.
2. The blue-green deployment collaboration mechanism based on message middleware according to claim 1, characterized in that, The message producer sends the first message to the message middleware, including: During the initial blue-green deployment, the message producer adds a message attribute identifier to the message based on the blue-green deployment environment of the message producer to obtain the first message; The first message is sent to the message middleware.
3. The blue-green deployment collaboration mechanism based on message middleware according to claim 2, characterized in that, Also includes: When traffic switching begins, the message production end gradually increases the proportion of the first message in the corresponding green environment according to a preset time and a preset ratio. Before each increase in the message proportion, the green environment is verified. If the verification passes, then the operation of increasing the message ratio will be performed; If the verification fails, the current message ratio of the first message will be rolled back to the previous message ratio. After the green environment verification is passed, the operation of increasing the message ratio will continue.
4. The blue-green deployment collaboration mechanism based on message middleware according to claim 3, characterized in that, Also includes: When the message ratio reaches 100% and the green environment verification is passed, the message attribute identifier of the first message generated by the message producer is uniformly modified to the message attribute identifier corresponding to the green environment. The message selector of the message consumer is adjusted synchronously so that the message selector only reads the first message with the message attribute identifier corresponding to the green environment, thus completing the full traffic switch.
5. The blue-green deployment collaboration mechanism based on message middleware according to claim 4, characterized in that, Also includes: After the full traffic switch is completed, when running the green environment, monitor the key performance indicators and log system of the message producer / consumer. If the key performance indicators exceed the preset threshold or the key logs of the log system frequently malfunction, roll back the running status of the message producer and the message consumer to before the full traffic switch.
6. The blue-green deployment collaboration mechanism based on message middleware according to claim 1, characterized in that, The first message also includes a message unique identifier, which is generated based on a UUID.
7. The blue-green deployment collaboration mechanism based on message middleware according to claim 6, characterized in that, Also includes: Before processing the first message, the message consumer queries whether the first message has been successfully processed based on the message's unique identifier.
8. A blue-green deployment collaboration device based on message middleware, characterized in that, include: The message sending unit is configured to send a first message to the message middleware from the message producer. The first message carries a message attribute identifier, which is used to identify the blue-green deployment environment to which the first message belongs. The message routing unit is configured to receive the first message from the message middleware and route the first message to the corresponding message partitioning unit according to the message attribute identifier of the first message. The message processing unit is configured to read the first message from the message partitioning unit and determine whether to process the first message based on the blue-green deployment environment of the message consumer and the message attribute identifier of the first message.
9. An electronic device, characterized in that, include: Memory, used to store computer-readable instructions; as well as A processor for running the computer-readable instructions, causing the electronic device to perform the message middleware-based blue-green deployment collaboration mechanism as described in any one of claims 1 to 7.
10. A non-transitory computer-readable storage medium for storing computer-readable instructions, characterized in that, When the computer-readable instructions are executed by a processor, the processor performs the message middleware-based blue-green deployment collaboration mechanism as described in any one of claims 1 to 7.