クラウドネイティブインフラストラクチャについて - EventMesh イベントドリブンメッシュ

今日はイベント駆動型メッシュであるEventMeshについてお話します。実際、クラウド ネイティブ テクノロジーに関する前回の記事では、ServiceMesh サービス ゲートウェイと EDA イベント駆動型アーキテクチャについて詳しく紹介しました。昨年、Tencent WeBank はイベント駆動型グリッドおよび金融メッセージングミドルウェアである EventMesh をオープンソース化しました。

そこで、今日はEventMeshの関連アーキテクチャ情報をもとに、EventMeshについての私の理解についてお話ししたいと思います。

EventMeshの概要

EventMesh は、イベント駆動を中核とする基本サービスです。 EventMesh は、マイクロサービス向けの Service Mesh と同じ位置付けになっています。動的なプラグイン クラウド ネイティブの基本サービス レイヤーである EventMesh は、アプリケーション レイヤーとミドルウェア レイヤーを分離し、柔軟で信頼性が高く、高速なイベント配信機能を提供します。また、イベントを管理し、アプリケーション プロセスの接続レイヤーとして機能することで、企業がデジタル変革の目標を達成するために必要なアプリケーション プロセス間通信モードの完全なセットを提供します。

インターネット上の別の説明は以下を参照してください。

イベント メッシュは、イベント駆動型アプリケーションにとって、サービス メッシュが RESTful アプリケーションにとってであるのと同じです。つまり、アプリケーションのデプロイ場所 (オンプレミス、パブリック クラウド、またはプライベート クラウド) に関係なく、あるアプリケーションからのイベントを動的にルーティングし、他のアプリケーションに取り込ませるアーキテクチャ レイヤーです。イベント メッシュは、相互接続されたイベント ブローカーのネットワークによって作成され、有効化されます。

これを読んでもまだ EventMesh を理解するのは難しいかもしれません。

ここでいくつかの点を強調したいと思います。

まず、EventMesh の基盤となるアーキテクチャは、依然としてイベント駆動型およびメッセージベースのミドルウェアです。その中核となるのは、メッセージベースの非同期メカニズムと、メッセージの公開およびサブスクリプション メカニズムです。従来の Rest API インターフェースは、同期呼び出しモードに近いものです。メッセージ イベント メカニズムを導入することで、分離をより適切に実現できます。

2 つ目は、このタイプは Mesh メッシュの概念を重視していることです。つまり、EventMesh の導入は別の集中型ノードを追加することではなく、ServiceMesh の Sidecar プロキシ モードと同様の方法で導入する必要があります。これを実現するには、メッシュ アーキテクチャの標準的な考え方を参考にして、コントロール プレーンとデータ プレーンを分離する必要があります。これがメッシュ アーキテクチャの基礎となります。したがって、EventMesh の実装でもこの原則に従う必要があります。

EventMesh を使用する必要があるのはなぜですか?

これについては、まだ 2 つの側面から答える必要があります。最初の内容自体は、実際には、EDA イベント駆動型アーキテクチャまたは CQRS モデルを採用する必要がある理由についての質問です。この問題の核心は、メッセージ メカニズムを通じてビジネスを完全に分離し、それに続いて、同様の 1 対多のメッセージの公開とサブスクリプション、大規模な同時実行下でのピーク シェービング処理などを行うことです。

クラウドネイティブでイベントドリブンアーキテクチャがEventMeshに変換されると、どのような変化がもたらされるのでしょうか？

ここで実際に議論すべき点が 2 つあります。

まず、EventMesh はクラウドネイティブ技術アーキテクチャ システム フレームワーク全体に統合されています。つまり、基礎層は Kubernetes と Docker コンテナ クラウドに基づいており、上位層は現在主流のマイクロサービスと統合されています。従来から説明してきたメッセージ ミドルウェアは、EventStore になります。

第二に、EventMesh の導入により、従来のコンテナ クラウドの最下層とメッセージ ミドルウェアの最上層に抽象化と統一された適応の層が実際に導入され、イベントの発行やサブスクリプションなど、マイクロサービスでのイベント メカニズムの使用がよりシンプルかつ標準化されるようになると個人的には考えています。次に、セキュリティ、ルーティング、その他のイベント管理および制御機能など、イベント自体を管理する機能が適応層に導入されます。

WeBank が EventMesh アーキテクチャをオープンソース化

EventMesh の現在の全体的なアーキテクチャを上の図に示します。イベント駆動型アーキテクチャにより、アプリケーション層とミドルウェア層が分離されます。これはアーキテクチャの簡単な理解です。

まず、EventMesh 全体はクラウドネイティブのコンテナ クラウド プラットフォーム上で実行でき、基盤となるレイヤーはコンテナ クラウド プラットフォームに直接接続されます。

2つ目はコネクタ部分です。現在、EventMesh は、Kafka、RocketMQ、WeBank 独自の金融メッセージ ミドルウェア、Redis 分散キャッシュなどのコネクタを介して複数のメッセージ ミドルウェアに接続し、適応しています。これらはすべて、EventMesh の EventStore として機能します。

過去にメッセージ ミドルウェアを使用していたとき、メッセージ ミドルウェアごとに、メッセージ イベントの送信、サブスクライブ、リッスンを行うための特定の API インターフェイスと実装方法が異なることは誰もが知っていました。 EventMesh を使用すると、プロキシ層でこれらの違いをシールドし、基盤となるメッセージ ミドルウェア機能の透過性を実現できます。

EventMesh の中核はランタイムです。

クライアントから送信されたイベントは、ランタイムによってスケジュールされたコネクタに引き渡され、コネクタは対応する場所にイベントを保存します。その後、イベント ストアはイベントを受信し、対応するイベントをサブスクライブする EventMesh を介してダウンストリーム クライアントに転送します。つまり、コアエンジン部分では、プロトコル変換、イベントルーティング、メッセージ中間適応、負荷分散、イベントリンク監視、セキュリティなどのさまざまなガバナンス機能を実現できます。

これらの機能は、メッセージ イベントのコンシューマーとサブスクライバーが提供する必要はなく、メッシュ アーキテクチャを通じてプロキシ内のさまざまなプラグインを通じて実装されます。この考え方は、実際には ServiceMesh サイドカー モードの考え方と一致しています。

したがって、EventMesh 実装メカニズムの中核は、既存のメッセージ ミドルウェア機能を再実装することではなく、現在主流のメッセージ ミドルウェアに適応レイヤーを追加し、このレイヤーでメッセージ イベントの統一された管理とガバナンスを完了することです。さらに抽象化すれば、メッセージ イベントのアセンブリとオーケストレーションも実行できるようになります。

外部に公開されたイベント機能

eventmesh-sdk-java: 現在 HTTP および TCP プロトコルをサポートしており、将来的には gRPC もサポートする予定です。これについてもう少し詳しく説明しましょう。

RocketMQ メッセージ ミドルウェアなどの特定のメッセージ ミドルウェアを使用する場合、ミドルウェア自体に、イベントの公開、メッセージの監視、サブスクリプションなどを実装するための独自の Java API インターフェイスがあることがわかります。マイクロサービス アーキテクチャ システムの下にある場合は、ビジネス システムまたはマイクロサービス側で、実際にプロキシ パッケージをインストールしてデプロイし、ローカル プロキシを実装する必要があります。その後、プロキシ パッケージ自体がアップグレードされると、すべてのコンシューマー側とサブスクライバー側で対応する変更を行う必要があります。

当社の初期の SOA 実装ビジネス シナリオでは、JMS メッセージ ミドルウェアを使用して 1 対多のメッセージ配信を実装するシナリオがありました。実装プロセス全体を通じて、JMS メッセージに対してプロキシと適応のレイヤーを実行しました。

JMS メッセージ公開機能は標準の Rest API インターフェース サービスとしてカプセル化されているため、コンシューマーはプロキシ コンポーネントをインストールする必要がなくなり、Rest API インターフェースを直接呼び出してメッセージ公開を実装できます。

ただし、サブスクライバー側でこのような適応を行うことは困難であり、従来の方法でメッセージ イベントの監視とサブスクリプションを実装するには、エージェント Jar パッケージをインストールする必要があります。このシナリオでは、メッセージ ミドルウェアを置き換える必要がある場合、またはメッセージ ミドルウェア プロキシ パッケージのバージョン自体をアップグレードする必要がある場合、非常に面倒になり、基本的にすべてのサブスクライバーをそれに応じてアップグレードする必要があることがわかります。

この問題は、EventMesh + マイクロサービス + コンテナ クラウドを導入することでより適切に解決できます。

EventMesh ランタイム エンジン コンポーネントの場合、イメージの作成時にそれらをイメージに動的に送信し、動的なデプロイメントを完了できます。手動操作は不要になりました。

次に、Mesh に適応レイヤーを作成して、標準 API インターフェイスとサブスクリプション メカニズムのセットを形成します。これにより、メッセージ ミドルウェア自体が変更または置き換えられた場合でも、ビジネス システムへの影響が最小限に抑えられます。

同時に、メッセージを公開する機能については、メッセージ レイヤー上の Http Rest API インターフェイスとしてカプセル化します。これにより、上位レベルのマイクロサービス アプリケーションへのアクセスと呼び出しが容易になり、マイクロサービスと基盤となるメッセージ イベント アーキテクチャの統合が実現します。

上の図に示すように、実際の Order マイクロサービスは引き続き Rest API インターフェースを消費して呼び出していますが、データを取得した後、EventMesh はプロキシ適応とルーティング転送を通じてそれをメッセージ ミドルウェアに書き込み、その後 CustomerService はサブスクライバー側の標準機能を通じてメッセージを取得します。

簡単に言えば、コンシューマー側は依然として Rest API サービスを呼び出しますが、基礎となるレイヤーは既に非同期メッセージ ミドルウェアとイベント エンジンであり、このエンジンはマイクロサービス間の完全な分離を実現するために使用されます。

注: メッセージ ミドルウェアから完全に分離する場合、サブスクライバー側はメッセージ ミドルウェア API を介してメッセージをリッスンおよびサブスクライブしません。代わりに、サブスクライバー側自体がメッセージ イベントをインポートするための Http Rest API インターフェイスを提供します。このとき、Mesh コンポーネントはメッセージを受信した後、この API インターフェース機能を呼び出してデータをターゲット エンドにプッシュできます。このモードを採用すると、メッセージ ミドルウェアは完全に EventStore 機能に進化します。

主要コンポーネントと階層化アーキテクチャ

上図から、EventMesh はコントロール パネル、データ パネル、ストア パネルの 3 つのレイヤーに水平に分割されていることがわかります。

一般的に、実際のビジネス システムは、データ PanelApp レイヤーと対話して、無効なメッセージ イベントを公開およびサブスクライブします。現時点では、基盤となる適応メッセージ ミドルウェアや基盤となるイベント ストレージ ロジックに注意を払う必要はありません。

実際には、データ層に単純なプロキシを実装するか、サイドカー モードを介してプロキシ パッケージを業務システムまたはマイクロサービス層に送信する必要があります。つまり、メッセージ イベントとデータ フロー全体の最終的な公開とサブスクリプションは、制御層ではなく、ビジネス システムと EventStore 間の対話を通じて完了し、新しい中心点の導入を回避する必要があります。

ただし、メッシュ アーキテクチャ全体が分散化されている一方で、登録、ルーティング、セキュリティ、監視、メトリック分析など、メッセージ イベントの管理およびガバナンス機能を導入する必要があります。これらの機能は、現在のコントロール パネル レイヤーに実装されています。コントロール パネルコントロール パネルは、ガバナンス モジュール、登録モジュール、セキュリティ モジュール、インジケーター モジュール、追跡および位置決めモジュールに分かれています。これらのモジュールは、業界全体で優れたソリューションを採用し、EventMesh に接続してコンテンツを充実させます。 EventMesh エコシステム。たとえば、登録モジュールは Nacos に接続でき、インジケーター モジュールは Prometheus に接続でき、追跡および位置決めモジュールは SkyWalking などに接続できます。

EventMeshの簡単な概要

最後に簡単にまとめさせていただきます。

ServiceMesh を導入する場合、ServiceMesh を通じて分散型サービス ガバナンス機能をどのように実現できるかについて説明します。同様に、EventMesh を使用する場合、このイベント アーキテクチャを通じて分散型のイベント管理およびガバナンス機能を実現したいと考えています。

ServiceMesh の場合、大規模なアプリケーション自体が外部に公開されていない場合は、API ゲートウェイの使用を完全に排除できます。 EventMesh に関しては、メッセージ ミドルウェアを完全に置き換えることはできないことがわかります。メッセージ ミドルウェアを適応させ、メッセージ ミドルウェアの機能を EventStore の機能に変換することが主な目的です。この考え方に基づくと、現在のメッセージ ミドルウェアを完全に放棄し、代わりに Redis + 独自開発に基づく分散型メッセージ イベント管理アーキテクチャを実装できることがわかります。この場合、メッセージ イベント管理機能自体は、集中型のメッセージ ミドルウェアで完了するのではなく、各ビジネス システムのエージェント側に移動されて完了します。

イベント駆動型アーキテクチャでは、多言語、多環境、ハイブリッドクラウド管理、プライベートクラウドとパブリッククラウドの連携、IoT ハードウェアデバイスのインターフェース連携に対して、より優れたサポートと適応機能が提供されます。これ自体がイベント駆動型アーキテクチャの利点です。

最後に、EventMesh エンジン自体はクラウドネイティブ アーキテクチャに基づいています。基盤となるレイヤーはコンテナ クラウド上で直接ホストまたはデプロイされ、上位レイヤーはマイクロサービス管理およびマイクロサービス ガバナンス センターと統合されます。適切に実行されれば、EventMesh エンジン自体も、ユーザーにとって透過的な基盤となるエンジン機能になります。