メッセージングの概念

非同期メッセージングを使うと、サービスは互いに直接呼び出すことなく通信できます。プロデューサーがメッセージを送信し、コンシューマーが後で受け取ります。これによりサービスが疎結合になり、負荷の急増が平準化され、コンシューマーが一時的に停止してもシステムの回復性が保たれます。

MassTransitは、RabbitMQ や Azure Service Bus などのメッセージブローカー上で動作する .NET フレームワークです。シリアル化、ルーティング、再試行などを処理するため、ブローカーの接続処理ではなく、メッセージとハンドラーに集中できます。

重要なメッセージの意図は2つあります。コマンドは、特定のサービスに何かを実行するよう指示します（"ChargePayment"）。イベントは、関心のある相手に何かが起きたことを通知します（"OrderPlaced"）。コマンドには1つのハンドラーが対応し、イベントには複数のハンドラーが対応できます。

コマンドは単純なメッセージ型で、命令形の名前を付けます。1つのコンシューマーに送信します。

イベントには過去形の名前を付け、関心のあるすべてのサブスクライバーに公開します。

キューは、コンシューマーが処理するまでメッセージを保持します。ポイントツーポイント方式で、各メッセージは必ず1つのコンシューマーにだけ配信されます。これにより、コンシューマーのインスタンス間で負荷分散できます（競合コンシューマー）。

RabbitMQ のようなブローカーは、エクスチェンジを介してルーティングします。プロデューサーがエクスチェンジに公開すると、エクスチェンジがメッセージをすべてのバインド済みキューへ分配します。これにより、1つのイベントを多数のサブスクライバーへ届けられます。

MassTransit は、メッセージ型をエクスチェンジとキューに自動的に対応付けます。Sendはキュー（コマンド）を対象とし、Publishはエクスチェンジを対象とします。その結果、購読している各コンシューマーのキューにコピー（イベント）が届きます。

注文サービスはOrderPlacedを公開して、処理を続行します。メールサービスと分析サービスは、それぞれ独立してそれを消費します。新しいサブスクライバーを追加する際、プロデューサーを変更する必要はありません。

ブローカーは通常、少なくとも1回（at-least-once）の配信を提供します。つまり、障害の後にメッセージが再配信される可能性があります。そのため、コンシューマーは冪等にし、同じメッセージを2回処理しても安全になるようにします。

非同期で実行できる処理がある場合、サービスを疎結合にしたい場合、または処理の急増を吸収したい場合に、メッセージングを利用します。すぐに応答が必要なリクエストとレスポンスには、直接 API を呼び出すほうが単純な場合もあります。

メッセージングの概念を確認します。

非同期メッセージングは、ブローカーを介してサービスを疎結合にします。MassTransitは RabbitMQ などのブローカーを抽象化します。コマンド（命令形で、ハンドラーは1つ）はキューへ送信し、イベント（過去形で、ハンドラーは複数）はエクスチェンジへ公開してサブスクライバーへ分配します。少なくとも1回の配信が前提となるため、コンシューマーは冪等にしてください。