Что означает архитектура N-уровня?

В традиционном смысле N-уровень означает разделение приложения на "уровни" и размещение каждого "уровня" на разных серверах. Это было сделано по крайней мере по трем причинам:

  • Обслуживание:

    a) Обслуживание кода: упростить исправления ошибок и дополнения к функциям.

    b) Техническое обслуживание аппаратного обеспечения: отказ одного сервера не прерывает обслуживание с другого уровня.

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

  • Масштабируемость: в частности горизонтальная масштабируемость

    a) Отказоустойчивость: Возможность иметь более 1 физического сервера на уровне уровня, когда 1 сервер выключен, приложение все еще может функционировать в целом.

    b) Балансировка нагрузки: наличие нескольких экземпляров уровня помогает обслуживать большое количество запросов.

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

Я думаю, что сейчас, когда люди говорят о архитектуре N-уровня, они говорят о разделении проблем в приложении. Это скорее логическое разделение, чем физическое. Я думаю, что до тех пор, пока мы достигнем хорошего разделения проблем и развязки, приложения не должны быть N-уровнями. Просто кажется, что многие программисты считают, что архитектура N-уровня является золотым стандартом, которым должно соответствовать каждое веб-приложение.

Итак, что такое архитектура N-уровня для вас в настоящее время?

Ответы

Ответ 1

Из статьи в Википедии я читал:

Как правило, термины ярусов используются для описания физического распределения компоненты системы на отдельных серверах, компьютерах или сетях (обрабатывающие узлы). Затем трехуровневая архитектура будет иметь три обрабатывающих узлов. Слои относятся к логической группировке компонентов который может или не может быть физически расположен на одной обработке node.

Я действительно думаю, что понятие "слой" и понятие "ярус" со временем перепутались. Мне лично нравится говорить только о слоях, а не о том, как я предпочитаю решения PAAS, где мои проблемы касаются только программного обеспечения, и индустрия медленно движется в этом направлении.

Также, когда вы планируете приложение, которое может значительно расширяться, я все равно не думаю, что вы должны думать о n-уровне для масштабируемости. На самом деле, очень популярные сайты с большим количеством трафика разделяют только на 3 компонента: Серверы баз данных, веб-серверы (включая серверы кеширования) и несколько CDN (сети доставки контента). Такое разделение может быть достигнуто в любом приложении.

Но в заключение я думаю, что программист должен думать только о слоях abuot и о разделении проблем в приложении для достижения самой важной (и сложной) задачи: ремонтопригодность в долгосрочной перспективе.

Ответ 2

Я думаю, что это и всегда было искусственным различием. Я согласен с вашей предпосылкой, что в основном это касается логического разделения компонентов в наши дни. Тем не менее, по-прежнему существует множество приложений, которые слишком велики (используйте мудрые или данные) для установки на одну машину, поэтому идея разделения приложения на дискретные компоненты по причинам масштабируемости определенно не мертва.

Ответ 3

Безопасность для одного? Я бы предпочел, чтобы вы удалили мои веб-серверы, чем мои серверы приложений!