Шаблон публикации-подписки

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

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

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

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

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

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

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

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

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

Топологии

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

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

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

История

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

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

Ослабленная связь

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

См. также

Atom , еще один высокомасштабируемый протокол веб-распространения.
Служба распространения данных (DDS)
Программирование, управляемое событиями
Архитектура высокого уровня
Протокол управления интернет-группами (IGMP)
Брокеры сообщений
Очередь сообщений
Шаблон наблюдателя
Проблема производителя и потребителя
Push-технология ^{[ 2 ]}
RSS — высокомасштабируемый протокол веб-распространения.
Юснет
WebSub , реализация pub/sub

Ссылки

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

[1] Хохпе, Грегор (2003). Шаблоны корпоративной интеграции: проектирование, создание и развертывание решений для обмена сообщениями . Аддисон-Уэсли Профессионал. ISBN 978-0321200686 .

[:0-2] Jump up to: ^а ^б Чен, Чен; Ток, Йоав; Гирдзияускас, Шарунас (2018). «БеаКонвей» . Материалы 12-й Международной конференции ACM по распределенным и событийным системам . Гамильтон, Новая Зеландия: ACM Press. стр. 64–75. дои : 10.1145/3210284.3210287 . ISBN 9781450357821 . S2CID 43929719 .

[3] Рахимиан, Фатима; Ле Нгуен Хуу, Тхинь; Гирдзияускас, Шарунас (2012), Гёшка, Карл Михаэль; Хариди, Сейф (ред.), «Опознание местоположения в одноранговой сети публикации/подписки», Распределенные приложения и взаимодействующие системы , том. 7272, Springer Berlin Heidelberg, стр. 45–58, doi : 10.1007/978-3-642-30823-9_4 , ISBN 9783642308222

[4] Бирман, К.; Джозеф, Т. (1987). «Использование виртуальной синхронизации в распределенных системах». Материалы одиннадцатого симпозиума ACM по принципам операционных систем - SOSP '87 . стр. 123–138. дои : 10.1145/41457.37515 . ISBN 089791242X . S2CID 7739589 .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]