クラウド環境では、新しいインスタンスがデプロイされると、統合テストが実行されます。しかし、既存のインスタンス（以前のバージョン）は引き続き実行されている間に、新しいコードがデプロイするサービスのキューにメッセージを挿入しているため、扱いにくくなります。我々は青緑の展開をしています。RabbitMQでブルー/グリーン展開を処理する方法は？
RabbitMQでは、リスナーがキューでリッスンすることは可能ですが、特定のバージョンでのみ可能ですか？
たとえば、実行中のすべてのサーバーは、バージョン2017.10.20（以前のバージョン）またはそれ以前のバージョンのメッセージを読み取りますが、新しいバージョンのメッセージは読み取れません。
このようにして、私は新しいサービスを展開することができ、他のドロップレットはテストメッセージを読むことはできません。
デプロイされる新しいサービスは、既存のサービスと同じ機能を持ちます。これは、現在実行中のサービスと同じメッセージタイプを生成し、消費します。
同じキューにテストメッセージとプロダクションメッセージが混在しているように見えます。そうだとすれば、それらを分けるべきだと思います。 ソリューションは、プロダクションと異なるキューのセットを公開/購読する新しいサービスを展開することができます。統合テストがうまくいく場合は、インスタンスをpub/subに切り替えるか（たとえば、新しいルート/キュー名を持つコマンドメッセージを送信するなど）、テストキューを新しいものに変更し、古いセットをリタイアさせますそれらの待ち行列と一緒にサービスの。
たとえば、現在バージョン3.1があり、my_command_a_3.1、my_command_b_3.1などのキュー/ルートにpubs/subsがあります。次に、バージョン3.2と並行して実行する環境の新しい3.2バージョンを導入します。すべてのサービスは、キュー/ルートmy_command_a_3.2およびmy_command_b_3.2で動作します。 3.2バージョンに満足すれば、あなたの3.1バージョンはキューと一緒にリタイアします。最初にこれらのキューを排水する必要があります（最初に生産者を切り替え、排水を待つこと、消費者をオフに切り替える）
あなたの質問に最も近い直接の回答：あなたの消費者を作ることができますnack消費者がメッセージのバージョンをサポートしていない場合（メッセージ自体にバージョンを入れる必要があります）、ブローカに再キューイングを要求します。次に、ある時点で新しいバージョンのコンシューマによって処理されます（ある時点で、ラウンドロビンアルゴリズムによって新しいメッセージが新しいコンシューマに配信されます）。それはブローカー側で追加の無駄な作業を作成し、どのメッセージについても、いつ実際に処理されるのか何度再キューされるのか分からないので、私の意見では汚いです。
新しいサービスを展開していますか？メッセージを生成しますか？メッセージを消費する？どちらも？ –
両方。新しいサービスは既存のサービスと同じように機能します。私は質問を更新します。 –