Dubbo Triple プロトコルの大幅なアップグレード: HTTP を介した Web とバックエンドマイクロサービスの接続のサポート

新しくアップグレードされたトリプルプロトコル

マイクロサービスプロトコルの選択に関しては、Triple の高効率、全二重、ストリーミングストリーミング通信モデルやその他の機能を最大限に活用するために、ますます多くのアプリケーションが Dubbo2 TCP バイナリプロトコルから Dubbo3 Triple プロトコル (gRPC と互換性あり) に移行していることがわかります。Triple + HTTP/2 の組み合わせにより、バックエンドサービスの浸透の問題は解決されますが、Ali や多くのコミュニティ企業の実践では、Triple に基づくマイクロサービスはまだ相対的に低いことがわかりました。フロントエンドデバイスのアクセスコストが高く、ユーザーはゲートウェイを経由する必要があるトリプルバックエンドサービスにアクセスするためのプロトコル変換 (以前の Dubbo2 一般化コールと同様) は、開発テスト、運用、保守などに非常にコストがかかります。

上記の背景に基づいて、Dubbo3 では Triple プロトコルを完全にアップグレードしました: Triple プロトコルは、Dubbo3 によって設計された HTTP ベースの RPC 通信プロトコル仕様です。gRPC プロトコルと完全に互換性があり、リクエスト/レスポンス、ストリーミングおよびその他の通信モデルをサポートし、HTTP/1 と HTTP/2 で同時に実行できます。

cURL などの標準 HTTP ツールを使用して、Triple プロトコルによって公開されたサービスにアクセスできます。

curl \
    --header "Content-Type: application/json" \
    --data '{"sentence": "Hello Dubbo."}' \
    https://host:port/org.apache.dubbo.sample.GreetService/sayHello

Triple プロトコルに基づいて、Dubbo バックエンドマイクロサービスシステムを簡単に構築できます。HTTP プロトコル用の Triple の使いやすい設計により、Web、モバイル、標準 HTTP などのフロントエンドデバイスは、より簡単にバックエンドシステムにアクセスできます。同時に、Triple は gRPC プロトコルと完全に互換性があり、gRPC システムとの相互運用性を実現します。

Dubbo フレームワークは、トリプルプロトコルの複数言語実装を提供します。これは、ブラウザーおよび gRPC 互換の HTTP API インターフェイスの構築に役立ちます。必要なのは、標準のプロトコルバッファー形式サービスを定義し、ビジネスロジックを実装することだけです。Dubbo は、言語関連のサーバースタブとクライアントスタブの生成を支援し、ルーティングやサービスディスカバリなどの呼び出しプロセス全体を Dubbo システムにシームレスに接続する役割を担います。一部の言語バージョンでは、Dubbo フレームワークは、言語特性により一致したプログラミングモード、つまり IDL に束縛されないサービス定義および開発モードも提供します。たとえば、Dubbo Java では、Java インターフェイスと Pojo クラスを使用して Dubbo サービスを定義し、トリプルプロトコル通信に基づいてマイクロサービスとして公開することを選択できます。

プロトコル設計の目標と適用可能なシナリオ

トリプルプロトコルに基づいて、次の目標を達成できます。

Dubbo がクライアントとして機能する場合

Dubbo クライアントは、Dubbo サーバー (サーバー) によって公開されるトリプルプロトコルサービスにアクセスでき、標準の gRPC サーバーにもアクセスできます。

標準 gRPC サーバーを呼び出し、Content-type が標準 gRPC タイプであるリクエストを送信します: application/grpc、application/grpc+proto、および application/grpc+json
Dubbo サーバーを呼び出し、Content-type が Triple であるリクエストを送信します: application/json、application/proto、application/triple+wrapper

Dubboをサーバーとして使用する場合

デフォルトでは、Dubbo サーバーは共通の HTTP プロトコルと gRPC プロトコルのサポートを同時に公開し、トリプルプロトコルは HTTP/1 と HTTP/2 で同時に動作できます。したがって、Dubbo サーバーは、Dubbo クライアントからのトリプルプロトコルリクエスト、標準の gRPC プロトコルリクエスト、および cURL およびブラウザからの HTTP リクエストを処理できます。Content-type で区別するには、次のようにします。

Content-type が標準 gRPC タイプである gRPC クライアントによって送信されたリクエストを処理します: application/grpc、application/grpc+proto、application/grpc+json
Dubbo クライアントによって送信されたコンテンツタイプの Triple リクエストを処理します: application/json、application/proto、application/grpc+wrapper
cURL、ブラウザなどによって送信される Content-type Triple のリクエストを処理します: application/json、application/proto、application/grpc+wrapper

例のシーン

gRPC 仕様によれば、トリプルプロトコルは Content-Type: application/grpc プロトコルの通信を完全にサポートします。このモードに基づいて、トリプルクライアントは任意の gRPC サーバーを呼び出すことができ、またその逆も可能です。

トリプルプロトコルは、json に基づく共通形式をサポートしており、あらゆるサービスを外部に公開し、標準 HTTP プロトコル (cURL、ブラウザ、端末など) をサポートするクライアントは、プロトコル変換を行わずに直接呼び出しを開始できます。

Triple は、HTTP プロトコルの上にカプセル化された Java フレンドリーなヘシアン、Kryo などのシリアル化をサポートします。ネットワーク層の観点から見ると、これは標準の HTTP プロトコルメッセージです。HTTP プロトコルをサポートするあらゆる WAF、ゲートウェイなどと当然の互換性があり、現在のネットワーク層のインフラストラクチャを十分に再利用できます。

プロトコル仕様書（仕様書）

トリプルプロトコル仕様の詳細については、トリプル仕様[1]をこちらでご確認ください。

gRPCプロトコルとの詳しい関係

前述したように、Triple は gRPC プロトコルと完全な互換性がありますが、gRPC は多言語フレームワークの実装を公式に提供しているのに、なぜ Dubbo は Triple を通じてそれを再実装するのでしょうか? 中心的な目的は 2 つあります。

まず、プロトコル設計の観点から、Dubbo は gRPC と gRPC-Web という 2 つのプロトコルを参照してカスタム Triple プロトコルを設計しました。 Triple は、HTTP トランスポート層プロトコルに基づく RPC プロトコルであり、gRPC と完全な互換性があり、HTTP/1 および HTTP/2 で実行できます。
第二に、Dubbo フレームワークは、各言語の実装におけるフレームワーク自体の位置付けに沿った設計概念に従っており、grpc-java や grpc-go などのフレームワークライブラリと比較して、Dubbo プロトコルの実装はよりシンプルかつ純粋であり、公式 gRPC ライブラリの一連の問題を回避しようとしています。

gRPC 自体は優れた RPC プロトコル仕様ですが、ネイティブ gRPC ライブラリの実装を実際に使用するには、複雑な実装、IDL のバインディング、デバッグの難しさなど一連の問題があります。Dubbo はプロトコルの設計と実装の実践から開始し、これらの問題をうまく回避します。

ネイティブ gRPC 実装は HTTP/2 インタラクション仕様によって制限されており、ブラウザーや HTTP API にインタラクティブなメソッドを提供できません。これを実現するには、grpc-web、grpc-gateway などの追加のプロキシコンポーネントが必要です。Dubbo では、curl とブラウザを使用して直接トリプルプロトコルサービスにアクセスできます。
gRPC 公式ライブラリはプロトコルバッファーのバインドに必須であり、唯一の開発オプションは IDL を使用してサービスを定義および管理することですが、多言語に強い魅力を持たない一部のユーザーにとっては非常に大きな負担となります。Dubbo は IDL をサポートしながら、Java、Go などの言語固有のサービス定義と開発メソッドを提供します。
開発段階では、gRPC プロトコルで公開されたサービスはデバッグが非常に難しく、gRPC 固有のツールしか使用できず、多くのツールは比較的粗雑で未熟です。Dubbo3 以降では、curl | jq または Chrome 開発者ツールを直接使用してサービスをデバッグし、JSON 構造を直接渡してサービスを呼び出すことができます。
まず、gRPC プロトコルライブラリは 10 万行を超えるコード規模ですが、Dubbo (Go、Java、Rust、Node.js など) ではプロトコル実装のコードが数千行しかなく、コードのメンテナンスやトラブルシューティングが容易です。
Google が提供する gRPC 実装ライブラリは、主流のサードパーティライブラリや公式言語プロトコルライブラリを使用せず、一連の実装を独自に維持することを選択しているため、全体のメンテナンスとエコロジカルな拡張がより複雑になります。たとえば、grpc-go は、使用される公式の go ライブラリの代わりに、一連の HTTP/2 ライブラリを維持します。Dubbo は公式ライブラリを使用しますが、gRPC 自体が管理する http プロトコルライブラリと比較して同じパフォーマンスレベルを維持します。
gRPC ライブラリは RPC プロトコルの実装のみを提供するため、サービスガバナンス機能をそれに導入するには多くの追加作業を行う必要があります。Dubbo 自体はプロトコルに束縛されないマイクロサービス開発フレームワークであり、組み込みの HTTP/2 プロトコル実装は Dubbo のサービスガバナンス機能とより適切に連携できます。

実装が簡単

Dubbo フレームワークの実装は Triple プロトコル自体に重点を置いていますが、基礎となるネットワーク通信、HTTP/2 プロトコル分析などは、長期間にわたってテストされてきたネットワークライブラリに依存することを選択します。たとえば、Dubbo Java は Netty に基づいて構築されていますが、Dubbo Go は直接使用される公式 Go HTTP ライブラリです。Dubbo が提供する Triple プロトコルの実装は非常にシンプルで、Dubbo の Protocol コンポーネントの実装に対応して、Dubbo プロトコルのコード実装をわずか 1 日の午後で理解することができます。

大規模生産環境検査

Dubbo3 のリリース以来、トリプルプロトコルは、Alibaba および多くのコミュニティベンチマーク企業で、特に一部のプロキシとゲートウェイのインターワーキングシナリオで広く使用されています。Triple は、大量生産の実践を通じて信頼性と安定性が証明されている一方で、Triple のシンプルでデバッグが容易で拘束力のない IDL 設計も、幅広いアプリケーションにとって重要な要素です。

ネイティブのマルチプロトコルのサポート

Dubbo フレームワークをサービスを公開するサーバーとして使用すると、同じポート上でトリプル、gRPC、および HTTP/1 プロトコルをネイティブにサポートできます。つまり、Dubbo サーバーによって公開されたサービスにさまざまな形式でアクセスでき、最終的にすべてのリクエストフォームが同じビジネスロジック実装に転送されるため、柔軟性が高まります。Dubbo は、gRPC プロトコルおよびストリーミング、トレーラー、エラー詳細などの関連機能と完全な互換性があります。Dubbo フレームワークで Triple プロトコルを直接使用することを選択した場合 (さらに、ネイティブ gRPC プロトコルを使用することも選択できます)、Dubbo クライアント、curl、ブラウザなどを直接使用して、公開するサービスにアクセスできます。gRPC エコシステムとの相互運用性の観点からは、標準の gRPC クライアントは通常、Dubbo サービスにアクセスできます。Dubbo クライアントは標準の gRPC サービスを呼び出すこともできます。相互運用性の例は次のとおりです [2] 以下は、cURL クライアントを使用して Dubbo サーバーのトリプルプロトコルサービスにアクセスする例です。

curl \
    --header "Content-Type: application/json" \
    --data '{"sentence": "Hello Dubbo."}' \
    https://host:port/org.apache.dubbo.sample.GreetService/sayHello

ワンストップのサービス管理アクセス

Dubbo には、サービス検出、負荷分散、トラフィック制御などの豊富なマイクロサービスガバナンス機能があることは誰もが知っています。これは、Dubbo フレームワークを使用してアプリケーションを開発する利点でもあります。Dubbo システムで gRPC プロトコル通信を利用するには、gRPC が正式にリリースしたバイナリパッケージを直接 Dubbo フレームワークに導入する方法と、gRPC プロトコルと互換性のあるソースコード実装を Dubbo でネイティブに提供する方法の 2 つの方法があります。バイナリ依存関係を導入する最初の方法と比較して、Dubbo フレームワークは、組み込みの Triple プロトコルの実装を通じて gRPC プロトコルをネイティブにサポートします。この方法の利点は、ソースコードがそれ自体で完全に制御されるため、プロトコルの実装が Dubbo フレームワークとより緊密に統合され、Dubbo のサービスガバナンスシステムにより柔軟に接続できることです。

多言語の実装

Triple プロトコルの設計に基づいて、できるだけ多くの言語に軽量 RPC プロトコル実装を提供する予定です。これにより、Triple プロトコルの相互通信は複数の言語スタックを完全にカバーでき、gRPC と互換性があり、使いやすさが向上します。同時に、Dubbo は、マイクロサービス開発で広く使用されている一部の言語 (Java、Go など) で包括的なマイクロサービスガバナンス機能を引き続き提供し、Dubbo をフロントエンドとバックエンドを接続できる一連のマイクロサービス開発システムにします。

現在、Dubbo Java 言語は、バージョン 3.3.0-triple-SNAPSHOT で上記のトリプルプロトコルアップグレードの暫定目標を完了しています。これは、samples/dubbo-samples-triple-unary サンプルで体験できます (クリックすると元のテキストを読み、サンプルリンクにジャンプします)。Triple プロトコルの同期進歩における多言語実装には、Go、Node.js、Rust などのバックエンド実装、および Javascript Web エンド実装も含まれます。

Java言語

Dubbo Java ライブラリの実装では、IDL メソッドに加えて、Java インターフェイスメソッドを使用してサービスを定義できます。これにより、Dubbo システムに精通している多くの Java ユーザーにとって、gRPC プロトコルの使用コストを大幅に削減できます。

さらに、Java バージョンのプロトコル実装のパフォーマンスは基本的に grpc-java ライブラリのパフォーマンスと同じであり、シナリオによっては grpc-java のパフォーマンスよりも優れていることさえあります。これらすべては、grpc-java が HTTP/2 プロトコル実装のカスタマイズされたバージョンを維持するため、Dubbo バージョンのプロトコルの実装の複雑さが gRPC バージョンの実装の複雑さよりもはるかに小さいという事実に基づいています。

ウェアハウスのアドレス: https://github.com/apache/dubbo

Go言語の実装

Dubbo Go は IDL 開発モードを推奨しています。Dubbo に付属する protoc プラグインを介してスタブコードを生成するには、対応するビジネスロジック実装を提供するだけで済みます。Dubbo Go によってリリースされた gRPC サービスには、curl とブラウザを通じてアクセスできます。ウェアハウスのアドレス: https://github.com/apache/dubbo-go/

さび

Dubbo Rust は gRPC プロトコルの互換性部分を完全に実装しており、現在 HTTP/1 およびその他のモードでの単項 RPC 呼び出しのサポートを推進しています。

ウェアハウスのアドレス: https://github.com/apache/dubbo-rust/

Node.js

Node.js 言語は gRPC プロトコルの互換性部分を完全に実装しており、現在 HTTP/1 およびその他のモードでの単項 RPC 呼び出しのサポートを推進しています。

ウェアハウスのアドレス: https://github.com/apache/dubbo-js/

ウェブ

Dubbo が提供する Javascript クライアントライブラリを介して、ブラウザで実行されるフロントエンドページを作成し、ブラウザ側でバックエンド Dubbo サービスへのリクエスト呼び出しを直接開始できます。ウェアハウスのアドレス: https://github.com/apache/dubbo-js/

Dubbo Triple プロトコルの大幅なアップグレード: HTTP を介した Web とバックエンドマイクロサービスの接続のサポート

新しくアップグレードされたトリプルプロトコル