Эффективное развертывание нескольких экземпляров одной и той же WAR (разные контексты, один и тот же контейнер)

Question

У меня есть одна WAR (app.war) и один контейнер (Tomcat, Jetty, Glassfish, что угодно). Моя цель - развернуть по запросу сотни экземпляров этого же веб-приложения на контейнере.

http://foo/app1 --> app.war 
http://foo/app2 --> app.war 
http://foo/app3 --> app.war 
... 
http://foo/appN --> app.war 

Некоторые очевидные способы достижения этой цели:

• В Tomcat, создать один context.xml файл для каждого приложения (названный appN.xml), все указывает на то же WAR. Другие контейнеры имеют аналогичные методы
  • Проблема с этим подходом: Это будет взрывать WAR N раз, занимая много дискового пространства
• Используйте символические ссылки для создания WebAPP/{app1, app2, APPn} папки указывая на взорванную версию app.war. Это предотвращает взрыв на диске, но JVM по-прежнему загружает много дубликатов JAR в память.
• Используйте некоторую папку с общим доступом, чтобы содержать большинство банок (и комбинацию из двух предыдущих опций).

Интересно, есть ли лучший способ для этого. В идеале, создание нового экземпляра не должно занимать больше места на диске (кроме крайних файлов конфигурации) и обрабатывать только память, связанную со стеками выполнения потоков и другими распределениями времени выполнения.

Любые идеи?

Answer 1

Jetty добавила поддержку того, что вы ищете некоторое время назад с помощью так называемых накладок.

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

Копирование немного со страницы вики:

• Вы можете сохранить файл WAR неизменны, даже подписан, так что ясно, какую версию вы раскрывали.
• Все изменения, внесенные вами для настройки/настройки веб-приложения, являются отдельными ВОЙНАМИ и поэтому легко идентифицируются для просмотра и перехода на новые версии.
• Вы можете создать параметризованное наложение шаблона, которое содержит общие настройки и настройки, которые применяются ко многим экземплярам веб-приложения (например, для развертывания с несколькими арендаторами).
• Поскольку многоуровневое развертывание четко идентифицирует общие и специфичные для экземпляра компоненты, Jetty может совместно использовать загрузчики классов и статические кэши ресурсов для шаблона, что значительно снижает объем памяти нескольких экземпляров.

Answer 2

Вы можете настроить Apache на передней панели (mod_proxy/mod_proxy_ajp), чтобы указать виртуальные хосты на одну WAR, развернутую на Tomcat. Ваша заявка должна быть спроектирована/написана таким образом, чтобы обслуживать весь запрос. Конфигурация конкретного веб-сайта может быть сохранена в базе данных или в виде файла конфигурации в вашем приложении - вашему приложению просто нужно будет исследовать запрашиваемое доменное имя пользователя убедитесь, что установлены правильные настройки (один раз за сеанс). В общем, вы должны решить это с помощью одного приложения. Отличные разработчики ЛАЗИ.

Answer 3

Хорошо, если это для эксперимента, то любой из методов, которые вы указали, может работать.

Если это для производства, я бы рекомендовал против этого. Хотя я не тестировал ВСЕ контейнеры, контейнеры, которые я использовал, заставляют меня полагать, что он намного более устойчив, просто предоставляя безголовые виртуальные машины с контейнерами. Linux VM могут быть очень маленькими, и с технологией VM вы можете добавлять или вычитать столько случаев, сколько необходимо.

Если вы действительно хотите иметь динамически растущее решение, вам следует попытаться устранить отдельные точки отказа, а затем попытаться объединить весь свой мир в один.

Если вам действительно нужно «до второго» расширения/сжатия нагрузки, вы должны посмотреть на AWS или CloundFoundry.

Answer 4

Если вы используете Jetty, вы можете добавлять контексты программно.

WebAppContext webapp = new WebAppContext(); 
webapp.setBaseResource(myBaseDirectory); 
webapp.setContextPath(myContextPath); 

Просто сделайте это в цикле для всех ваших контекстов. Он должен иметь близкие к нулю служебные данные дискового пространства.

Возможно, аналогичный способ можно использовать в Tomcat.

Answer 5

Извинения за то, что вы немного не по теме, но, на мой взгляд, ваш сценарий выкрикивает приложение с несколькими приложениями, так что у вас есть одно приложение, которое будет обслуживать несколько «арендаторов» (клиентов).

Что касается мульти-арендного установок, следующие соображения должны быть рассмотрены:

• Клиенты не могут получить доступ к друг другу данные (если они данные хранятся в одной и той же базе данных, так же схемы и с помощью " дискриминатора "для разделения данных). Это может быть достигнуто с помощью Spring Security с Access Control Lists
• Hibernate имеет встроенный support for multitenancy apps с версии 4.0.
• Эти два SO вопросы могут быть полезными, а также
  • Multiple Entity Manager issue in Spring when using more than one datasource (для использования различных источников данных (различные базы данных или просто разные схемы на одной и той же базы данных на каждого клиента).
  • Multi tenancy support in Java EE 6

Привилегии:

• Общий код означает, что исправлена ​​ошибка для одного клиента для всех (это может быть и недостатком, если разные клиенты имеют разные взгляды на то, что представляет собой ошибку, и что представляет собой функцию).
• Кластеризованное развертывание может совместно использовать нагрузку между клиентами (однако необходимо обеспечить максимальную пропускную способность для всех клиентов).

Downsides:

• код будет немного сложнее, так как запросы должны гарантировать, что «дискриминация» между клиентами работает без accidentially подвергая клиентов друг другу данные.