comparaison grpc et zeromq

Question

J'aimerais comparer en quelque sorte des capacités de grpc vs zeromq & ses motifs: et j'aimerais créer une certaine comparaison (ensemble de fonctionnalités) - en quelque sorte - 0mq est "mieux" sockets - mais de toute façon, si je l'applique 0mq modèles - je obtenir des données comparables 'cadres', je pense - et ici 0mq semble être beaucoup plus souple ...

Les principales exigences sont:

• async req / res communication (inproc ou distance) entre les nœuds
• flexible messages de routage
• l'équilibrage de la charge d'appui
• bien documenté

des idées?

merci!

Answer 1

• async req / res communication (inproc ou distance) entre les nœuds

Les deux bibliothèques de permettre synchrone ou asynchrone de la communication en fonction de la façon de mettre en œuvre la communication. Voir cette page pour gRPC: http://www.grpc.io/docs/guides/concepts.html. Fondamentalement gRPC permettre typique HTTP synchrone demande/réponse ou un "websocket-comme" bidirectionnel en streaming. Pour 0mq vous pouvez configurer un simple REQ-REP de connexion qui est essentiellement une communication synchrone chemin, ou vous pouvez créer async ROUTEUR-MARCHAND type de typologies.

• flexible messages de routage

'Routage' signifie essentiellement qu'un message passe de A à B par l'intermédiaire d'un courtier. C'est trivialement fait dans 0mq et il y a un certain nombre de typologies de soutien des trucs comme ça (http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern). Dans gRPC le même genre de typologie peut être créé avec une "pub-sub" comme connexion pendant un cours d'eau. gRPC prend en charge de mettre des métadonnées dans le message (https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) qui vous permettra de "route" avec un message dans une file d'attente "pub-sub" de la connexion pourrait tirer de.

• l'équilibrage de la charge d'appui

gRPC a un bilan de santé de soutien (https://github.com/grpc/grpc/blob/master/doc/health-checking.mdmais parce que c'est HTTP/2, vous devez avoir une adresse HTTP/2 programme d'équilibrage de charge à l'appui, le bilan de santé. Ce n'est pas un énorme big deal, cependant, parce que vous pouvez lier le bilan de santé de HTTP/1.1 service que l'équilibrage de la charge des appels. 0mq est une connexion tcp qui signifie qu'un programme d'équilibrage de charge serait probablement une prise connect " dans tcpmode pour vérifier la connexion. Cela fonctionne, mais c'est pas aussi beau. Encore une fois, vous pourriez obtenir slick et avant la fin de la 0mq avec un service de HTTP/1.1 serveur web que l'équilibrage de la charge de lit à partir de.

• bien documenté

les deux sont bien documentés. 0mq la documentation doit être lu pour pleinement comprendre la technologie et est plus élevé ascenseur.

Voici les grandes différences:

1. 0mq est un protocole tcp tandis que gRPC est HTTP avec un binaire de la charge utile.
2. 0mq nécessite la conception d'un protocole de tramage (image 1 = verison, image 2 = charge utile, etc.), alors que beaucoup de ce travail est fait pour vous tout au gRPC
3. gRPC est transparente coverted de REPOS (https://github.com/grpc-ecosystem/grpc-gateway) alors que 0mq nécessite un intergiciel, si vous voulez parler de REPOS pour elle.
4. gRPC utilise la norme tls certificats x509 (pensez à des sites web) alors que 0mq utilise un cryptage personnalisé/(protocole d'authentificationhttp://curvezmq.org/). Avant 4.x il n'y a pas de prise en charge du cryptage dans 0mq et si tu le voulais vraiment, il fallait plonger dans cette merde: https://wiki.openssl.org/index.php/BIO. (faites-moi confiance, ne le font pas)
5. 0mq peut créer certains très malade typologies (https://github.com/zeromq/majordomo) (https://rfc.zeromq.org/spec:7/MDP/) alors que gRPC est fondamentalement client/serveur
6. 0mq nécessite beaucoup plus de temps à construire et à faire fonctionner alors que gRPC est fondamentalement la compilation d'un protobuf des messages et de l'importation du service dans votre code.

Answer 2

Pas tout à fait la même. gRPC est essentiellement hétérogène pour l'interopérabilité des services, ZeroMQ (ZMQ/0MQ/ØMQ) est d'un niveau inférieur de messagerie cadre. ØMQ ne spécifie pas la charge utile de sérialisation delà de l'adoption de blobs binaires alors que gRPC choisit Tampons de Protocole par défaut. ØMQ est un peu coincé sur la même machine ou des machines entre les centres de données/les nuages, tandis que gRPC pourrait éventuellement travailler sur un client réel trop (ie mobile ou web, elle prend déjà en charge d'iOS). gRPC à l'aide de ØMQ pourrait être nettement plus rapide et plus efficace dans le cloud/-datacenter services de la surcharge, de la latence et de la complexité de http2 de demande/réponse de la chaîne. Je ne suis pas sûr de savoir comment (ou même si) gRPC sécurité TLS est adéquat pour le public, le cloud et le mobile/l'utilisation du web, mais on pouvait toujours injecter de bout en bout les exigences de sécurité (c'est à dire libsodium) au niveau du routeur/contrôleur de niveau de l'application/application du cadre et de l'exécuter en mode texte brut (ce qui permettrait également de supprimer OpenSSL fourche BoringSSL de provoquer l'entretien des maux de tête en raison de défauts en amont).

Pour une latence très élevée / faible bande passante des services (c'est à dire mission to mars), on pense RPC à l'aide d'un transport comme SMTP (c'est à dire Active Directory suppléant de la réplication) ou MQTT (ie Facebook Messenger, ZigBee, SCADA)

Bonus (hors-sujet): Ce serait bien si gRPC disposait d'autres enfichable transports comme ØMQ (qui d'ailleurs lui-même prend en charge les sockets UNIX, TCP, PGM et inproc), parce que HTTP/2 n'est pas stable dans toutes les langues, et il est plus lent que ØMQ. Et, il vaut la peine de regarder nanomsg (en particulier dans le HFT monde), car il pourrait être étendu avec RDMA/SDP/MPI et rendus fous à faible latence/zéro-copie/Infiniband-prêt.