Я думаю, что ответ на ваши вопросы сильно зависит от поведения приложения, использования базы данных и т. Д., И ничего нельзя сказать, не взглянув на текущие показатели производительности (как уже упоминалось в других ответах). Я публикую некоторые из своих мыслей в качестве руководства.
База данных
Большинство организаций используют СУБД на отдельных хостах, и некоторые инженеры предпочитают никогда не виртуализировать их, в зависимости от того, что говорят их лучшие практики поставщиков БД для своего случая (при этом я обычно считаю виртуальные машины эквивалентными физическим хостам, и я используйте их, когда это возможно).
С точки зрения производительности, СУБД часто требуют настройки ядра или нестандартных стратегий файловой системы, и может помочь их размещение на отдельных хостах. Если БД когда-либо необходимо настроить в режиме высокой доступности или в кластере, ее отделение от серверов приложений также может упростить задачу. Обратите внимание, что настройка базы данных, если вам когда-либо понадобится это, может быть сложной темой, если серьезно, и она часто включает в себя такие вещи, как выравнивание разделов на диске, пытаясь уменьшить перемещение головки диска путем умного распределения сегментов / файлов данных базы данных, учитывая Размеры и стратегии кеша СУБД и ОС ... Все это может повлиять на другие приложения, работающие на том же хосте, поэтому я бы предпочел оставить БД в покое.
Кроме того, СУБД часто обслуживают несколько приложений (для этого есть веские причины: иногда для некоторых интеграций требуется доступ к нескольким базам данных приложений). Помогает отделить их от серверов приложений.
Кроме того, системы БД имеют свои собственные процедуры обновления, резервного копирования, распределения / кластеризации и администрирования и часто обслуживаются другими лицами, а не серверами приложений. Таким образом, всю тему администрирования базы данных легче рассмотреть, если рассматривать ее отдельно. И если база данных становится узким местом, вы можете работать только с базой данных, не учитывая, влияют ли другие уровни на производительность.
Я рекомендую хранить СУБД отдельно на одном хосте для производственных сред разумного размера. Но, конечно, если у вас нет требований к производительности, администрированию или доступности, вы можете рассмотреть возможность использования общего сервера для всего.
Glassfish
В общих чертах, когда вы хотите развернуть приложение Java EE на нескольких серверах (для балансировки нагрузки или высокой доступности), вы устанавливаете один и тот же сервер приложений и артефакты на все серверы приложений в кластере. Затем вы можете выбрать, какие артефакты включить на каждом узле кластера. Некоторые серверы приложений могут включать или отключать компоненты в зависимости от нагрузки на сервер. В этом случае ваш сервер приложений является «модулем», который вам нужно распространять.
Теперь могут быть случаи, когда вы или ваша организация предпочитаете иметь полностью разделенные сетевые уровни для веб-уровня и бизнес-уровня (т. Е. Проблемы безопасности). В этом случае вы бы использовали отдельные хосты для этого. Если ваш веб-уровень действительно тяжелый и вам нужно масштабировать его отдельно от бизнес-уровня (т. Е. Вам нужно 6 веб-серверов, но вы можете сделать это с 1 или 2 контейнерами EJB), я бы разделил эти два уровня тоже.
Как примечание: использование веб-уровней и уровней EJB в одном и том же экземпляре Glassfish дает небольшие преимущества: поскольку они совместно используют JVM, вызовы между веб-уровнем и бизнес-уровнем могут использовать семантику вызовов по ссылке. В зависимости от рабочей нагрузки, размера и стоимости сериализации ответов это может привести к заметному увеличению производительности.
В большинстве случаев для многих корпоративных приложений я бы использовал один или два сервера (в зависимости от того, нужна ли вам высокая доступность), содержащих оба слоя, потому что даже если нагрузка возрастает, вы все равно можете расти вертикально (увеличивая мощность сервера или ресурсы виртуальных машин). ) или по горизонтали (добавьте другой сервер и запросите балансировку нагрузки).
Во всемирно доступных приложениях с высокой пропускной способностью необходимо учитывать множество других аспектов, чтобы их можно было масштабировать (простое добавление узлов в узел кластера Java EE не приведет к его сокращению), поэтому я не думаю, что что-либо из этого Решение лучше или хуже для развертывания в «облаке», но в общих чертах, если вы планируете развертывать службы эластичной виртуализации и ваши требования оправдывают это, я рекомендую разделить веб-уровни и бизнес-уровни.
Безопасность
По моему мнению, обсуждаемые темы не имеют прямого влияния на безопасность.
Наконец, я уверен, что по этой теме можно сказать гораздо больше, и мой опыт ограничен, поэтому, пожалуйста, получите больше мнений;).