Стиль архитектуры N-уровней

Архитектура N-уровня делит приложение на логические уровни и физических уровней.

Слои — это способ разделения обязанностей и управления зависимостями. Каждый слой несет определенную ответственность. Более высокий уровень может использовать службы в нижнем слое, но не наоборот.

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

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

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

Приложение уровня N может иметь архитектуру закрытого слоя или архитектуру открытого слоя :

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

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

Когда следует использовать эту архитектуру

Архитектуры N-уровней обычно реализуются как приложения инфраструктуры как услуга (IaaS), при этом каждый уровень выполняется в отдельном наборе виртуальных машин. Однако N-уровень приложения не должен быть чистым IaaS. Часто удобно использовать управляемые службы для некоторых частей архитектуры, особенно кэширования, обмена сообщениями и хранилища данных.

Рассмотрим архитектуру уровня N для следующих способов:

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

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

Преимущества

• Переносимость между облаком и локальной средой и между облачными платформами.
• Меньшая кривая обучения для большинства разработчиков.
• Относительно низкая стоимость путем не перепроектирования решения
• Естественная эволюция от традиционной модели приложения.
• Открыть разнородную среду (Windows/Linux)

Проблемы

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

Рекомендации

• Используйте автомасштабирование для обработки изменений в нагрузке. Ознакомьтесь с рекомендациями по автомасштабированию .
• Используйте асинхронного обмена сообщениями для развязки уровней.
• Кэшировать полустатические данные. Ознакомьтесь с рекомендациями по кэшированию .
• Настройте уровень базы данных для обеспечения высокой доступности, используя такое решение, как группы доступности SQL Server AlwaysOn.
• Поместите брандмауэр веб-приложения (WAF) между интерфейсом и Интернетом.
• Поместите каждый уровень в собственную подсеть и используйте подсети в качестве границы безопасности.
• Ограничить доступ к уровню данных, разрешая запросы только из среднего уровня.

Архитектура уровня N на виртуальных машинах

В этом разделе описывается рекомендуемая архитектура уровня N, выполняемая на виртуальных машинах.

архитектуры уровня N

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

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

Веб-уровни и бизнес-уровни являются без отслеживания состояния. Любая виртуальная машина может обрабатывать любой запрос для этого уровня. Уровень данных должен состоять из реплицированной базы данных. Для Windows рекомендуется использовать группы доступности AlwaysOn для обеспечения высокого уровня доступности. Для Linux выберите базу данных, которая поддерживает репликацию, например Apache Cassandra.

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

Дополнительные рекомендации

• Архитектуры N-уровней не ограничиваются тремя уровнями. Для более сложных приложений обычно используется больше уровней. В этом случае рекомендуется использовать маршрутизацию уровня 7 для маршрутизации запросов к конкретному уровню.

• Уровни — это граница масштабируемости, надежности и безопасности. Рассмотрите возможность наличия отдельных уровней для служб с различными требованиями в этих областях.

• Используйте масштабируемые наборы виртуальных машин для автомасштабирования.

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

• Для повышения безопасности поместите сеть dmZ перед приложением. DmZ включает сетевые виртуальные устройства (NVA), которые реализуют функции безопасности, такие как брандмауэры и проверка пакетов. Дополнительные сведения см. в эталонной архитектуре сети DMZ.

• Для обеспечения высокой доступности разместите два или более NVA в группе доступности с внешней подсистемой балансировки нагрузки для распределения запросов в Интернете по экземплярам. Дополнительные сведения см. в статье Развертывание высокодоступных виртуальных сетевых устройств.

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

• Вы можете расширить виртуальную сеть Azure в локальной сети с помощью виртуальной частной сети типа "сеть — сеть" или Azure ExpressRoute. Дополнительные сведения см. в эталонной архитектуре гибридной сети.

• Если ваша организация использует Active Directory для управления удостоверениями, может потребоваться расширить среду Active Directory в виртуальной сети Azure. Дополнительные сведения см. в эталонной архитектуре управления удостоверениями.

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

Связанные ресурсы

• N-уровневого приложения с apache Cassandra
• [Приложение уровня Windows в Azure с SQL Server][n-tier-windows-SQL]
• модуль Microsoft Learn : обзор стиля архитектуры N уровня
• Бастион Azure
• Дополнительные сведения о обмене сообщениями в стиле архитектуры уровня N в Azure