gRPC を C-core から .NET 用 gRPC に移行する

  • [アーティクル]

基になるスタックの実装のため、C-core ベースの gRPC アプリと .NET 用 gRPC の間ですべての機能が同じように動作するわけではありません。 このドキュメントでは、2 つのスタック間で移行する場合の主な違いについて説明します。

重要

gRPC C-core は、メンテナンス モードになっていて、非推奨となります。 .NET 用 gRPC が優先されます。 gRPC C-core は新しいアプリにはお勧めしません。

プラットフォームのサポート

gRPC C-core と .NET 用 gRPC のプラットフォーム サポートは異なります。

  • gRPC C-core: 独自の TLS および HTTP/2 スタックを備えた C++ gRPC 実装。 Grpc.Core パッケージは、gRPC C-core の .NET ラッパーで、gRPC クライアントとサーバーを含みます。 .NET Framework、.NET Core、および .NET 5 以降がサポートされます。
  • .NET 用 gRPC: .NET Core 3.x および .NET 5 以降向けに設計されています。 最新の .NET リリースに組み込まれている TLS および HTTP/2 スタックを使用します。 Grpc.AspNetCore パッケージには、ASP.NET Core でホストされ、.NET Core 3.x または .NET 5 以降を必要とする gRPC サーバーが含まれます。 Grpc.Net.Client パッケージには、gRPC クライアントが含まれます。 Grpc.Net.Client のクライアントでは、WinHttpHandler を使用した .NET Framework のサポートが制限されています。

詳細については、「.NET での gRPC でサポートされているプラットフォーム」を参照してください。

サーバーとチャネルを構成する

gRPC C-Core から gRPC for .NET に移行する場合は、NuGet パッケージ、構成、スタートアップ コードを変更する必要があります。

gRPC for .NET には、クライアントとサーバー用に個別の NuGet パッケージがあります。 追加するパッケージは、アプリで gRPC サービスをホストしているか、呼び出しているかによって異なります。

移行が完了したら、アプリから Grpc.Core パッケージを削除する必要があります。 Grpc.Core には大きなネイティブ バイナリが含まれているため、パッケージを削除すると、NuGet の復元時間とアプリ サイズを減らすことができます。

コードによって生成されるサービスとクライアント

gRPC C-Core と gRPC for .NET は多くの API を共有しており、.proto ファイルから生成されたコードは両方の gRPC 実装と互換性があります。 ほとんどのクライアントとサービスは、C-Core から gRPC for .NET に変更することなく移行できます。

gRPC サービス実装の有効期間

ASP.NET Core スタックでは、既定で gRPC サービスは、スコープが設定された有効期間で作成されます。 これに対し、gRPC C-core は、既定で、シングルトン有効期間でサービスにバインドされます。

スコープが設定された有効期間により、サービス実装では、スコープが設定された有効期間を持つその他のサービスを解決できます。 たとえば、スコープが設定された有効期間では、コンストラクター インジェクションによって DI コンテナーから DbContext を解決することもできます。 スコープが設定された有効期間の使用:

  • サービス実装の新しいインスタンスが、要求ごとに作成されます。
  • 実装型のインスタンス メンバーを介して、要求間で状態を共有することはできません。
  • シングルトン サービスでの共有状態は、DI コンテナーに格納することが期待されます。 格納された共有状態は、gRPC サービス実装のコンストラクターで解決されます。

サービスの有効期間の詳細については、「ASP.NET Core での依存関係の挿入」を参照してください。

シングルトン サービスの追加

gRPC C-core 実装から ASP.NET Core への移行を容易にするために、サービス実装のサービス有効期間をスコープからシングルトンに変更することができます。 これには、サービス実装のインスタンスを DI コンテナーに追加する必要があります。

public void ConfigureServices(IServiceCollection services)
{
    services.AddGrpc();
    services.AddSingleton(new GreeterService());
}

ただし、シングルトン有効期間を持つサービス実装では、コンストラクター インジェクションによって、スコープ設定されたサービスを解決できなくなります。

gRPC サービス オプションの構成

C-core ベースのアプリでは、grpc.max_receive_message_length や grpc.max_send_message_length などの設定は、サーバー インスタンスの構築時に ChannelOption で構成します。

ASP.NET Core では、gRPC で GrpcServiceOptions 型による構成を提供しています。 たとえば、gRPC サービスの最大受信メッセージ サイズは、AddGrpc を使用して構成できます。 次の例では、既定の MaxReceiveMessageSize を 4 MB から 16 MB に変更しています。

public void ConfigureServices(IServiceCollection services)
{
    services.AddGrpc(options =>
    {
        options.MaxReceiveMessageSize = 16 * 1024 * 1024; // 16 MB
    });
}

構成の詳細については、「.NET 用 gRPC の構成」を参照してください。

ログの記録

C-core ベースのアプリでは、デバッグ目的でロガーを構成するために GrpcEnvironment に依存しています。 ASP.NET Core スタックでは、ロギング API によってこの機能を提供しています。 たとえば、コンストラクター インジェクションを使用して、gRPC サービスにロガーを追加できます。

public class GreeterService : Greeter.GreeterBase
{
    public GreeterService(ILogger<GreeterService> logger)
    {
    }
}

gRPC のログ記録と診断の詳細については、「.NET での gRPC のログ記録と診断」を参照してください。

HTTPS

C-core ベースのアプリでは、Server. Ports プロパティを使用して HTTPS を構成します。 同様の概念は、ASP.NET Core でサーバーを構成するために使用されます。 たとえば、Kestrel では、この機能のためにエンドポイント構成を使用します。

C-core ベースのアプリでは、Server. Ports プロパティを使用して HTTPS を構成します。 同様の概念は、ASP.NET Core でサーバーを構成するために使用されます。 たとえば、Kestrel では、この機能のためにエンドポイント構成を使用します。

gRPC インターセプター

ASP.NET Core ミドルウェアは、C-core ベースの gRPC アプリのインターセプターと比較して、同様の機能を提供します。 ASP.NET Core gRPC アプリではどちらもサポートされるため、インターセプターを書き直す必要はありません。

これらの機能の比較については、「gRPC インターセプターとミドルウェア」を参照してください。

non-ASP.NET Core プロジェクトで gRPC をホストする

C-core ベースのサーバーは、任意のプロジェクト タイプに追加できます。 .NET 用 gRPC サーバーには ASP.NET Core が必要です。 プロジェクト ファイルによって SDK として Microsoft.NET.SDK.Web が指定されているため、通常 ASP.NET Core は使用可能です。

プロジェクトに <FrameworkReference Include="Microsoft.AspNetCore.App" /> を追加すると、ASP.NET Core 以外のプロジェクトに gRPC サーバーをホストできます。 フレームワーク参照によって ASP.NET Core API が使用可能になり、ASP.NET Core サーバーを起動するために使用できます。

詳細については、「non-ASP.NET Core プロジェクトで gRPC をホストする」を参照してください。

その他のリソース