N-уровневые архитектурные шаблоны для веб-приложений

Question

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

• один сервер : все части приложения работают на одном сервере (база данных, приложение, веб-сервер, прослушивающий порт 80 и т. Д.)
• простой 2-уровневый : база данных работает на одном сервере «БД», все остальные части на уровне «appserver», который может содержать любое количество серверов. Уровни связываются через ODBC или тому подобное.
• из этого, вариации (сколько? Мы можем перечислить их?) Включают в себя серверы БД с одним главным / несколькими ведомыми и серверы с несколькими главными БД
• 3-уровневый : база данных работает на одном уровне, бизнес-объекты и логика - на втором уровне, презентация - на третьем уровне, где 1 и 2 взаимодействуют через ODBC, а 2 и 3 - в некоторой форме. удаленные вызовы (например, RMI)
• Похоже, из какой-то презентации я вспомнил, что когда-то eBay имела архитектуру, в которой уровень приложения генерировал XML, который затем был преобразован в HTML на отдельном уровне. Это обычное дело или странность?
• куча веб-приложений используют memcachedb или что-то подобное для ускорения работы. Возможно, набор серверов кэширования - это еще один уровень?

Не могли бы вы помочь мне перечислить некоторые из этих шаблонов или указать места, где некоторые из них были описаны?

Answer 1

Вам может понравиться десятилетняя, но все еще актуальная классика Создание крупномасштабного сайта электронной коммерции с Apache и mod_perl . Их уровни были:

1. Балансировщики нагрузки
2. Обратные прокси
3. Веб / серверы приложений
4. Серверы баз данных

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

Обратите внимание, что они использовали mod_perl, что означает, что их веб-серверы были их серверами приложений. Если бы вы использовали Java в то время, вы бы запустили серверы приложений как уровень позади веб-серверов (и под «веб-серверами» я имею в виду Apache, обрабатывающий синтаксический анализ HTTP, TLS и статические файлы; выборка и перенос, но не логика) и связал их с AJP. Вы все еще можете сделать это сегодня, но с большей вероятностью вы просто будете использовать серверы приложений в качестве веб-серверов (то есть вообще не использовать Apache, только JBoss или аналогичный). Серверы приложений теперь достаточно надежны для этого, и вы можете полагаться на обратные прокси-серверы и сеть распространения контента для выполнения большей части выборки и переноса.

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

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