要約： 組み合わせたアプリケーションが直面する必要のある難しい問題は、さまざまなアプリケーション間の統合標準の問題をどのように解決するかです。たとえば、アプリケーションはHTTPやTCPなどのプロトコルの1つしかサポートしておらず、ユニファイドコミュニケーション標準がない場合はビジネスをアーキテクチャにもたらします。困難が伴います。次に、イベントグリッド（EventGrid）がこの問題を解決する方法について説明します。
SaaSの新時代では、ビジネスの適応性要件により、企業は、迅速で安全かつ効率的なアプリケーションの変更をサポートする技術アーキテクチャに目を向けるようになります。デジタル化を加速する重要なテクノロジーとして、コンポーザブルアプリケーションは、2022年にガートナーによって提案された重要な戦略的テクノロジーの1つです。これは、ビジネス中心のモジュラーコンポーネントから構築され、テクノロジーチームとビジネスチームがコードをより機敏かつ効果的に再利用できるようにします。結合されたアプリケーションが直面する必要のある課題の1つは、さまざまなアプリケーション間の統合標準の問題をどのように解決するかです。たとえば、アプリケーションはHTTPやTCPなどのプロトコルの1つしかサポートしない場合があり、ユニファイドコミュニケーション標準がないためにアーキテクチャへのビジネス。難しさ。次に、イベントグリッド（EventGrid）がこの問題を解決する方法について説明します。
Event Gridは、クラウドネイティブ時代にHUAWEI CLOUDミドルウェアによって立ち上げられた新世代のサーバーレスイベントバスであり、従来のアプリケーション、クラウドサービスアプリケーション、SaaSパートナーアプリケーションからのさまざまなイベントを伝送および管理し、アプリケーション開発者が高可用性を簡単に構築できるようにします、疎結合の分散イベント駆動型アーキテクチャ。サーバーレスアーキテクチャの下でのイベント駆動型アーキテクチャの重要な部分として、弾力性のある非同期の分散型イベントガバナンスサービスを提供し、集約、モデル検証、フィルタリング、ルーティング、変換、イベントのプッシュなどのコア機能を提供します。フォールトトレラントでヘビーデューティーなイベントだけでなく、テスト、デッドレターストレージ、イベントクエリトラッキング、イベントワークフローなどの拡張機能。
上記のEventGridの全体的なアーキテクチャ図からわかるように、EventGridは一連のクラウドサービスをイベントソースとして接続します。これらのクラウドサービスには、分散メッセージングサービス（RocketMQ、Kafka、Pulsarなど）、オブジェクトストレージサービス（OBS）、および分散キャッシュサービス（Redis）が含まれます。イベントソースは、管理クラス、データクラス、およびカスタムイベントを生成し、EventGrid SDKを介してそれらをEventGridのイベントバス（バスランタイム）のイベントチャネルにプッシュします。イベントバスは、テナントごとにEventGridユーザーのイベントチャネルを構成します。1つのテナントにより、複数のイベントチャネルでさまざまなイベントソースからのイベントを伝送できます。たとえば、デフォルトのイベントチャネルには、HUAWEI CLOUDによって生成されたイベントが格納されますが、カスタムイベントチャネルには、アプリケーションとマイクロサービスのイベントが格納されます。EventGridユーザーは、サブスクリプションごとにイベントを消費します。サブスクリプション構成アイテムでイベントソース、イベントターゲット、イベントフィルタリング、および変換ルールを定義することにより、EventGridはイベントバスから関連イベントを抽出し、定義されたイベントターゲットにリアルタイムでプッシュできます。プッシュ方式は同期または非同期にすることができます。同期プッシュは通常、アプリケーションとマイクロサービスに適したHTTPプロトコルに基づいています。非同期プッシュは、通常、SaaSパートナーアプリケーションのメッセージキューにプッシュされます。
したがって、HUAWEI CLOUD EventGridは、クラウドサービス、クラウドネイティブアプリケーション、およびSaaSパートナーアプリケーションをイベント駆動型でリンクし、サービスとアプリケーション間の分離を実現し、独自のサービスの利点に焦点を当て、HUAWEIのさまざまなイベントモデルを介して接続しますCLOUDより多くのアプリケーションシナリオを作成し、HUAWEICLOUDの開発者エコシステムを充実させます。
エンジンとしてEventMeshを使用する
HUAWEI CLOUD EventGridは、ランタイムエンジンとしてオープンソースのスタープロジェクトApacheEventMeshを導入しました。クラウドネイティブのイベント駆動型アーキテクチャミドルウェアとして、Apache EventMeshは、アプリケーションとバックエンドイベントストア（イベントストア）を分離するために使用され、ハイブリッドクラウドや従来のデータセンター、分散アーキテクチャなど、幅広いアプリケーションシナリオをサポートします。さまざまなテクノロジースタックを使用します。
Apache EventMeshは、概念的にはEventGridに似ています。また、イベントソースに接続し、イベントを集約して、クライアントにプッシュします。そのハイライトは、そのカーネルがプラグインをサポートできることです。さまざまなイベントアプリケーションのシナリオに応じて、さまざまなプラグインを接続して一致させることができます。たとえば、イベントコネクタ（イベントコネクタ）では、RocketMQコネクタまたはKafkaコネクタを接続できます。HTTP認証（Http-Auth）に関しては、BasicAuthまたはTokenAuthを参照できます。このような柔軟なアーキテクチャは、さまざまな製品やサービスを接続するエコシステムの作成に役立ちます。
EventMeshgRPCの機能
Apache EventMeshの最新のv1.4.0リリースでは、以前のバージョンと比較して、いくつかの重要な機能とアーキテクチャの最適化が追加されています。ハイライトの1つは、gRPCのサポートです。gRPCは、HTTP / 2に基づく最新の高性能RPC（リモートプロシージャコール）フレームワークです。HTTPプロトコルと比較して、gRPCはクライアントとサーバー間の双方向非同期通信をサポートし、Protobufを介してAPIインターフェイスデータモデルを定義し、多言語SDKをサポートします。gRPCプロトコルを実装することにより、Apache EventMeshは元のTCPプロトコルとHTTPプロトコルを統合し、現在のランタイムを軽量化できます。同時に、そのSDKを拡張して、Java、Go、JavaScriptなどの複数の言語をサポートすることができます。
Protobufデザイン
GRPCへのEventMeshの導入は、Protobuf定義（eventmesh-client.proto）の設計から始まります。eventmesh-client.protoファイルで、EventMeshイベント送信およびサブスクリプションサービスのメソッドとイベントモデルを定義します。スペース上の理由から、以下では定義の重要な部分のみを紹介します。完全なドキュメントについては、以下を参照してください。
1.イベント送信サービスは、以下のインターフェースを提供します。
service PublisherService {
rpc publish(SimpleMessage) returns (Response);
rpc requestReply(SimpleMessage) returns (SimpleMessage);
rpc batchPublish(BatchMessage) returns (Response);
}イベントはSimpleMessageデータモデルで表示されます。イベント送信は、同期送信、非同期送信、バッチ送信の3つのモードをサポートします。その中で、同期送信とは、イベントプロデューサーがイベントをEventMeshに送信し、イベントがイベントコンシューマーに正常にプッシュされるのを待って、イベントコンシューマーのリターンを受信してから、エンドツーエンドのイベント送信プロセス全体を完了することを意味します。非同期送信とは、イベントプロデューサーがイベントをイベントコンシューマーに正常にプッシュされるのを待たずにEventMeshに送信できることを意味します。バッチ送信とは、イベントのバッチをEventMeshに非同期で送信することです。
2.イベントモデルは次のとおりです。
message RequestHeader {
string env = 1;
string region = 2;
string idc = 3;
string ip = 4;
string pid = 5;
string sys = 6;
string username = 7;
string password = 8;
string language = 9;
string protocolType = 10;
string protocolVersion = 11;
string protocolDesc = 12;
}
message SimpleMessage {
RequestHeader header = 1;
string producerGroup = 2;
string topic = 3;
string content = 4;
string ttl = 5;
string uniqueId = 6;
string seqNum = 7;
string tag = 8;
map<string, string> properties = 9;
}イベントモデルは、CNCF CloudEvents、OpenMessenging、EventMeshネイティブイベントプロトコルなどの複数のプロトコルをサポートできます。これらは、SimpleMessageのプロトコル関連フィールドに反映されます。さらに、モデルにはイベントルーティング用のproducerGroupとトピックがあります。ttl、uniqueId、およびseqNumはイベント管理に使用されます。リクエストヘッダーには、イベントプロデューサーの基本情報（env、region、idc、ip、sys）が含まれています。
3.イベントサブスクリプションサービスは、次のインターフェイスを提供します。
service ConsumerService {
rpc subscribe(Subscription) returns (Response);
rpc subscribeStream(stream Subscription) returns (stream SimpleMessage);
rpc unsubscribe(Subscription) returns (Response);
}イベントサブスクリプションは、クラスターとブロードキャストの2つの方法をサポートします。クラスターモードでは、イベントコンシューマークラスター内の1つのインスタンスのみがイベントを消費できます。ブロードキャストモードでは、クラスター内のすべてのインスタンスがイベントを消費します。これらのサブスクリプションモードは、サブスクリプションデータモデルで定義されています。さらに、サブスクリプションサービスは、サブスクライブAPIとサブスクライブストリームAPIの2つのサブスクリプションインターフェイスを提供します。サブスクライブAPIは、URLを介してイベントをコンシューマーにプッシュします。URLはWebhookとも呼ばれます。このシナリオは、クラウドネイティブのマイクロサービスとカスタムアプリケーションおよび機能に適しています。subscribeStream APIは、gRPC双方向ストリーミングを介してイベントをコンシューマーにプッシュし、イベントコンシューマーが確認応答情報（Ack）をイベントプロデューサーに返すことを可能にします。これは、イベント配信を同期するためのプロデューサーRequestReplyのニーズを満たします。
サーバー側のマルチスレッド同時実行
イベントの生成と消費のパフォーマンスを向上させるために、EventMeshサーバー（EventMesh Runtime）はgRPCサービスでスレッドプール（ThreadPool）を定義し、イベントの生成と消費のさまざまなパフォーマンス要件に対して独立したパラメーターを構成します。これらのパラメーターは、EventMesh構成ファイル（eventmesh.properties）にあります。たとえば、イベントの生成、サブスクリプション、プッシュのスレッド数はそれぞれ次のとおりです。
eventMesh.server.sendmsg.threads.num=50
eventMesh.server.clientmanage.threads.num=30
eventMesh.server.pushmsg.threads.num=50gRPCサービスが開始されると、クライアントのリクエストをリッスンします。新しいリクエストが着信すると、対応するサービスのスレッドプールに配信され、対応するプロセッサによって処理されるため、次のリクエストが処理されます。リクエストはブロックされないため、同時実行量が増加します。
public void publish(SimpleMessage request, StreamObserver<Response> responseObserver){
cmdLogger.info("cmd={}|{}|client2eventMesh|from={}|to={}", "AsyncPublish",
EventMeshConstants.PROTOCOL_GRPC, request.getHeader().getIp(),
eventMeshGrpcServer.getEventMeshGrpcConfiguration().eventMeshIp);
EventEmitter<Response> emitter = new EventEmitter<>(responseObserver);
threadPoolExecutor.submit(() -> {
SendAsyncMessageProcessor sendAsyncMessageProcessor = new SendAsyncMessageProcessor(eventMeshGrpcServer);
try {
sendAsyncMessageProcessor.process(request, emitter);
} catch (Exception e) {
logger.error("Error code {}, error message {}", StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getRetCode(),
StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getErrMsg(), e);
ServiceUtils.sendRespAndDone(StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR, e.getMessage(), emitter);
}
});
}たとえば、上記のコードは、イベント送信サービス（公開サービス）の実装です。threadPoolExecutorを使用して、ダウンストリームのSendAsyncMessageProcessorが処理するスレッドプールにイベントを送信します。
イベントコンシューマーの負荷分散と再試行
イベントコンシューマ側では、EventMeshは負荷分散をサポートしています。ユーザーは、イベントサブスクリプションで複数のイベントコンシューマーを指定して、イベントを消費できます。各コンシューマーはURL（Webhook）またはgRPCクライアント（ストリーム）になり、これらのコンシューマーはクラスターまたはアクティブスタンバイモードでデプロイできます。次に、EventMeshは、アルゴリズム計算を通じてイベントをプッシュするコンシューマーの1つを選択します。現在のコンシューマーがイベントを消費できない場合、EventMeshは次のコンシューマーを選択します。デフォルトでは、EventMeshは、コンシューマーの負荷分散を実現するために、ポーリング方式でコンシューマープッシュイベントを選択します。開発者は、プラグインを介して他のアルゴリズムを提供することにより、コンシューマーを選択できます。
おそらくネットワーク上の理由により、イベントのプッシュが失敗しました。現在のコンシューマーはビジーまたはオフラインです。EventMeshは、最初に再試行を試みます。各再試行の間隔は数秒で、最大3回再試行します。3回の再試行が失敗した場合、EventMeshは次のコンシューマーを選択します。再試行間隔は、構成ファイルで定義できます。
gRPC非ブロッキング和ブロッキングスタブ
クライアントのパフォーマンスを向上させるために、gRPCは非ブロッキングスタブを提供します。非ブロッキングスタブクライアントを使用してリクエストを送信した後、サーバーが応答するのを待つ必要はなく、次のステップに進みます。これは、多数のイベントが生成されるシナリオに適しています。ただし、イベントRequestReplyシナリオでは、クライアントはイベントがイベントコンシューマーに同期的に正常にプッシュされるのを待つ必要があり、gRPCのブロッキングスタブが必要です。クライアントに2つのオプションを提供することにより、さまざまなイベントの生成と消費のシナリオにより柔軟に対応できます。現在、EventMeshSDKはBlockingStubを使用しており、次のステップは、非Bocking Stubを使用して、クライアントの高い同時実行性のパフォーマンスを向上させることです。
多言語SDKをサポート
Apache EventMesh v1.3.0より前は、JavaSDKのみが提供されていました。これには、他のクラウドネイティブアプリケーションシナリオへのアクセスに制限があります。多くのクラウドサービスはGo、Python、JavaScript（NodeJSフレームワーク）で開発されているためです。KNativeやDaprなどの一部のクラウドネイティブオープンソースプロジェクトも、開発言語としてGoを使用しています。したがって、EventMeshには、アプリケーション開発者のエコシステムを引き続き充実させるために、多言語SDKをサポートする緊急の必要性があります。
gRPCの開発ツールには、Java、Go、NodeJS、PHP、Python、C＃、C++などの多言語コード生成ツールが付属しています。EventMeshがgRPCプロトコルを実装した後、このツールを使用して多言語SDKをすばやく提供できます。その後の通信APIの変更は、Protobufモデル定義を同期的に変更し、コードを再生成するだけで済みます。反復は高速で、メンテナンスは簡単です。
TCPプロトコルとHTTPプロトコルを統合する
gRPCは、4つのクライアントおよびサーバー通信RPCメカニズムをサポートします：Unary RPC、Server Streaming RPC、Client Streaming RPC、およびBidirection Streaming RPC SDK API、イベント公開、ブロードキャスト、要求応答、Webhookサブスクリプション、およびイベントストリームサブスクリプション。
TCPプロトコルとHTTPプロトコルを統合することにより、EventMeshランタイムとSDKアーキテクチャはより軽量になり、コードのメンテナンスが削減されます。同時に、ユーザーはSDKを使用するときにどのプロトコルを選択するかを考慮する必要はありません。ユーザーはSDKレベルで通信プロトコルを学習して認識する必要はありません。gRPCはすべてのイベントの生成と消費のシナリオを満たすことができます。
すぐに使えるgRPCサンプル
EventMesh開発者がgRPCの新機能をよりよく体験できるようにするために、コミュニティは、イベントパブリッシャーとイベントサブスクライバー向けの完全なドキュメントと複数のコードサンプルを提供しています。関連するドキュメントは次のとおりです。
最初のドキュメントでは、EventMeshサーバーをデプロイして起動する方法について説明しています。ドキュメントの最初の部分では、仮想マシンにEventMeshをリモートで展開する方法について説明します。これは、テストおよび実稼働環境での展開に適しています。2番目の部分では、ローカル開発環境にEventMeshを展開する方法について説明します。これは、一般的なローカル開発に適しています。デバッグシナリオ。次のコマンドラインは、Linux環境でEventMeshランタイムをデプロイして開始する方法を示しています。
> tar -zxvf Eventmesh_1.3.0-release.tar.gz
> cd bin
> sh start.sh
> tail -f ./logs/eventmesh.out2番目のドキュメントでは、EventMesh SDKを使用して、TCP、HTTP、gRPCなどのイベントを生成および消費するアプリケーションを開発する方法を紹介しています。EventMeshプロジェクトには、gRPCイベントパブリッシャーとイベントサブスクライバーのコードを含むクライアント側のコードサンプル（eventmesh-example）があります。たとえば、EventMeshプロジェクトをJava IDE（Intellij IDEAなど）にインポートできます。以下の手順に従って、gRPCイベントパブリッシャーとサブスクライバーを起動します。
1. eventmesh-examples / src / main / resources / application.propertiesを変更して、デプロイされたEventMeshランタイムを指すようにします。
2. Event Publisherを起動し、実行します
Eventmesh-example/src/main/java/
org.apache.eventmesh.grpc.pub.eventmeshmessage.AsyncPublishInstance
3.イベントサブスクライバーを起動し、実行します
Eventmesh-example/src/main/java/
org.apache.eventmesh.grpc.sub.app.SpringBootDemoApplication
構成可能なアプリケーションのための新しいツールとして、gRPCの導入は間違いなく統合の標準化を大きく後押しします。もちろん、通信規格に加えて、スキーマやガバナンスなどの統合が必要な統合規格もあります。EventGridは、これらの分野で独自の調査を続けていきます。
[フォロー]をクリックして、HUAWEI CLOUDの新技術について初めて学びましょう〜