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

Мультитенантность и Конфигурация приложений Azure

  • Статья

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

Модели изоляции

Хранилище относится к одному экземпляру службы Конфигурация приложений Azure.

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

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

В следующей таблице перечислены различия между моделями изоляции main аренды для Конфигурация приложений Azure.

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

Общие хранилища

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

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

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

Магазины на клиента

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

Рассмотрите возможность использования хранилищ, зависящих от клиента, если у вас есть одна из следующих ситуаций:

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

Функции Конфигурация приложений Azure, поддерживающие мультитенантность

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

Префиксы ключей

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

Например, предположим, что необходимо сохранить параметр, чтобы указать уровень ведения журнала для приложения. В решении с одним клиентом можно присвоить этому параметру LogLevelимя . В мультитенантном решении можно использовать иерархическое имя ключа, например tenant1/LogLevel для клиента 1, tenant2/LogLevel для клиента 2 и т. д.

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

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

Метки

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

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

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

Кэширование на стороне приложения

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

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

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

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

Соавторы

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

Основной автор:

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

  • Арсен Владимирский | Главный инженер клиентов, FastTrack для Azure
  • Чжэнлан Ван | Главный менеджер по разработке программного обеспечения, Конфигурация приложений Azure

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Дальнейшие действия

Ознакомьтесь с подходами к развертыванию и настройке мультитенантности.