Мне бы хотелось как-то сравнить возможности grpc vs. zeromq и его шаблонов: и я хотел бы создать некоторый набор (набор функций) - так или иначе - 0mq - это "лучшие" сокеты, но в любом случае - если я применил 0mq Я считаю, что сопоставимые "рамки" я думаю - и здесь 0mq кажется намного более гибким...
Основные требования:
любые идеи?
спасибо!
Обе библиотеки допускают синхронную или асинхронную связь в зависимости от того, как реализовать связь. См. Эту страницу для 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 документация должна быть прочитана, чтобы наглядно понять технологию и более высокий подъем.
Здесь большие отличия:
Не совсем то же самое. gRPC в первую очередь для гетерогенной совместимости сервисов, ZeroMQ (ZMQ/0MQ/ØMQ) - это платформа обмена сообщениями более низкого уровня. ØMQ не указывает сериализацию полезной нагрузки, кроме передачи двоичных blob, тогда как gRPC по умолчанию выбирает Buffer протокола. ØMQ довольно сильно застрял на одной машине или машинах между центрами данных/облаками, тогда как gRPC потенциально может работать и на реальном клиенте (например, мобильный или веб-интерфейс, он уже поддерживает iOS). gRPC с использованием ØMQ может быть значительно быстрее и эффективнее для служб "облако" / "центра данных", чем накладные расходы, задержка и сложность цепочки запросов/ответов http2. Я не уверен, как (или даже если) gRPC TLS security является адекватным для общего облачного и мобильного/веб-использования, но всегда можно вводить конец (т.е. libsodium) на уровне маршрутизатора/контроллера в структуре приложения/приложения и работать в режиме открытого текста (что также приведет к удалению OpenSSL fork 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-ready.