Шаблон «публикация–подписка»
Модель обмена сообщениями, при которой отправители и получатели не общаются напрямую

В архитектуре программного обеспечения publish –subscribe или pub/sub — это шаблон обмена сообщениями , где издатели классифицируют сообщения по классам, которые получают подписчики. Это контрастирует с типичной моделью шаблона обмена сообщениями, где издатели отправляют сообщения напрямую подписчикам.

Аналогичным образом подписчики выражают интерес к одному или нескольким классам и получают только те сообщения, которые представляют интерес, не имея представления о том, какие издатели существуют, если таковые имеются.

Publish–subscribe — это родственная парадигма очереди сообщений , и обычно является частью более крупной системы промежуточного программного обеспечения, ориентированной на сообщения . Большинство систем обмена сообщениями поддерживают как модели pub/sub, так и модели очереди сообщений в своих API ; например, Java Message Service (JMS).

Этот шаблон обеспечивает большую масштабируемость сети и более динамичную топологию сети , что приводит к снижению гибкости в изменении издателя и структуры опубликованных данных. По словам Грегора Хохпе, по сравнению с синхронными шаблонами обмена сообщениями (такими как RPC ) и шаблонами обмена сообщениями точка-точка , шаблон публикации-подписки обеспечивает наивысший уровень разделения между архитектурными компонентами, однако он также может связывать их некоторыми другими способами (такими как формат и семантическая связь), поэтому со временем они становятся беспорядочными. [1]

Фильтрация сообщений

В модели публикации-подписки подписчики обычно получают только часть всех опубликованных сообщений. Процесс выбора сообщений для приема и обработки называется фильтрацией . Существует две распространенные формы фильтрации: основанная на теме и основанная на контенте.

В тематической системе сообщения публикуются в «темах» или именованных логических каналах. Подписчики в тематической системе будут получать все сообщения, опубликованные в темах, на которые они подписаны. Издатель несет ответственность за определение тем, на которые подписчики могут подписываться.

В системе на основе контента сообщения доставляются подписчику только в том случае, если атрибуты или содержание этих сообщений соответствуют ограничениям, определенным подписчиком. Подписчик несет ответственность за классификацию сообщений.

Некоторые системы поддерживают гибрид этих двух подходов: издатели публикуют сообщения в определенной теме, а подписчики регистрируют подписки на основе контента на одну или несколько тем.

Топологии

Во многих системах публикации-подписки издатели отправляют сообщения промежуточному брокеру сообщений или шине событий , а подписчики регистрируют подписки у этого брокера, позволяя брокеру выполнять фильтрацию. Обычно брокер выполняет функцию хранения и пересылки для маршрутизации сообщений от издателей к подписчикам. Кроме того, брокер может устанавливать приоритеты сообщений в очереди перед маршрутизацией. [ необходима цитата ]

Подписчики могут регистрироваться для получения определенных сообщений во время сборки, во время инициализации или во время выполнения. В системах с графическим интерфейсом подписчики могут быть закодированы для обработки пользовательских команд (например, нажатие кнопки), что соответствует регистрации во время сборки. Некоторые фреймворки и программные продукты используют файлы конфигурации XML для регистрации подписчиков. Эти файлы конфигурации считываются во время инициализации. Наиболее сложная альтернатива — когда подписчики могут быть добавлены или удалены во время выполнения. Этот последний подход используется, например, в триггерах баз данных , списках рассылки и RSS . [ необходима цитата ]

Промежуточное программное обеспечение службы распределения данных (DDS) не использует брокера в середине. Вместо этого каждый издатель и подписчик в системе pub/sub обмениваются метаданными друг о друге через многоадресную IP-рассылку . Издатель и подписчики кэшируют эту информацию локально и маршрутизируют сообщения на основе обнаружения друг друга в общем ведении. По сути, архитектуры без брокеров требуют, чтобы система публикации/подписки создавала оверлейную сеть, которая обеспечивает эффективную децентрализованную маршрутизацию от издателей к подписчикам. Джон Кляйнберг показал, что эффективная децентрализованная маршрутизация требует топологий Navigable Small-World . Такие топологии Small-World обычно реализуются децентрализованными или федеративными системами публикации/подписки. [2] Системы публикации/подписки с учетом местоположения [3] создают топологии Small-World, которые направляют подписки через короткие расстояния и недорогие соединения, тем самым сокращая время доставки подписки.

История

Одной из первых публично описанных систем pub/sub была подсистема «новостей» набора инструментов Isis, описанная в 1987 году на симпозиуме по принципам операционных систем Ассоциации вычислительной техники (ACM) (SOSP '87) в статье «Использование виртуальной синхронности в распределенных системах . 123–138». [4]

Преимущества

Слабое сцепление

Издатели слабо связаны с подписчиками и даже не должны знать об их существовании. Поскольку тема находится в центре внимания, издатели и подписчики могут оставаться в неведении относительно топологии системы. Каждый может продолжать работать в обычном режиме независимо от другого. В традиционной тесно связанной парадигме клиент-сервер клиент не может отправлять сообщения на сервер, пока серверный процесс не запущен, а сервер не может получать сообщения, если клиент не запущен. Многие системы pub/sub не только разделяют местоположения издателей и подписчиков, но и разделяют их временно. Распространенная стратегия, используемая аналитиками промежуточного программного обеспечения с такими системами pub/sub, заключается в отключении издателя, чтобы позволить подписчику работать с задержкой (форма регулирования пропускной способности ).

Масштабируемость

Pub/sub обеспечивает возможность лучшей масштабируемости , чем традиционная клиент-серверная архитектура, за счет параллельной работы, кэширования сообщений, древовидной или сетевой маршрутизации и т. д. Однако в некоторых типах тесно связанных корпоративных сред с большим объемом данных, когда системы масштабируются и становятся центрами обработки данных с тысячами серверов, совместно использующих инфраструктуру pub/sub, текущие системы поставщиков часто теряют это преимущество; масштабируемость для продуктов pub/sub при высокой нагрузке в этих контекстах является исследовательской задачей.

С другой стороны, за пределами корпоративной среды парадигма pub/sub доказала свою масштабируемость до объемов, значительно превышающих возможности одного центра обработки данных, обеспечивая распределенную передачу сообщений по всему Интернету с помощью веб-протоколов синдикации, таких как RSS и Atom . Эти протоколы синдикации допускают более высокую задержку и отсутствие гарантий доставки в обмен на возможность даже веб-сервера низкого уровня синдицировать сообщения (потенциально) миллионам отдельных узлов подписчиков.

Проблемы с доставкой сообщений

  • Избыточные подписчики в системе pub/sub могут помочь обеспечить доставку сообщений с минимальной дополнительной сложностью. Например, фабрика может использовать систему pub/sub, где оборудование может публиковать проблемы или сбои для подписчика, который отображает и регистрирует эти проблемы. Если регистратор выходит из строя (падает), издатели проблем оборудования не обязательно получат уведомление об отказе регистратора, и сообщения об ошибках не будут отображаться или записываться каким-либо оборудованием в системе pub/sub. В системе клиент/сервер, когда регистратор ошибок выходит из строя, система получит указание на отказ регистратора ошибок (сервера). Однако система клиент/сервер должна будет справиться с этим отказом, имея избыточные серверы регистрации в сети или динамически создавая резервные серверы регистрации. Это добавляет сложности к конструкциям клиента и сервера, а также к архитектуре клиент/сервер в целом. В системе pub/sub избыточные подписчики на регистрацию, которые являются точными копиями существующего регистратора, могут быть добавлены в систему для повышения надежности регистрации без какого-либо влияния на любое другое оборудование в системе. Функция гарантированной регистрации сообщений об ошибках также может быть добавлена ​​постепенно, после внедрения базовой функциональности регистрации сообщений о проблемах с оборудованием.

Недостатки

Наиболее серьезные проблемы систем pub/sub являются побочным эффектом их главного преимущества: разделения издателя и подписчика.

Проблемы с доставкой сообщений

Система публикации/подписки должна быть тщательно спроектирована, чтобы обеспечить более надежные системные свойства, которые могут потребоваться для конкретного приложения, например, гарантированную доставку.

  • Брокер в системе pub/sub может быть спроектирован так, чтобы доставлять сообщения в течение определенного времени, но затем прекращать попытки доставки, независимо от того, получил ли он подтверждение успешного получения сообщения всеми подписчиками. Система pub/sub, спроектированная таким образом, не может гарантировать доставку сообщений любым приложениям, которым может потребоваться такая гарантированная доставка. Более тесная связь конструкций такой пары издателя и подписчика должна быть реализована за пределами архитектуры pub/sub для достижения такой гарантированной доставки (например, требуя от подписчика публиковать сообщения о получении).
  • Издатель в системе pub/sub может предположить, что подписчик его слушает, хотя на самом деле это не так.

Шаблон pub/sub хорошо масштабируется для небольших сетей с небольшим количеством узлов-издателей и подписчиков и небольшим объемом сообщений. Однако по мере роста количества узлов и сообщений увеличивается вероятность нестабильности, что ограничивает максимальную масштабируемость сети pub/sub. Примеры нестабильности пропускной способности в больших масштабах включают:

  • Всплески нагрузки — периоды, когда запросы абонентов перегружают пропускную способность сети, за которыми следуют периоды низкого объема сообщений (недоиспользование пропускной способности сети)
  • Замедление — поскольку все больше приложений используют систему (даже если они взаимодействуют по отдельным каналам pub/sub), поток сообщений к отдельному подписчику будет замедляться.

Для систем pub/sub, использующих брокеров (серверы), аргумент для брокера отправлять сообщения подписчику является внутриполосным и может быть подвержен проблемам безопасности. Брокеры могут быть обмануты и отправить уведомления не тому клиенту, что усилит запросы на отказ в обслуживании против клиента. Сами брокеры могут быть перегружены, поскольку они выделяют ресурсы для отслеживания созданных подписок.

Даже в системах, не использующих брокеров, подписчик может получать данные, на получение которых у него нет полномочий. Неавторизованный издатель может вводить неверные или вредоносные сообщения в систему pub/sub. Это особенно актуально для систем, которые транслируют или многоадресно рассылают свои сообщения. Шифрование (например, Transport Layer Security (SSL/TLS)) может предотвратить несанкционированный доступ, но не может предотвратить вредоносные сообщения, вводимые авторизованными издателями. Архитектуры, отличные от pub/sub, такие как клиент-серверные системы, также уязвимы для авторизованных отправителей сообщений, которые ведут себя злонамеренно.

Смотрите также

Ссылки

  1. ^ Хохпе, Грегор (2003). Шаблоны интеграции предприятий: проектирование, построение и развертывание решений для обмена сообщениями . Addison-Wesley Professional. ISBN 978-0321200686.
  2. ^ ab Chen, Chen; Tock, Yoav; Girdzijauskas, Sarunas (2018). "BeaConvey". Труды 12-й Международной конференции ACM по распределенным и событийным системам. Гамильтон, Новая Зеландия: ACM Press. стр.  64–75 . doi :10.1145/3210284.3210287. ISBN 9781450357821. S2CID  43929719.
  3. ^ Рахимиан, Фатемех; Ле Нгуен Хыу, Тхинь; Гирдзиаускас, Шарунас (2012), Гёшка, Карл Михаэль; Хариди, Сейф (ред.), «Осведомленность о местоположении в одноранговой сети публикации/подписки», Distributed Applications and Interoperable Systems , т. 7272, Springer Berlin Heidelberg, стр.  45–58 , doi : 10.1007/978-3-642-30823-9_4 , ISBN 9783642308222
  4. ^ Бирман, К.; Джозеф, Т. (1987). «Использование виртуальной синхронности в распределенных системах». Труды одиннадцатого симпозиума ACM по принципам операционных систем — SOSP '87 . С.  123–138 . doi :10.1145/41457.37515. ISBN 089791242X. S2CID  7739589.


Взято с "https://en.wikipedia.org/w/index.php?title=Publish–subscribe_pattern&oldid=1272339610"