Использование Tomcats (в кластере Apache-Tomcat) в качестве обратных прокси-серверов для серверов Apache позади

Question

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

Что может быть хорошей архитектурой для вышеуказанного сервиса с точки зрения производительности и масштабируемости?

1. Просто использовать сервер приложений (tomcat) для того и другого?
2. Но потом я слышал, что apache лучше справляется со статическим контентом, имея легко настраиваемые параметры, такие как сжатие контента. Так как насчет использования Tomcat в качестве обратного прокси-сервера (используя j2ep, noodle ..) для веб-серверов Apache, стоящих позади. Tomcat может выполнять аутентификацию и поиск, в то время как серверы Apache могут обслуживать контент.
3. Но Tomcat, являясь единственной точкой контакта, может стать мощной бутылочной горлышкой. Так почему бы не использовать кластеризацию Apache Tomcat снова, чтобы сбалансировать нагрузку на весь набор?

В основном я смотрю на кластер apache-tomcat, где каждый tomcat действует как обратный прокси-сервер для набора серверов apache позади. Это возможно? Кто-нибудь делал это раньше? Я искал по этому вопросу, но не смог найти никаких указателей. Если это возможно, есть ли потенциальные недостатки в этой архитектуре?

В случае, если это плохой вариант, каков будет правильный путь для этого веб-сервиса?

Answer 1

Для начала я бы использовал tomcat для статического и нестатического контента. tomcat (из версии 5 AFAIK) хорошо справляется и со статическим контентом. Но если это не очень хорошо для вас, тогда я предлагаю использовать Apache httpd в качестве внешнего сервера и tomcat. Я использовал mod_jk, и директива JKMount может сообщить apache, какие вызовы должны быть перенаправлены на tomcat. Таким образом, вещи, которые не соответствуют директиве JKMount, обрабатываются самим Apache httpd. Таким образом, ваш статический контент может обслуживаться httpd, а нестатические запросы направляются в tomcat. Вы можете иметь несколько кошек в зависимости от нагрузки.

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

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

Надеюсь, это немного поможет.