Рекомендации по n-уровневым архитектурам
Мы рассмотрели составляющие n-уровневой архитектуры и развернули трехуровневую архитектуру в качестве примера. Давайте рассмотрим некоторые преимущества и трудности этого архитектурного стиля, а также рекомендации для оптимизации его производительности и безопасности.
Льготы
Этот стиль архитектуры удобен в своей простоте. Это часто используемый и хорошо известный архитектурный шаблон для локальных и облачных развертываний, который подходит для широкого рядя приложений.
Такая архитектура не зависит от платформы и работает с Windows или Linux. Как мы показали в нашем примере среды, можно использовать службы PaaS или IaaS на любом уровне.
Когда приложение разделено на уровни, каждый уровень можно масштабировать или обновлять независимо от других. Если количество запросов к веб-сайту возрастает, можно добавить дополнительные веб-серверы, не затрагивая другие уровни. Аналогичным образом, если возрастает количество запросов к уровню данных, можно масштабировать базу данных, чтобы ей хватало мощности для обработки запросов.
Разделение сети является естественным побочным эффектом этой архитектуры. Так как приложение разделено на уровни, мы изолируем каждый из них и разрешаем только необходимый сетевой доступ. Уровень представления может быть открыт для Интернета, база данных может полностью находиться за несколькими сетевыми уровнями, а наше приложение будет функционировать точно так же. Защищая сетевой доступ между уровнями, мы сокращаем направления атак на приложение и повышаем его безопасность.
Проблемы и решения
Разделяя приложение на уровни, избегайте средних уровней, которые выполняют только операции с базой данных. Каждый уровень должен выполнять конкретные задачи. Дополнительные уровни добавляют сложность, время обработки, задержку и в конечном счете задержку пользователю.
Так как API для каждого домена уровня приложения не разделены на отдельные службы, их необходимо масштабировать вместе. Если один метод приложения требует дополнительные вычислительные мощности или должен обрабатывать больше запросов, чем другие, необходимо масштабировать уровень приложения как единое целое, а не отдельную службу, чтобы справиться с нагрузкой.
В некоторых случаях вы можете разрабатывать приложение как n-уровневую архитектуру, но развертывать его как монолит. Если вы полностью разделили уровни, развертывайте их по отдельности. Полное разделение включает удаление общих зависимостей и более высокую зависимость от вызовов API между уровнями. При правильном выполнении это гарантирует, что развертывания приложений являются гибкими.
Приложения в n-уровневой архитектуре часто развертываются на виртуальных машинах. Это хороший первый шаг, но если ваше приложение будет использовать службы PaaS, вам будут доступны многочисленные преимущества безопасности, масштабируемости и администрирования. Разработчики часто упускают из виду такую возможность развития, и n-уровневые архитектуры остаются на виртуальных машинах.
N-уровень является классическим архитектурным стилем, но во многих сценариях он заменен другими современными шаблонами дизайна, такими как архитектура микрослужб. Часто стоит инвестировать некоторое время, чтобы оценить другие архитектуры, чтобы увидеть, лучше ли они подходят для вашего приложения.
Рекомендации по n-уровневой архитектуре
Существует несколько моментов, которые следует учесть для эффективного использования n-уровневой архитектуры. На следующей схеме показано, как можно совершенствовать n-уровневую архитектуру.
Оптимизация производительности
Давайте рассмотрим способы оптимизации производительности и безопасности в n-уровневой архитектуре.
Автомасштабирование
Когда приложение разделено на уровни, для адаптации к нагрузкам на систему можно использовать облачные функции, такие как автомасштабирование. По мере увеличения пользователей или запросов автомасштабирование на нескольких уровнях добавляет ресурсы для обработки запросов. Когда число запросов снижается, автомасштабирование сокращает вычислительные ресурсы и, следовательно, затраты. Автомасштабирование позволяет легко гарантировать оптимальное взаимодействие с пользователем при низких затратах. Можно использовать Масштабируемые наборы виртуальных машин Azure для рабочих нагрузок на основе виртуальных машин, а многие службы PaaS, такие как Служба приложений Azure, имеют встроенные возможности автомасштабирования.
Балансировка нагрузки
Когда вы увеличиваете масштаб приложения с помощью автомасштабирования, балансировка нагрузки становится неотъемлемой частью архитектуры. При балансировке нагрузки при добавлении дополнительных вычислительных ресурсов на уровень они добавляются в распределение подсистемы балансировки нагрузки для использования дополнительных вычислительных ресурсов. И наоборот, если система завершается сбоем, она удаляется из нагрузки, чтобы свести к минимуму влияние пользователей через низкую производительность или запросы на ошибку. Это гарантирует, что запросы пользователей будут поступать к работоспособным системам. Подсистема балансировки нагрузки Azure — это встроенная функция сетевых возможностей, а шлюз приложений предоставляет расширенное решение по балансировке нагрузки HTTP.
Обмен сообщениями
Использование службы обмена сообщениями между уровнями оказывает положительное влияние на производительность, особенно на запросы, которые являются асинхронными в природе. Служба помещает сообщение в очередь, где она остается до обработки, смещая влияние нижней нагрузки. Если происходит сбой системы, служба обмена сообщениями гарантирует, что ваше сообщение по-прежнему обрабатывается. Сообщение остается в очереди и обрабатывается после восстановления системы в сети. Azure предлагает несколько решений по обмену сообщениями на выбор в зависимости от требований. Среди них — служебная шина Azure, очереди службы хранилища Azure и центры событий Azure.
Кэширование данных
Используйте кэш для данных, которые часто используются и редко меняются, или для данных, не требующих долгосрочного хранения, таких как состояние сеанса. Системы кэширования располагаются между уровнями и сокращают время извлечения данных такого типа. Кэш Azure для Redis — это служба PaaS, которая хорошо подходит для этого сценария.
Оптимизация безопасности
Оптимизация приложения для обеспечения безопасности часто является заданием, которое никогда не выполняется. Несмотря на то, что приложение разделено на уровни, в архитектуре по-прежнему должны быть хорошо запланированные методики безопасности. Чем больше уровней вы добавляете, тем больше необходимо обеспечить безопасность и тем больше сложности в системе. Существует несколько моментов, которые нужно учитывать, чтобы ваша архитектура обеспечивала безопасную среду для запуска приложения.
Сетевая изоляция
При запуске N-уровня архитектуры на виртуальных машинах убедитесь, что каждый уровень находится в собственной подсети. Эта подсеть выступает в качестве границы безопасности, что позволяет изолировать подключение через списки управления доступом к сети. Подсеть также упрощает управление, гарантируя, что новые системы в подсети получают те же правила. В Azure эта функция предусмотрена в виде групп безопасности сети (NSG). Те же принципы относятся к службам PaaS, но возможности интеграции сети различаются в зависимости от службы и должны оцениваться отдельно. Лучше всего убедиться, что каждый уровень может взаимодействовать только со следующим уровнем под ним. Уровень представления должен взаимодействовать только с уровнем приложения, а уровень приложения — только с уровнем данных. Ограничение этого взаимодействия обеспечивает многоуровневый подход к безопасности сети, а также повышает общий уровень защищенности архитектуры.
Брандмауэр веб-приложения
Если вы изолировали подсети, необходимо убедиться в безопасности общедоступного интерфейса и разрешить доступ только к самому необходимому. Вы должны предоставлять доступ только к уровню презентации для входящего интернет-трафика. Технология брандмауэра веб-приложения (WAF) перед уровнем презентации повышает безопасность на этом уровне. WAF проверяет трафик на предмет вредоносных действий, обеспечивает шифрование подключений и предупреждает вас обо всех необычных событиях. В Azure Шлюз приложений является подсистемой балансировки нагрузки HTTP со встроенным WAF, который можно включить.