RocketMQ EventBridge の概要

RocketMQ EventBridgeは、ユーザーが高信頼性、低結合、高性能なイベント駆動型アーキテクチャを構築するのを支援することに特化しています。イベント駆動型アーキテクチャでは、マイクロサービスは外部メッセージを積極的に購読する必要はなく、マイクロサービスシステム内の変更をトリガーするすべてのエントリをAPIに集中させ、現在のマイクロサービス自身のビジネスドメインモデルの定義とAPIの設計にのみ焦点を当てればよく、多くのグルーコードを介して外部サービスメッセージを適応および解析する必要はありません。EventBridgeは、外部サービスで生成されたイベントを、現在のマイクロサービスで設計されたAPIに安全かつ確実に適応および配信する役割を担います。

RocketMQメッセージとEventBridgeイベントはいつ使用すべきでしょうか？イベントの意味は何ですか？メッセージとの違いは何ですか？

メッセージとイベント

イベントは次のように定義されています。

Events refer to things that have already happened, especially important things.

イベントとメッセージの関係は次のとおりです。

メッセージには、コマンドメッセージとイベントメッセージが含まれます。コマンドメッセージは、外部システムからこのシステムに送信される操作コマンドです（図の左部分に示す）。イベントメッセージは、システムがコマンド操作リクエストを受信し、内部変更が発生した後に発生するイベントです（図の右部分に示す）。

イベントの4つの特性

1. 発生済み

イベントは常に「すでに発生した」ものです。「すでに発生した」ということは、不変でもあることを意味します。この機能は非常に重要です。イベントを処理および分析する場合、これらのイベントを絶対に信頼できることを意味します。イベントを受信した限り、それらはシステムの真の動作である必要があります。

コマンドは操作リクエストを表しますが、それが本当に発生するかどうかはわかりません。例：

* Turning on the kitchen lights
* Someone pressed the doorbell
* Account A received 100,000.

イベントは、すでに発生した明確な出来事です。例：

* The kitchen light being turned on
* Someone pressing the doorbell
* Account A receiving 100,000

2. 期待がない

An event is an objective description of a change in the state or attribute value of a thing, but it does not make any expectations about how to handle the event itself. In contrast, both Command and Query have expectations, they hope the system will make changes or return results, but the Event is just an objective description of a change in the system.

例：信号機が青から黄に変わることは、客観的な事実を記述しているだけであり、それ自体には客観的な期待はありません。国や地域によって、このイベントに対する期待は異なります。たとえば、日本では黄色は赤に相当しますが、ロシアでは黄色の点灯での走行は容認されています。

コマンドメッセージと比較して：

• イベント：は「市場経済」に少し似ています。商品が生産され、ショッピングモールの大きな窓に置かれます。消費者は気に入れば買い戻し、誰も買わなければ、商品は期限切れになり、無駄になる可能性があります。
• コマンドメッセージ：は「計画経済」に少し似ています。生産は需要に基づいており、指定された配布対象があり、無駄はほとんどありません。

3. 自然に順序付けられ、一意である

The same entity cannot have both A and B occur at the same time, there must be a temporal relationship; if so, these two events must belong to different event types.

例：同じ信号機の場合、同時に青と赤に変わることはできません。特定の瞬間に1つの状態にしかなりません。同じ内容の2つのイベントが表示された場合、それは2回発生したはずであり、1つがもう1つよりも前に発生したはずです。これは、データの一貫性とシステム動作の分析（ABAシナリオなど）を処理する上で価値があります。システムの最終結果だけでなく、その結果につながった中間プロセスも確認できます。

4. 具体化

イベントは「犯罪現場」をできるだけ完全に記録しようとします。イベントは消費者がどのように使用するかを知らないため、可能な限り詳細になります。含む

When did the event occur?
Who generated it?
What type of event is it?
What is the content of the event? What is the structure of the content?
... ...

通常見られるメッセージと比較すると、一般的にアップストリームとダウンストリームが決定されているため、多くの場合、パフォーマンスと伝送効率を向上させるために、メッセージは可能な限り簡潔になります。これは、「計画経済」で指定された消費者のニーズを満たしている限りです。

RocketMQ EventBridgeの典型的なアプリケーションシナリオ

シナリオ1：イベント通知

マイクロサービスでは、あるマイクロサービスで生成されたメッセージを他のコンシューマーに通知する必要がある状況がよくあります。ここでは、3つの方法を比較します。

A：強い依存関係のある方法

プロデューサーはコンシューマーのマイクロサービスをアクティブに呼び出し、コンシューマーのAPIを適合させます。この設計は間違いなく非常に悪く、プロデューサーはコンシューマーに強く依存しており、深く結合しています。コンシューマーへの呼び出しで例外が発生し、効果的な分離が行われないと、マイクロサービス全体がハングアップする可能性が非常に高くなります。新しいコンシューマーが入ってくると非常に貧弱です。

B：半結合解除法

プロデューサーはメッセージサービスにメッセージを送信し、コンシューマーはメッセージサービスを購読してメッセージを取得し、メッセージを独自のビジネスドメインモデルに必要なデータ形式に変換します。この方法は、呼び出しチェーンでの結合解除を実現し、システムリスクを大幅に軽減しましたが、コンシューマーの場合、プロデューサーのビジネスセマンティクスを理解して解析し、メッセージを独自のビジネスドメインに必要な形式に変換する必要があります。この方法では、コンシューマーが複数のプロデューサーからデータを購読する必要がある場合、プロデューサーによって生成された各メッセージに適合させるために大量のグルーコードが必要になります。さらに、アップストリームプロデューサーのメッセージ形式が変更されると、リスクと運用コストも発生します。

C：完全な結合解除法

この方法では、コンシューマーはブローカーを購読するためにSDKを導入する必要はありません。独自のビジネスドメインモデルに従ってAPIを設計するだけでよく、メッセージサービスがアップストリームをフィルタリングおよび変換します。

シナリオ2：システム間統合

シナリオ1は、主に単一製品内のマイクロサービス間のイベント通信に焦点を当てています。シナリオ2は、主に複数の製品間のイベント通信に焦点を当てています。企業では、複数の製品を使用することが多く、これらの製品の多くは自社で開発したものではなく、外部のSaaSサービスとして購入されている可能性があります。この場合、これらの外部SaaS製品は自社で開発したものではなく、コードを簡単に変更できないため、さまざまな外部SaaS製品間でイベントをフローさせるのは困難です。EventBridgeが提供するイベントセンター機能は、さまざまな製品で生成されたイベントを収集し、整理して管理するのに役立ちます。これは、デパートのウィンドウの商品のように、慎重に配置され、説明書が添付されており、消費者が選択できるように、宅配サービスも提供しています。

RocketMQ EventBridgeはどのように機能しますか？

上記の2つのシナリオで言及されている問題に対処するために、EventBridgeは5つの側面からアプローチします。

1. イベント標準を決定する

イベントは自分自身のためではなく、皆のためであるためです。明確なコンシューマーはおらず、すべてが潜在的なコンシューマーです。したがって、誰もが理解でき、理解しやすいように、イベントの定義を標準化する必要があります。現在、CNCFのCloudEventは、広く認識されている事実上の標準になりつつあるため、CloudEventをEventBridgeイベント標準として選択します。

2. イベントセンターを設立する

イベントセンターには、さまざまなシステムによって登録されたすべてのイベントが含まれています。これは、上記の市場経済のデパートのようなもので、さまざまなイベントが分類されて配置されており、誰もがどのイベントが必要になるかを見に来て、買い戻すことができます。

3. イベント形式を定義する

イベント形式は、イベントの具体的な内容を記述するために使用されます。これは、市場経済における販売契約に相当します。プロデューサーが送信するイベント形式は決定する必要があり、常に変更することはできません。コンシューマーがイベントを受信する形式も決定する必要があります。そうしないと、市場全体が混乱に陥ります。

4. サブスクリプション「ルール」

コンシューマーにイベントをターゲットエンドに配信する機能を提供し、配信前にイベントをフィルタリングおよび変換して、ターゲットエンドAPIの受信パラメーターの形式に適応できるようにする必要があります。このプロセスをサブスクリプションルールの作成と呼びます。

5. イベントバス：最後に、イベントを保存する場所も必要です。それが図の中央にあるイベントバスです。