*著者: Apache Dubbo PMC、Momo R&D エンジニア、Chen Youwei 氏
RPC プロトコル開発マイクロサービス
通常、マイクロサービスを開発する場合、従来の RPC サービスが最下位になることがあります。上位層には、ブラウザ、モバイル端末、外部サーバー、独自のテスト、カールなどが考えられます。Tomcat などの外部サーバーを使用して RPC 層 (BFF) を組み立てることもあります。または、BFF がなく、RPC は外部の世界にサービスを提供することになっています。ただし、ブラウザはアクセスする必要があるため、APISIX や ShenYu などの HTTP ゲートウェイが必要です。
上の写真は私たちのプロセスを示していますが、いくつかの問題があります。
サービスが非常に軽く、転送層のみが必要な場合、ゲートウェイを構成したり、転送用の Web サーバーを設定したりする方法に関係なく、面倒になります。
さらに、ほとんどの RPC サービスはバイナリに基づいており、バイナリをローカルでテストすることはできません。したがって、当社はテスト用にバックエンドまたは中間プロキシを開発する場合があります。ただし、その前提条件として、少なくともテスト環境にデプロイする必要があるため、ローカルでテストすることはできません。
一般に、これら 2 つの問題により、ビジネスとは関係のない反復作業が必要になるため、使いやすさが比較的低くなり、開発コストが比較的高くなります。
新しくアップグレードされたトリプルプロトコル
上記の 2 つの質問に基づいて、トリプル プロトコルを紹介しましょう。
まず、前世代のプロトコルとその作成理由について話しましょう。Dubbo はもともと Dubbo プロトコルであり、tcp に基づいており、パッケージは 1 つだけであることを誰もが知っているはずです。ゲートウェイはパッケージの設計上、一部の特殊なルール判定やフィルタリングなどの操作を行うことができません。パフォーマンスを犠牲にしてパッケージを完全に解凍し、元に戻して組み立ててから渡すことを厭わない場合は、それでも実行できますが、一般的には誰もがそれを受け入れることができません。
そこで私たちは、元のデータを実際のパケットから分離できないか考えていました。現在では、主流の業界標準である既製の HTTP と gRPC が用意されているため、私たちの目標は gRPC と互換性を持つことです。なぜなら、gRPC は現在 IDL を使用しており、IDL には特に Java 側で問題があるからです。誰もがいくつかのインターフェイスを作成し、それらを実装するためにいくつかのパッケージを定義するため、これは非常に面倒です。Go 側では問題ありません。誰もがすでにこの開発モデルに慣れているからです。
そこで私たちは Triple プロトコルを開発しましたが、まず第一に、このプロトコルは gRPC と互換性があるため、gRPC との完全な相互運用性を実現できます。2つ目は、インターフェースを自分で定義する方法に対応していることです。一部のパフォーマンスは失われますが、使いやすさは多少向上します。さらに、RPC は一般にビジネスのボトルネックではなく、ほとんどのボトルネックは依然として DB にあります。
しかし、まだ問題があり、gRPC と互換性がありますが、gRPC は TPC に基づいているため、フロントエンドやその他のサードパーティ システムが HTTP しか持たない場合、依然として私たちのシステムを受け入れることができません。
これに基づいて、新しいトリプルプロトコルを立ち上げたいと考えています。上記の問題をすべて解決するために、gRPC、gRPC Web、一般的な HTTP およびその他のプロトコルを参照して、ブラウザー アクセスを実現し、ストリーミングをサポートし、HTTP/1 および HTTP/2 プロトコルでの同時実行をサポートします。HTTP/3 はまだ大規模に推進されていないため、将来的には HTTP/3 がサポートされる予定です。
最終的な設計の実装は完全に HTTP に基づいており、人間にとっても、開発やデバッグにとっても使いやすいものになります。特に単項 RPC の場合は、単純なブラウザーまたは Curl を介してアクセスできます。さらに、gRPC と完全に相互運用できるため、HTTP を使用する企業は、互換性の問題や契約への署名を心配する必要がありません。安定性を確保するために、Java のネイティブや Go の基本的なネット パッケージなど、業界で人気のあるネットワーク ライブラリのみを使用します。
Triple プロトコルと gRPC プロトコルは両方とも HTTP に基づいていますが、gRPC は HTTP/2 に基づいており、Triple は HTTP/1 と HTTP/2 に基づいています。
gRPCとの互換性を保ちつつ、使いやすさを追求した機能拡張も行っています。たとえば、リクエストでは、Application/Json リクエスト形式をサポートし、curl アクセスをサポートします。
さらに、プロトコルの以前のバージョンでは、インターフェイスを定義する従来の方法をサポートするために、二次シリアル化プロセスがありました。特別なコンテンツ タイプを使用して本体の構造を決定し、二次シリアル化の問題を解決したいと考えています。理論上、HTTP のすべての機能は Triple プロトコル上に実装でき、拡張することもできます。
Triple プロトコルの使用後、開発プロセスも変わりました。アセンブルする必要がない場合、または外部プロキシがない場合、アクセス プロセスは、外部リクエスト ブラウザ、相手のサーバー、カール、独自のテストなどからサーバーに直接行われる可能性があります。
他の gRPC との通信には問題はなく、このプロセスはレイヤーが欠落していることに相当します。ほとんどのユーザーにとって、このシナリオが必要ない場合、実際には大きなメリットがあります。
Triple プロトコルは当初 gRPC と互換性があったため、当時は HTTP/2 ベースのみでしたが、HTTP/2 にはストリーミング機能があるため、当然ストリーミングをサポートします。ただし、ここで特別なのは、プロトコルの新しいバージョンは HTTP/1 のストリームもサポートしますが、HTTP/1 の制限により、サーバー ストリーミングのみをサポートできることです。HTTP/1 のサーバー プッシュ実装に依存します。
Client Stream と Bi Stream については、特に言うことはありません。ただし、1 つ特別なことは、Java 側に Bi Stream が存在しないことです。これはコーディングの観点からは存在しませんが、実装の観点からは存在します。
トリプルプロトコル開発マイクロサービス
現在、Triple プロトコルは、IDL 定義と直接定義の 2 つの定義方法を柔軟にサポートしています。直接定義は、同期、非同期、および手書きをサポートします。より極端な例もあります。インターフェイスを定義するときに IDL を使用して protobuf クラスを生成するなどです。サービスは定義しません。生成されたリクエストとレスポンスのクラスだけを使用しても問題ありません。トリプル プロトコルはインターフェイスの使用状況を自動的に識別します。 .protobuf を使用するか、送信に protobuf を使用しません。
サーバーはタスクを実装するだけです。上図は一例で、APIのアセンブリメソッドを直接使用していますが、実際のビジネスではアノテーションやXMLを使用する場合があります。
HTTP の標準プロトコルをサポートしているため、理論上はテストが非常に簡単になります。
gRPC をサポートしているため、gRPCcurl を使用してサービスを呼び出すことができます。ただし、前提条件として、リフレクション サービスを用意し、それを手動でオンにする必要があります。デフォルトではオンになっていません。次に、リフレクションを通じてインターフェイスのソース データを取得し、Json を通じて protobuf 形式に変換して送信します。または、Application/Json を使用して直接転送することもできます。ここで特別なことの 1 つは、HTTP/1 で Sreaming も使用できることです。
さらに、HTTP をサポートしているため、理論的にはすべてのサードパーティの HTTP クライアントを呼び出すことができます。その後、Dubbo の Admin を登録すれば、テストに使用することもできます。
呼び出し側がPOJOであってもIDLであっても本質的な違いはありません。
現在、トリプル プロトコルがありますが、このプロトコルはベアラーなしでは機能しません。したがって、マイクロサービスであるフレームワークと何らかのサービス ガバナンスが必要です。したがって、サービス ガバナンスもマイクロサービスには不可欠な部分です。
Dubbo は Triple プロトコルにガバナンス機能をもたらします
Triple はあくまで Dubbo のプロトコルの 1 つとして位置づけられており、互換性のためにオリジナルの Dubbo プロトコルや他のプロトコルを使用することももちろん可能です。また、同じポート上で複数のプロトコルを開くこともサポートされており、必要に応じて選択できます。
同時に、Dubbo は Triple の多言語実装を提供します。現在、正式実装はRust、Go、Java、JS、node、Pythonで実装される予定です。この方法では、ユーザーは実験プロトコルの仕様に従って実装する必要がありません。内部フレームワークなどのカスタマイズ要件がある場合は、仕様に従って実装できます。
Dubbo はサービス フレームワークとよく統合されており、理論的には、開発プロセス、特に Java 側で、顧客はサービス定義、サービス ガバナンス、サービス登録の検出などについて心配する必要がなく、外部から使用できます。箱。
Dubbo は豊富なエコシステムを提供しており、サードパーティのエコシステムには Nacos、Zookeeper などが含まれており、革新する必要はなく、対応するパッケージを直接導入できます。
これは、トリプル プロトコル サービス登録の使用例です。上では Nacos、Zookeeper、K8s が選択でき、左側にはクライアントとサーバーがあり、このように呼ばれます。
管理者での実装を見てみましょう。ここで、私たちの管理者も新しいバージョンでリファクタリングされ、Go で実装されていることを言及しておきます。
グレースケールの公開やトラフィックの色付けが必要になることがよくあります。管理者からタグ ガバナンス ルールを送信し、いくつかのインスタンスにタグを付けると、タグを含むトラフィックが入り口から 1 つずつ渡されるため、フルリンク トラフィック ダイイングが実現します。
Qt 6.6が正式リリース Gomeアプリの抽選ページのポップアップウィンドウが創設者を侮辱 Ubuntu 23.10が正式リリース 金曜日を利用してアップグレードするのもいいかもしれません！ RISC-V: 単一の企業や国によって管理されていない Ubuntu 23.10 リリース エピソード: ヘイトスピーチが含まれているため ISO イメージが緊急に「リコール」された ロシアの企業は Loongson プロセッサをベースにしたコンピュータとサーバーを製造している ChromeOS は Google デスクトップを使用する Linux ディストリビューション環境 23 歳の 博士課程学生が Firefox の 22 年前の「ゴーストバグ」を修正 TiDB 7.4 リリース: MySQL 8.0 と正式互換 Microsoft が Windows Terminal Canary バージョンを発表