Compartir a través de


Migración de gRPC de C-core a gRPC para .NET

Nota:

Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión .NET 8 de este artículo.

Advertencia

Esta versión de ASP.NET Core ya no se admite. Para obtener más información, consulte la Directiva de soporte técnico de .NET y .NET Core. Para la versión actual, consulte la versión .NET 8 de este artículo.

Importante

Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.

Para la versión actual, consulte la versión .NET 8 de este artículo.

Debido a la implementación de la pila subyacente, no todas las características funcionan de la misma manera entre aplicaciones gRPC basadas en C-core y gRPC para .NET. En este documento se destacan las diferencias principales para realizar migraciones entre las dos pilas.

Importante

gRPC C-core está en modo de mantenimiento y dejará de utilizarse en favor de gRPC para .NET. No se recomienda gRPC C-core para nuevas aplicaciones.

Compatibilidad con plataformas

gRPC C-core y gRPC para .NET tienen compatibilidad con distintas plataformas:

  • gRPC C-core: una implementación gRPC de C++ con sus propias pilas TLS y HTTP/2. El paquete Grpc.Core es un contenedor de .NET en torno a gRPC C-core y contiene un cliente y un servidor gRPC. Admite .NET Framework, .NET Core y .NET 5 o posterior.
  • gRPC para .NET: diseñado para .NET Core 3.x y .NET 5 o posterior. Usa pilas TLS y HTTP/2 integradas en versiones modernas de .NET. El paquete Grpc.AspNetCore contiene un servidor gRPC que se hospeda en ASP.NET Core y requiere .NET Core 3.x o .NET 5 o posterior. El paquete Grpc.Net.Client contiene un cliente gRPC. El cliente de Grpc.Net.Client tiene compatibilidad limitada con .NET Framework mediante WinHttpHandler.

Para más información, consulte gRPC en plataformas compatibles con .NET.

Configuración del servidor y el canal

Los paquetes NuGet, la configuración y el código de inicio se deben modificar al migrar de gRPC C-Core a gRPC para .NET.

gRPC para .NET tiene paquetes NuGet independientes para su cliente y servidor. Los paquetes agregados dependen de si una aplicación hospeda servicios de gRPC o los llama:

Una vez que se completa la migración, el paquete Grpc.Core se debe quitar de la aplicación. Grpc.Core contiene archivos binarios nativos de gran tamaño y, al quitar el paquete, NuGet reduce el tiempo de restauración y el tamaño de la aplicación.

Servicios y clientes generados por código

gRPC C-Core y gRPC para .NET comparten muchas API, y el código generado a partir de los archivos .proto es compatible con las dos implementaciones de gRPC. La mayoría de los clientes y servicios se pueden migrar de C-Core a gRPC para .NET sin cambios.

Duración de la implementación del servicio gRPC

En la pila de ASP.NET Core, los servicios gRPC se crean de forma predeterminada con una duración restringida. En cambio, gRPC C-core se enlaza de forma predeterminada a un servicio con una duración singleton.

Una duración restringida permite que la implementación del servicio resuelva otros servicios con duraciones restringidas. Por ejemplo, una duración restringida también puede resolver DbContext desde el contenedor de inserción de dependencias a través de la inserción de constructores. Si se usa una duración restringida:

  • Se crea una instancia de la implementación del servicio para cada solicitud.
  • No es posible compartir el estado entre solicitudes a través de miembros de instancia en el tipo de implementación.
  • Lo normal es almacenar los estados compartidos en un servicio singleton en el contenedor de inserción de dependencias. Los estados compartidos almacenados se resuelven en el constructor de la implementación del servicio gRPC.

Para más información sobre las duraciones del servicio, consulte Inserción de dependencias en ASP.NET Core.

Adición de un servicio singleton

Para facilitar la transición de una implementación de gRPC de C-core a ASP.NET Core, se puede cambiar la duración de la implementación del servicio de restringida a singleton. Esto implica agregar una instancia de la implementación del servicio al contenedor de inserción de dependencias:

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

Sin embargo, una implementación del servicio con una duración singleton ya no puede resolver los servicios restringidos a través de la inserción de constructores.

Configuración de las opciones de servicios gRPC

En las aplicaciones basadas en C-core, los valores como grpc.max_receive_message_length y grpc.max_send_message_length se configuran con ChannelOption en el momento de crear la instancia del servidor.

En ASP.NET Core, gRPC proporciona la configuración a través del tipo GrpcServiceOptions. Por ejemplo, el tamaño máximo del mensaje entrante del servicio gRPC se puede configurar mediante AddGrpc. En el ejemplo siguiente, se cambia el valor predeterminado de MaxReceiveMessageSize de 4 MB a 16 MB:

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

Para más información sobre la configuración, consulte Configuración de gRPC para .NET.

Registro

Las aplicaciones basadas en C-core usan GrpcEnvironment para configurar el registrador con fines de depuración. La pila de ASP.NET Core proporciona esta funcionalidad a través de la API de registro. Por ejemplo, se puede agregar un registrador al servicio gRPC mediante la inserción de constructores:

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

Para más información sobre el registro y el diagnóstico de gRPC, consulte Registro y diagnósticos en gRPC en .NET.

HTTPS

Las aplicaciones basadas en C-core configuran HTTPS mediante la propiedad Server.Ports. Se usa un concepto similar para configurar servidores en ASP.NET Core. Por ejemplo, Kestrel usa la configuración de puntos de conexión para esta funcionalidad.

Las aplicaciones basadas en C-core configuran HTTPS mediante la propiedad Server.Ports. Se usa un concepto similar para configurar servidores en ASP.NET Core. Por ejemplo, Kestrel usa la configuración de puntos de conexión para esta funcionalidad.

Interceptores de gRPC

El middleware de ASP.NET Core ofrece funcionalidades similares a los interceptores de aplicaciones gRPC basadas en C-core. Ambos son compatibles con aplicaciones gRPC de ASP.NET Core, por lo que no es necesario volver a escribir interceptores.

Para más información sobre cómo se comparan entre sí estas características, vea Interceptores gRPC frente a middleware.

Hospedaje de gRPC en proyectos que no son de ASP.NET Core

Un servidor basado en C-core se puede agregar a cualquier tipo de proyecto. gRPC para el servidor .NET requiere ASP.NET Core. ASP.NET Core suele estar disponible porque el archivo de proyecto especifica Microsoft.NET.SDK.Web como SDK.

Un servidor gRPC se puede hospedar en proyectos que no sean de ASP.NET Core agregando <FrameworkReference Include="Microsoft.AspNetCore.App" /> a un proyecto. La referencia del marco hace que las API de ASP.NET Core estén disponibles y se puedan usar para iniciar un servidor ASP.NET Core.

Para obtener más información, consulte Hospedaje de gRPC en proyectos que no son de ASP.NET Core.

Recursos adicionales