RPCとは何ですか
RPC（リモートプロシージャコール）リモート・プロシージャ・コール、例えば、今、二つのサーバのA、Bを持って、アプリケーション上のAは、サーバーB上のサーバーアプリケーションを呼び出すために望んでいる、二つの方法、それはメモリではないためではありませんスペースは、データの意味、直接呼び出され、ネットワークを介して発現されるように、コールコールのニーズを伝えることはできません。多くの場合、分散システムで見つかりました。
RPCの問題を解決すべき
- 通信を確立します。クライアントとサーバーは、データ伝送チャネルを確立します。有名[GRPC（GRPC / grpc.io）HTTP2プロトコルは、クラス定義のパケットからダボTCPプロトコルのように、使用されます。
- RPCフレームワーク指示する必要があります上のサーバーアプリケーション：アドレッシングBサーバーのアドレス、ポートを、関数名を呼びます。私たちは、マッピングメソッド呼び出しIDさんと呼ばれるように実装する必要があります。
- シリアライゼーションおよびデシリアライゼーション：ネットワーク・プロトコルは、バイナリであるため、第1の2値シーケンスに渡され、メソッド呼び出しのパラメータを行う場合、パラメータは再びBサーバは要求を受信するデシリアライズされるからです。メモリの発現を復元し、市内通話のための対応方法を見つけ、戻り値を取得します。AにBから送信された戻り値は依然としてシリアライズとデシリアライズプロセスです。XML JSONテキストエンコーディングに基づいて、プロトコルのシーケンスは、のような二値化いるProtobufのヘッセ行列が存在します。
実際には、知っているRPCの必要性は、上記の基本的な内容で、私たちは言葉を知りたいと利点は、問題を解決するために、一般的なHTTPに比べて何です。
-
Http何が
要求と応答に基づいて、ステートレスなプロトコル、アプリケーション層、多くの場合、TCP / IPプロトコル、インターネットで最も広く使われているネットワークプロトコルに基づいてデータを転送し、すべてのファイルがWWW必要があり、ハイパーテキスト転送プロトコルこの標準に準拠しています。デザインHTTPは本来の意図は、HTMLページを公開し、受信するための方法を提供することでした。ここでのHttp開発の歴史があります。
歴史のhttp開発 -
HTTPは切断振っTCP接続と4を確立するために、このような3ウェイハンドシェイクとしてTCPプロトコル、HTTPプロトコルのボトルネックとTCPプロトコル自体の特性に基づいて最適化技術の上に構築され、各接続がもたらすために確立されていますRTT遅延時間。
-
基本的なHTTPの最適化：帯域幅と遅延を：主に2つのHTTPリクエストのネットワークに影響を与える要因。
-
なぜバックエンドのプロセス間通信を行うために、自己定義されたRPC TCP契約を使いますか？
TCPパケットHTTP1.1プロトコル共通定義情報があまりにも多くの廃棄物が含まれ、以下のように、POSTプロトコルの形式は、
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body> </html> 契約は、バイナリ符号化プロトコルを使用して符号化された本体であっても、パケットのヘッダメタデータは、そうバイトの数を占め、ヘッドが、テキストエンコーディングでキーです。バイトの有効数で使用される図のパケットは、わずか約30％、符号化されたメタデータを送信するために費やされる時間の、すなわち70％です。もちろん、実際の状況でのメッセージの内容はこれより長くてもよいが、ヘッダのシェアの比率が非常に印象的です。
簡単に言えば、比較的成熟したHTTPのRPCライブラリコンテナ、「サービス発見」のパッケージのより、「ロード・バランシング」、「吹きダウングレードは、」高度な機能のサービス指向のクラスです。それが理解することができ、RPCサービス指向フレームワークは、より高度なパッケージです。あなたは、エージェントサービスの発見と関数呼び出しをカプセル化するHTTPサーブレット・コンテナの上に置く場合は、すでにRPCフレームワークを行うことができます。
gRpc
GoogleがオープンソースgRPCモバイルおよびHTTP / 2の設計のためのRPCフレームワークです。
コンテンツ交換フォーマットは、オープンソースは、長い時間となっている、いるProtobuf（Googleのプロトコルバッファ）を使用して構造化データをシリアル化するために、柔軟、効率的で自動メカニズムを提供し、XMLの役割、JSONが、バイナリを使用し、（反）の高速シリアル化のスピード高い圧縮効率。
トランスポートプロトコルHTTP2、HTTP1.1よりもはるかに優れた性能
と多くのRPCシステムでは、サーバが定義されたインタフェースを実装するための責任であり、クライアントの要求を処理し、クライアントは、サービスがインタフェース記述から直接必要と呼び出されます。クライアントとサーバは、それぞれ異なる言語gPRCサポートの実装を使用することができます。
強いIDL（インタフェース記述言語、インタフェース記述言語）と関連ツール（主にprotoc）とともにいるProtobuf。書き込まれたユーザプロファイル.Proto、protocインターフェイスコードの数の言語にコンパイルすることができます。
HTTP / 2
-
新しいバイナリ形式（バイナリ形式）、解像度のHTTP1.xテキストをベースにしています。テキストの形で多様性があり、自然に欠陥が発生したテキストベースの形式のプロトコルを解析し、多くのことを行うには、シーンの堅牢性は、0と1の組み合わせのみを認識し、バイナリが異なる場合、必然的に考慮すべき。この検討のHTTP2.0に基づいて、バイナリ形式、便利かつ堅牢な実装を解析するプロトコルを採用することを決めました。
-
多重化（多重）、すなわち、共有接続、すなわち、各要求は、共有機構が接続として使用されます。要求IDに対応し、そのような接続要求が複数存在してもよく、各要求は一緒にランダムな混合に接続することができ、その後、受信機は、終了リクエストのリクエストIDに応じてそれらの異なる要求サービスに起因し得ます。
-
ヘッダ圧縮は、上記のように多くの情報を有する前述HTTP1.xヘッダに、前記、繰り返し送信される、通信それぞれのキャッシュヘッダのサイズを小さくするために使用されるたびに、HTTP2.0エンコーダに送信されますフィールド・テーブル・ヘッダ、ヘッダの重複伝送を回避するために、両方だけでなく、送信されるサイズを減少させます。
-
サーバープッシュ（サーバープッシュ）、SPDY、HTTP2.0と同じでも、サーバープッシュ機能を持っています。現在、ほとんどのサイトには、例えば、HTTP2.0を有効にしている YOUTUBE、淘宝網と他のサイト、H2を有効にするかどうかを確認することができますクロムコンソールの使用：
DOTNET gRPCデモ
プロトを作成および構成するGprcプロジェクト
dotnet new grpc -o GrpcGreeter
- greet.proto
syntax = "proto3";
option csharp_namespace = "GrpcGreeter";
package Greet;
// The greeting service definition.
service Greeter {
// Sends a greeting rpc SayHello (HelloRequest) returns (HelloReply); } // The request message containing the user's name. message HelloRequest { string name = 1; } // The response message containing the greetings. message HelloReply { string message = 1; } - Start.cs public void ConfigureServices(IServiceCollection services){ services.AddGrpc(); } public void Configure(IApplicationBuilder app, IWebHostEnvironment env){ app.UseEndpoints(endpoints =>{ endpoints.MapGrpcService<GreeterService>(); endpoints.MapGet("/", async context => { await context.Response.WriteAsync("Communication with gRPC endpoints"); }); }); }