戻る

名前付きパイプを使用してgrpcをホストする

grpcの主な利点は次のとおりです

  • 最新の高性能軽量RPCフレームワーク。
  • プロトコル優先API開発、プロトコルバッファのデフォルトの使用、言語に依存しない実装を可能にします。
  • 強く型付けされたサーバーとクライアントを生成するための複数の言語用のツール。
  • クライアント、サーバー、および双方向ストリーミング通話をサポートします。
  • 使用Protobufバイナリのシリアライゼーションは、ネットワークの使用を削減します。

対応する該当するシナリオ：

  • Microservice：grpcは、低レイテンシと高スループット通信用に設計されています。Grpcは、効率が重要な軽量のマイクロサービスに非常に役立ちます。
  • ポイントツーポイントのリアルタイム通信：grpcは双方向ストリーミングの優れたサポートを提供します。Grpcサービスは、ポーリングせずにリアルタイムでメッセージをプッシュできます。
  • 多言語環境：grpcツールはすべての一般的な開発言語をサポートしているため、grpcは多言語環境に最適です。
  • ネットワークが制限された環境：grpcメッセージは、軽量メッセージ形式であるprotobufを使用してシリアル化されます。Grpcメッセージは常に同等のJSONメッセージよりも小さくなります。

Grpcにはいくつかの欠点があります

  • 制限付きブラウザサポート：ほとんどのブラウザはサポートしていませんHTTP/2
  • 手動で読み取り不可protoファイルの形式は、通信時にバイナリデータにシーケンスされるため、手動で解析することは困難です。

該当しないシナリオと代替案：

  • ブラウザでアクセス可能なAPI：grpcはブラウザで完全にはサポートされていません。gRPC-Webブラウザのサポートを提供できますが、制限があり、サーバープロキシが導入されます。
  • リアルタイム通信のブロードキャスト：grpcはストリーミングによるリアルタイム通信をサポートしていますが、登録された接続にメッセージをブロードキャストするという概念はありません。たとえば、チャットルームスキームでは、新しいチャットメッセージをチャットルーム内のすべてのクライアントに送信する必要があります。これには、各grpc呼び出しで新しいチャットメッセージをクライアントに個別にストリーミングする必要があります。Signalrは、このスキームのフレームワークです。Signalrには、持続的接続とブロードキャストメッセージの組み込みサポートの概念があります。
  • プロセス間通信：プロセスは、着信grpc呼び出しを受け入れるためにHTTP / 2サーバーをホストする必要があります。Windowsの場合、プロセス間通信パイプラインは高速で軽量な通信方法です。

客観的分析

リモートコールを実現するための良い方法が必要です。システムはウィンドウをサポートします。パフォーマンスが高く（大量のデータ）、プログラムが小さい方がよいでしょう。しかし、バイナリデータストリームを直接処理したくありません（カプセル化されたフレームワークを使用することをお勧めします）。

プロセス通信の一般的な方法を検討する

  • シグナル/セマフォ：シンプルで、メッセージの内容を少なくすることができます。
  • メッセージキュー：メッセージをサポートし、強力な機能を備えています。
  • 共有メモリ：最高のパフォーマンスですが、単一のマシンのみです。
  • パイプライン：強力なパフォーマンスがありますが、ストリームのみをサポートします。
  • ソケット：最も柔軟性がありますが、ネットワークカードが必要です。

まず、信号/セマフォが除外され、処理される情報の量が少なすぎます。その場合、共有メモリも除外され、1台のマシンだけが私の要件を満たしません。残りの3つは要件を満たしているようで、RPCはこれに基づいて構築でき、grpcはソケット（HTTP / 2）上に構築されます。上記のように、HTTP / 2サーバー（ケストレルなど）を統合する必要がありますが、これは十分に軽量ではありません。残りの2つのウィンドウにはサポートが組み込まれているので、検討してください。

教義を取るという考えに沿って、GitHubでgrpc dotnet名前付きパイプを見つけました。これは名前付きパイプラインでのgrpcの実装をサポートします。これは、バイナリデータストリームを直接処理せずにストリーム上のレイヤーをカプセル化するのと同じです。

著者自身の言葉では、これには通常のgrpcに比べていくつかの利点があります

  • より良いアクセス制御;
  • ピュア。ネットライブラリ。ASP.NETCoreまたは3MBを超えるアンマネージドライブラリの依存関係をもたらす必要はありません。
  • 起動時間の短縮
  • 2〜3倍のデータスループット
  • ファイアウォールの警告はありません
  • ネットワークカードは必要ありません

実現

プロトを構築する

  1. を作成します。ネットライブラリ
  2. プロトファイルを追加すると、Microsoftの簡単な例を直接使用できます
syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}
  1. nugetパッケージを追加します：Google.Protobuf、Grpc.Core、Grpc.Tools
  2. protoファイルをクリックし、[プロパティ]ダイアログボックスで[ Protobufコンパイラとして生成]を選択します

クライアントを確立する

新しいコンソールプログラムを作成し、上記のプロジェクト参照を追加して、次のコードを入力します。

var server = new NamedPipeServer("MY_PIPE_NAME");
Greeter.BindService(server.ServiceBinder, new GreeterService());
server.Start();

次のGrpcDotNetNamedPipesNuget依存関係に追加します。

Install-Package GrpcDotNetNamedPipes

サーバーをセットアップする

新しいコンソールプログラムを作成し、上記のプロジェクト参照、nuget依存関係、およびその他の依存関係を追加して、次のコードを入力します。

var channel = new NamedPipeChannel(".", "MY_PIPE_NAME");
var client = new Greeter.GreeterClient(channel);

var response = await client.SayHelloAsync(
	new HelloRequest { Name = "World" });

Console.WriteLine(response.Message);

次に、おなじみのHelloの世界を見ることができます。これは、grpcの標準的な実装とそれほど変わりません。

まとめ

完全なcode_デモについてはgrpcを参照してください。

この方法にも制限があります。まず、WindowsのネーミングパイプラインはLinuxのネーミングパイプラインとは異なるため、直接のクロスプラットフォーム通信を実現できません。第二に、他の言語で開発されたgrpcは完全に互換性がなく、他の言語で適応させる必要があります。言い換えれば、それは一般的な標準ではありません。したがって、一般的なgrpcアプリケーションには標準の実装をお勧めします。

参照リソース

  • grpcの簡単な紹介。ネットコア
  • grpcサービスをHTTPAPIと比較する
  • IPCのパフォーマンスに関する質問
  • Linux上のさまざまなIPCのパフォーマンス比較

Published Aug 3, 2021

フリーランスをやっています。Yuji Tokuda on Twitter