Серверы приложений были созданы для того, чтобы помочь ограничить ресурсы: вычислить мощность на среднем уровне. Эта идея изначально пришла из мэйнфреймов, где ЦП было дефицитным и дорогим, и поэтому было потрачено много времени, усилий и денег на нарезку ЦП мэйнфрейма для разных пользователей, регулирование рабочей нагрузки, сохранение нагрузки на базу данных, «пассивация». "транзакции, пока нагрузка не уменьшится после нескольких часов и так далее. В те дни люди тратили миллионы долларов на программное обеспечение, которое отслеживало транзакции на мэйнфрейме, чтобы иметь возможность выполнить «возвратный платеж» - внутренний учет затрат на использование мэйнфрейма. Да, люди потратили кучу денег, чтобы они могли выставлять счета внутренним отделам за использование мэйнфрейма.
Дело в том, Intel (и позже AMD), Cisco (и др), EMC, Microsoft и Linux оказывается вся идея спорна. Компьютерные вычисления стали дешевыми. Действительно дешево. По-настоящему, действительно, действительно нет необходимости рационировать вычислительные ресурсы среднего уровня. Что такое сервер с двумя процессорами в эти дни? Сколько из них вы могли бы использовать для годовой зарплаты ОДНОГО ИТ-парня? Это инверсия старой экономики мэйнфреймов, где вычисления были дорогим, дефицитным ресурсом, а люди были относительно (!!) дешевы. Теперь люди - это дорогая часть, а вычисления - это дешево.
Серверы приложений, и все навороты, которые у них есть для ограничения доступа к вычислениям, или разделения его, или регулирования, или даже для «мониторинга» транзакций с целью возврата ... эти вещи не нужны, когда вы есть стойки с дешевыми серверами AMD.
Еще одна вещь, которую сделали серверы приложений, - это защита базы данных от рабочей нагрузки. По сути, разгрузка работы с сервера БД. Время было, разработчики поместили бизнес-логику в хранимую процедуру и, бум, появилось ваше приложение. Но с этим подходом были проблемы с масштабируемостью. Однако теперь хранимые процедуры работают быстро и эффективно. Серверы баз данных могут быть расширены, дешево. Скорее всего, у вас нет одного из 100 лучших томов рабочей нагрузки в мире, который не может быть перенесен на аппаратное обеспечение Intel с сохраненной логикой процесса.
Одна из основных проблем, связанных с подходом с хранимыми процессами, заключается в том, что все еще сложно создавать хранимые процессы на основных языках (Java, C #, VB и т. Д.) И управлять ими. Да, я знаю о SQL CLR и виртуальных машинах Java, управляемых БД. Но это не основные подходы. Кроме того, администратор БД не любит, когда жулики кода портят свои графики использования. По этим причинам все еще есть желание написать бизнес-логику на отдельном языке, предназначенном для этой цели. И все же есть желание запустить и управлять этой логикой на выделенных вычислительных ресурсах. Но ... традиционный "сервер приложений" ?? Нет, это не имеет смысла.
Разместите всю свою логику на сервере Intel и позвольте ей разорваться! Если вам нужно больше масштаба, клонируйте коробку. Вся бизнес-логика не имеет состояния (верно?), Поэтому вы можете масштабировать OUT. Используйте 3 сервера приложений, или 4, 5 или столько, сколько вам нужно. Все работает точно такой же код. Клоны друг друга. Независимо от того, сколько у вас машин бизнес-логики, физически не распределяйте рабочую нагрузку. Для максимальной масштабируемости старайтесь хранить каждую транзакцию в одном окне. Это рецепт эффективности и оптимального использования ресурсов.
Рекомендуется использовать логические уровни в архитектуре вашего приложения. Это облегчает разработку и поддержку. Но не думайте, что логическое разделение должно подразумевать или даже рекомендовать физическое разделение. Это не.