You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have confirmed that this should be classified as an enhancement rather than a bug/feature.
Summary
I hope to provide a scalable strategy and implementation to achieve canary releases under client-rebalance mode using the RMQ client.
Motivation
Currently, most projects use the canary release model to control the impact of version releases. For regular request traffic, precise traffic control can be effectively achieved through various gateway request headers. However, there is no perfect solution in the community for RMQ in this regard. Changes in consumer logic versions cannot utilize canary releases, which is a significant pain point.
Describe the Solution You'd Like
Based on the ideas provided by the community and my understanding of RMQ, I have published an article on implementing canary deployments for RMQ in the community. This design approach has been widely used and validated in our internal projects, confirming that it is reliable and safe. The general design idea is as follows:
Provide an extensible algorithm that allows users to define which queues under a specific topic are designated as canary queues and under what conditions the current environment is considered a canary environment.
Utilize the RMQ clientId mechanism to append identifiers to distinguish between canary clients and regular clients, such as xxx@canary for canary clients and xxx@default for regular clients.
Design a balancing strategy that extends AbstractAllocateMessageQueueStrategy. The core idea is to differentiate between canary and non-canary clients using the clientId identifier from step one during rebalancing, ensuring that canary clients consume from canary queues and non-canary clients consume from non-canary queues.
Consumers need to specify the balancing strategy designed in step three. The sender needs to filter out the canary queues based on the algorithm from step one before selecting which queue to send messages to.
Before Creating the Enhancement Request
Summary
I hope to provide a scalable strategy and implementation to achieve canary releases under client-rebalance mode using the RMQ client.
Motivation
Currently, most projects use the canary release model to control the impact of version releases. For regular request traffic, precise traffic control can be effectively achieved through various gateway request headers. However, there is no perfect solution in the community for RMQ in this regard. Changes in consumer logic versions cannot utilize canary releases, which is a significant pain point.
Describe the Solution You'd Like
Based on the ideas provided by the community and my understanding of RMQ, I have published an article on implementing canary deployments for RMQ in the community. This design approach has been widely used and validated in our internal projects, confirming that it is reliable and safe. The general design idea is as follows:
Provide an extensible algorithm that allows users to define which queues under a specific topic are designated as canary queues and under what conditions the current environment is considered a canary environment.
Utilize the RMQ clientId mechanism to append identifiers to distinguish between canary clients and regular clients, such as xxx@canary for canary clients and xxx@default for regular clients.
Design a balancing strategy that extends AbstractAllocateMessageQueueStrategy. The core idea is to differentiate between canary and non-canary clients using the clientId identifier from step one during rebalancing, ensuring that canary clients consume from canary queues and non-canary clients consume from non-canary queues.
Consumers need to specify the balancing strategy designed in step three. The sender needs to filter out the canary queues based on the algorithm from step one before selecting which queue to send messages to.
detail link: RMQ canary solution
Describe Alternatives You've Considered
/
Additional Context
/
The text was updated successfully, but these errors were encountered: