Шаблон публикации – подписки - Publish–subscribe pattern

О функции Macintosh, представленной в System 7, см. Публикация и подписка (Mac OS). Чтобы узнать, как платить до завершения работы, см. Подписка на бизнес-модель.
«PubSub» перенаправляется сюда. Информацию о несуществующем веб-сайте поиска см. PubSub (сайт).
"Pub sub" перенаправляется сюда. Для сэндвича, продаваемого в Publix, см. Publix § Market.

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

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

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

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

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

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

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

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

Топологии

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

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

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

История

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

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

Слабая связь

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ а б Чен, Чен; Ток, Йоав; Гирдзияускас, Шарунас (2018). «BeaConvey: совместное проектирование наложения и маршрутизации для тематической публикации / подписки в сетях Small-World Networks». Материалы 12-й Международной конференции ACM по распределенным и событийным системам - DEBS '18. Гамильтон, Новая Зеландия: ACM Press: 64–75. Дои:10.1145/3210284.3210287. ISBN  9781450357821. S2CID  43929719.
  2. ^ Рахимиан, Фатемех; Ле Нгуен Хуу, Тхинь; Гирдзияускас, Шарунас (2012), Гёшка, Карл Михаэль; Хариди, Сейф (ред.), "Осведомленность о местности в одноранговой сети публикации / подписки", Распределенные приложения и интероперабельные системы, Springer Berlin Heidelberg, 7272, стр. 45–58, Дои:10.1007/978-3-642-30823-9_4, ISBN  9783642308222
  3. ^ Бирман, К .; Джозеф, Т. (1987). «Использование виртуальной синхронности в распределенных системах». Материалы одиннадцатого симпозиума ACM по принципам операционных систем - SOSP '87. С. 123–138. Дои:10.1145/41457.37515. ISBN  089791242X. S2CID  7739589.

внешняя ссылка