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

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

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

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

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

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

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

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

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

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

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

Используйте n-уровневую архитектуру для следующих сценариев:

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

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

Льготы

• Возможность переноса между облаком и локальной средой, а также между облачными платформами.
• Быстрый процесс обучения для большинства разработчиков.
• Относительно низкая стоимость путем не перепроектирования решения
• Естественный процесс перехода от традиционной модели приложений.
• Открытость для разнородных сред (Windows или Linux).

Сложности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Чтобы обеспечить высокий уровень доступности, разместите два или несколько модулей NVA в группе доступности с внешней подсистемой балансировки нагрузки для распределения запросов из Интернета по экземплярам. Дополнительные сведения см. в статье Deploy highly available network virtual appliances (Развертывание виртуальных сетевых модулей высокой доступности).

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

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

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

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

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

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