Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] enable canary deploy in client-rebalance mode #8370

Open
1 task done
mobaijaavaer opened this issue Jul 5, 2024 · 0 comments
Open
1 task done

[Enhancement] enable canary deploy in client-rebalance mode #8370

mobaijaavaer opened this issue Jul 5, 2024 · 0 comments

Comments

@mobaijaavaer
Copy link

Before Creating the Enhancement Request

  • 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.

detail link: RMQ canary solution

Describe Alternatives You've Considered

/

Additional Context

/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
1 participant