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

Шаблон публикация–подписка является аналогом парадигмы очереди сообщений и обычно является частью более крупной системы промежуточного программного обеспечения, ориентированного на работу с сообщениями. Большинство систем обмена сообщениями поддерживают модели publiser/subscribe и очереди сообщений в своем API, например Служба сообщений Java (JMS).

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

Содержание

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

2 Топологии

3 История

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

4.1 Слабая связь

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

5 Недостатки

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

6 Известные реализации шаблона издатель/подписка

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

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

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

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

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

Топологии

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

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

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

История

Одной из первых публично описанных систем публикации/подписки была «новостная» подсистема Isis Toolkit, описанная в 1987 г. Association for Computing Machinery (ACM) Конференция симпозиума по принципам операционных систем (SOSP '87), в статье «Использование виртуальной синхронизации в распределенных системах. 123–138».

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

Слабая связь

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

Известные реализации шаблона издатель/подписка

Существует большое количество различных вариантов реализации принципа Publish/Subscribe:

• Amazon SNS - Pub / Sub Service от AWS
• Azure Сервисная шина - Служба Pub / Sub от Microsoft Azure
• Google Cloud Pub / Sub - Служба Pub / Sub от Google Cloud Platform
• IBM MQ
• XMPP XEP-0060: публикация-подписка
• Message Broker MQTT с Парадигма публикации-подписки
• Портал OMG DDS
• Пример публикации-подписки на C ++
• Synapse - это платформа C ++, реализующая шаблон публикации-подписки