Поделиться через

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

  • Статья

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

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

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

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

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

События

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

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

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

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

Сообщения

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

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

Пример сценариев

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

  • Дискретные события:
    • Платформа обмена музыкой отслеживает тот факт, что конкретный пользователь в определенном клиенте прослушивал определенный музыкальный трек.
    • В веб-приложении интернет-магазина приложение каталога отправляет событие с помощью шаблона publisher-подписчика другим приложениям, чтобы уведомить их о том, что цена на элемент изменилась.
    • Компания-производитель отправляет информацию в режиме реального времени клиентам и третьим лицам о обслуживании оборудования, работоспособности систем и обновлении контрактов.
  • Точки данных:
    • Система управления зданием получает события телеметрии, такие как данные температуры или влажности от датчиков, принадлежащих нескольким клиентам.
    • Система мониторинга на основе событий получает и обрабатывает журналы диагностика практически в режиме реального времени из нескольких служб, таких как веб-серверы.
    • Клиентский скрипт на веб-странице собирает действия пользователей и отправляет их в решение аналитики щелчком.
  • Сообщения:
    • Финансовое приложение B2B получает сообщение о начале обработки банковских записей клиента.
    • Длительный рабочий процесс получает сообщение, которое активирует выполнение следующего шага.
    • Приложение корзины приложения интернет-магазина отправляет команду CreateOrder с помощью асинхронного постоянного сообщения в приложение заказа.

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

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

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

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

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

Некоторые предложения служб, такие как уровень "премиум" Служебная шина Azure, обеспечивают изоляцию ресурсов на уровне ЦП и памяти, чтобы каждая рабочая нагрузка клиента выполнялись в изоляции. Контейнер ресурса называется единицей обмена сообщениями. Для каждого премиального пространства имен выделяется хотя бы одна единица обмена сообщениями. Вы можете приобрести 1, 2, 4, 8 или 16 единиц обмена сообщениями для каждого служебная шина пространства имен Premium. Одна рабочая нагрузка или сущность может охватывать несколько единиц обмена сообщениями, и при необходимости можно изменить количество единиц обмена сообщениями. Результатом является прогнозируемая и повторяемая производительность решения на основе служебная шина. Дополнительные сведения см. в разделе служебная шина уровнях обмена сообщениями уровня "Премиум" и "Стандартный". Аналогичным образом, Центры событий Azure ценовые категории позволяют масштабировать пространство имен на основе ожидаемого объема входящих и исходящих событий. Например, предложение Premium оплачивается единицами обработки (PUS), которые соответствуют общей папке изолированных ресурсов (ЦП, памяти и хранилища) в базовой инфраструктуре. Эффективная пропускная способность приема и потоковой передачи для каждого pu будет зависеть от следующих факторов:

  • Количество отправителей и получателей
  • Размер полезной нагрузки
  • Количество секций
  • Частота исходящих запросов
  • Использование сбора Центров событий, реестра схем и других дополнительных функций

Дополнительные сведения см. в разделе "Обзор Центров событий Premium".

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

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

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

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

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

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

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

При развертывании системы обмена сообщениями на виртуальных машинах следует совместно находить эти виртуальные машины с вычислительными ресурсами, чтобы уменьшить задержку в сети. Эти виртуальные машины не должны совместно использоваться другими службами или приложениями, чтобы избежать инфраструктуры обмена сообщениями для конкуренции за системные ресурсы, такие как ЦП, память и пропускная способность сети с другими системами. Виртуальные машины также могут распространяться по зонам доступности, чтобы повысить устойчивость внутри региона и надежность критически важных для бизнеса рабочих нагрузок, включая системы обмена сообщениями. Предположим, что вы решили разместить систему обмена сообщениями, например RabbitMQ или Apache ActiveMQ, на виртуальных машинах. В этом случае рекомендуется развернуть его в масштабируемом наборе виртуальных машин и настроить его для автомасштабирования на основе метрик, таких как ЦП или память. Таким образом, количество узлов агента, в которых размещена система обмена сообщениями, будет правильно масштабироваться и масштабироваться в зависимости от условий трафика. Дополнительные сведения см. в статье "Обзор автомасштабирования с масштабируемыми наборами виртуальных машин Azure".

Аналогичным образом при размещении системы обмена сообщениями в кластере Kubernetes рекомендуется использовать селекторы узлов и фрагменты, чтобы запланировать выполнение модулей pod в выделенном пуле узлов, а не совместно с другими рабочими нагрузками, чтобы избежать проблемы с шумным соседом. При развертывании системы обмена сообщениями в кластере AKS, избыточном между зонами, используйте ограничения топологии Pod для управления распределением модулей pod по кластеру AKS между доменами сбоев, такими как регионы, зоны доступности и узлы. При размещении сторонней системы обмена сообщениями в AKS используйте автомасштабирование Kubernetes для динамического масштабирования числа рабочих узлов при увеличении трафика. При использовании автомасштабирования горизонтального модуля Pod и автомасштабирования кластера AKS тома узлов и модулей pod динамически настраиваются в режиме реального времени, чтобы обеспечить соответствие условию трафика и избежать простоев, вызванных проблемами емкости. Дополнительные сведения см. в статье Автоматическое масштабирование кластера в соответствии с требованиями приложения в Службе Azure Kubernetes (AKS). Рассмотрите возможность использования автоматического масштабирования Kubernetes (KEDA), если вы хотите масштабировать количество модулей pod размещенной в Kubernetes системы обмена сообщениями, например RabbitMQ или Apache ActiveMQ, на основе длины заданной очереди. С помощью KEDA можно управлять масштабированием любого контейнера в Kubernetes на основе количества событий, которые необходимо обработать. Например, можно использовать KEDA для масштабирования приложений на основе длины очереди Служебная шина Azure, очереди RabbitMQ или очереди ActiveMQ. Дополнительные сведения о KEDA см. в разделе "Автомасштабирование на основе событий Kubernetes".

Изоляция

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

  • Несколько клиентов могут совместно использовать одни и те же сущности обмена сообщениями, такие как очереди, разделы и подписки, в одной системе обмена сообщениями. Например, мультитенантное приложение может получать сообщения, которые несут данные для нескольких клиентов из одной очереди Служебная шина Azure. Это решение может привести к проблемам производительности и масштабируемости. Если некоторые клиенты создают больший объем заказов, чем другие, это может привести к невыполненной работы сообщений. Эта проблема, также известная как проблема Шумного соседа, может снизить уровень обслуживания с точки зрения задержки для некоторых клиентов. Проблема более очевидна, если приложение-потребитель считывает и обрабатывает сообщения из очереди, по одному за раз, в строгом хронологическом порядке, и если необходимое время для обработки сообщения зависит от количества элементов в полезных данных. При совместном использовании одного или нескольких ресурсов очереди в нескольких клиентах инфраструктура обмена сообщениями и системы обработки должны соответствовать ожидаемому трафику на основе масштабирования и пропускной способности. Этот архитектурный подход хорошо подходит в тех сценариях, когда мультитенантное решение принимает единый пул рабочих процессов, чтобы получать, обрабатывать и отправлять сообщения для всех клиентов.
  • Несколько клиентов используют одну и ту же систему обмена сообщениями, но используют разные ресурсы раздела или очереди. Такой подход обеспечивает более высокую изоляцию и защиту данных при более высокой стоимости, повышенной операционной сложности и более высокую гибкость, так как системные администраторы должны подготавливать, отслеживать и поддерживать более высокое количество ресурсов очереди. Это решение обеспечивает согласованный и прогнозируемый интерфейс для всех клиентов с точки зрения производительности и соглашений на уровне обслуживания, так как он запрещает любому клиенту создавать узкие места, которые могут повлиять на других клиентов.
  • Для каждого клиента используется отдельная выделенная система обмена сообщениями. Например, мультитенантное решение может использовать отдельное пространство имен Служебная шина Azure для каждого клиента. Это решение обеспечивает максимальную степень изоляции при более высокой сложности и эксплуатационных затратах. Такой подход гарантирует согласованную производительность и позволяет точно настроить систему обмена сообщениями на основе конкретных потребностей клиента. При подключении нового клиента в дополнение к полностью выделенной системе обмена сообщениями приложение подготовки может также потребоваться создать отдельное управляемое удостоверение или субъект-службу с соответствующими разрешениями RBAC для доступа к созданному пространству имен. Например, если кластер Kubernetes совместно используется несколькими экземплярами одного приложения SaaS, по одному для каждого клиента и каждый запущен в отдельном пространстве имен, каждый экземпляр приложения может использовать другой субъект-службу или управляемое удостоверение для доступа к выделенной системе обмена сообщениями. В этом контексте система обмена сообщениями может быть полностью управляемой службой PaaS, например пространством имен Служебная шина Azure или системой обмена сообщениями, размещенной в Kubernetes, например RabbitMQ. При удалении клиента из системы приложение должно удалить систему обмена сообщениями и любой выделенный ресурс, который был предварительно создан для клиента. Основным недостатком этого подхода является увеличение операционной сложности и снижение гибкости, особенно при увеличении числа клиентов с течением времени.

Ознакомьтесь со следующими дополнительными рекомендациями и наблюдениями.

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

Аналогичным образом, приложение, управляемое событиями, может обеспечить различные уровни изоляции:

  • Приложение, управляемое событиями, получает события из нескольких клиентов через один общий Центры событий Azure экземпляр. Это решение обеспечивает высокий уровень гибкости, так как подключение нового клиента не требует создания выделенного ресурса приема событий, но обеспечивает низкий уровень защиты данных, так как он перемешивает сообщения из нескольких клиентов в одной структуре данных.
  • Клиенты могут выбрать выделенный концентратор событий или раздел Kafka, чтобы избежать проблемы с шумным соседом и удовлетворить свои требования к изоляции данных, когда события не должны быть совместно перемешаны с другими клиентами для обеспечения безопасности и защиты данных.
  • Если клиентам требуется высокий уровень устойчивости и непрерывности бизнес-процессов, мультитенант должен обеспечить возможность подготовки пространства имен Концентраторов событий Класса Premium с включенными зонами геокатасторного восстановления и доступности. Дополнительные сведения см. в статье Географическое аварийное восстановление в Центрах событий Azure.
  • Выделенные центры событий с включенной функцией отслеживания центров событий должны создаваться для тех клиентов, которые должны архивировать события в учетную запись служба хранилища Azure по нормативным причинам и обязательствам. Дополнительные сведения см. в статье Сбор событий из Центров событий Azure в Хранилище BLOB-объектов Azure или Azure Data Lake Storage.
  • Одно мультитенантное приложение может отправлять уведомления нескольким внутренним и внешним системам с помощью Сетка событий Azure. В этом случае для каждого приложения-потребителя необходимо создать отдельную подписку сетки событий. Если приложение использует несколько экземпляров сетки событий для отправки уведомлений в большое количество внешних организаций, рассмотрите возможность использования доменов событий, которые позволяют приложению публиковать события в тысячах разделов, таких как один для каждого клиента. Дополнительные сведения см. в разделе "Общие сведения о доменах событий" для управления разделами "Сетка событий".

Сложность реализации

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

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

Особое внимание уделяется мультитенантным решениям данных— это уровень настройки, которую вы поддерживаете. Любая настройка должна быть автоматически настроена и применена системой подготовки приложений (например, системой DevOps), которая основана на наборе начальных параметров при развертывании однотенантного или мультитенантного приложения.

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

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

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

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

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

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

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

Шаблон меток развертывания

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

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

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

Схема, на которой показана одна общая мультитенантная система обмена сообщениями для всех клиентов.

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

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

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

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

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

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

Схема с сегментированной системой обмена сообщениями. Одна система обмена сообщениями содержит очереди для клиентов A и B, а другая — очереди для клиента C.

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

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

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

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

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

Схема с разными системами обмена сообщениями для каждого клиента.

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

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

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

Шаблон геообъектов

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

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

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

Соавторы

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

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

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

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

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