сравнение grpc и zeromq

• асинхронная связь req/res (inproc или удаленная) между узлами

Обе библиотеки допускают синхронную или асинхронную связь в зависимости от того, как реализовать связь. См. эту страницу для gRPC: http://www.grpc.io/docs/guides/concepts.html. В основном gRPC допускает типичный синхронный HTTP-запрос/ответ или двунаправленную потоковую передачу, подобную веб-сокету. Для 0mq вы можете настроить простое соединение REQ-REP, которое в основном представляет собой синхронный канал связи, или вы можете создать асинхронную топологию типа ROUTER-DEALER.

• гибкая маршрутизация сообщений

«Маршрутизация» по сути означает, что сообщение попадает от А к Б через некоего посредника. Это тривиально делается в 0mq, и существует ряд топологий, которые поддерживают подобные вещи (http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern). В gRPC такая же топология может быть создана с подключением типа «публикация-подписка» через поток. 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, чтобы проверить соединение. Это работает, но не так приятно. Опять же, вы можете настроить внешний интерфейс службы 0mq с помощью веб-сервера HTTP/1.1, с которого считывает балансировщик нагрузки.

• хорошо задокументированы

оба хорошо документированы. Документацию 0mq необходимо прочитать, чтобы полностью понять технологию, и она представляет собой более высокий уровень.

Вот большие отличия:

1. 0mq — это протокол TCP, тогда как gRPC — это HTTP с двоичной полезной нагрузкой.
2. 0mq требует, чтобы вы разработали протокол кадрирования (кадр 1 = версия, кадр 2 = полезная нагрузка и т. д.), в то время как большая часть этой работы выполняется за вас в gRPC.
3. gRPC прозрачно совместим с REST (https://github.com/grpc-ecosystem/grpc-gateway), тогда как для 0mq требуется приложение промежуточного программного обеспечения, если вы хотите поговорить с ним REST.
4. gRPC использует стандартные сертификаты tls x509 (например, веб-сайты), тогда как 0mq использует собственный протокол шифрования/аутентификации (http://curvezmq.org/). До 4.x в 0mq не было поддержки шифрования, и если вы действительно этого хотели, вам приходилось нырять в эту хрень: https://wiki.openssl.org/index.php/BIO. (поверь мне, не делай этого)
5. 0mq может создавать довольно нехорошие топологии (https://github.com/zeromq/majordomo) (https://rfc.zeromq.org/spec:7/MDP/), тогда как gRPC в основном клиент/сервер
6. 0mq требует гораздо больше времени для сборки и запуска, тогда как gRPC в основном компилирует сообщения protobuf и импортирует сервис в ваш код.

Не совсем то же самое. gRPC в первую очередь предназначен для взаимодействия гетерогенных сервисов, ZeroMQ (ZMQ/0MQ/ØMQ) — это платформа обмена сообщениями более низкого уровня. ØMQ не определяет сериализацию полезной нагрузки, кроме передачи двоичных больших двоичных объектов, тогда как gRPC по умолчанию выбирает протокольные буферы. ØMQ в значительной степени застрял на одной машине или машинах между центрами обработки данных/облаками, в то время как gRPC потенциально может работать и на реальном клиенте (т. е. на мобильном или веб-сайте, он уже поддерживает iOS). gRPC с использованием ØMQ может быть значительно быстрее и эффективнее для служб в облаке/центре обработки данных, чем накладные расходы, задержка и сложность цепочки запросов/ответов http2. Я не уверен, как (или даже если) gRPC защита TLS подходит для общедоступного облака и мобильного/веб-использования, но всегда можно внедрить сквозные требования безопасности (например, libsodium) на уровне маршрутизатора/контроллера среды приложения/приложения и запустить в режиме открытого текста (что также удалит Форк OpenSSL BoringSSL не вызывает головной боли при обслуживании из-за недостатков восходящего потока).

Для сервисов с очень высокой задержкой/низкой пропускной способностью (например, миссии на Марс) можно подумать о RPC с использованием транспорта, такого как SMTP (т. е. альтернативная репликация Active Directory) или MQTT (т. е. Facebook Messenger, ZigBee, SCADA).

Бонус (не по теме): было бы неплохо, если бы у gRPC были альтернативные подключаемые транспорты, такие как ØMQ (который также сам поддерживает сокеты UNIX, TCP, PGM и inproc), потому что HTTP/2 еще не стабилен на всех языках и медленнее, чем ØMQ. И стоит взглянуть на nanomsg (особенно в мире HFT), потому что его можно расширить с помощью RDMA/SDP/MPI и сделать безумно малой задержкой/нулевым копированием/готовым к Infiniband.