gRPC

Sugerencia

Este contenido es un extracto del libro electrónico “Architecting Cloud Native .NET Applications for Azure” (Diseño de la arquitectura de aplicaciones .NET nativas en la nube para Azure), disponible en Documentos de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Hasta ahora en este libro, nos hemos centrado en la comunicación basada en REST. Hemos visto que REST es un estilo de arquitectura flexible que define las operaciones basadas en CRUD en los recursos de entidad. Los clientes interactúan con recursos a través de HTTP con un modelo de comunicación de solicitud-respuesta. Aunque REST es una tecnología de comunicación más reciente ampliamente implementada, gRPC ha ganado un enorme impulso en toda la comunidad nativa de la nube.

¿Qué es gRPC?

gRPC es un marco moderno de alto rendimiento que desarrolla el protocolo de llamada a procedimiento remoto (RPC) antiguo. A nivel de aplicación, gRPC simplifica la mensajería entre los clientes y los servicios back-end. Procedente de Google, gRPC es código abierto y forma parte del ecosistema Cloud Native Computing Foundation (CNCF) de ofertas nativas de nube. CNCF considera a gRPC un proyecto de incubación. El término incubación significa que los usuarios finales usan la tecnología en las aplicaciones de producción y el proyecto tiene un número correcto de colaboradores.

Una aplicación cliente de gRPC típica expondrá una función local en proceso que implementa una operación empresarial. En segundo plano, esa función local invoca otra función en una máquina remota. Lo que parece ser una llamada local básicamente se convierte en una llamada fuera de proceso transparente a un servicio remoto. La asociación RPC abstrae la comunicación de red de punto a punto, la serialización y la ejecución entre equipos.

En las aplicaciones nativas de la nube, los desarrolladores suelen trabajar entre diversos lenguajes de programación, marcos y tecnologías. Esta interoperabilidad complica los contratos de mensajes y la fontanería necesaria para la comunicación multiplataforma. gRPC proporciona una "capa horizontal uniforme" que abstrae estas preocupaciones. Los desarrolladores crean código en su plataforma nativa centrada en la funcionalidad empresarial, mientras que gRPC controla la fontanería de la comunicación.

gRPC ofrece compatibilidad completa entre las pilas de desarrollo más populares, como Java, JavaScript, C#, Go, Swift y NodeJS.

Ventajas de gRPC

gRPC usa HTTP/2 como protocolo de transporte. Aunque es compatible con HTTP 1.1, HTTP/2 presenta muchas funcionalidades avanzadas:

• Un protocolo de trama binaria para el transporte de datos, a diferencia de HTTP 1.1, que se basa en texto.
• Compatibilidad con multiplexación para enviar varias solicitudes paralelas a través de la misma conexión: HTTP 1.1 limita el procesamiento a un mensaje de solicitud-respuesta a la vez.
• Comunicación bidireccional de dúplex completo para enviar tanto solicitudes de cliente como respuestas de servidor simultáneamente
• Streaming integrado que permite solicitudes y respuestas a flujos asincrónicos de grandes conjuntos de datos.
• Compresión de encabezados que reduce el uso de la red.

gRPC es ligero y de alto rendimiento. Puede ser hasta 8 veces más rápido que la serialización JSON con mensajes entre un 60 y un 80 % más pequeños. En la jerga de Microsoft Windows Communication Foundation (WCF), el rendimiento de gRPC supera la velocidad y eficacia de los enlaces NetTCP muy optimizados. A diferencia de NetTCP, que favorece la pila de Microsoft, gRPC es multiplataforma.

Búferes de protocolo

gRPC adopta una tecnología de código abierto denominada Búferes de protocolo. Estos búferes proporcionan un formato de serialización muy eficiente e independiente de la plataforma para serializar mensajes estructurados que los servicios se envían. Con un lenguaje de definición de interfaz (IDL) multiplataforma, los desarrolladores definen un contrato de servicio para cada microservicio. El contrato, implementado como un archivo .proto basado en texto, describe los métodos, las entradas y las salidas de cada servicio. El mismo archivo de contrato se puede usar para clientes y servicios gRPC creados en diferentes plataformas de desarrollo.

Con el archivo proto, el compilador Protobuf, protoc, genera código de cliente y servicio para la plataforma de destino. El código incluye los siguientes componentes:

• Objetos fuertemente tipados, compartidos por el cliente y el servicio, que representan las operaciones del servicio y los elementos de datos de un mensaje.
• Una clase base fuertemente tipada con la fontanería de red necesaria que el servicio gRPC remoto puede heredar y extender.
• Código auxiliar de cliente que contiene la fontanería necesaria para invocar el servicio gRPC remoto.

En tiempo de ejecución, cada mensaje se serializa como una representación de Protobuf estándar y se intercambia entre el cliente y el servicio remoto. A diferencia de JSON o XML, los mensajes de Protobuf se serializan como bytes binarios compilados.

Compatibilidad con gRPC en .NET

gRPC se integra en el SDK de .NET Core 3.0 y versiones posteriores. Las siguientes herramientas lo admiten:

• Visual Studio 2022 con la carga de trabajo ASP.NET y de desarrollo web instalada
• Visual Studio Code
• La CLI dotnet

El SDK incluye herramientas para el enrutamiento de puntos de conexión, IoC integrado y registro. El servidor web Kestrel de código abierto admite conexiones HTTP/2. En la figura 4-20 se muestra una plantilla de Visual Studio 2022 que aplica scaffolding a un proyecto esqueleto de un servicio gRPC. Tenga en cuenta que .NET es totalmente compatible con Windows, Linux y macOS.

Figura 4-20. Compatibilidad con gRPC en Visual Studio 2022

En la figura 4-21 se muestra el servicio gRPC esqueleto generado a partir del scaffolding integrado incluido en Visual Studio 2022.

Figura 4-21. Proyecto gRPC en Visual Studio 2022

En la ilustración anterior, anote el archivo de descripción proto y el código de servicio. Como verá en breve, Visual Studio genera una configuración adicional tanto en la clase Startup como en el archivo de proyecto subyacente.

Uso de gRPC

Preferencia de gRPC en los siguientes escenarios:

• Comunicación sincrónica de microservicio a microservicio de back-end donde se requiere una respuesta inmediata para continuar el procesamiento.
• Entornos políglotas que necesitan admitir plataformas de programación mixtas.
• Baja latencia y comunicación de alto rendimiento donde el rendimiento es crítico.
• Comunicación en tiempo real de punto a punto: gRPC puede insertar mensajes en tiempo real sin sondeo y tiene una excelente compatibilidad con el streaming bidireccional.
• Entornos restringidos de red: los mensajes binarios de gRPC siempre son más pequeños que un mensaje JSON basado en texto equivalente.

En el momento de redactar este documento, gRPC se usa principalmente con servicios back-end. Los exploradores modernos no pueden proporcionar el nivel de control HTTP/2 necesario para admitir un cliente gRPC de front-end. Dicho esto, hay compatibilidad con gRPC-Web con .NET que permite la comunicación gRPC desde aplicaciones basadas en explorador creadas con JavaScript o tecnologías Blazor WebAssembly. gRPC-Web permite que una aplicación gRPC de ASP.NET Core admita características de gRPC en aplicaciones de explorador:

• Clientes fuertemente tipados y generados por código
• Mensajes de Protobuf compactos
• Streaming de servidor

Implementación de gRPC

La arquitectura de referencia de microservicios, eShop on Containers, de Microsoft, muestra cómo implementar servicios gRPC en aplicaciones .NET. En la figura 4-22 se presenta la arquitectura de back-end.

Figura 4-22. Arquitectura de back-end para eShop en contenedores

En la ilustración anterior, observe cómo eShop adopta el patrón Back-end para front-end (BFF) mediante la exposición de varias puertas de enlace de API. Anteriormente en este capítulo se ha analizado el patrón BFF. Preste mucha atención al microservicio Aggregator (en gris) que se encuentra entre la puerta de enlace de API de Web-Shopping y los microservicios Shopping de back-end. Aggregator recibe una única solicitud de un cliente, la envía a varios microservicios, agrega los resultados y los envía de vuelta al cliente solicitante. Normalmente, estas operaciones requieren una comunicación sincrónica para generar una respuesta inmediata. En eShop, las llamadas de back-end desde Aggregator se realizan mediante gRPC, como se muestra en la figura 4-23.

Figura 4-23. gRPC en eShop en contenedores

La comunicación gRPC requiere componentes cliente y servidor. En la ilustración anterior, observe cómo Shopping Aggregator implementa un cliente gRPC. El cliente realiza llamadas gRPC sincrónicas (en rojo) a microservicios de back-end, cada uno de los cuales implementa un servidor gRPC. Tanto el cliente como el servidor aprovechan las ventajas de la fontanería de gRPC integrada del SDK de .NET. Los códigos auxiliares del lado cliente proporcionan la fontanería para invocar llamadas gRPC remotas. Los componentes del lado servidor proporcionan la fontanería gRPC que las clases de servicio personalizadas pueden heredar y consumir.

Los microservicios que exponen una comunicación API RESTful y gRPC requieren varios puntos de conexión para administrar el tráfico. Abriría un punto de conexión que escucha el tráfico HTTP para las llamadas RESTful y otro para las llamadas gRPC. El punto de conexión gRPC debe configurarse para el protocolo HTTP/2 necesario para la comunicación gRPC.

Aunque nos esforzamos por desacoplar microservicios con patrones de comunicación asincrónicos, algunas operaciones requieren llamadas directas. gRPC debe ser la opción principal para la comunicación sincrónica directa entre microservicios. Su protocolo de comunicación de alto rendimiento, basado en HTTP/2 y búferes de protocolo, lo convierte en una opción perfecta.

Pensando en el futuro

De cara al futuro, gRPC seguirá ganando adeptos para los sistemas nativos de la nube. Las ventajas de rendimiento y la facilidad de desarrollo son convincentes. Sin embargo, es probable que REST siga existiendo durante mucho tiempo. Destaca por las API expuestas públicamente y por motivos de compatibilidad con versiones anteriores.

AnteriorSiguiente