¿Qué es gRPC? Buffers de protocolo, transmisión y arquitectura explicadas

gRPC es un marco poderoso para trabajar con llamadas a procedimiento remoto. Los RPC le permiten escribir código como si fuera a ejecutarse en una computadora local, aunque se pueda ejecutar en otra computadora.

Estos últimos días me he sumergido profundamente en gRPC. Voy a compartir algunos de mis grandes descubrimientos aquí en este artículo.

Tenga en cuenta que me centraré más en conceptos que en detalles de implementación. Aprenderá la arquitectura central de gRPC en sí. También aprenderá:

  • Por qué los desarrolladores utilizan tanto gRPC
  • Cómo funciona tan bien
  • Y cómo funciona todo bajo el capó.

Retrocedamos un poco

Antes de apresurarnos a gRPC, deberíamos echar un vistazo a lo que son las llamadas a procedimiento remoto .

Un RPC es una forma de comunicación cliente-servidor que utiliza una llamada de función en lugar de una llamada HTTP habitual.

Utiliza IDL (lenguaje de definición de interfaz) como una forma de contrato sobre las funciones a llamar y sobre el tipo de datos.

Si todavía no se han dado cuenta, el RPC en gRPC significa llamada a procedimiento remoto. Y sí, gRPC replica este estilo arquitectónico de comunicación cliente-servidor, a través de llamadas a funciones.

Entonces, técnicamente, gRPC no es un concepto nuevo. Más bien se adoptó de esta vieja técnica y se mejoró, haciéndola muy popular en tan solo 5 años.

Descripción general de gRPC

En 2015, Google abrió su proyecto de código abierto que eventualmente sería el llamado gRPC. Pero, ¿qué significa realmente la "g" en gRPC?

Mucha gente podría asumir que es para Google porque Google lo creó, pero no es así.

Google cambia el significado de la "g" para cada versión hasta el punto en que incluso hicieron un README para enumerar todos los significados.

Desde que se introdujo gRPC, ha ganado bastante popularidad y muchas empresas lo utilizan.

¿Qué hace que gRPC sea tan popular?

Hay muchas razones por las que gRPC es tan popular:

  • La abstracción es fácil (es una llamada a función)
  • Es compatible con muchos idiomas.
  • Es muy eficaz
  • Las llamadas HTTP suelen ser confusas, por lo que esto lo hace más fácil

Y aparte de todas las razones anteriores, gRPC es popular porque los microservicios son muy populares.

Los microservicios a menudo ejecutarán varios servicios en diferentes lenguajes de programación. También suelen tener una gran cantidad de interacciones de servicio a servicio.

Aquí es donde gRPC ayuda más al proporcionar el soporte y la capacidad para resolver los problemas típicos que surgen de esas situaciones.

gRPC es muy popular en llamadas de servicio a servicio, ya que a menudo las llamadas HTTP son más difíciles de entender a primera vista.

Las funciones de gRPC son mucho más fáciles de razonar, por lo que los desarrolladores no tienen que preocuparse por escribir mucha documentación porque el código en sí debería explicarlo todo.

Algunos de los servicios también pueden estar escritos en diferentes idiomas y gRPC viene con múltiples bibliotecas para admitirlo.

El rendimiento es la cereza en la parte superior, y es una gran cereza.

Arquitectura gRPC

He mencionado varias veces que el rendimiento de gRPC es muy bueno, pero quizás te preguntes qué lo hace tan bueno. ¿Qué hace que gRPC sea mucho mejor que RPC cuando sus diseños son bastante similares?

Aquí hay algunas diferencias clave que hacen que gRPC sea tan eficaz.

HTTP / 2

HTTP ha estado con nosotros durante mucho tiempo. Ahora, casi todos los servicios de backend usan este protocolo.

Como muestra la imagen de arriba, HTTP / 1.1 se mantuvo relevante durante mucho tiempo.

Luego, en 2015, salió HTTP / 2 y esencialmente reemplazó a HTTP / 1.1 como el protocolo de transporte más popular en Internet.

Si recuerdas que 2015 también fue el año en que salió gRPC, no fue una coincidencia en absoluto. HTTP / 2 también fue creado por Google para ser utilizado por gRPC en su arquitectura.

HTTP / 2 es una de las principales razones por las que gRPC puede funcionar tan bien. Y en la siguiente sección, verá por qué.

Multiplexación de solicitud / respuesta

En un protocolo HTTP tradicional, no es posible enviar múltiples solicitudes u obtener múltiples respuestas juntas en una sola conexión. Será necesario crear una nueva conexión para cada uno de ellos.

Este tipo de multiplexación de solicitud / respuesta es posible en HTTP / 2 con la introducción de una nueva capa HTTP / 2 denominada trama binaria.

Esta capa binaria encapsula y codifica los datos. En esta capa, la solicitud / respuesta HTTP se divide en marcos.

El marco de encabezados contiene información típica de encabezados HTTP y el marco de datos contiene la carga útil. Con este mecanismo, es posible tener datos de múltiples solicitudes en una sola conexión.

Esto permite cargas útiles de múltiples solicitudes con el mismo encabezado, identificándolo como una sola solicitud.

Compresión de encabezado

Es posible que haya encontrado muchos casos en los que los encabezados HTTP son incluso más grandes que la carga útil. Y HTTP / 2 tiene una estrategia muy interesante llamada HPack para manejar eso.

Por un lado, todo en HTTP / 2 se codifica antes de enviarse, incluidos los encabezados. Esto ayuda con el rendimiento, pero eso no es lo más importante de la compresión de encabezados.

HTTP / 2 mapea el encabezado tanto en el lado del cliente como en el del servidor. A partir de eso, HTTP / 2 puede saber si el encabezado contiene el mismo valor y solo envía el valor del encabezado si es diferente del encabezado anterior.

Como se ve en la imagen de arriba, la Solicitud # 2 solo enviará la ruta ya que los otros valores son exactamente los mismos. Y sí, esto reduce mucho el tamaño de la carga útil y, a su vez, mejora aún más el rendimiento de HTTP / 2.

Búfer de protocolo, también conocido como Protobuf

Protobuf es el IDL (lenguaje de definición de interfaz) más utilizado para gRPC. Es donde básicamente almacena sus datos y contratos de funciones en forma de un archivo proto.

message Person { required string name = 1; required int32 id = 2; optional string email = 3; }

Como se trata de un contrato, tanto el cliente como el servidor deben tener el mismo archivo proto. El archivo proto actúa como contrato intermediario para que el cliente llame a cualquier función disponible desde el servidor.

Protobuf también tiene sus propios mecanismos, a diferencia de una API REST habitual que solo envía cadenas de JSON como bytes. Estos mecanismos permiten que la carga útil sea mucho más pequeña y permiten un rendimiento más rápido.

El método de codificación que usa Protobuf es bastante complicado. Si desea profundizar en cómo funciona, consulte esta documentación completa.

¿Qué más ofrece gRPC?

estrellas en el cielo

Ahora debería tener un conocimiento básico de la arquitectura de gRPC, cómo funciona y de qué es capaz.

Pero aquí hay algunas otras cosas interesantes que nos ofrece gRPC.

Metadatos

En lugar de utilizar un encabezado de solicitud HTTP habitual, gRPC tiene algo llamado metadatos. Los metadatos son un tipo de datos clave-valor que se pueden configurar desde el lado del cliente o del servidor.

Headerpueden asignarse desde el lado del cliente, mientras que los servidores pueden asignar Headery Trailerssiempre que ambos estén en forma de metadatos.

Transmisión

La transmisión es uno de los conceptos centrales de gRPC donde pueden suceder varias cosas en una sola solicitud. Esto es posible gracias a la capacidad de multiplexación de HTTP / 2 mencionada anteriormente.

Hay varios tipos de transmisión:

  • Server Streaming RPC: donde el cliente envía una sola solicitud y el servidor puede devolver múltiples respuestas. Por ejemplo, cuando un cliente envía una solicitud para una página de inicio que tiene una lista de varios elementos, el servidor puede enviar respuestas por separado, lo que permite al cliente utilizar la carga diferida.
  • Client Streaming RPC: donde el cliente envía múltiples solicitudes y el servidor solo envía una única respuesta. Por ejemplo, un zip / fragmento cargado por el cliente.
  • RPC de transmisión bidireccional: donde tanto el cliente como el servidor se envían mensajes entre sí al mismo tiempo sin esperar una respuesta.

Interceptores

gRPC admite el uso de interceptores para su solicitud / respuesta. Interceptores, bueno, interceptan mensajes y te permiten modificarlos.

¿Te suena familiar? Si ha jugado con los procesos HTTP en una API REST, los interceptores son muy similares al middleware.

Las bibliotecas de gRPC generalmente admiten interceptores y permiten una implementación sencilla. Los interceptores se suelen utilizar para:

  • Modifique la solicitud / respuesta antes de pasarla. Se puede utilizar para proporcionar información obligatoria antes de enviarse al cliente / servidor.
  • Le permite manipular cada llamada de función, como agregar registros adicionales para rastrear el tiempo de respuesta.

Balanceo de carga

Si aún no está familiarizado con el equilibrio de carga, es un mecanismo que permite que las solicitudes de los clientes se distribuyan en varios servidores.

Pero el equilibrio de carga generalmente se realiza a nivel de proxy (por ejemplo, NGINX). Entonces, ¿por qué estoy hablando de eso aquí?

Resulta que gRPC admite un método de equilibrio de carga por parte del cliente. Ya está implementado en la biblioteca Golang y se puede usar con facilidad.

Si bien puede parecer una especie de magia loca, no lo es. Hay algún tipo de resolución de DNS para obtener una lista de IP y un algoritmo de equilibrio de carga bajo el capó.

Cancelación de llamada

Los clientes de gRPC pueden cancelar una llamada de gRPC cuando ya no necesita una respuesta. Sin embargo, la reversión en el lado del servidor no es posible.

Esta función es especialmente útil para la transmisión del lado del servidor donde pueden llegar múltiples solicitudes de servidor. La biblioteca gRPC viene equipada con un patrón de método de observador para saber si una solicitud se cancela y permitirle cancelar múltiples solicitudes correspondientes a la vez.

Terminando

Perdido en el espacio y el tiempo

Todo lo que compartí hoy solo rasca la superficie de lo que es gRPC, de lo que es capaz y aproximadamente cómo funciona.

Realmente espero que este artículo te haya ayudado a comprender más sobre gRPC. Pero todavía hay mucho más por aprender, ¡así que no te detengas aquí! Sigue cavando.

¡Gracias por leer!