служба приложение Azure — это мощная платформа размещения веб-приложений. Функции Azure, построенный на основе инфраструктуры Служба приложений, позволяет легко создавать бессерверные и управляемые событиями вычислительные рабочие нагрузки. Обе службы часто используются в мультитенантных решениях.
Функции службы приложение Azure и Функции Azure, поддерживающие мультитенантность
приложение Azure служба и Функции Azure включают множество функций, поддерживающих мультитенантность.
Личные доменные имена
служба приложение Azure позволяет использовать wild карта DNS и добавлять собственные сертификаты TLS карта. При использовании поддоменов для конкретного клиента дикие карта DNS и TLS-сертификаты позволяют легко масштабировать решение до большого количества клиентов, не требуя ручной перенастройки для каждого нового клиента.
При использовании пользовательских доменных имен для конкретного клиента может быть большое количество доменных имен, которые необходимо добавить в приложение. Это может стать громоздким для управления большим количеством пользовательских доменных имен, особенно если они требуют отдельных сертификатов TLS. Служба приложений предоставляет управляемые сертификаты TLS, что сокращает работу, необходимую при работе с пользовательскими доменами. Однако существуют ограничения, которые следует учитывать, например, сколько пользовательских доменов можно применить к одному приложению.
Интеграция с Azure Front Door
Служба приложений и Функции Azure интегрироваться с Azure Front Door, чтобы выступать в качестве компонента вашего решения с подключением к Интернету. Azure Front Door позволяет добавлять брандмауэр веб-приложения (WAF) и пограничный кэширование, а также обеспечивает другие оптимизации производительности. Вы можете легко перенастроить потоки трафика для перенаправления трафика в разные серверные части на основе изменения бизнес-требований или технических требований.
При использовании Azure Front Door с мультитенантным приложением вы можете использовать его для управления именами пользовательских доменов и завершения подключений TLS. Затем приложение Служба приложений настроено с одним именем узла, а весь трафик передается в это приложение, что помогает избежать управления именами пользовательских доменов в нескольких местах.
Как и в приведенном выше примере, Azure Front Door можно настроить для изменения заголовка Hostзапроса. Исходный Host заголовок, отправленный клиентом, распространяется через X-Forwarded-Host заголовок, и код приложения может использовать этот заголовок для сопоставления запроса с правильным клиентом.
Предупреждение
Если ваше приложение отправляет файлы cookie или ответы перенаправления, необходимо учесть особое внимание. Изменения в заголовках запроса Host могут привести к недопустимости этих ответов. Дополнительные сведения см. в рекомендации по сохранению имени узла.
Вы можете использовать частные конечные точки или Служба приложений ограничения доступа, чтобы обеспечить передачу трафика через Front Door перед достижением приложения.
Дополнительные сведения об использовании Azure Front Door в мультитенантном решении см. в статье "Использование Azure Front Door" в мультитенантном решении
Аутентификация и авторизация
служба приложение Azure может проверять маркеры проверки подлинности от имени приложения. Когда Служба приложений получает запрос, он проверка, чтобы узнать, выполнены ли все из следующих условий:
- Запрос содержит маркер.
- маркер является действительным;
- Запрос авторизован.
Если какие-либо условия не выполнены, Служба приложений может заблокировать запрос или перенаправить пользователя в поставщик удостоверений, чтобы он смог войти в систему.
Если клиенты используют идентификатор Microsoft Entra в качестве системы удостоверений, можно настроить службу приложение Azure, чтобы использовать конечную точку /common для проверки маркеров пользователей. Это гарантирует, что независимо от клиента Microsoft Entra пользователя, их маркеры проверяются и принимаются.
Вы также можете интегрировать службу приложение Azure с Azure AD B2C для проверки подлинности потребителей.
Дополнительные сведения:
- авторизация Служба приложений
- Настройка проверки подлинности в примере веб-приложения с помощью Azure AD B2C
- Работа с мультитенантными удостоверениями Microsoft Entra
Ограничения доступа
Вы можете ограничить трафик приложения с помощью ограничений доступа. Их можно использовать для указания диапазонов IP-адресов или виртуальных сетей, которые разрешены для подключения к приложению.
При работе с мультитенантным решением следует учитывать максимальное количество правил ограничения доступа. Например, если необходимо создать правило ограничения доступа для каждого клиента, возможно, превышено максимальное количество разрешенных правил. Если требуется большее количество правил, рассмотрите возможность развертывания обратного прокси-сервера, например Azure Front Door.
Модели изоляции
При работе с мультитенантной системой с помощью службы приложение Azure или Функции Azure необходимо принять решение об уровне изоляции, которую вы хотите использовать. Ознакомьтесь с моделями аренды, которые следует учитывать для мультитенантного решения и рекомендации, приведенные в архитектурных подходах для вычислений в мультитенантных решениях, чтобы помочь вам выбрать оптимальную модель изоляции для вашего сценария.
При работе со службой приложение Azure и Функции Azure следует учитывать следующие основные понятия:
- В службе приложение Azure план представляет инфраструктуру размещения. Приложение представляет одно приложение, работающее в этой инфраструктуре. Можно развернуть несколько приложений в одном плане.
- В Функции Azure размещение и приложение также разделены, но у вас есть дополнительные варианты размещения, доступные для эластичного размещения, где Функции Azure управляет масштабированием. Для простоты мы рассмотрим инфраструктуру размещения как план в этой статье, так как принципы, описанные здесь, применяются как к Служба приложений, так и к Функции Azure независимо от используемой модели размещения.
В следующей таблице перечислены различия между основными моделями изоляции аренды для службы приложение Azure и Функции Azure:
| Фактор | Общие приложения | Приложения для каждого клиента с общими планами | Планы для каждого клиента |
|---|---|---|---|
| Изоляция конфигурации | Низкая | Средняя. Параметры уровня приложения выделены для клиента, параметры уровня плана являются общими | Высокая. Каждый клиент может иметь собственную конфигурацию |
| Изоляция производительности | Низкая | Низкий средний. Потенциально подвержены шумным проблемам соседа | Высокая |
| Сложность развертывания | Низкая | Средняя | Высокая |
| Операционная сложность | Низкий | Высокий | Высокая |
| Затраты на ресурсы | Низкая | Низкое значение в зависимости от приложения | Высокая |
| Пример сценария | Крупное мультитенантное решение с общим уровнем приложений | Перенос приложений, которые не знают о клиенте в Azure при получении некоторой экономичности | Уровень приложений с одним клиентом |
Общие приложения
Вы можете развернуть общее приложение в одном плане и использовать общее приложение для всех клиентов.
Это, как правило, является наиболее экономичным вариантом, и это требует наименьших эксплуатационных накладных расходов, так как для управления меньше ресурсов. Вы можете масштабировать общий план на основе нагрузки или спроса, и все клиенты, совместно использующие план, будут использовать увеличенную емкость.
Важно учитывать Служба приложений квоты и ограничения, такие как максимальное количество настраиваемых доменов, которые можно добавить в одно приложение, и максимальное количество экземпляров плана, который можно подготовить.
Чтобы использовать эту модель, код приложения должен быть многотенантным.
Приложения для каждого клиента с общими планами
Вы также можете предоставить общий доступ к плану между несколькими клиентами, но развернуть отдельные приложения для каждого клиента. Это обеспечивает логическую изоляцию между каждым клиентом, и этот подход дает следующие преимущества:
- Экономичность. Общий доступ к инфраструктуре размещения позволяет сократить общие затраты на каждого клиента.
- Разделение конфигурации. Приложение каждого клиента может иметь собственное доменное имя, сертификат TLS, ограничения доступа и политики авторизации маркеров.
- Разделение обновлений: двоичные файлы каждого приложения клиента можно обновлять независимо от других приложений в одном плане.
Тем не менее, так как вычислительные ресурсы плана являются общими, приложения могут быть подвержены проблеме Шумного соседа. Кроме того, существуют ограничения на то, сколько приложений можно развернуть в одном плане.
Примечание.
Не используйте слоты развертывания для разных клиентов. Слоты не обеспечивают изоляцию ресурсов. Они предназначены для сценариев развертывания, если вам нужно иметь несколько версий приложения, работающих в течение короткого времени, таких как сине-зеленые развертывания и стратегия развертывания канарной версии.
Планы для каждого клиента
Самый сильный уровень изоляции — развертывание выделенного плана для клиента. Этот выделенный план гарантирует, что клиент полностью использует все серверные ресурсы, выделенные этому плану.
Этот подход позволяет масштабировать решение, чтобы обеспечить изоляцию производительности для каждого клиента и избежать проблемы с шумным соседом. Однако она также имеет более высокую стоимость, так как ресурсы не совместно используются несколькими клиентами. Кроме того, необходимо учитывать максимальное количество планов , которые можно развернуть в одной группе ресурсов Azure.
API узла
Api можно размещать как в службе приложение Azure, так и в Функции Azure. Выбор платформы зависит от определенного набора функций и параметров масштабирования.
Независимо от платформы, используемой для размещения API, рекомендуется использовать Azure Управление API перед приложением API. Управление API предоставляет множество функций, которые могут быть полезны для мультитенантных решений, включая следующие:
- Централизованная точка для всей проверки подлинности. Это может включать определение идентификатора клиента из утверждения токена или других метаданных запроса.
- Маршрутизация запросов на различные серверные серверы API, которые могут быть основаны на идентификаторе клиента запроса. Это может быть полезно при размещении нескольких меток развертывания с собственными независимыми приложениями API, но вам потребуется один URL-адрес API для всех запросов.
Сеть и мультитенантность
IP-адреса
Многие мультитенантные приложения должны подключаться к локальным сетям клиентов для отправки данных.
Если необходимо отправить исходящий трафик из известного статического IP-адреса или из набора известных статических IP-адресов, рассмотрите возможность использования шлюза NAT. Дополнительные сведения об использовании шлюза NAT в мультитенантных решениях см . в рекомендациях по мультитенантности шлюза Azure NAT. Служба приложений предоставляет рекомендации по интеграции с шлюзом NAT.
Если вам не нужен статический исходящий IP-адрес, но вместо этого необходимо иногда проверка IP-адрес, который используется приложением для исходящего трафика, можно запросить текущие IP-адреса развертывания Служба приложений.
Планы продаж
Так как Служба приложений является мультитенантной службой, необходимо заботиться о том, как вы используете общие ресурсы. Сеть — это область, в которую необходимо обратить особое внимание, так как существуют ограничения , влияющие на работу приложения с исходящими и исходящими сетевыми подключениями, включая преобразование сетевых адресов источника (SNAT) и ограничения TCP-портов.
Если приложение подключается к большому количеству баз данных или внешних служб, ваше приложение может столкнуться с угрозой исчерпания портов SNAT. Как правило, исчерпание портов SNAT указывает на то, что код неправильно использует TCP-подключения, а даже в мультитенантном решении следует соблюдать рекомендации по повторному использованию подключений.
Однако в некоторых мультитенантных решениях количество исходящих подключений к отдельным IP-адресам может привести к исчерпанию портов SNAT, даже если следовать рекомендациям по программированию. В этих сценариях рассмотрите один из следующих вариантов:
- Разверните шлюз NAT, чтобы увеличить количество портов SNAT, доступных для вашего приложения. Дополнительные сведения об использовании шлюза NAT в мультитенантных решениях см . в рекомендациях по мультитенантности шлюза Azure NAT.
- Используйте конечные точки службы при подключении к службам Azure для обхода ограничений подсистемы балансировки нагрузки.
Даже при использовании этих элементов управления можно приблизиться к ограничениям с большим количеством клиентов, поэтому следует спланировать масштабирование до дополнительных Служба приложений планов или меток развертывания.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Джон Даунс | Главный инженер клиента, FastTrack для Azure
Другие участник:
- Тиаго Алмейда | Главный диспетчер программ, Функции Azure
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Просмотрите ресурсы для архитекторов и разработчиков мультитенантных решений.