Назад | Перейти на главную страницу

несколько веб-приложений в Tomcat - какова оптимальная архитектура?

Я поддерживаю растущую базу в основном веб-приложений на основе Cocoon-2.1 [http://cocoon.apache.org/2.1/], развернутый в контейнере сервлетов Tomcat [http://tomcat.apache.org/]и проксируется с помощью http-сервера Apache [http://httpd.apache.org/docs/2.2/]. Я концептуально пытаюсь найти лучший способ развернуть несколько веб-приложений в Tomcat. Поскольку я не программист на Java и у нас нет штатных системных администраторов, я должен сам выяснить, как это сделать наиболее разумным способом. Моя установка развивалась по двум сценариям, и я рассматриваю третий для максимального разделения различных веб-приложений.

[1] 1 экземпляр Tomcat, 1 экземпляр Cocoon, несколько веб-приложений.

-tomcat
  |_ webapps
     |_ webapp1
     |_ webapp2
     |_ webapp[n]
     |_ WEB-INF (with Cocoon libs)

Это был мой первый подход: просто поместите все веб-приложения в одну папку веб-приложений Cocoon внутри одного контейнера Tomcat. Кажется, все прошло нормально, проблем с памятью не возникло.

Однако это создает недостаток ремонтопригодности, поскольку некоторые компоненты Cocoon подлежат обновлению, что часто влияет на кодирование веб-приложений. Следовательно, обновление Cocoon становится громоздким: поскольку все веб-приложения используют один и тот же пул компонентов Cocoon, обновление одного из них потребует одновременного обновления кода во всех веб-приложениях.

Чтобы изолировать веб-приложения, я перешел ко второму сценарию.

[2] 1 экземпляр Tomcat, каждое веб-приложение в своей выделенной среде Cocoon.

-tomcat
  |_ webapps
     |_ webapp1
     |  |_ WEB-INF (with Cocoon libs)
     |_ webapp1
     |  |_ WEB-INF (with Cocoon libs)
     |_ webapp[n]
        |_ WEB-INF (with Cocoon libs)

Этот подход разделяет все веб-приложения в их собственную среду Cocoon, запускаемую внутри одного контейнера Tomcat. Теоретически это работает нормально: все веб-приложения можно обновлять независимо.

Однако это вскоре приводит к ошибкам PermGenSpace. Казалось, что я смогу решить эту проблему, увеличив объем памяти для Tomcat, но я понимаю, что это не структурное решение, и что подобная перегрузка одного Tomcat может привести к ошибкам памяти в будущем.

Это заставило меня задуматься о третьем сценарии.

[3] несколько экземпляров Tomcat, каждый с одним веб-приложением в выделенной среде Cocoon.

-tomcat
 |_ webapps
    |_ webapp1
       |_ WEB-INF (with Cocoon libs)
-tomcat
 |_ webapps
    |_ webapp2
        |_ WEB-INF (with Cocoon libs)
-tomcat
 |_ webapps
    |_ webapp[n]
       |_ WEB-INF (with Cocoon libs)

Я не пробовал этот подход, но думаю о переменной $ CATALINA_BASE. Один дистрибутив Tomcat может быть многократно инстанцирован с разными средами $ CATALINA_BASE, каждая из которых указывает на экземпляр Cocoon с собственным веб-приложением. Интересно, может ли такой подход избежать проблем подхода [2], связанных со структурной памятью, или же применимы те же проблемы?

С другой стороны, этот подход усложнил бы управление веб-интерфейсом Apache http, поскольку для этого потребуется, чтобы коннекторы AJP разных экземпляров Tomcat прослушивали разные порты. Следовательно, рабочая конфигурация Apache должна обновляться и перезагружаться всякий раз, когда добавляется новое веб-приложение (в его собственном экземпляре Tomcat). И, похоже, нет способа перезагрузить worker.properties без перезапуска всего http-сервера Apache.

Есть ли, возможно, другой / более динамичный способ «модулирования» нескольких веб-приложений, обслуживаемых Tomcat, или можно улучшить один из этих сценариев?

Любые мысли, предложения, советы очень ценятся.

Рон

Я сделал все, что вы упомянули, и на данный момент мы пошли в совершенно другом направлении. У нас есть образ виртуальной машины JEos, который мы используем с упрощенной виртуализированной ОС, и мы клонируем его для каждого нового приложения. Это не самый эффективный вариант с точки зрения памяти / процессора / диска, но избавляет меня от мысли о том, «к какому порту / каталогу все подключено».

По сути, СЕРВЕР определяет, какое приложение мы используем вместо порта / каталога /, что у вас есть.

Очевидно, это не сработает, если все, что у вас есть, - это одна машина или вы уже виртуализированы. В этом случае я бы рекомендовал общий CATALINA_BASE и указывал каждому новому приложению новый CATALINA_HOME. Соглашение о нумерации портов (например, 10) имеет большое значение для сохранения вашего рассудка в этом случае (поверьте мне).