Ваше приложение должно делать это не tomcat.Теперь вы можете развернуть свое приложение в трех новых контекстах (client1, client2, client3) с немного другой конфигурацией для базы данных, и если вы будете осторожны в использовании относительных URL-адресов (то есть не делайте такие вещи, как / images), то вы можете сделать этобез изменений.Это прозрачный способ сделать ваше приложение многоразовым, так как ваше приложение не знает о глобальной картине, в которой работают 3 разных экземпляра.Это означает, что вы можете легко развернуть больше или больше без необходимости менять приложение.Вы просто настраиваете новый экземпляр и идете.Это только требует, чтобы вы не использовали абсолютные URL-адреса к ресурсам.Использование ServletContext.getContextPath () и использование .. в вашем CSS, скриптах и т. Д. Также полезно здесь.
Вероятно, одно из самых больших преимуществ, работающих таким образом, заключается в том, что ваше приложение не заботится о глобальных проблемах.Поскольку он не участвует в этих решениях, вы можете запустить 3 экземпляра на одном сервере Tomcat или, если одному клиенту требуется больше масштабирования, их можно легко перенести на собственный сервер Tomcat.Сделав ваше приложение переносимым, оно заставило вас иметь дело с тем, как установить ваше приложение в любой среде.Это столп горизонтального масштабирования, в котором ваша ситуация может быть очень полезна, поскольку вы можете разделить данные вашей БД без необходимости присоединяться к ним (огромное преимущество).Опция, о которой вы спрашивали, не заставляет вас иметь дело с этим, поэтому, когда придет время с ней справиться, она будет болезненной.
Другой вариант более сложен и требует значительных изменений в вашем приложении, чтобы справиться с этим.,Это путем анализа входящего URL-адреса и извлечения имени клиента, а затем с использованием этого имени для поиска в файле конфигурации базы данных, которая должна использоваться для этого клиента.SpringMVC может обрабатывать такие вещи, как извлечение переменных из URL-путей.Затем убедитесь, что вы отрисовываете все обратно, чтобы они указывали на их часть URL.Это, вероятно, потребует много тех же требований, что и первый.Вы можете использовать абсолютные URL-адреса для таких вещей, как JavaScript, CSS и изображения, но URL-адреса вашего приложения должны быть переписаны во время выполнения так, чтобы они относились к запрашивающему клиенту.Преимущество заключается в том, что вы загружаете свое приложение только один раз.
Кроме того, если вы размещаете свои CSS, Javascript, изображения на CDN в производстве, то оба эти параметра должны относительно учитывать URL.Плюсы и минусы использования CDN.
Хотя это звучит хорошо, это может быть не очень хорошо, потому что все клиенты используют одну и ту же версию приложения.Кроме того, если вы закрываете приложение, чтобы исправить client1 для выполнения обслуживания, это влияет на всех клиентов.Если вы считаете, что вам придется выполнять настройку для каждого клиента, то эта опция будет быстро запутаться.Обновление одного клиента означает, что все клиенты должны обновиться, и в зависимости от вашей бизнес-модели это может быть несовместимо.Кроме того, я не совсем уверен, что вы сэкономите много памяти, либо запустив только одну версию приложения, поскольку большинство приложений занимают всего 10 МБ загруженного кода.Подавляющее большинство памяти находится в ВМ и обрабатывает запросы, а использование одного экземпляра Tomcat означает, что вы совместно используете ВМ.И с 1 или 3 запущенными экземплярами у вас все равно остается такое же количество запросов.Вы можете увидеть разницу в 30-100 МБ, которая в сегодняшнем мире является чурбановой, и все эти другие проблемы не являются адресами, если вы решите сэкономить только пару МБ.
По сути, в Tomcat есть средствачтобы помочь вам в этом (в нескольких контекстах), но это в основном зависит от вашего приложения, особенно если это один экземпляр.