Библиотека сайта rus-linux.net
Система обмена сообщениями ZeroMQ
Глава 24 из книги "Архитектура приложений с открытым исходным кодом", том 2.Оригинал: "ZeroMQ",
глава из книги "The Architecture
of Open Source Applications" том 2.
Автор: Martin Sústrik
Дата публикации: 2012г.
Перевод: Н.Ромоданов
Дата перевода: июнь 2013 г.
Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
ØMQ является системой обмена сообщениями, или, с вашего позволения, «программным обеспечением среднего слоя, ориентированным на работу с сообщениями». Оно используется в разнообразных средах, например, в финансовых сервисах, в разработке игр, во встраиваемых системах, в научных исследованиях и в аэрокосмической отрасли.
Системы обмена сообщениями работают в основном также, как и средства мгновенного обмена сообщениями в приложениях. В приложении принимается решение передавать событие в другое приложение (или в несколько приложений), оно собирает данные для отправки, высвечивает кнопку «send» («Отправить») и — вперед, обо всем остальном позаботится система обмена сообщениями.
В отличие от систем мгновенных сообщений (instant messaging), в системах обмена сообщениями (messaging system) нет графического интерфейса и в конечных точках не предполагается вмешательства человека в случае, если что-то пойдет не так. Поэтому системы обмена сообщениями должны быть как отказоустойчивыми, так и более быстрыми, чем обычные системы обмена мгновенными сообщениями.
Система ØMQ был изначально задумана как ультра-быстрая система сообщений для торговли акциями и поэтому основное внимание было уделено исключительно оптимизации. Первый год реализации проекта был посвящен разработке методики тестирования производительности и попытке определить архитектуру, которая была бы как можно более эффективной.
Позднее, примерно в течение второго года разработки, акцент сместился на создание общей системы для построения распределенных приложений и поддержке произвольных шаблонов сообщений, различных механизмов, транспортов, произвольных языковых сборок и т.д.
В течение третьего года акцент делался, главным образом, на улучшение удобства использования и обеспечении большей плавности кривой обучения. Мы взяли BSD Sockets API, пытаясь навести порядок в семантике отдельных шаблонов обмена сообщениями, и так далее.
Будем надеяться, что настоящая глава даст понимание того, как три цели, указанные выше, были преобразованы во внутреннюю архитектуру системы ØMQ, и даст несколько советов тем, кто борется с аналогичными проблемами.
Начиная со своего третьего года разработки ØMQ перерос работу только с кодом; есть инициатива стандартизации протоколов соединений, которые он использует, и экспериментальной реализации ØMQ как системы обмена сообщениями внутри ядра Linux и т.д. Эти темы не рассматриваются в данной книге. Тем не менее, для получения дополнительной информации вы можете обратиться к следующим интернет-ресурсам: http://www.250bpm.com/concepts, http://groups.google.com/group/sp-discuss-group и http://www.250bpm.com/hits.
24.1. Приложение или библиотека
ØMQ является библиотекой, а не сервером обмена сообщениями. На это у нас пошло несколько лет работы с протоколом AMQP: на попытку стандартизировать в финансовой индустрии сетевой протокол для обмена бизнес сообщениями, на написание эталонной реализации для него и участие в нескольких крупномасштабных проектах, базирующихся в значительной степени на технологии обмена сообщениями, на понимание того, что что-то не так с классической клиент/серверной моделью умного сервера обмена сообщениями (брокера) и бессловесными клиентами обмена сообщениями.
Наша главная задача в то время была связана с производительностью: Если в середине находится сервер, то каждое сообщение должно пройти в сети два раза (от отправителя к брокеру и от брокера к приемнику), порождая при этом проблемы, связанные с задержками и пропускной способностью. Более того, если все сообщения передаются через брокера, то в какой-то момент он обязан стать узким местом.
Вторая задача была связана с развертыванием системы в крупномасштабных сетях: когда при развертывании пересекаются организационные границы, то концепция центрального органа управления всем потоком сообщений перестает применяться. Ни одна из компаний не готова уступить контроль сервером другой компании, есть коммерческая тайна и есть юридическая ответственность. Результат на практике состоит в том, что в компании есть один сервер обмена сообщениями с рукописными мостами для подключения к системам обмена сообщениями в других компаниях. Поэтому экосистема в целом сильно фрагментирована, а поддержка большого количества мостов для каждой участвующей компании не делает ситуацию лучше. Чтобы решить эту проблему, нам нужна полностью распределенная архитектура, архитектура, в которой каждым компонентом может управлять, возможно, иной хозяйствующий субъект. Учитывая, что блоком управления в серверной архитектуре является сервер, мы можем решить эту проблему путем установки отдельного сервера для каждого компонента. В таком случае можно дополнительно оптимизировать проект, сделав так, сервер и компонент будут использовать одни и те же процессы. Так, что в итоге у нас мы все это завершилось созданием библиотеки обмена сообщениями.
Проект ØMQ был начат, когда мы получили представление о том, как сделать работу с сообщениями без центрального сервера. Это требует переворот всей концепции сообщений с ног на голову и замены модели автономного централизованного хранилища сообщений в центре сети на архитектуру «умные конечные точки, молчащая сеть», которая базируется на принципе соединений «точка-точка». Техническим следствием этого решения было то, что проект ØMQ с самого начала был библиотекой, а не приложением.
Одновременно мы смогли доказать, что такая архитектура является более эффективной (меньшие задержки, более высокая пропускная способность) и более гибкой (она проще для построения различных сложных топологий, чем привязка к классической модели «ось и спицы»).
Однако, одним из непреднамеренных последствий было то, что выбор в пользу библиотечной модели улучшил удобство работы с продуктом. Снова и снова пользователи выражают свое удовольствие по поводу того, что им не требуется устанавливать автономный сервер обмена сообщениями и им управлять. Оказывается, что отсутствие сервера является предпочтительным вариантом, поскольку это сокращает эксплуатационные затраты (не требуется администратор сервера сообщений) и становится проще выход на рынок (нет необходимости вести переговоры о необходимости запуска сервера с клиентом, командой, осуществляющей управление, или эксплуатационной командой).
Усвоенный урок в том, что при запуске нового проекта вы должны отдавать предпочтение созданию библиотек, если это вообще возможно. Довольно легко создать приложение из библиотеки, запустив ее из тривиальной программы, но практически невозможно создать библиотеку из существующих исполняемых модулей. Библиотека для пользователей будет гораздо более гибкой и в то же время не потребует от них нетривиальных административных усилий.
Далее: 24.2. Глобальное состояние