Архитектурные подходы к обмену сообщениями в мультитенантных решениях

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

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

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

Сообщения, точки данных и дискретные события

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

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

Дополнительные сведения см. в разделе "События", "Точки данных" и "Сообщения" — выбор подходящей службы обмена сообщениями Azure для ваших данных

Azure предоставляет несколько служб обмена сообщениями, которые можно использовать для поддержки требований к обмену сообщениями, включая Центры событий Azure, Сетку событий Azure и служебную шину Azure. Сведения о выборе подходящей службы для ваших потребностей см. в разделе "Выбор между службами обмена сообщениями Azure" — "Сетка событий", "Центры событий" и "Служебная шина".

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

Ключевые рекомендации и требования

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

Масштабировать

Количество арендаторов, сложность потоков сообщений и eventstream объем сообщений, ожидаемый профиль трафика и уровень изоляции должны учитываться при принятии решений о планировании инфраструктуры обмена сообщениями или событий.

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

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

Например, можно развернуть систему обмена сообщениями для клиента во время процесса подготовки с помощью средства "Инфраструктура как код" (IaC), например Terraform, Bicep или шаблоны Azure Resource Manager (ARM) и системы DevOps, например Azure DevOps или GitHub Actions. Дополнительные сведения см. в разделе " Архитектурные подходы к развертыванию и настройке мультитенантных решений".

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

Прогнозируемость производительности и надежность

Для ограниченного количества клиентов использование единой системы обмена сообщениями может быть отличным решением для удовлетворения функциональных требований с точки зрения пропускной способности и снижения общей стоимости владения. Мультитенантное приложение может использовать одни и те же сущности обмена сообщениями, такие как очереди и топики, для нескольких клиентов. Кроме того, можно использовать выделенный набор компонентов для каждого клиента для повышения изоляции клиентов. Однако общий доступ к одной инфраструктуре обмена сообщениями между несколькими клиентами может предоставить все решение проблем с шумным соседом. Активность одного арендатора может навредить другим арендаторам в плане производительности и операбельности.

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

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

Сложность управления и операций

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

• Предположим, что вы делитесь системой обмена сообщениями между несколькими клиентами. Как решение может собирать и сообщать метрики использования клиента или регулировать количество сообщений, которые каждый клиент может отправлять или получать?
• Как перенести клиентов, если им нужно перейти в другой тип службы обмена сообщениями, другого развертывания или другого региона?
• Когда система обмена сообщениями использует службу PaaS, следует задать следующий вопрос:
  • Как настроить ценовую категорию для каждого клиента на основе функций и уровня изоляции (общего или выделенного), запрошенного клиентом?
  • Как создать управляемые удостоверения для конкретного арендатора и назначения ролей Azure для назначения соответствующих разрешений только сущностям системы обмена сообщениями, к которым арендатор должен иметь доступ? Например, ознакомьтесь с проверкой подлинности управляемого удостоверения с помощью идентификатора Microsoft Entra для доступа к ресурсам служебной шины Azure.
• Вы можете запланировать размещение системы обмена сообщениями, используемой приложением в выделенном наборе виртуальных машин или контейнеров, по одному для каждого клиента. В этом случае вы планируете развертывать, обновлять, отслеживать и масштабировать эти системы?

Себестоимость

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

Подходы и шаблоны, которые следует учитывать

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

• Ключи шифрования: Если арендаторам необходимо использовать собственный ключ для шифрования и расшифровки сообщений, убедитесь, что ваша служба обмена сообщениями поддерживает изоляцию ключей на необходимом уровне. Например, если вы используете служебную шину, вам может потребоваться создать отдельное пространство имен служебной шины Azure premium для каждого клиента, которому требуются собственные ключи, чтобы использовать управляемые клиентом ключи.
• Непрерывность бизнес-процессов: Определите всех клиентов, которым требуется высокий уровень восстановления и непрерывности бизнес-процессов, и рассмотрите возможность использования избыточности зоны, геоизбыточности и геокатастрофного восстановления для этих клиентов, где это доступно.
• Обработка рабочих процессов: При использовании отдельных ресурсов очередей или выделенной системы обмена сообщениями для каждого клиента, целесообразно использовать отдельный пул рабочих процессов для каждого из них, чтобы повысить уровень изоляции данных и снизить сложность работы с несколькими сущностями обмена сообщениями. Каждый экземпляр системы обработки может принимать различные учетные данные, такие как строка подключения, субъект-служба или управляемое удостоверение для доступа к выделенной системе обмена сообщениями. Такой подход обеспечивает более широкий уровень безопасности и изоляцию между клиентами, но требует повышенной сложности в управлении удостоверениями.

Общая система обмена сообщениями

Вы можете рассмотреть возможность развертывания общей системы обмена сообщениями, например одного пространства имен сервисной шины Azure, и совместного использования его всеми вашими арендаторами.

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

Однако при совместном использовании ресурса или всей инфраструктуры в нескольких клиентах следует учитывать следующие предостережения:

• Всегда помните и учитывайте ограничения, возможности масштабирования, квоты и ограничения ресурса. Например, максимальное количество центров событий в одном пространстве имен или максимальная пропускная способность может в конечном итоге стать жестким ограничением, если и когда архитектура расширяется для поддержки большего числа клиентов.
• Как упоминалось в приведенных выше разделах, проблема «Шумный сосед» может стать фактором, когда вы делитесь ресурсом между несколькими арендаторами, особенно если некоторые из них особенно заняты или создают больший трафик, чем другие. В этом случае рекомендуется применить шаблон регулирования или шаблон ограничения скорости , чтобы устранить эти последствия. Например, можно ограничить максимальное количество сообщений, которые один клиент может отправлять или получать в единицу времени.
• Возможно, у вас возникли трудности при мониторинге активности и измерении потребления ресурсов для отдельного клиента. Некоторые службы, например, некоторые уровни Azure Service Bus, взимают плату за операции обмена сообщениями. Таким образом, при совместном использовании пространства имен в нескольких клиентах приложение должно отслеживать количество операций обмена сообщениями, выполненных от имени каждого клиента и затраты на возврат. Другие службы не предоставляют тот же уровень детализации.

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

Шаблон сегментирования

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

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

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

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

Мультитенантное приложение с выделенной системой обмена сообщениями для каждого клиента

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

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

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Паоло Сальватори | Главный инженер клиента, FastTrack для Azure

Другие участники:

• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure
• Клеменс Вессерс | Главный архитектор, службы обмена сообщениями и стандарты
• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

Следующие шаги

Дополнительные сведения о шаблонах проектирования обмена сообщениями см. в следующих ресурсах:

• шаблонClaim-Check
• Шаблон конкурирующих потребителей
• Шаблон источника событий
• Шаблон каналов и фильтров
• шаблонPublisher-Subscriber
• Последовательный шаблон конвоя