protobuf frente a gRPC


101

Intento entender protobuf y gRPC y cómo puedo usar ambos. ¿Podría ayudarme a comprender lo siguiente?

  • Teniendo en cuenta el modelo OSI, ¿dónde está, por ejemplo, Protobuf en la capa 4?
  • Pensando en la transferencia de un mensaje, ¿cómo es el "flujo", qué hace gRPC y qué falla el protobuf?
  • Si el remitente usa protobuf, ¿puede el servidor usar gRPC o gRPC agrega algo que solo un cliente de gRPC puede entregar?
  • Si gRPC puede hacer posible la comunicación sincrónica y asincrónica, Protobuf es solo para la clasificación y, por lo tanto, no tiene nada que ver con el estado: ¿verdadero o falso?
  • ¿Puedo usar gRPC en una aplicación de interfaz que se comunique en lugar de REST o GraphQL?

Ya sé, o supongo que sí, que:

Protobuf

  • Protocolo binario para intercambio de datos
  • Diseñado por Google
  • Utiliza una descripción similar a "Struct" generada en el cliente y el servidor para un - / - mensaje de marshall

gRPC

  • Utiliza protobuf (v3)
  • De nuevo de Google
  • Marco para llamadas RPC
  • También hace uso de HTTP / 2
  • Posibilidad de comunicación síncrona y asíncrona

De nuevo, asumo que es una pregunta fácil para alguien que ya usa la tecnología. Todavía le agradecería que tuviera paciencia conmigo y me ayudara. También estaría muy agradecido por cualquier análisis profundo de las tecnologías en la red.

Respuestas:


85

Los búferes de protocolo son (¿son?) Un lenguaje de definición de interfaz y una biblioteca de serialización:

  • Usted define sus estructuras de datos en su IDL, es decir, describe los objetos de datos que desea utilizar.
  • Proporciona rutinas para traducir sus objetos de datos hacia y desde binarios, por ejemplo, para escribir / leer datos desde el disco

gRPC usa el mismo IDL pero agrega la sintaxis "rpc" que le permite definir firmas de método de llamada a procedimiento remoto usando las estructuras de datos de Protobuf como tipos de datos:

  • Tú defines tus estructuras de datos
  • Agrega las definiciones de su método rpc
  • Proporciona código para servir y llamar a las firmas de métodos a través de una red.
  • Aún puede serializar los objetos de datos manualmente con Protobuf si necesita

En respuesta a las preguntas:

  1. gRPC funciona en las capas 5, 6 y 7. Protobuf funciona en la capa 6.
  2. Cuando dice "transferencia de mensajes", Protobuf no se preocupa por la transferencia en sí. Solo funciona en cualquier extremo de cualquier transferencia de datos, convirtiendo bytes en objetos
  3. El uso de gRPC de forma predeterminada significa que está utilizando Protobuf . Puede escribir su propio cliente que use Protobuf pero no gRPC para interoperar con gRPC, o agregar otros serializadores a gRPC, pero usar gRPC sería más fácil
  4. Cierto
  5. sí tu puedes

¿Pueden decirme de qué "capas" están hablando ustedes? Por favor, dame un enlace para comprender este concepto en detalle. Gracias.
Millie Hudson

Es el modelo OSI: se agregó un enlace en la pregunta. Es discutible si gRPC pertenece a las capas 5 y 6 porque usa un protocolo de capa 7 ( HTTP/2), pero definitivamente hace el trabajo de esas capas.
Peter Wishart

67

En realidad, gRPC y Protobuf son dos cosas completamente diferentes. Déjame simplificar:

  • gRPC administra la forma en que un cliente y un servidor pueden interactuar (como un cliente / servidor web con una API REST)
  • protobuf es solo una herramienta de serialización / deserialización (como JSON)

gRPC tiene 2 lados: un lado del servidor y un lado del cliente, que puede marcar un servidor. El servidor expone RPC (es decir, funciones a las que puede llamar de forma remota). Y tiene muchas opciones allí: puede asegurar la comunicación (usando TLS), agregar una capa de autenticación (usando interceptores), ...

Puede usar protobuf dentro de cualquier programa, que no necesita ser cliente / servidor. Si necesita intercambiar datos y desea que estén fuertemente tipados, protobuf es una buena opción (rápida y confiable).

Dicho esto, puede combinar ambos para construir un buen sistema cliente / servidor: gRPC será su código cliente / servidor y protobuf su protocolo de datos.

PD: escribí este artículo para mostrar cómo se puede construir un cliente / servidor con gRPC y protobuf usando Go, paso a paso.


3
Gracias, esto me ayuda a implementar una muestra.
lony

7

grpc es un framework creado por Google y se utiliza en proyectos de producción de Google y #HyperledgerFabric está construido con grpc hay muchas aplicaciones de código abierto creadas con grpc

protobuff es una representación de datos como json, esto también es de google, de hecho, tienen algunos miles de archivos proto que se generan en sus proyectos de producción

grpc

  • gRPC es un marco de código abierto desarrollado por Google
  • Nos permite crear Solicitud y respuesta para RPC y manejar el resto por el marco.
  • REST está orientado a CRUD pero grpc está orientado a API (sin restricciones)
  • Construir sobre HTTP / 2
  • Proporciona >>>>> Auth, Loadbalancing, Monitoring, logging
  • [HTTP / 2]
    • HTTP1.1 se lanzó en 1997 hace mucho tiempo
    • HTTP1 abre una nueva conexión TCP a un servidor en cada solicitud
    • No comprime encabezados
    • SIN servidor push, solo funciona con Req, Res
    • HTTP2 lanzado en 2015 (SPDY)
    • Soporta multiplexación
    • el cliente y el servidor pueden enviar mensajes en paralelo a través de la misma conexión TCP
    • Reduce enormemente la latencia
    • HTTP2 admite la compresión de encabezados
    • HTTP2 es binario
      • proto buff es binario, por lo que es una gran combinación para HTTP2
  • [TIPOS]
    • Unario
    • streaming de cliente
    • transmisión del servidor
    • Transmisión bidireccional
    • Los servidores grpc son Async por defecto
    • Los clientes de grpc pueden ser sincronizados o asincrónicos

protobuff

  • Los búferes de protocolo son independientes del idioma
  • El análisis de búferes de protocolo (formato binario) consume menos CPU
  • [Naming]
    • Utilice mayúsculas y minúsculas para los nombres de los mensajes
    • subrayado_separado para campos
    • Utilice camelcase para Enums y CAPITAL_WITH_UNDERSCORE para nombres de valores
  • [Comentarios]
    • Soporte //
    • Soporte / * * /
  • [Ventajas]
    • Los datos están completamente escritos
    • Los datos están completamente comprimidos (menos uso de ancho de banda)
    • Se necesita un esquema (mensaje) para generar código y leer el código
    • La documentación se puede incrustar en el esquema
    • Los datos se pueden leer en cualquier idioma
    • El esquema puede evolucionar en cualquier momento de manera segura
    • más rápido que XML
    • el código se genera automáticamente
    • Google inventó el proto buff, usan 48000 mensajes protobuf y 12000 archivos .proto
    • Muchos marcos de RPC, incluido grpc, usan búferes de protocolo para intercambiar datos

3
La compresión NO reduce el uso de la CPU. Tiene que comprimirlo y descomprimirlo para enviar o usar los datos en la serialización, lo que quema la CPU HACIENDO eso. Lo que la compresión hace por usted es reducir la huella serializada, reducir la presión potencial de la memoria, el uso del disco si se usa para serializar a disco, o más la señalización por cable.
Svartalf

@Svartalf editó para corregir esto. ¡Gracias por mencionarlo!
swrobel
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.