このトピックでは、ApsaraMQ for RocketMQ のドメインモデルについて説明します。
サービスのポジショニング
ApsaraMQ for RocketMQ は、分散アーキテクチャ向けのミドルウェアプロダクトです。非同期通信方式とパブリッシュ/サブスクライブメッセージングモデルを使用します。
通信方式とメッセージングモデルの詳細については、「通信方式」と「メッセージングモデル」をご参照ください。
ApsaraMQ for RocketMQ は、シンプルなシステムトポロジーや、アップストリームシステムとダウンストリームシステム間の疎結合など、非同期通信のメリットを提供します。主に非同期デカップリングやピークシフトなどのシナリオで使用されます。
リアルタイムの呼び出し結果を必要とする同期リンクには、リモートプロシージャコール (RPC) ソリューションを使用します。
ビジネスシナリオと主な要件に基づいてプロダクトを選択してください。
ApsaraMQ for RocketMQ のドメインモデル
上の図に示すように、ApsaraMQ for RocketMQ におけるメッセージのライフサイクルは、メッセージの生成、メッセージのストレージ、メッセージの消費という 3 つの主要な部分で構成されます。
プロデューサーはメッセージを作成し、ApsaraMQ for RocketMQ サーバーに送信します。メッセージはサーバー上の Topic に保存されます。その後、コンシューマーは Topic をサブスクライブしてメッセージを消費します。
メッセージの生成
プロデューサー (Producer): メッセージを作成する ApsaraMQ for RocketMQ のランタイムエンティティです。プロデューサーは通常、ビジネスコールチェーンのアップストリームに統合されます。プロデューサーは軽量で匿名です。
メッセージストレージ
Topic (Topic): メッセージの転送とストレージのための ApsaraMQ for RocketMQ の論理コンテナーです。Topic は複数のキューで構成されます。Topic 内のキューは、メッセージを保存し、水平スケーリングを可能にするために使用されます。
Lite Topic (LiteTopic): ApsaraMQ for RocketMQ では、Topic が Lite タイプの場合、その下に Lite Topic と呼ばれるセカンダリリソースを作成できます。デフォルトでは、各 Lite Topic は 1 つのキューで構成されます。
キュー (MessageQueue): ApsaraMQ for RocketMQ におけるメッセージのストレージと転送の基本単位です。Kafka のパーティションに似ています。ApsaraMQ for RocketMQ は、ストリームベースの無限キュー構造を使用してメッセージを保存します。キュー内のメッセージは順番に保存されます。
メッセージ (Message): ApsaraMQ for RocketMQ における最小の伝送単位です。メッセージは、初期化、送信、保存された後は不変です。
メッセージの消費
コンシューマーグループ (ConsumerGroup): ApsaraMQ for RocketMQ のパブリッシュ/サブスクライブモデルにおけるコンシューマーの論理的なグループです。コンシューマーグループは、複数の基盤となるコンシューマーを一元管理するために使用されます。同じコンシューマーグループ内のすべてのコンシューマーは、同じ消費ロジックと構成を持つ必要があります。サブスクライブした Topic からメッセージを共同で消費することで、消費能力の水平スケーリングが可能になります。
コンシューマー (Consumer): メッセージを消費する ApsaraMQ for RocketMQ のランタイムエンティティです。コンシューマーは通常、ビジネスコールチェーンのダウンストリームに統合されます。コンシューマーは特定のコンシューマーグループに割り当てる必要があります。
サブスクリプション (Subscription): ApsaraMQ for RocketMQ のパブリッシュ/サブスクライブモデルでメッセージのフィルター、リトライ、消費の進行状況を定義するルールのセットです。サブスクリプションはコンシューマーグループレベルで管理されます。コンシューマーグループは、そのコンシューマーがメッセージをフィルターする方法、消費をリトライする方法、および消費の進行状況を復元する方法をコントロールするためにサブスクリプションを定義します。
ApsaraMQ for RocketMQ では、フィルター式を除き、サブスクリプションは永続的です。これは、サーバーが再起動したり、クライアントが切断したりしても、サブスクリプション関係が保持されることを意味します。
通信方式
分散システムアーキテクチャーでは、複雑なシステムはマイクロサービスなどの複数の独立したモジュールに分割されることがよくあります。これらのモジュールは、リモートで相互に通信する必要があります。最も一般的な 2 つの通信パターンは、同期リモートプロシージャコール (RPC) と、ミドルウェアプロキシを使用する非同期通信です。
同期 RPC 呼び出しモデル
同期 RPC 呼び出しモデルでは、異なるシステムが直接通信します。呼び出し元は呼び出し先にリクエストを送信し、呼び出し先はすぐに応答を返す必要があります。
この文脈での「同期」という用語は、プログラミング API を指すものではありません。RPC は、非同期のノンブロッキングプログラミングスタイルを使用することもできます。ただし、このモデルでは、指定された期間内にターゲットエンドポイントから直接応答を返す必要があります。
非同期通信モデル
非同期通信モデルでは、サブシステムは疎結合であり、直接接続しません。呼び出し元はリクエストを非同期イベント (メッセージ) に変換し、ミドルウェアプロキシに送信します。メッセージが正常に送信されると、呼び出しは完了したと見なされます。その後、プロキシは、メッセージをダウンストリームシステムに確実に配信し、対応するタスクが実行されることを保証する責任を負います。このタイプのプロキシは、通常、メッセージ指向ミドルウェアです。
非同期通信には、次の利点があります。
シンプルなシステムトポロジー
アップストリームシステムとダウンストリームシステムの両方がミドルウェアプロキシと通信するため、システムは保守と管理が容易な星型トポロジーになります。
アップストリームシステムとダウンストリームシステム間の疎結合
システムは疎結合であるため、アーキテクチャがより柔軟になります。ミドルウェアプロキシは、バッファリングや非同期回復などのタスクを処理します。これにより、アップストリームシステムとダウンストリームシステムを互いに独立してアップグレードおよび変更できます。
ピークシフト
メッセージベースのミドルウェアプロキシは、多くの場合、強力なトラフィックバッファリングおよびシェーピング機能を備えています。これにより、トラフィックのピークがダウンストリームシステムに過大な負荷をかけるのを防ぎます。
メッセージングモデル
メッセージ指向ミドルウェアの主要なメッセージングモデルは、ポイントツーポイントモデルとパブリッシュ/サブスクライブモデルです。
ポイントツーポイントモデル
ポイントツーポイントモデルは、キューベースのメッセージングモデルとも呼ばれ、次の特徴があります。
匿名消費: キューは、アップストリームシステムとダウンストリームシステム間の通信のための唯一の識別子です。ダウンストリームのコンシューマーは、キューからメッセージを取得するときに独立した ID を宣言できません。
1 対 1 の通信: 匿名消費のため、複数のダウンストリームコンシューマーが存在する場合でも、それらは独立した ID を持ちません。その結果、キュー内のメッセージを競合します。各メッセージは 1 つのコンシューマーによってのみ処理できます。これは、ポイントツーポイントモデルが 1 対 1 の通信を促進することを意味します。
パブリッシュ/サブスクライブモデル
パブリッシュ/サブスクライブモデルには、次の特徴があります。
独立した消費: キューベースのモデルの匿名消費と比較して、パブリッシュ/サブスクライブモデルのコンシューマーは、通常コンシューマーグループと呼ばれる独自の ID を持ちます。異なるコンシューマーグループは独立しており、互いに影響を与えません。
1 対多の通信: 各グループは独立した ID を持っているため、同じ Topic 内のメッセージは複数のコンシューマーグループで処理できます。各コンシューマーグループは、すべてのメッセージのコピーを受信できます。したがって、パブリッシュ/サブスクライブモデルは 1 対多の通信を可能にします。
伝送モデルの比較
ポイントツーポイントモデルとパブリッシュ/サブスクライブモデルには、それぞれ独自の利点があります。ポイントツーポイントモデルはよりシンプルですが、パブリッシュ/サブスクライブモデルはより優れた拡張性を提供します。ApsaraMQ for RocketMQ はパブリッシュ/サブスクライブモデルを使用するため、このモデルの特徴を提供します。