Ответ 1
- связь async req/res (inproc или remote) между узлами
Обе библиотеки допускают синхронную или асинхронную связь в зависимости от того, как реализовать связь. См. Эту страницу для gRPC: http://www.grpc.io/docs/guides/concepts.html. В основном gRPC позволяет использовать типичный HTTP-синхронный запрос/отклик или двунаправленную поточную передачу, похожую на websocket. Для 0mq вы можете настроить простое соединение REQ-REP, которое в основном представляет собой синхронный путь связи, или вы можете создать типовые типы async ROUTER-DEALER.
- маршрутизация гибких сообщений
"Маршрутизация" по сути означает, что сообщение получает от A до B через какого-либо брокера. Это тривиально сделано в 0mq, и существует ряд типологий, которые поддерживают такие вещи (http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern). В gRPC можно создать такую же типологию с соединением "pub-sub" как поток по потоку. gRPC поддерживает размещение метаданных в сообщении (https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md), что позволит вам "маршрутизировать" сообщение в очередь, чтобы" pub-sub 'соединение может тянуть.
- поддержка балансировки
gRPC имеет поддержку проверки работоспособности (https://github.com/grpc/grpc/blob/master/doc/health-checking.md), но из-за того, что для HTTP/2 вам понадобится загрузка HTTP/2 балансировщик для поддержки проверки работоспособности. Однако это не очень большое дело, потому что вы можете связать проверку работоспособности с сервисом HTTP/1.1, который вызывает балансировка нагрузки. 0mq - это tcp-соединение, что означает, что балансировщик нагрузки, скорее всего, проверит соединение "сокет" в tcpmode, чтобы проверить соединение. Это работает, но это не так приятно. Снова вы можете получить slick и front-end службу 0mq с веб-сервером HTTP/1.1, с которого считывает балансировщик.
- хорошо документировано
оба документа хорошо документированы. 0mq документация должна быть прочитана, чтобы наглядно понять технологию и более высокий подъем.
Здесь большие отличия:
- 0mq - протокол tcp, тогда как gRPC - это HTTP с бинарной полезной нагрузкой.
- 0mq requries вы разрабатываете протокол кадрирования (кадр 1 = verison, frame 2 = полезная нагрузка и т.д.), тогда как большая часть этой работы выполняется для вас в gRPC
- gRPC прозрачно закрывается для REST (https://github.com/grpc-ecosystem/grpc-gateway), тогда как 0mq требует приложения промежуточного программного обеспечения, если вы хотите поговорить с REST.
- gRPC использует стандартные сертификаты tls x509 (думаю, сайты), тогда как 0mq использует собственный протокол шифрования/аутентификации (http://curvezmq.org/). До 4.x не было поддержки шифрования в 0mq, и если вы действительно этого хотели, вам пришлось погрузиться в это дерьмо: https://wiki.openssl.org/index.php/BIO. (поверьте мне, не делайте этого)
- 0mq может создавать некоторые довольно больные типологии (https://github.com/zeromq/majordomo) (https://rfc.zeromq.org/spec:7/MDP/), тогда как gRPC - это в основном клиент/сервер
- 0mq требует гораздо больше времени для создания и запуска, тогда как gRPC в основном компилирует сообщения protobuf и импортирует сервис в ваш код.