RocketMQ Multi-Version Environment Isolation Practice in Test Environments

This article introduces how vivo's Internet Middleware Team implemented multi-version environment isolation for testing projects based on open-source RocketMQ. In August 2022, the team completed the MQ engine upgrade from RabbitMQ to RocketMQ for their internet online business.

The article first presents the message middleware platform architecture, consisting of four core components: mq-meta (responsible for platform metadata management and authentication addressing), RabbitMQ-SDK (existing self-developed SDK using AMQP protocol), mq-proxy (message gateway component for protocol conversion between AMQP and RocketMQ Remoting), and RocketMQ cluster (multiple brokers across data centers with master-slave deployment).

For multi-version environment isolation, the team analyzed the existing challenges: high usage cost requiring businesses to apply for multiple MQ logical clusters, and high environment maintenance costs. After evaluating multiple solutions including physical isolation and resource logical isolation, they chose the "user-property based message dimension" approach to implement multi-version isolation.

The implementation includes: traffic marking transmission throughout the production/consumption process using full-linkage agent; production logic storing version tags as message properties; consumption logic using different consumer groups with message filtering based on user-property; message fallback mechanism for baseline consumption when project versions go offline; and broker-side extensions for online multi-version group collection and message filtering.

The solution achieves: multi-version environment isolation at proxy layer without requiring SDK upgrades; support for message fallback; and retry message delivery to corresponding versions. However, there's a limitation when all multi-version consumer clients go offline - some messages may not be guaranteed to be consumed by the baseline version.