ПОЧЕМУ / КОГДА использовать DDS вместо ZeroMQ?
Я прочитал следующее:
И кажется, что нет никакой пользы, использующей DDS вместо zmq:
- задержка zmq лучше.
- Мне кажется, что API ZMQ понятен и прост.
- Я не могу использовать ZMQ для передачи данных между потоками / процессами / станциями.
Так:
- Когда лучше использовать DDS?
- Есть ли лучшая производительность DDS по сравнению с ZMQ?
- Есть ли четкая цель использования DDS (а не ZMQ)?
Спасибо
1 ответ
По моему (предположительно предвзятому) опыту в качестве разработчика / поставщика DDS многие приложения находят значительные преимущества использования DDS по сравнению с технологиями промежуточного программного обеспечения, включая ZeroMQ. На самом деле я вижу гораздо больше "критических приложений", использующих DDS, чем ZeroMQ...
Сначала пара разъяснений:
(1) DDS и протокол RTPS, который он использует ниже, являются стандартами, а не конкретными продуктами. Существует много реализаций этих стандартов. Насколько мне известно, есть как минимум 9 различных компаний, которые имеют независимые продукты и кодовые базы, которые реализуют эти стандарты. Не имеет смысла говорить о "производительности" DDS против ZeroMQ, вы можете говорить только о производительности конкретной реализации. Я расскажу о проблеме производительности позже, но только с этой точки зрения ваше утверждение "латентность zmq лучше" явно неверно. Противоположное утверждение было бы так же неправильно, конечно.
(2) Я не нашел много объективной информации в первой предоставленной вами ссылке. Основным моментом было то, что DDS казался наиболее подходящим для этого приложения, и была обеспокоенность по поводу того, насколько широко оно использовалось, что пояснил ответ AC. Но аргументы казались немного субъективными. Был отрицательный ответ на публикацию AC, основанную на чьем-то субъективном исследовании кодовой базы конкретного продукта. Даже если предположить, что лицо, опубликовавшее отрицательные комментарии, имеет действительный смысл, комментарии будут применяться только к одной конкретной реализации / продукту DDS, а не к DDS в целом. Лично я бы не стал верить этому комментарию, его тон кажется слишком враждебным, чтобы основываться только на заявленных фактах.
(3) Относительно ясности / простоты API. Ваши комментарии основаны на эталонном примере, который вы приводите во второй ссылке? Этот код не использует стандартные API DDS. Я не уверен, почему OCI (компания, написавшая эту статью) сделала это так - возможно, они адаптировали какой-то другой предыдущий код.
Хорошее место, чтобы взглянуть на примеры API, которые соответствуют спецификации DDS:
- Современный C++: http://blogs.rti.com/2014/08/01/create-a-p2p-distributed-application-in-under-35-lines-of-c11-code/
- Классический C++: http://www.twinoakscomputing.com/coredx/examples/hello_cpp
В любом случае, как я упоминаю позже, уровень абстракции, предоставляемый DDS и ZeroMQ, довольно сильно отличается, поэтому API-интерфейсы не сравнимы напрямую...
В ответ на ваши конкретные вопросы.
1. Когда лучше использовать DDS?
Трудно дать краткий / объективный ответ на такой широкий вопрос. Я уверен, что ZeroMQ - хороший продукт, и многие люди счастливы. То же самое можно сказать и о DDS.
Я думаю, что лучше всего указать на некоторые различия и позволить людям решить, что для них важно.
DDS и ZeroMQ различаются с точки зрения управления, экосистемы, возможностей и даже уровня абстракции.
Некоторые важные отличия:
1.1 Управление, стандарты и экосистема
DDS и RTPS являются открытыми международными стандартами от Object Management Group (OMG). ZeroMQ - это "свободная структура, контролируемая ее участниками"
Это означает, что существует открытое управление и четкие процессы OMG, которые контролируют спецификацию и ее развитие, а также правила ПИС.
ZeroMQ IPR менее понятен IMO. Со своей веб-страницы ( http://zeromq.org/docs:features) они заявляют, что "ядро libzmq ZeroMQ принадлежит его авторам" и "Организация ZeroMQ - свободная конфедерация без четкой структуры власти, которая в основном живет на GitHub. На вики-странице организации объясняется, как любой может присоединиться к команде владельцев, просто выполняя интересную работу ".
Эта "свободная структура" может быть более проблематичной для пользователей, которые заботятся о таких вещах, как родословная прав интеллектуальной собственности, гарантия и компенсация и т. Д.
С этим связано. если я правильно понял, есть только одна базовая реализация ZeroMQ (та, что в github), и единственная компания, которая стоит за ней (iMatix). Оттуда кажется, что только 4 коммиттера выполняют большую часть работы по разработке в ядре (libzmq). Если бы iMatix должен был быть приобретен или решено изменить свою бизнес-модель, или если основные коммиттеры потеряли интерес, пользователи не стали бы прибегать к помощи помимо поддержки кодовой базы сами.
Конечно, есть много успешных проектов / технологий, основанных на совместном владении кодом. С другой стороны, наличие экосистемы компаний, конкурирующих с независимыми продуктами, кодовыми базами и бизнес-моделями, обеспечивает хорошую уверенность в будущем технологии... Все зависит от того, насколько велики сообщества и экосистемы и насколько пользователь не склонен к риску.
1.2 Особенности и уровень абстракции
И DDS, и ZeroMQ поддерживают шаблоны, такие как публикация-подписка и запрос-ответ (это новое дополнение к DDS, так называемый DDS-RPC). Но, вообще говоря, уровень абстракции DDS выше. это означает, что промежуточное ПО делает больше "автоматически" для приложения. В частности.
DDS обеспечивает автоматическое обнаружение
В DDS вы просто публикуете / подписываетесь на названия тем. Вам никогда не придется указывать IP-адреса, имена компьютеров или порты. Все это обрабатывается встроенным открытием. И делает это автоматически без дополнительных услуг. Это означает, что приложения могут быть повторно развернуты и интегрированы без перекомпиляции или реконфигурации.
ZeroMQ - более низкий уровень. Вы должны указать порты, IP-адреса и т. Д.
DDS pub-sub ориентирован на данные.
Приложение может публиковать в теме, но связанные данные могут представлять собой обновленные несколько объектов данных, каждый из которых идентифицируется ключевыми атрибутами. Например, при публикации местоположений самолетов каждое обновление может идентифицировать "идентификатор самолета", а промежуточное ПО может предоставлять историю, обеспечивать QoS, частоту обновлений и т. Д. Для каждого самолета в отдельности. Промежуточное программное обеспечение понимает и сообщает, когда новые самолеты появляются или исчезают из системы.
В связи с вышеизложенным DDS может хранить кэш соответствующих данных для приложения, которые он может запрашивать (по ключу или содержимому) по своему усмотрению, например, считывать последние 5 позиций самолета. Приложение уведомляется об изменениях, но оно не обязано немедленно их использовать. Это также может помочь уменьшить объем кода, который должен написать разработчик приложения.
DDS обеспечивает больше поддержки для "приложений" QoS
DDS поддерживает более 22 политик QoS для доставки сообщений и данных, таких как надежность, живучесть конечных точек, постоянство и доставка сообщений для поздних присоединяющихся, истечение срока действия сообщений, отработка отказа, мониторинг периодических обновлений, фильтрация на основе времени, упорядочение и т. Д. Это все настраивается с помощью простых настроек политики QoS. Приложение использует тот же API для чтения / записи, и вся дополнительная работа выполняется под ним.
ZeroMQ подходит к этой проблеме, предоставляя строительные блоки и шаблоны. Это довольно гибко, но приложение должно программировать, собирать и управлять различными шаблонами, чтобы получить поведение более высокого уровня. Например, чтобы получить надежный паб-саб, необходимо объединить несколько шаблонов, как описано в http://zguide.zeromq.org/page:all.
DDS поддерживает дополнительные возможности, такие как фильтрация контента, фильтрация времени, разделы, домены,...
Они не доступны в ZeroMQ. Они должны быть построены на уровне приложений.
DDS предоставляет систему типов и поддерживает расширяемость и изменчивость типов
Вы должны объединить ZeroMQ с другими пакетами, такими как буферы протокола Google, чтобы получить аналогичную функциональность.
Безопасность
Существует спецификация DDS-Security, которая обеспечивает детальную (на уровне раздела) безопасность, включая аутентификацию, шифрование, подпись, распространение ключей, безопасную многоадресную рассылку и т. Д.
2. Есть ли лучшая производительность DDS по сравнению с ZMQ?
Обратите внимание, что эталонные тесты, на которые вы ссылаетесь, относятся к реализации "OpenDDS" от Object Computing Inc. Насколько я знаю, это не одна из самых быстрых реализаций DDS. Я бы порекомендовал вам взглянуть на некоторые другие, такие как RTI Connext DDS (наша реализация), OpenSplice DDS PrimsTech или CoreDX DDS TwinOaks. Конечно, результаты в значительной степени зависят от реального теста, сети и компьютеров, но типичные характеристики задержки для более быстрых реализаций DDS с использованием C++ составляют порядка 50 микросекунд, а не 180 микросекунд). См. https://www.rti.com/products/dds/benchmarks.html.
Слои промежуточного программного обеспечения, такие как DDS или ZeroMQ, работают поверх таких вещей, как UDP или TCP, поэтому я ожидаю, что они связаны с тем, что может делать базовая сеть, и для простых случаев они, вероятно, не слишком отличаются, и, конечно, будут хуже, чем сырой транспорт.
Различия также связаны с тем, какие услуги они предоставляют. Поэтому вы должны сравнить то, что вы можете получить для одного и того же уровня обслуживания, например, надежную публикацию с масштабированием для многих потребителей, приоритезацию информации, отправку нескольких потоков и больших данных через UDP (чтобы избежать блокирования заголовка TCP) и т. Д.
Основываясь на исследовании OpenDDS, на которое вы ссылаетесь, и относительной производительности различных реализаций DDS ( http://www.dre.vanderbilt.edu/DDS/), я ожидаю, что в тесте "яблоки к яблокам" более эффективные реализации DDS будет соответствовать или превышать ZeroMQ.
При этом люди редко выбирают промежуточное программное обеспечение, которое дает им "лучшую производительность". В противном случае никто не будет использовать веб-службы или HTTP. Выбор основан на многих факторах, производительность просто должна быть настолько хорошей, насколько это необходимо для удовлетворения потребностей приложения. Надежность, масштабируемость, поддержка, риск, ремонтопригодность, соответствие модели программирования для предметной области, общая стоимость владения и т. Д., Как правило, более важны для принятия решения.
3. Есть ли четкая цель использования DDS (а не ZMQ)?
Ну да... во многих приложениях это обеспечивает лучший компромисс с точки зрения производительности, масштабируемости, функциональности, простоты приложения, надежности, снижения рисков и общей стоимости владения. За последние несколько лет тысячи проектов пришли к такому выводу:)
Херардо