Comments 8
Добавлю несколько любопытных ссылок:
stackoverflow.com/questions/731233/activemq-or-rabbitmq-or-zeromq-or
github.com/nanomsg/nanomsg
github.com/zeromq/malamute
stackoverflow.com/questions/731233/activemq-or-rabbitmq-or-zeromq-or
github.com/nanomsg/nanomsg
github.com/zeromq/malamute
Все выглядит красиво ровно до выхода приложения в прод.
Я говорю не о вашем коде, а о некоторых концептуальных вещах в самой библиотеке, которые сами разработчики править даже не собираются.
Первое, что нужно продукту при выходе в прод — мониторинг, желательно всего и вся, чтобы потом не было мучительно больно.
И вот на этом этапе у ZMQ все не так хорошо, как казалось бы:
Что в итоге
Библиотека просто отлична для прототипирования проекта и для быстрой разработки PoC-решений.
В проде тоже, в общем-то, жизнеспособна, за вычетом того, что подводных камней количество немалое.
Если опыта работы с ZMQ мало, а в прод пустить хочется, то готовьтесь к веселому дебагу по ночам, а лучше подумайте еще раз.
Если опыт есть — почему бы и нет, зато хорошо прокачаете скилл построения протоколов без потерь сообщений; термины heartbeat, «нумерация пакетов», распределение нагрузки и масштабирование больше не будут пустыми звуками, а резюме будет выглядеть куда круче :)
ЗЫ: Меня зовут Денис и яалкоголик с ZMQ в проде больше двух лет.
Я говорю не о вашем коде, а о некоторых концептуальных вещах в самой библиотеке, которые сами разработчики править даже не собираются.
Первое, что нужно продукту при выходе в прод — мониторинг, желательно всего и вся, чтобы потом не было мучительно больно.
И вот на этом этапе у ZMQ все не так хорошо, как казалось бы:
- Узнать состояние сооединения с клиентом/другим сервисом через API библиотеки невозможно. Эта информация скрыта от пользователя by design. Отлаживать проблемы связи между компонентами вашего приложения, особенно если оно немаленькое и компонентов сильно больше двух, становится задачей нетривиальной
- Точно так же скрыта от разработчика информация об количестве сообщений в очередях получения/отправки IO-процессов. Благодаря этому даже мягко (gracefully) завершить процесс не получится, т.к. приложение не знает, все ли входящие сообщения уже обработаны и все ли исходящие отправлены. И если с входящей очередью можно разобраться алгоритмически, добавив пару-тройку сервисных сообщений между сервисами, то с исходящей очередью все плохо.
- Продолжение предыдущего пункта — невозможно закрыть соединение с другими сервисами. Никак. ZMQ решает это за вас, и считает что при этом умнее. Как показывает практика, не всегда
- А если соединение все-таки закрылось, даже самым похабным образом (exit(1), die, etc) — вторая сторона об этом никогда не узнает, и будет дальше слать сообщения (которые дропнутся на выходе из приложения-отправителя, молча — ZMQ умный же), или ждать ответа от помершего сервиса. Единственный метод решения — повальный heartbeat между сервисами.
- ZMQ_IDENTITY. Еще одна замечательная опция от создателей ZMQ. Честно идентифицирует отправителя, но если вы решили использовать её для адреса сервиса в кластере, то это зря. Если ваш сервис по какой-то причине решит помереть, а потом восстать из пепла (банально — при обновлении версии софта), после чего представится старым идентом и будет ждать сообщений, то получит он шиш. Ибо ZMQ умный же, да. Единственное, что поможет в такой ситуации — рестарт всех сервисов, которые сотрудничали с перезапущенным, что в реальной жизни значит рестарт всего кластера.
Что в итоге
Библиотека просто отлична для прототипирования проекта и для быстрой разработки PoC-решений.
В проде тоже, в общем-то, жизнеспособна, за вычетом того, что подводных камней количество немалое.
Если опыта работы с ZMQ мало, а в прод пустить хочется, то готовьтесь к веселому дебагу по ночам, а лучше подумайте еще раз.
Если опыт есть — почему бы и нет, зато хорошо прокачаете скилл построения протоколов без потерь сообщений; термины heartbeat, «нумерация пакетов», распределение нагрузки и масштабирование больше не будут пустыми звуками, а резюме будет выглядеть куда круче :)
ЗЫ: Меня зовут Денис и я
Полностью согласен. Посему и написал just-for-fun) На работе все-таки используется IBM/Tibco, а для своих проектов RabbitMQ (в котором тоже есть грабли, но решаемые с меньшими трудозатратами).
Приятно видеть еще одного ZMQ'шника. С библиотекой я знаком более трех лет, но не профессионально. Может статью набросаете? А то в русскоязычном сегменте по ZMQ удручающе мало информации.
Приятно видеть еще одного ZMQ'шника. С библиотекой я знаком более трех лет, но не профессионально. Может статью набросаете? А то в русскоязычном сегменте по ZMQ удручающе мало информации.
Что по вашему лучше использовать тогда?
Стоит приглядеться к nanomsg
Серебрянной пули нет.
Приходится выбирать между высокой производительностью/пропускной способностью, которую дают brokerless решения вроде ZeroMQ и его детищ — nanomsg и crossroads, и стабильностью/надежностью/гарантией доставки, которые дают брокеры — RabbitMQ, ActiveMQ, Redis (с оговорками), NATS и остальные.
Есть отличный материал со сравнением и тестами многих систем — Dissecting Message Queues
Crossroads I/O и NanoMSG в какой-то степени детища ZeroMQ. Первое — форк, который сначала забросили, потом с помпой возобновили и опять забросили.
Второе — детище одного из разработчиков ZeroMQ, которое исправляет многие недочеты прародителя, но при этом приносит свои и исповедует все ту же идеологию ZMQ — библиотека сама знает, как лучше отправлять, ибо умнее ее пользователей.
Nanomsg, как и zmq, гарантирует атомарность доставленных сообщений и их порядок, при этом не гарантирует саму доставку. При потере части разделенного сообщения оно все будет дропнуто получателем, сообщения могут не доходить вообще (о чем я писал выше). При этом автор (Martin Sustrik) ясно дает понять, что чинить это никак не собирается:
Во многих аспектах nanomsg интереснее, модульнее и проще для разработчика, но с моей точки зрения это такой же черный ящик для мониторинга в проде. И если ZMQ проект уже устоявшийся, обладает большим комьюнити, которое большую часть «особенностей» уже выявило и опубликовало решения на том же StackOverflow, то Nanomsg штука свежая, комьюнити небольшое, и чего от него ждать при нагрузке в боевых условиях я не знаю.
Ну и кому интересно, есть отличный обзор Nanomsg на том же ресурсе — A Look at Nanomsg and Scalability Protocols
При этом стоит сказать, что я его в проде не использовал, и, может быть, еще просто не умею готовить :)
Если подытожить:
Надо быстро и допустимы потери: brokerless решения — ZeroMQ, NanoMSG, Crossroads I/O
Надо надежно и можно подождать: брокеры — RabbitMQ, ActiveMQ, RATS, etc
Приходится выбирать между высокой производительностью/пропускной способностью, которую дают brokerless решения вроде ZeroMQ и его детищ — nanomsg и crossroads, и стабильностью/надежностью/гарантией доставки, которые дают брокеры — RabbitMQ, ActiveMQ, Redis (с оговорками), NATS и остальные.
Есть отличный материал со сравнением и тестами многих систем — Dissecting Message Queues
Crossroads I/O и NanoMSG в какой-то степени детища ZeroMQ. Первое — форк, который сначала забросили, потом с помпой возобновили и опять забросили.
Второе — детище одного из разработчиков ZeroMQ, которое исправляет многие недочеты прародителя, но при этом приносит свои и исповедует все ту же идеологию ZMQ — библиотека сама знает, как лучше отправлять, ибо умнее ее пользователей.
Nanomsg, как и zmq, гарантирует атомарность доставленных сообщений и их порядок, при этом не гарантирует саму доставку. При потере части разделенного сообщения оно все будет дропнуто получателем, сообщения могут не доходить вообще (о чем я писал выше). При этом автор (Martin Sustrik) ясно дает понять, что чинить это никак не собирается:
Guaranteed delivery is a myth. Nothing is 100% guaranteed. That’s the nature of the world we live in. What we should do instead is to build an internet-like system that is resilient in face of failures and routes around damage.
Во многих аспектах nanomsg интереснее, модульнее и проще для разработчика, но с моей точки зрения это такой же черный ящик для мониторинга в проде. И если ZMQ проект уже устоявшийся, обладает большим комьюнити, которое большую часть «особенностей» уже выявило и опубликовало решения на том же StackOverflow, то Nanomsg штука свежая, комьюнити небольшое, и чего от него ждать при нагрузке в боевых условиях я не знаю.
Ну и кому интересно, есть отличный обзор Nanomsg на том же ресурсе — A Look at Nanomsg and Scalability Protocols
При этом стоит сказать, что я его в проде не использовал, и, может быть, еще просто не умею готовить :)
Если подытожить:
Надо быстро и допустимы потери: brokerless решения — ZeroMQ, NanoMSG, Crossroads I/O
Надо надежно и можно подождать: брокеры — RabbitMQ, ActiveMQ, RATS, etc
Очень интересно.
Хорошо бы ваш такой богатый опыт оформить это в виде статьи «Как правильно готовить ZMQ», а то в zguide не так много таких нюансов описано.
На счет идентии не знал, спасибо. Наверно по правилам надо перегенерить идентити при перезапуске. Тогда не должно быть проблем, и не нужно тормозить кластер(я правда не уверен. что тогда ликов конекшенов не будет)
Хеартбит и уведобления о доставки — это да, нужно обязательно. тут разработчики не скрывают.
На счет диагностики тоже согласен, это ужасно раздражает и напрягает. Я уже думаю — а не написать, ли пач zmq (или форк сделать) в котором была-бы прикручена диагностика. В принципе это не сложно реализовать.
И если не секрет — а в проде клиенты и сервисы на чем бекенд написан?
Хорошо бы ваш такой богатый опыт оформить это в виде статьи «Как правильно готовить ZMQ», а то в zguide не так много таких нюансов описано.
На счет идентии не знал, спасибо. Наверно по правилам надо перегенерить идентити при перезапуске. Тогда не должно быть проблем, и не нужно тормозить кластер(я правда не уверен. что тогда ликов конекшенов не будет)
Хеартбит и уведобления о доставки — это да, нужно обязательно. тут разработчики не скрывают.
На счет диагностики тоже согласен, это ужасно раздражает и напрягает. Я уже думаю — а не написать, ли пач zmq (или форк сделать) в котором была-бы прикручена диагностика. В принципе это не сложно реализовать.
И если не секрет — а в проде клиенты и сервисы на чем бекенд написан?
У нас как IDENT используется UUID, при этом он не задействован нами в какой-то логики, а скорее как адрес сервиса для правильного роутинга пакета по кластеру. Если его не задавать самому вручную, то он будет сгенерен автоматически, при этом сталкивался с коллизиями идентов, созданных разными машинами.
У нас по большей части php (php-zmq), c++ (cppzmq) и java через jzmq
У нас по большей части php (php-zmq), c++ (cppzmq) и java через jzmq
Sign up to leave a comment.
Брокер сообщений для сервисной архитектуры на базе ZMQ — или отдых разработчика