Проектирование распределенной сетевой архитектуры
В распределенном приложении важно убедиться, что компоненты могут надежно взаимодействовать, и запросы могут направляться в другой компонент или регион при сбое.
Мы решили переархитировать портал доставки в Azure, чтобы снизить уязвимость к региональной ошибке. Мы хотим убедиться, что при недоступности основного региона приложение переключается на резервные компоненты в резервном регионе. Отработка отказа должна привести к минимальному нарушению доставки служб пользователям.
Здесь мы узнаем, как Azure DNS, диспетчер трафика, Front Door и Azure CDN поддерживают архитектуру приложения компании доставки.
Azure DNS
Напомним, что нам не нужны какие-либо изменения для реализации Azure DNS. Мы используем Azure DNS для размещения записей доменных имен, определяющих наше приложение.
Azure DNS полностью обеспечивает разрешение имен через инфраструктуру Azure. Эта служба изначально является многорегиональной, поэтому нет необходимости изменять существующую конфигурацию Azure DNS для поддержки функциональности в нашем новом архитектурном дизайне.
Соглашение об уровне обслуживания Azure DNS также имеет 100% гарантирует, что допустимые запросы DNS получают ответ от по крайней мере одного сервера доменных имен Azure DNS все время.
Выбор маршрутизатора трафика
Нам нужна служба, которая может сбалансировать и перенаправить трафик в нескольких регионах с распределенными веб-приложениями.
Azure предоставляет несколько различных служб, которые могут направлять трафик между интерфейсными компонентами. Помните, что нам нужно заменить шлюз приложений Azure, так как он привязан к одному региону. Если этот регион не функционирует, маршрутизацию невозможно выполнить.
В Azure есть два маршрутизатора трафика, которые могут выполнять глобальную маршрутизацию между несколькими регионами и не уязвимы для одного региона сбоя:
- Диспетчер трафика Azure
- Azure Front Door
Давайте рассмотрим эти службы более подробно, чтобы мы могли выбрать правильный маршрутизатор для нашего приложения.
Что такое диспетчер трафика Azure?
Диспетчер трафика Azure — это глобальная подсистема балансировки нагрузки, которая использует записи DNS для маршрутизации трафика в назначения в нескольких регионах Azure.
Мы можем настроить диспетчер трафика для маршрутизации всех запросов в основной регион и отслеживать скорость реагирования службы приложений в этом регионе. Если служба приложений в основном регионе завершается ошибкой, диспетчер трафика автоматически перенаправляет запросы пользователей в службу приложений во вторичном регионе. Это переключение маршрута выполняет отработку отказа, обеспечивая непрерывность обслуживания. Мы называем это режимом приоритета маршрутизации .
Так как диспетчер трафика использует систему DNS для маршрутизации трафика, он направляет любой протокол, а не только HTTP-трафик. Однако диспетчер трафика не может маршрутизировать или фильтровать трафик на основе свойств HTTP, таких как коды стран клиента или заголовки агента пользователя. Кроме того, он не может выполнять завершение протокола TLS, когда маршрутизатор расшифровывает запросы и шифрует ответы, чтобы снять нагрузку с виртуальных серверов службы приложений. Если нам нужна любая из этих функций, мы должны использовать Azure Front Door.
Диспетчер трафика использует высококонфигурируемый мониторинг конечных точек. Например, можно определить протокол, порт, путь, настраиваемые параметры заголовка, ожидаемые диапазоны кодов состояния и допустимое количество сбоев. Мониторинг конечных точек дает нам непрерывную идею о общей работоспособности всех частей нашего приложения.
Что такое Azure Front Door?
Как и диспетчер трафика, Azure Front Door — это глобальная подсистема балансировки нагрузки. В отличие от диспетчера трафика, он работает на уровне сетевого приложения, уровне 7 и использует свойства HTTP и HTTPS для фильтрации и маршрутизации.
С помощью Front Door можно выполнять множество типов маршрутизации, которые диспетчер трафика не поддерживает. Например, мы можем маршрутизировать трафик на основе кода страны браузера. Front Door также поддерживает завершение протокола TLS.
Однако существует исключение. Если мы хотим маршрутизировать трафик для любого протокола, отличного от ПРОТОКОЛА HTTP и HTTPS, необходимо использовать диспетчер трафика.
Front Door позволяет нам назначать приоритеты различным бэкендам, которые составляют портал отслеживания. Эти приоритеты позволяют Front Door направлять запросы по мере необходимости. Мы назначаем наши службы основного региона с главным приоритетом и службы вторичного региона с более низким приоритетом.
Front Door реализует проверки состояния для мониторинга работоспособности служб, и в случае сбоя он может правильно перенаправить трафик. Режим маршрутизации приоритета и мониторинг конечных точек в Front Door аналогичен этим функциям в диспетчере трафика, за исключением того, что пробы работоспособности всегда работают по протоколу HTTP.
Весь трафик веб-интерфейса нашего портала доставки и его API осуществляется по протоколу HTTPS и позволяет переключить диспетчер трафика Azure на Front Door. Мы также можем настроить Front Door с приоритетом назначения серверной части.
Azure CDN
В нашей архитектуре с одним регионом мы использовали Azure CDN для кэширования статического содержимого из хранилища BLOB-объектов Azure. Служба Azure CDN — это глобальная сеть серверов, которые кэшируют статическое содержимое, близкое к пользователям. Нам не нужно изменять эту службу для архитектуры с несколькими регионами. Однако в следующем уроке мы рассмотрим нашу учетную запись хранения Azure.