Эта эталонная архитектура предоставляет рекомендации по развертыванию критически важной рабочей нагрузки, которая использует централизованные общие службы, нуждается в локальном подключении и интегрируется с другими рабочими нагрузками предприятия. Это руководство предназначено для владельца рабочей нагрузки, который является частью команды приложений в организации.
Вы можете оказаться в такой ситуации, когда ваша организация хочет развернуть рабочую нагрузку в целевой зоне приложения Azure , которая наследует группу управления corp. Ожидается, что рабочая нагрузка будет интегрирована с предварительно подготовленными общими ресурсами в целевой зоне платформы Azure , которые управляются централизованными командами.
Важно!
Что такое целевая зона Azure? Целевая зона приложения — это подписка Azure, в которой выполняется рабочая нагрузка. Она подключена к общим ресурсам организации. Через это подключение у него есть доступ к базовой инфраструктуре, необходимой для выполнения рабочей нагрузки, например к сети, управлению доступом к удостоверениям, политикам и мониторингу. Целевые зоны платформы — это коллекция различных подписок, каждая из которых имеет определенную функцию. Например, подписка на подключение обеспечивает централизованное разрешение DNS, локальное подключение и сетевые виртуальные модули (NVA), доступные для использования командами приложений.
Как владелец рабочей нагрузки вы получаете преимущество, разгружая управление общими ресурсами в центральные команды и фокусируясь на разработке рабочих нагрузок. Организация выигрывает, применяя согласованное управление и амортизацию затрат для нескольких рабочих нагрузок.
Настоятельно рекомендуется понимать концепцию целевых зон Azure.
При таком подходе максимальная надежность является общей ответственностью между вами и командой платформы. Компоненты, управляемые централизованно, должны быть высоконадежными, чтобы критически важные рабочие нагрузки работали должным образом. Вы должны иметь доверительные отношения с командой платформы, чтобы проблемы недоступности в централизованных службах, влияющие на рабочую нагрузку, устранялись на уровне платформы. Но ваша команда отвечает за требования к команде платформы для достижения ваших целей.
Эта архитектура основана на критически важной базовой архитектуре с элементами управления сетью. Прежде чем продолжить работу с этой статьей, рекомендуется ознакомиться с базовой архитектурой .
Примечание
Руководство подкреплено примером реализации производственного уровня, демонстрирующим разработку критически важных приложений в Azure. Эту реализацию можно использовать в качестве основы для дальнейшей разработки решения в качестве первого шага на пути к рабочей среде.
Ключевые стратегии проектирования
Примените следующие стратегии поверх критически важных базовых показателей:
Критический путь
Не все компоненты архитектуры должны быть одинаково надежными. Критический путь включает в себя компоненты, которые должны поддерживать работоспособность, чтобы в рабочей нагрузке не было простоя или снижения производительности. Сохранение этого пути сведено к минимуму точек отказа.
Жизненный цикл компонентов
Рассмотрим жизненный цикл критически важных компонентов, так как он влияет на достижение цели достижения почти нулевого времени простоя. Компоненты могут быть временными или кратковременными ресурсами, которые можно создавать и уничтожать по мере необходимости; неэфемерные или долгоживущие ресурсы, которые совместно используют время существования с системой или регионом.
Внешние зависимости
Сведите к минимуму внешние зависимости от компонентов и процессов, что может привести к точкам сбоя. В архитектуре есть ресурсы, принадлежащие различным командам за пределами вашей команды. Эти компоненты (если они критически важны) область для этой архитектуры.
топология использования подписки;
Целевые зоны Azure не подразумевают одну топологию подписки. Заранее спланируйте объем подписки вместе с командой платформы, чтобы обеспечить соответствие требованиям к надежности рабочей нагрузки во всех средах.
Автономная наблюдаемость на критическом пути
У вас есть выделенные ресурсы мониторинга, которые позволяют команде быстро запрашивать сбор данных (особенно по критическому пути) и принимать меры по исправлению.
Архитектура
Скачайте файл Visio этой архитектуры.
Компоненты этой архитектуры аналогичны критически важной базовой архитектуре с сетевыми элементами управления. Описания сокращены для краткости. Дополнительные сведения см. в связанных статьях. Документацию по продуктам о службах Azure см. в разделе Связанные ресурсы.
Глобальные ресурсы
Эти ресурсы живут в подписках целевой зоны приложения. Глобальные ресурсы не являются временными и совместно используют время существования системы. Службы Azure и их конфигурация остаются такими же, как и базовые глобальные ресурсы.
Региональные сетевые ресурсы
Эти ресурсы живут в подписках целевой зоны платформы и подписках целевой зоны приложения. Базовая архитектура развертывает все ресурсы, принадлежащие вам. Однако в этой архитектуре сетевые ресурсы предоставляются через подписку на подключение , подготавливаются как часть целевой зоны платформы.
В этой статье см. раздел Виртуальная сеть регионального концентратора .
Ресурсы региональной метки
Эти ресурсы живут в подписках целевой зоны приложения. Эти ресурсы не имеют общего доступа к другим ресурсам, за исключением глобальных ресурсов.
Большинство служб Azure и их конфигурация остаются такими же, как и базовая архитектура меток, за исключением сетевых ресурсов, которые предварительно подготовлены командой платформы.
В этой статье см. раздел Региональная периферийная виртуальная сеть .
Внешние ресурсы
Рабочая нагрузка взаимодействует с локальными ресурсами. Некоторые из них находятся на критическом пути для рабочей нагрузки, например локальная база данных. Эти ресурсы и взаимодействие с ними учитываются в общем составном соглашении об уровне обслуживания (SLA) рабочей нагрузки. Все обмен данными осуществляется через подписку на подключение. Существуют и другие внешние ресурсы, которые могут быть доступны рабочей нагрузке, но они не считаются критически важными.
Ресурсы конвейера развертывания
Конвейеры сборки и выпуска для критически важных приложений должны быть полностью автоматизированы, чтобы гарантировать согласованный способ развертывания проверенной метки. Эти ресурсы остаются теми же, что и конвейер базового развертывания.
Региональные ресурсы мониторинга
Эти ресурсы живут в подписках целевой зоны приложения. Данные мониторинга для глобальных и региональных ресурсов хранятся независимо друг от друга. Службы Azure и их конфигурация остаются такими же, как и базовые ресурсы мониторинга.
В этой статье см. раздел Рекомендации по мониторингу .
Ресурсы управления
Для получения доступа к частному вычислительному кластеру и другим ресурсам в этой архитектуре используются частные агенты сборки и экземпляры виртуальных машин jump box. Бастион Azure обеспечивает безопасный доступ к полям перехода. Ресурсы внутри меток остаются такими же, как и базовые ресурсы управления.
Рекомендации по работе с сетями
В этом случае рабочая нагрузка развертывается в целевой зоне приложения и требует подключения к федеративным ресурсам в целевой зоне платформы. Целью может быть доступ к локальным ресурсам, управление исходящим трафиком и т. д.
Топология сети
Команда платформы определяет топологию сети для всей организации. В этой архитектуре предполагается звездообразная топология. Альтернативой может быть Azure Виртуальная глобальная сеть.
Виртуальная сеть регионального концентратора
Подписка на подключение содержит центральную виртуальную сеть с ресурсами, которые совместно используются всей организацией. Эти ресурсы принадлежат и обслуживаются команде платформы.
С критически важной точки зрения эта сеть не является эфемерной, и эти ресурсы находятся на критическом пути.
| Ресурс Azure | Назначение |
|---|---|
| Azure ExpressRoute | Обеспечивает частное подключение из локальной среды к инфраструктуре Azure. |
| Брандмауэр Azure | Действует как NVA, который проверяет и ограничивает исходящий трафик. |
| Azure DNS | Обеспечивает разрешение имен в разных средах. |
| VPN-шлюз | Подключает удаленные ветви организации через общедоступный Интернет к инфраструктуре Azure. Также выступает в качестве альтернативы резервному подключению для повышения устойчивости. |
Ресурсы подготавливаются в каждом регионе и пиринговые подключения к периферийной виртуальной сети (см. далее). Убедитесь, что вы понимаете и согласны с обновлениями NVA, правилами брандмауэра, правилами маршрутизации, отработка отказа ExpressRoute для VPN-шлюз, инфраструктуры DNS и т. д.
Примечание
Ключевое преимущество использования федеративного концентратора заключается в том, что рабочая нагрузка может интегрироваться с другими рабочими нагрузками в Azure или в нескольких средах путем обхода сетевых концентраторов, управляемых организацией. Это изменение также снижает эксплуатационные расходы, так как часть ответственности перекладывается на команду платформы.
Региональная периферийная виртуальная сеть
Целевая зона приложения содержит по крайней мере две предварительно подготовленные виртуальные сети Azure для каждого региона, на которые ссылаются региональные метки. Эти сети не являются временными. Один из них обслуживает рабочий трафик, а другой предназначен для развертывания vNext. Такой подход дает возможность выполнять надежные и безопасные методы развертывания.
Операции виртуальной сети
Рабочий трафик изолирован в отдельной виртуальной сети. Эта виртуальная сеть не является эфемерной, и вы владеете этой сетью. Эта архитектура сохраняет ту же структуру, что и базовая архитектура с сетевыми элементами управления.
Пиринг между операционной сетью и периферийной сетью не существует. Весь обмен данными осуществляется через Приватные каналы.
Совместная ответственность
Четкое представление о том, какая команда отвечает за каждый элемент проектирования архитектуры. Ниже приведены некоторые ключевые аспекты.
Планирование IP-адресов
После оценки размера, необходимого для выполнения рабочей нагрузки, обратитесь к команде платформы, чтобы они могли соответствующим образом подготовить сеть.
Команда платформы
Укажите отдельные адреса для виртуальных сетей, участвующих в пиринге. Перекрывающиеся адреса, например локальные сети и сети рабочей нагрузки, могут привести к сбоям.
Выделите достаточно большие пространства IP-адресов для размещения ресурсов среды выполнения и развертываний, обрабатывайте отработку отказа и поддерживайте масштабируемость.
Предварительно подготовленные виртуальные сети и пиринги должны поддерживать ожидаемый рост рабочей нагрузки. Вы должны регулярно оценивать этот рост вместе с командой платформы. Дополнительные сведения см. в статье Подключение к Azure.
Подсеть региональной периферийной сети
Вы несете ответственность за выделение подсетей в региональной виртуальной сети. Подсети и ресурсы в них являются временными. Адресное пространство должно быть достаточно большим, чтобы обеспечить потенциальный рост.
Подсеть частных конечных точек После того как трафик достигает виртуальной сети, обмен данными со службами PaaS в сети ограничивается с помощью частных конечных точек, как и базовая архитектура с сетевыми элементами управления. Эти конечные точки размещаются в выделенной подсети. Частные IP-адреса частным конечным точкам назначаются из этой подсети.
Подсеть кластера Требования к масштабируемости рабочей нагрузки влияют на объем адресного пространства, которое должно быть выделено для подсетей. По мере увеличения масштаба узлов и модулей pod AKS IP-адреса назначаются из этой подсети.
сегментация сети.
Поддерживайте правильную сегментацию, чтобы надежность рабочей нагрузки не была скомпрометирована несанкционированным доступом.
В этой архитектуре используются группы безопасности сети (NSG) для ограничения трафика между подсетями и подпиской на подключение. Группы безопасности сети используют теги службы для поддерживаемых служб.
Команда платформы
Принудительное использование групп безопасности сети с помощью политик Диспетчера сети Azure.
Учитывайте структуру рабочей нагрузки. Между метками нет прямого трафика. Кроме того, нет потоков между регионами. Если эти пути необходимы, трафик должен проходить через подписку на подключение.
Предотвратить ненужный трафик концентратора, исходящий из других рабочих нагрузок, в критически важную рабочую нагрузку.
Исходящий трафик из региональных меток
Весь исходящий трафик из каждой региональной периферийной сети направляется через централизованный Брандмауэр Azure в сети регионального концентратора. Он выступает в качестве следующего прыжка, который проверяет, а затем разрешает или запрещает трафик.
Команда платформы
Создайте определяемые пользователем маршруты для этого пользовательского маршрута.
Назначьте политики Azure, которые блокируют команде приложений создание подсетей, в которых нет новой таблицы маршрутов.
Предоставьте команде приложений соответствующие разрешения на управление доступом на основе ролей (RBAC), чтобы они могли расширять маршруты в соответствии с требованиями рабочей нагрузки.
Избыточность в нескольких регионах
Критически важные рабочие нагрузки должны быть развернуты в нескольких регионах, чтобы выдержать региональные сбои. Обратитесь к команде платформы, чтобы убедиться, что инфраструктура надежна.
Команда платформы
Развертывание централизованных сетевых ресурсов для каждого региона. Критически важная методология проектирования требует региональной изоляции.
Обратитесь к группе разработчиков приложений, чтобы выявить скрытые региональные зависимости, чтобы ресурс платформы с пониженной производительности в одном регионе не влиял на рабочие нагрузки в другом регионе.
Разрешение DNS
Подписка на подключение предоставляет частные зоны DNS. Однако этот централизованный подход может не учитывать потребности DNS, которые могут быть характерными для вашего варианта использования. Подготовьте собственные зоны DNS и свяжите ссылку на региональную метку. Если команда приложений не владеет DNS, управление приватными каналами становится сложной задачей для глобальных ресурсов, таких как Azure Cosmos DB.
Команда платформы
Делегируйте зоны Частная зона DNS Azure команде приложений, чтобы охватить их варианты использования.
Для региональной сети концентратора задайте для ПАРАМЕТРА DNS-серверы значение По умолчанию (предоставляется Azure) для поддержки частных зон DNS, управляемых командой приложений.
Рекомендации по проектированию среды
Обычно рабочие нагрузки размещаются в отдельных средах для рабочей среды, подготовки и разработки. Ниже приведены некоторые ключевые рекомендации.
Как поддерживается изоляция?
Рабочая среда должна быть изолирована от других сред. Более низкие среды также должны поддерживать уровень изоляции. Избегайте совместного использования ресурсов, принадлежащих приложению, между средами.
Для глобальных, региональных ресурсов и ресурсов меток, принадлежащих команде приложений, требуется одна рабочая среда. Предварительные среды, такие как промежуточная среда и интеграция, необходимы для максимальной проверки приложения в среде, которая имитирует рабочую среду. Среда разработки должна быть уменьшенной версией рабочей среды.
Каков ожидаемый жизненный цикл?
После завершения проверочных тестов предварительные среды могут быть уничтожены. Рекомендуется, чтобы среды разработки совместно используют время существования компонента и уничтожались после завершения разработки. Эти действия выполняются путем автоматизации непрерывной интеграции и непрерывного развертывания (CI/CD).
Каковы компромиссы?
Рассмотрите компромиссы между изоляцией сред, сложностью управления и оптимизацией затрат.
Совет
Все среды должны принимать зависимости от рабочих экземпляров внешних ресурсов, включая ресурсы платформы. Например, рабочий региональный концентратор в подписке на подключение. Вы сможете свести к минимуму разницу между подготовительной и рабочей средами.
Топология подписки для инфраструктуры рабочей нагрузки
Подписки предоставляются командой платформы. В зависимости от количества сред вы запрашиваете несколько подписок только для одной рабочей нагрузки. В зависимости от типа среды для некоторых сред могут потребоваться выделенные подписки, в то время как другие среды могут быть объединены в одну подписку.
Независимо от этого, обратитесь к команде платформы, чтобы спроектировать топологию, которая соответствует общему целевому показателю надежности для рабочей нагрузки. Существует преимущество совместного использования предоставляемых платформой ресурсов между средами в одной подписке, так как они будут отражать рабочую среду.
Примечание
Использование нескольких подписок для размещения сред может обеспечить необходимый уровень изоляции. Подписки целевой зоны наследуются от одной группы управления. Таким образом, для тестирования и проверки обеспечивается согласованность с рабочей средой.
Рабочая подписка
Для предоставленной вам подписки могут существовать ограничения на ресурсы. Если вы разограничите все эти ресурсы в одной подписке, вы можете достичь этих ограничений. В зависимости от единиц масштабирования и ожидаемого масштабирования рассмотрите более распределенную модель. Например,
Одна подписка, содержащая как агенты сборки Azure DevOps, так и глобальные ресурсы.
Одна подписка на регион. Он содержит региональные ресурсы, ресурсы меток и поля перехода для региональных меток.
Ниже приведен пример топологии подписки, используемой в этой архитектуре.
Предварительная подписка
Требуется по крайней мере одна подписка. Он может запускать множество независимых сред, однако рекомендуется использовать несколько сред в выделенных подписках. На эту подписку также могут распространяться ограничения ресурсов, такие как рабочая подписка, описанная выше.
Подписка на разработку
Требуется по крайней мере одна подписка. На эту подписку могут распространяться ограничения ресурсов, если выполняются все независимые среды. Таким образом, вы можете запросить несколько подписок. Рекомендуется использовать отдельные среды в выделенных подписках.
Старайтесь максимально соответствовать рабочей топологии.
Рекомендации по развертыванию
Распространенными причинами сбоев приложений являются неудачные развертывания или ошибочные выпуски. Тщательно протестируйте приложение (и новые функции) в рамках жизненного цикла приложения. При развертывании рабочей нагрузки в целевой зоне необходимо интегрировать проект с предоставляемыми платформой ресурсами и системой управления.
См. раздел Хорошо спроектированные критически важные рабочие нагрузки: развертывание и тестирование.
Развертывание инфраструктуры
Надежность инфраструктуры развертывания, такой как агенты сборки и их сеть, часто так же важна, как и ресурсы среды выполнения рабочей нагрузки.
Эта архитектура использует частные агенты сборки для предотвращения несанкционированного доступа, который может повлиять на доступность приложения.
Настоятельно рекомендуется поддерживать изоляцию между ресурсами развертывания. Инфраструктура развертывания должна быть привязана к подпискам рабочей нагрузки для этой среды. Если вы используете несколько сред в предварительных подписках, создайте дополнительное разделение, ограничив доступ только этими отдельными средами. Ресурсы развертывания по регионам можно рассматривать для повышения надежности инфраструктуры развертывания.
Развертывание с нулевым временем простоя
Обновления в приложение может привести к сбоям. Применение согласованных развертываний повысит надежность. Рекомендуется использовать следующие подходы:
- Иметь полностью автоматизированные конвейеры развертывания.
- Развертывание обновлений в предварительных средах с чистой меткой.
Дополнительные сведения см. в статье Рекомендации по развертыванию и тестированию критически важных задач.
В базовой архитектуре эти стратегии реализуются путем отмены подготовки и последующего разрыва метки при каждом обновлении. В этом случае полная отмена подготовки невозможна, так как команда платформы владеет некоторыми ресурсами. Поэтому модель развертывания была изменена.
Модель развертывания
Базовая архитектура использует модель Blue-Green для развертывания обновлений приложений. Новые метки с изменениями развертываются вместе с существующими метками. После перемещения трафика на новую метку существующая метка уничтожается.
В этом случае данная пиринговая виртуальная сеть не является эфемерной. Метка не позволяет создавать виртуальную сеть или пиринг с региональным концентратором. Вам потребуется повторно использовать эти ресурсы в каждом развертывании.
Канарееарная модель может обеспечить безопасное развертывание с возможностью отката. Сначала развертывается новая метка с изменениями кода. Конвейер развертывания ссылается на предварительно подготовленную виртуальную сеть и выделяет подсети, развертывает ресурсы, добавляет частные конечные точки. Затем он перемещает трафик в эти подсети в этой предварительно подготовленной виртуальной сети.
Если существующая метка больше не требуется, конвейер удаляет все ресурсы меток, за исключением ресурсов, принадлежащих платформе. Виртуальная сеть, параметры диагностики, пиринг, пространство IP-адресов, конфигурация DNS и управление доступом на основе ролей (RBAC) сохраняются. На этом этапе метка находится в чистом состоянии и готова к следующему новому развертыванию.
Политики Azure DINE (deploy-if-not-exists)
Целевые зоны приложений Azure могут иметь политики Azure DINE (deploy-if-not-exists). Эти проверки гарантируют, что развернутые ресурсы соответствуют корпоративным стандартам в целевых зонах приложений, даже если они принадлежат команде приложений. Возможно, между развертыванием и конечной конфигурацией ресурса может быть несоответствие.
Понимать влияние всех политик DINE, которые будут применяться к ресурсам. При внесении изменений в конфигурацию ресурсов включите намерения политик в декларативные развертывания на ранних этапах цикла разработки рабочей нагрузки. В противном случае может возникнуть смещение, что приведет к разнице между нужным и развернутным состоянием.
Управление доступом к подпискам развертывания
Рассматривайте границы подписки как границы безопасности, чтобы ограничить радиус взрыва. Угрозы могут повлиять на надежность рабочей нагрузки.
Команда платформы
- Предоставьте командам приложений авторизацию для операций с разрешениями, которые ограничены подпиской целевой зоны приложения.
Если вы выполняете несколько развертываний в одной подписке, нарушение повлияет на оба развертывания. Рекомендуется выполнять развертывания в выделенных подписках. Создайте субъекты-службы для каждой среды для поддержания логического разделения.
Субъект-служба должен обеспечить автономию над ресурсами рабочей нагрузки. Кроме того, он должен иметь ограничения, которые предотвратит чрезмерное манипулирование ресурсами платформы в подписке.
Рекомендации по мониторингу
Платформа целевой зоны Azure предоставляет общие ресурсы наблюдаемости в рамках подписок управления. Централизованная группа эксплуатации рекомендует командам приложений использовать федеративную модель. Но для критически важных рабочих нагрузок не рекомендуется использовать единое централизованное хранилище наблюдаемости, так как оно потенциально может быть единой точкой отказа. Критически важные рабочие нагрузки также создают данные телеметрии, которые могут быть неприменимы для централизованных операционных групп.
Поэтому настоятельно рекомендуется использовать автономный подход к мониторингу. Операторы рабочей нагрузки в конечном итоге отвечают за мониторинг и должны иметь доступ ко всем данным, представляющим общую работоспособность.
Базовая архитектура соответствует этому подходу и продолжается в этой эталонной архитектуре. Azure Log Analytics и приложение Azure Insights развертываются на региональном и глобальном уровнях для мониторинга ресурсов в этих областях. Агрегирование журналов, создание панелей мониторинга и оповещений — это область для вашей команды. Воспользуйтесь возможностями Диагностика Azure, которые отправляют метрики и журналы в различные приемники для поддержки требований платформы для сбора метрик журналов&.
Модель обеспечения работоспособности
Для критически важной методологии проектирования требуется модель работоспособности системы. При определении общей оценки работоспособности включите в область потоки целевой зоны платформы, от которых зависит приложение. Создавайте запросы журналов, работоспособности и оповещений для выполнения мониторинга между рабочими областями.
Команда платформы
Предоставьте запросы управления доступом на основе ролей (RBAC) и приемники журналов чтения для соответствующих ресурсов платформы, которые используются в критическом пути критически важного приложения.
Поддержите цель организации по обеспечению надежности критически важной рабочей нагрузки, предоставив команде приложений достаточно разрешений для выполнения своих операций.
В этой архитектуре модель работоспособности включает журналы и метрики из ресурсов, подготовленных в подписке на подключение. При расширении этой структуры для доступа к локальному ресурсу, такому как база данных, модель работоспособности должна включать сетевое подключение к этому ресурсу, включая границы безопасности, такие как сетевые виртуальные устройства в Azure и локальной среде. Эти сведения важны для быстрого определения первопричины и устранения последствий для надежности. Например, произошел ли сбой при попытке маршрутизации в базу данных или возникла проблема с базой данных?
См. раздел Хорошо спроектированные критически важные рабочие нагрузки: моделирование работоспособности.
Интеграция с политиками и правилами, предоставляемыми платформой
Подписка целевой зоны приложения наследует политики Azure, правила Диспетчера сети Azure и другие элементы управления из своей группы управления. Команда платформы предоставляет эти ограничения.
Для развертываний не зависите исключительно от политик, предоставляемых платформой, так как:
- Они не подходят для удовлетворения потребностей отдельных рабочих нагрузок.
- Политики и правила могут обновляться или удаляться за пределами вашей команды, что может повлиять на надежность.
Настоятельно рекомендуется создавать и назначать политики Azure в развертываниях. Эти усилия могут привести к некоторому дублированию, но это приемлемо, учитывая потенциальное влияние на надежность системы. Если в политиках платформы есть изменения, политики рабочей нагрузки по-прежнему будут действовать локально.
Команда платформы
- Привлекайте группу приложений к процессу управления изменениями политик по мере их развития.
- Помните о политиках, используемых командой приложений. Оцените, следует ли добавить их в группу управления.
Развертывание архитектуры
Сетевые аспекты этой архитектуры реализованы в реализации критически важных подключений.
Примечание
Подключенная реализация предназначена для демонстрации критически важной рабочей нагрузки, которая использует ресурсы организации, интегрируется с другими рабочими нагрузками и использует общие службы. Реализация предполагает, что подписка на подключение уже существует.
Дальнейшие действия
Ознакомьтесь с областью проектирования сетей и подключений в Azure Well-Architected Framework.
Связанные ресурсы
Помимо служб Azure, используемых в базовой архитектуре, эти службы важны для этой архитектуры.