Многопользовательская система обмена сообщениями для Apache Pulsar

искусственный интеллект Безопасность Эксплуатация и техническое обслуживание Apache
Многопользовательская система обмена сообщениями для Apache Pulsar
Эта статья была первоначально создана "AI Frontline", оригинальная ссылка:Многопользовательская система обмена сообщениями для Apache Pulsar
Маттео Мерли и Сиджи Го
Переводчик |Даю Руочжи
Редактор | Эмили

Руководство по передовой ИИ:”В этой статье представлена ​​система обмена сообщениями Apache Pulsar, предназначенная для крупных многоуровневых предприятий. "


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

В этой статье основное внимание будет уделено возможностям многопользовательского обмена сообщениями в Apache Pulsar. Мультитенантность означает возможность обслуживать нескольких арендаторов с помощью одного экземпляра программного обеспечения. Арендатор — это группа пользователей, имеющих одинаковое «представление» о системе. Являясь корпоративным центром обмена сообщениями, Apache Pulsar поддерживает мультиарендность с самого начала, потому что проект изначально был разработан для удовлетворения строгих потребностей Yahoo, и в то время на рынке не было системы с открытым исходным кодом, которая обеспечивала бы мультиарендность. возможности, включая часто используемые журналы.Системы абстракции, такие как Apache Kafka. Создание нескольких экземпляров Pulsar для нескольких пользователей или функций, как правило, неприемлемо, поскольку это затрудняет для пользователей обмен данными между разными отделами в режиме реального времени, создавая изоляцию.

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

  • Обеспечение соблюдения строгих SLA
  • Гарантированная изоляция между разными арендаторами
  • Применение квот на использование ресурсов
  • Обеспечивает безопасность на уровне арендатора и системы
  • Обеспечение малозатратных операций и максимально простого управления

Apache Pulsar удовлетворяет вышеуказанные потребности следующими способами:

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

Введение в пульсар

Чтобы помочь вам лучше понять возможности мультитенантности Pulsar, сначала кратко рассмотрим модель сообщений Pulsar.

Подобно многим другим системам публикации и подписки, приложения, которые передают данные в Pulsar, называются производителями, а приложения, использующие данные из Pulsar, называются потребителями. Потребительские приложения иногда также называют подписчиками. Подобно общему стилю публикации-подписки, тема (Topic) также является основной конструкцией сообщения Pulsar. Грубо говоря, тема может представлять собой канал для добавления данных производителями, а потребители могут извлекать данные из темы. Группа потребителей может составить подписку на тему. Различные группы потребителей могут выбирать предпочитаемых получателей сообщений для одной и той же темы: Эксклюзивные, Общие или Отказоустойчивые. Различные модели подписки показаны на рисунке 1.

Рисунок 1: Модель подписки Pulsar: эксклюзивная, общая и отказоустойчивая

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

Рис. 2. Развертывание Pulsar состоит из трех независимых арендаторов.

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

безопасность

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

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

По умолчанию Pulsar поддерживает двух поставщиков аутентификации: клиентскую аутентификацию TLS и Athenz, систему аутентификации, разработанную Yahoo. Пользователи также могут реализовать своих собственных поставщиков аутентификации, подробности см. в документации Pulsar.

После того, как провайдер аутентификации распознает токен роли клиента, Pulsar Broker использует провайдера авторизации, чтобы определить, на что имеет право клиент. Авторизация управляется на уровне объекта, что означает, что в кластере Pulsar можно использовать несколько одновременно активных схем авторизации. Например, пользователь может создать торговый актив и установить для него набор ролей, которые будут применяться к приложениям для покупок, используемым на предприятии, и создать ресурс инвентаризации, чтобы применить его только к приложению инвентаризации. Разрешения управляются на уровне пространства имен, то есть внутри актива. Мы можем назначать разрешения набору ролей для конкретной роли, например, производить и потреблять, в отношении пространства имен. См. документацию Pulsar для получения подробной информации о том, как настроить авторизацию на уровне объекта и назначить разрешения для пространств имен.

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

изолировать

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

Прежде чем представить конкретный механизм изоляции, давайте посмотрим, как выглядит кластер Apache Pulsar. На рис. 3 показана типичная среда установки. Кластер Pulsar состоит из набора брокеров (для обслуживания трафика публикации-подписки), букмекеров (для хранения сообщений) и Apache ZooKeeper, отвечающего за общую координацию и управление конфигурацией. Pulsar Broker — это компонент, отвечающий за получение и доставку сообщений, а Bookie — это сервер Apache BookKeeper, который обеспечивает постоянное хранение сообщений перед окончательным потреблением.

Рис. 3. Типичная среда Apache Pulsar.

мягкая изоляция

Брокеры и букмекеры обычно представляют собой физические ресурсы, совместно используемые несколькими производителями и потребителями. Для защиты арендаторов и выполнения требований SLA Pulsar предоставляет ряд различных механизмов для брокеров и букмекеров.

место хранения

Apache Pulsar использует Apache BookKeeper в качестве системы постоянного хранения сообщений. Каждый букмекер в Apache BookKeeper обычно может эффективно обслуживать сотни или тысячи регистров (каждый регистр — это фрагмент, созданный для темы). BookKeeper может достичь такой эффективности главным образом потому, что он разработан с учетом требований к изоляции ввода-вывода. У каждого букмекера есть собственный специальный журнал (расположенный на отдельном выделенном диске) для обработки всех входящих записей в агрегированном виде. Затем сообщения периодически сбрасываются в фоновом режиме (Flush) и сохраняются на специальном диске. Такая архитектура ввода-вывода может обеспечить изоляцию операций чтения и записи, что означает, что арендаторы могут выполнять чтение с максимально возможной скоростью, чтобы получить максимальную производительность ввода-вывода, которую могут обеспечить устройства хранения, не влияя на производительность операций записи.Пропускная способность и задержка.

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

Брокер Пульсара

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

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

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

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

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

жесткая изоляция

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

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

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

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

в заключении

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

Если вы заинтересованы в Pulsar, вы можете принять участие в сообществе Pulsar:

  • Канал Pulsar Slack, зарегистрируйтесь здесь:
  • apache-pulsar.herokuapp.com/
  • Список рассылки пульсара.

Для получения более общей информации о проекте Apache Pulsar посетите официальный сайт:pulsar.incubator.apache.org/и подписывайтесь на аккаунт проекта в Твиттере: @apache_pulsar.

Прочитайте оригинальный английский текст:

поток class.IO/blog/multi-…

Для большего содержания сухих товаров вы можете обратить внимание на AI Frontline, ID:ai-front, фоновый ответ "AI", "TF", "Большие данные«Вы можете получить серию мини-книг в формате PDF и карт навыков «AI Frontline».