zeromq messaging grpc

comparsion grpc y zeromq



messaging (2)

Me gustaría comparar de alguna manera las capacidades de grpc contra zeromq y sus patrones: y me gustaría crear un poco de comparsion (conjunto de características) - de alguna manera - 0mq es "mejor" sockets - pero de todos modos - si aplico 0mq patrones - Consigo ''marcos'' comparables, creo, y aquí 0mq parece ser mucho más flexible ...

Los principales requisitos son:

  • Comunicación async req / res (inproc o remote) entre nodos
  • enrutamiento de mensajes flexibles
  • soporte de equilibrio de carga
  • bien documentada

¿algunas ideas?

¡Gracias!

No es exactamente lo mismo. gRPC es principalmente para la interoperabilidad de servicios heterogéneos, ZeroMQ (ZMQ / 0MQ / ØMQ) es un marco de mensajería de nivel inferior. ØMQ no especifica la serialización de la carga útil más allá de pasar blobs binarios, mientras que gRPC elige los búferes de protocolo de forma predeterminada. ØMQ está bastante atascado en la misma máquina o máquinas entre los centros de datos / nubes, mientras que gRPC también podría funcionar en un cliente real (es decir, móvil o web, ya es compatible con iOS). gRPC usando ØMQ podría ser significativamente más rápido y más eficiente para los servicios en la nube / centro de datos que la sobrecarga, la latencia y la complejidad de la cadena de solicitud / respuesta http2. No estoy seguro de cómo (o incluso si) la seguridad de gRPC TLS es adecuada para el uso de la nube pública y móvil / web, pero siempre se podrían inyectar requisitos de seguridad de extremo a extremo (es decir, libsodium) en el nivel del enrutador / controlador de la aplicación. / app framework y se ejecuta en modo de texto simple (lo que también eliminaría a OpenSSL fork BoringSSL de causar problemas de mantenimiento debido a fallas en el proceso).

Para servicios de latencia muy alta / ancho de banda bajo (es decir, misión a mars), se podría pensar en RPC usando un transporte como SMTP (es decir, replicación alternativa de Active Directory) o MQTT (es decir, Facebook Messenger, ZigBee, SCADA)

Bono (fuera de tema): sería bueno si gRPC tuviera transportes enchufables alternativos como ØMQ (que también admite sockets UNIX, TCP, PGM e inproc), porque HTTP / 2 no es estable en todos los idiomas todavía y es más lento que ØMQ. Y vale la pena mirar nanomsg (especialmente en el mundo HFT) porque podría extenderse con RDMA / SDP / MPI y convertirse en una locura de baja latencia / copia cero / Infiniband-ready.

  • Comunicación async req / res (inproc o remote) entre nodos

Ambas bibliotecas permiten la comunicación síncrona o asíncrona dependiendo de cómo implementar la comunicación. Consulte esta página para gRPC: http://www.grpc.io/docs/guides/concepts.html . Básicamente, gRPC permite una solicitud / respuesta síncrona HTTP típica o una transmisión bidireccional "tipo websocket". Para 0mq puede configurar una conexión REQ-REP simple que es básicamente una ruta de comunicación sincrónica, o puede crear tipologías de tipo ROUTER-DEALER asíncronas.

  • enrutamiento de mensajes flexibles

''Enrutamiento'' significa esencialmente que un mensaje se envía de A a B a través de algún intermediario. Esto se hace de forma trivial en 0mq y hay varias tipologías que admiten este tipo de cosas ( http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern ) En gRPC, se podría crear el mismo tipo de tipología con una conexión tipo ''pub-sub'' a través de un flujo. gRPC admite poner metadatos en el mensaje ( https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md ) que le permitirá "enrutar" un mensaje en una cola que un '' La conexión de pub-sub podría arrancar.

  • soporte de equilibrio de carga

gRPC tiene un soporte de comprobación de estado ( https://github.com/grpc/grpc/blob/master/doc/health-checking.md ) pero como HTTP / 2 tendría que tener un equilibrador de carga HTTP / 2 para apoyar el chequeo de salud. Sin embargo, esto no es un gran problema, ya que puede vincular la comprobación de estado a un servicio HTTP / 1.1 al que llama el equilibrador de carga. 0mq es una conexión tcp, lo que significa que un equilibrador de carga probablemente compruebe un ''socket socket'' en tcpmode para verificar la conexión. Esto funciona pero no es tan bonito. Nuevamente, podría obtener un servicio impecable y el servicio de 0 mq con un servidor web HTTP / 1.1 desde el que lee el equilibrador de carga.

  • bien documentada

ambos están bien documentados. La documentación de 0mq debe leerse para comprender completamente la tecnología y es más bien una elevación más alta.

Aquí están las grandes diferencias:

  1. 0mq es un protocolo tcp mientras que gRPC es HTTP con una carga útil binaria.
  2. Requerimientos de 0mq usted diseña un protocolo de trama (trama 1 = versión, trama 2 = carga útil, etc.), mientras que gran parte de este trabajo se realiza para usted en gRPC
  3. gRPC está cubierto transparente a REST ( https://github.com/grpc-ecosystem/grpc-gateway ), mientras que 0mq requiere una aplicación de middleware si desea hablar REST.
  4. gRPC usa certificados tls x509 estándar (piense en sitios web) mientras que 0mq usa un protocolo de cifrado / autenticación personalizado ( http://curvezmq.org/ ). Antes de 4.x no había soporte de cifrado en 0mq y si realmente lo querías, tenías que sumergirte en esta mierda: https://wiki.openssl.org/index.php/BIO . (confía en mí, no lo hagas)
  5. 0mq puede crear algunas tipologías bastante enfermas ( https://github.com/zeromq/majordomo ) ( https://rfc.zeromq.org/spec:7/MDP/ ) mientras que gRPC es básicamente cliente / servidor
  6. 0mq requiere mucho más tiempo para compilar y ejecutar, mientras que gRPC básicamente compila mensajes protobuf e importa el servicio a su código.