В архитектуре программного обеспечения публикация -подписка — это шаблон обмена сообщениями , при котором издатели классифицируют сообщения по классам, которые получают подписчики. Это контрастирует с типичной моделью обмена сообщениями, когда издатели отправляют сообщения непосредственно подписчикам.
Аналогичным образом подписчики выражают интерес к одному или нескольким классам и получают только те сообщения, которые представляют интерес, без знания того, какие издатели существуют, если таковые имеются.
Публикация-подписка является разновидностью парадигмы очереди сообщений и обычно является частью более крупной системы промежуточного программного обеспечения, ориентированной на сообщения . Большинство систем обмена сообщениями поддерживают в своем API модели публикации/подписки и очереди сообщений ; например, Служба сообщений Java (JMS).
Этот шаблон обеспечивает большую масштабируемость сети и более динамичную топологию сети , что приводит к снижению гибкости при изменении издателя и структуры публикуемых данных.
В модели публикации-подписки подписчики обычно получают только часть общего количества опубликованных сообщений. Процесс отбора сообщений для приема и обработки называется фильтрацией . Существует две распространенные формы фильтрации: по темам и по содержанию.
В системе , основанной на темах , сообщения публикуются в «темах» или именованных логических каналах. Подписчики в тематической системе будут получать все сообщения, опубликованные в темах, на которые они подписаны. Издатель несет ответственность за определение тем, на которые могут подписаться подписчики.
В системе, основанной на контенте , сообщения доставляются подписчику только в том случае, если атрибуты или содержимое этих сообщений соответствуют ограничениям, определенным подписчиком. Абонент несет ответственность за классификацию сообщений.
Некоторые системы поддерживают гибрид этих двух систем; издатели публикуют сообщения в теме, а подписчики регистрируют подписки на основе контента на одну или несколько тем.
Во многих системах публикации-подписки издатели отправляют сообщения промежуточному брокеру сообщений или шине событий , а подписчики регистрируют подписки у этого брокера, позволяя брокеру выполнять фильтрацию. Брокер обычно выполняет функцию хранения и пересылки для маршрутизации сообщений от издателей подписчикам. Кроме того, брокер может определять приоритетность сообщений в очереди перед маршрутизацией.
Подписчики могут зарегистрироваться для получения определенных сообщений во время сборки, во время инициализации или во время выполнения. В системах с графическим пользовательским интерфейсом подписчики могут быть закодированы для обработки пользовательских команд (например, нажатия кнопки), что соответствует регистрации времени сборки. Некоторые платформы и программные продукты используют файлы конфигурации XML для регистрации подписчиков. Эти файлы конфигурации считываются во время инициализации. Самая сложная альтернатива — это когда подписчиков можно добавлять или удалять во время выполнения. Последний подход используется, например, в триггерах баз данных , списках рассылки и RSS .
Промежуточное программное обеспечение службы распределения данных (DDS) не использует посредника . Вместо этого каждый издатель и подписчик в системе публикации/подписки обмениваются метаданными друг о друге посредством многоадресной IP-рассылки . Издатель и подписчики кэшируют эту информацию локально и маршрутизируют сообщения на основе обнаружения друг друга в общей базе данных. По сути, безброкерские архитектуры требуют, чтобы система публикации/подписки построила оверлейную сеть, которая обеспечивает эффективную децентрализованную маршрутизацию от издателей к подписчикам. Джон Кляйнберг показал , что эффективная децентрализованная маршрутизация требует топологий Navigable Small-World . Такие топологии «Маленького мира» обычно реализуются децентрализованными или федеративными системами публикации/подписки. [1] Системы публикации/подписки с учетом местоположения [2] создают топологии «маленького мира», которые маршрутизируют подписки через короткие расстояния и недорогие каналы, тем самым сокращая время доставки подписки.
Одной из первых публично описанных систем pub/sub была подсистема новостей Isis Toolkit, описанная в 1987 году на симпозиуме Ассоциации вычислительной техники (ACM) по принципам операционных систем (SOSP '87) в статье «Эксплуатация виртуальных систем» . Синхронность в распределенных системах 123–138». [3]
Издатели слабо связаны с подписчиками, и им даже не обязательно знать об их существовании. Поскольку эта тема находится в центре внимания, издатели и подписчики могут оставаться в неведении о топологии системы. Каждый из них может продолжать работать в обычном режиме независимо от другого. В традиционной тесно связанной парадигме клиент-сервер клиент не может отправлять сообщения на сервер, пока серверный процесс не запущен, а также сервер не может получать сообщения, пока клиент не запущен. Многие системы публикации и подписки разделяют не только местоположение издателей и подписчиков, но и временно. Общая стратегия, используемая аналитиками промежуточного программного обеспечения в таких системах публикации/подписки, заключается в отключении издателя, чтобы позволить подписчику работать с отставанием (форма регулирования пропускной способности ).
Публикация/подписка обеспечивает возможность лучшей масштабируемости , чем традиционный клиент-сервер, за счет параллельной работы, кэширования сообщений, древовидной или сетевой маршрутизации и т. д. масштабироваться до центров обработки данных с тысячами серверов, совместно использующих инфраструктуру публикации/подписки, системы нынешних поставщиков часто теряют это преимущество; масштабируемость продуктов pub/sub при высокой нагрузке в этих контекстах является исследовательской задачей.
С другой стороны, за пределами корпоративной среды парадигма публикации/подписки доказала свою масштабируемость до объемов, значительно превышающих объемы одного центра обработки данных, обеспечивая распределенный обмен сообщениями по всему Интернету через протоколы веб-синдикации, такие как RSS и Atom . Эти протоколы синдикации допускают более высокую задержку и отсутствие гарантий доставки в обмен на возможность даже низкопроизводительного веб-сервера синдицировать сообщения (потенциально) миллионам отдельных абонентских узлов.
Наиболее серьезные проблемы с системами публикации/подписки являются побочным эффектом их главного преимущества: отделения издателя от подписчика.
Система публикации/подписки должна быть тщательно спроектирована, чтобы иметь возможность обеспечить более сильные системные свойства, которые могут потребоваться конкретному приложению, например, гарантированную доставку.
Шаблон «публикация/подписка» хорошо масштабируется для небольших сетей с небольшим количеством узлов издателя и подписчика и небольшим объемом сообщений. Однако по мере роста количества узлов и сообщений увеличивается вероятность нестабильности, ограничивая максимальную масштабируемость сети публикации/подписки. Примеры нестабильности пропускной способности в больших масштабах включают в себя:
Для систем публикации/подписки, использующих брокеров (серверы), аргумент для брокера для отправки сообщений подписчику является внутриполосным и может быть подвержен проблемам безопасности. Брокеры могут быть обмануты и отправят уведомления не тому клиенту, что усугубит запросы на отказ в обслуживании в отношении клиента. Сами брокеры могут быть перегружены, поскольку выделяют ресурсы для отслеживания созданных подписок.
Даже в системах, которые не полагаются на брокеров, подписчик может иметь возможность получать данные, на получение которых у него нет разрешения. Неавторизованный издатель может иметь возможность внести неправильные или вредные сообщения в систему публикации/подписки. Это особенно верно для систем, которые широковещательно или многоадресно рассылают свои сообщения. Шифрование (например, безопасность транспортного уровня (SSL/TLS)) может предотвратить несанкционированный доступ, но не может предотвратить распространение вредоносных сообщений авторизованными издателями. Архитектуры, отличные от pub/sub, такие как системы клиент/сервер, также уязвимы для авторизованных отправителей сообщений, которые ведут себя злонамеренно.