RPCサービスとHTTPサービスの比較

クズども · 掲載地 2019/04/01 14:02:45

長い間、RPC(リモートプロシージャコール)とHTTPコールの違いが分かっていません。ここで笑わせてくれ~純粋! この記事では、C/Sアーキテクチャの2つの形態を簡単に紹介します。まず、最も重要な違いです。つまり、RPCは主にTCP/IPプロトコルに基づいているのに対し、HTTPサービスは主にHTTPプロトコルに基づいています。HTTPプロトコルはトランスポート層プロトコルTCPの上に載っていることは皆知っています。したがって、効率性の観点ではRPCの方が当然優れています! RPCサービスとHTTPサービスについて詳しく話しましょう。

OSIネットワーク7層モデル

RPCとHTTPの違いについて話す前に、OSIの7層ネットワーク構造モデル(実際には基本的に5層ですが)を理解する必要があると思います。これは以下の層に分けられます:(上から下へ)

最初の層:アプリケーション層です。ネットワーク内の通信およびデータ伝送のためのインターフェースが定義されています。
第二層:表現層。伝送フォーマットの定義、異なるシステムにおけるデータの符号化および復号仕様など;
第三の層:会話層です。ユーザーセッションの管理や、ユーザー間の論理接続の確立および中断を制御します。
第四層:輸送層。ネットワーク内のエンドツーエンドデータ伝送を管理します。
レイヤー5:ネットワーク層。ネットワークデバイス間でデータの転送方法を定義します。
第六層:リンク層。上記のネットワーク層のデータパケットは、物理層の伝送を容易にするためにデータフレームにカプセル化されます。
レイヤー7:物理層。この層は主にこのバイナリデータの送信に使われています。

実用的には、5層プロトコル構造にはプレゼンテーション層とセッション層はありません。ただし、これらはアプリケーション層と統合されます。アプリケーション層とトランスポート層に焦点を当てるべきです。なぜならHTTPはアプリケーション層プロトコルであり、TCPはトランスポート層プロトコルだからです。さて、ネットワークの階層化モデルが分かった今、なぜRPCサービスがHTTPサービスよりも優れているのかをよりよく理解できるようになりました!

RPCサービス

RPCサービスは、RPCアーキテクチャ、同期非同期呼び出し、そして一般的なRPCフレームワークの3つの視点から紹介されます。

RPCアーキテクチャ

RPCサービスの基本的なアーキテクチャについて話しましょう。恥ずかしいことに少しだけ引用させてください~完全なRPCアーキテクチャには、クライアント、サーバー、クライアントスタブ、そしてスタブと理解できるサーバースタブという4つのコアコンポーネントが明確に含まれています。これらの要素について別々に話しましょう。

クライアント、サービスの発信者。
サーバーは本当のサービス提供者です。
クライアントスタブはサーバーのアドレスメッセージを保存し、クライアントのリクエストパラメータをネットワークメッセージにまとめて、ネットワーク経由でリモートでサービスパーティに送信します。
サーバー側のスタブはクライアントから送信されたメッセージを受け取り、それを解凍してローカルメソッドを呼び出します。

RPCは主に大企業で使われます。なぜなら、大企業には多くのシステムや複雑な事業ラインがあり、効率性の利点が非常に重要だからです。これは実際の開発段階で行われ、プロジェクトは通常Mavenで管理されます。例えば、注文を処理するシステムサービスがあり、まずすべてのインターフェース(ここでは特にJavaのインターフェース)を宣言し、その後プロジェクト全体をjarパッケージにまとめます。なぜこんなことをするのか? 主な目的はクライアント側のjarパッケージのサイズを削減することです。なぜなら、パッケージがリリースされるたびにjarパッケージが多すぎると効率に影響が出るからです。また、クライアントとサーバーを分離してコードの移植性を向上させます。

同期および非同期通話

同期通話とは何ですか? 非同期通話とは何ですか? 同期呼び出しとは、クライアントが呼び出しの実行完了を待ってから結果を返すことです。非同期呼び出しとは、クライアントが呼び出しの実行を待って結果を返すのを待たず、コールバック関数を通じて返還結果の通知を受け取ることを意味します。クライアントが結果を気にしないと、一方通行の電話に変わってしまうことがあります。このプロセスはJavaの呼び出し可能インターフェースや実行可能インターフェースにやや似ており、非同期実行時に実行結果を知る必要がある場合は呼び出し可能なインターフェースを使い、Futureクラスを通じて非同期実行の結果情報を取得できます。実行結果を気にしなければ、実行可能なインターフェースを使うこともできます。結果は返されません。もちろん、呼び出し可能なインターフェースも可能です。未来を取る必要はありません。

人気のあるRPCフレームワーク

今でも多くの人気のあるオープンソースRPCフレームワークがあります。以下に3つのハイライトを紹介します。

gRPCは、最新のHTTP 2.0プロトコルを基にしたGoogleの最近発表されたオープンソースソフトウェアで、多くの一般的なプログラミング言語をサポートしています。 HTTP 2.0はバイナリに基づくHTTPプロトコルのアップグレード版であり、主要なブラウザが現在急速にサポートしていることがわかっています。このRPCフレームワークはHTTPプロトコルに基づいており、基盤はNettyフレームワークのサポートを利用しています。
ThriftはFacebook向けのオープンソースプロジェクトで、主に言語間サービス開発フレームワークです。定義したIDL定義ファイルのサービスコードフレームワークを自動的に生成するコードジェネレーターを備えています。ユーザーはその前に二次開発を行うだけでよく、基盤となるRPC通信は透明です。しかし、ユーザーにとっては特定の分野の言語を学ぶには一定のコストがかかります。
Dubboはアリババグループが提供したよく知られたRPCフレームワークのオープンソースで、多くのインターネット企業や企業向けアプリケーションで広く使用されています。プロトコルとシリアライゼーションフレームワークの両方をプラグイン可能です。同じリモートインターフェースはJavaインターフェースをベースにしており、開発を容易にするためにSpringフレームワークに依存しています。単一のファイルに簡単にパッケージ化し、独立して実行できるため、現在のマイクロサービスの概念と整合しています。

こっそり、グループはもうあまりダボを使わないと伝える。現在より一般的に使われているのはHSFと呼ばれています「とても快適」とも呼ばれています。後でオープンソースが出るかもしれないので、様子を見ましょう。

HTTPサービス

実際、ずっと昔、私はエンタープライズ開発モデルをHTTPインターフェース開発、つまりRESTfulスタイルのサービスインターフェースと呼ぶものと特徴づけてきました。実際、インターフェースが少なくシステム間の相互作用が少ない情報孤島の初期段階でよく使われる通信手法です。利点はシンプルで直接的、そして開発が容易です。送信には既製のHTTPプロトコルを活用してください。以前、会社でバックグラウンド開発をしていたときは主にインターフェースを開発し、また入力と出力を厳密に示した大きなインターフェースドキュメントも書かなければなりませんでした。各インターフェースのリクエストメソッドとリクエストパラメータで注意すべき点を説明してください。例えば、次の例です:

投稿http://www.httpexample.com/restful/buyer/info/share

インターフェースはJSON文字列やXMLドキュメントを返すことがあります。クライアントはこの返された情報を処理し、より迅速な開発を可能にします。しかし、大企業の場合、多くの内部サブシステムやインターフェースがある場合、RPCフレームワークの利点が示されます。まず第一に、長いリンクであり、httpのように毎回3回握手する必要がなく、ネットワークのオーバーヘッドを削減できます。第二に、RPCの枠組みには一般的に登録センターと充実した監視・管理が備わっています。パブリッシング、オフラインインターフェース、動的拡張などは、発信者にとって非認識的かつ統一された操作です。

概要

一般的に言えば、RPCサービスは主に大企業向けであり、HTTPサービスは主に小規模企業向けです。なぜならRPCの方が効率的で、HTTPサービスの開発がより速いからです。要するに、どのようなフレームワークを選ぶかは市場で人気があるものではなく、プロジェクト全体を評価し、2つの開発フレームワークがプロジェクト全体に与える影響を慎重に比較し、最終的にプロジェクトに最も適したものを決定することです。すべてのプロジェクトでRPCを使うためだけにRPCを使うのではなく、現地の状況に適応し、具体的な状況を分析する必要があります。

RPCサービスとHTTPサービスの比較

関連記事

閲覧したセクション