高速航空機のエンジンを変更する場合、MQはどのようにしてスムーズな移行を実現しますか？

数日前、MichelleYeohがKnowledgePlanetについて質問し、同社はMQを切り替えて、古いサービスプロバイダーから新しいサービスプロバイダーにアップグレードすると述べ、適切な計画があるかどうかを尋ねました。

この需要は非常に一般的であると推定されています。ここにいくつかの経験を共有します。

1.MQアーキテクチャの簡単な説明

高速航空機のエンジンを変更する場合、MQはどのようにしてスムーズな移行を実現しますか？
上の図に示すように、MQ非同期通信の使用は、一般に3つの層に分けられ
ます。メッセージ送信者：MQクライアントを使用してメッセージを生成します。
MQ-client :: SendMsg（topic、msg）;

MQサービス：メッセージを中継します。

メッセージの受信者：MQクライアントを使用してメッセージを消費します。
MQ-client :: RecvMsg（topic、msg、CALLBACK_FUNC）;

これは典型的なpub-subアーキテクチャです。MQプロバイダーを置き換える場合は、少なくとも3つの場所を置き換える必要があります。

送信者mq-client
MQサーバー
レシーバーmq-client
をスムーズに移行する方法は、今日議論されるトピックです。

2.スムーズな移行計画

スムーズな移行の目標は、継続的なサービスとスムーズなアップグレードです。

トピックが多い場合は、1つずつ移行する必要があります。各テーマの移行は3つのステップに分かれています。

ステップ1：消費者の双方向サブスクリプション

高速航空機のエンジンを変更する場合、MQはどのようにしてスムーズな移行を実現しますか？
上の図に示すように、次のように設定します。

ピンクは古いMQシステムです
青は、新しいMQシステム
のスムーズな移行の最終目標であり、「publish-service-subscribe」の3つのレイヤーをピンクから青にアップグレードすることです。

最初のステップは、コンシューマーをアップグレードすることです。同じトピックを古いMQと新しいMQにサブスクライブする必要があります。

現時点では、「新しいサービス-新しいサブスクリプション」の間にTCP接続がありますが、「新しいリリース」はオンラインではありませんが、実際にはメッセージは送信されず（上の図の点線）、メッセージは引き続き古いMQを通過します（上の図はライン）。

ステップ2：メーカーが新しいリリースにアップグレードする

高速航空機のエンジンを変更する場合、MQはどのようにしてスムーズな移行を実現しますか？
2番目のステップは、プロデューサーを古いMQリリースから新しいMQリリースにアップグレードすることです。

このとき、「new release-new service-newsubscription」の間にTCP接続が確立され、メッセージが新しいチャネルに転送されます（上図の実線）。「old service-oldsubscription」の間にTCP接続はありますが、実際にはそうではありません。メッセージが送信されます（上の図の点線）。

ステップ3：消費者が古いサブスクリプションをオフラインにする

高速航空機のエンジンを変更する場合、MQはどのようにしてスムーズな移行を実現しますか？
3番目のステップは、コンシューマーをアップグレードし、古いサブスクリプションをオフラインにして、MQ全体の移行を完了することです。

3、建築のインスピレーション

MQはサービスプロバイダーを変更し、アリは段階的に移動し、スムーズに移動します。実際にはコストが非常に高くなります。

それが非常に面倒で、統一された方法でアップグレードできない理由は、ビジネスと基盤となるインフラストラクチャの詳細（つまり、どのMQを使用するか）の間の結合です。会社が初期の技術システム計画で「カプセル化の層を浅くする」ことができれば、「ビジネスコード」を「基礎となるインフラストラクチャの詳細」から分離することができます。

より人気のある例を挙げてください。

カプセル化レイヤーがない場合、ビジネスコードは次のとおりです。

ActiveMQ-client::SendMsg(topic, msg);
ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);

つまり、ビジネス側はActiveMQに注意を払う必要があります。インフラストラクチャをRabbitMQにアップグレードする場合は、ビジネスコードをアップグレードする必要があります。

浅いパッケージがある場合：

ShenJianMQ::SendMsg(topic, msg){
ActiveMQ-client::SendMsg(topic,msg);
}

ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
ActiveMQ-client::RecvMsg(topic,msg, CALLBACK_FUNC);
}

ビジネス側は、基盤となるMQを気にする必要はありませんが、基本コンポーネントShenJianMQに依存するだけで済みます。

このとき、インフラストラクチャをRabbitMQにアップグレードする場合は、基本コンポーネントのShenJianMQのみをアップグレードする必要があります。
最初のステップ：RecvMsgは双方向サブスクリプションにアップグレードされます。

ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
ActiveMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
}

ステップ2：SendMsgを新しいリリースにアップグレードします。

ShenJianMQ::SendMsg(topic, msg){
RabbitMQ-client::SendMsg(topic, msg);
}

ステップ3：RecvMsgオフラインの古いサブスクリプション。

ShenJianMQ::RecvMsg(topic, msg,CALLBACK_FUNC)
RabbitMQ-client::RecvMsg(topic, msg, CALLBACK_FUNC);
}

ShenJianMQ基本コンポーネントの新しいバージョンをアップグレードして依存することに加えて、ビジネスコードはコードを変更する必要がないことがわかります。

キャッシュとデータベースのクライアントであるMQだけでなく、浅いカプセル化により、ビジネスコードと基本コンポーネントの分離を実現できます。基本コンポーネントを交換したり、基本コンポーネントをアップグレードしたりする場合は、ビジネスコードをアップグレードする必要はありません。
Voiceover：浅いパッケージの後、監視/アラーム/データ収集およびその他のタスクをより簡単に統合できます。

オープンソース、浅いパッケージ、自己調査のいずれを使用するかについて、「基本コンポーネント、自己調査が必要ですか？「より詳細な議論があります。

MQのスムーズな移行については、Michelle Yeohの質問に答えることを期待して、最初に多くのことを話しましょう。
高速航空機のエンジンを変更する場合、MQはどのようにしてスムーズな移行を実現しますか？
ナレッジプラネット-ナレッジプラネットのプレイを始めたばかり
です。質問へようこそ。
Voiceover：すべての質問に慎重に回答します（この質問など）。
前回は200か所がオープンして満員になり、その後500か所がオープンしました（あまり多くないのでお答えできません）。

研究：

あなたの会社は浅いパッケージを持っていますか？それとも自習？それともネイティブカップリングですか？