Справочная информация: я хочу разделить наши функции веб-сервера / сервера приложений на отдельные машины (логически или физически). Это означает, что я хочу выделить определенные ресурсы для обслуживания статического контента (статический HTML, изображения, Javascript, CSS, видео и т. Д.) И хочу выделить другие ресурсы для создания динамического HTML (мое веб-приложение, которое оказывается ColdFusion app, и вы можете рассматривать его как любое приложение J2EE).
Я знаком с несколькими методами поставщиков J2EE для подключения серверов приложений к веб-серверам. Например, Adobe предоставляет mod_jrun, Tomcat предлагает mod_ajp, mod_proxy_ajp, & mod_jk, Caucho (Resin) предлагает mod_caucho и т. Д. Некоторые из этих коннекторов позволяют выполнять функции балансировки нагрузки. Я предполагаю, что они взаимодействуют с частью сервера приложений, который может функционировать как контроллер кластера.
Я заметил одну вещь: эти коннекторы предназначены для использования с Apache (и часто с IIS в Windows). Мы рассматриваем возможность перехода с Apache на один из более легких веб-серверов, например Nginx или Cherokee. Если я это сделаю, похоже, что у меня не будет возможности использовать разъемы, подобные упомянутым выше. Последовательное предложение в документации для этих серверов - просто настроить их возможность обратного прокси-сервера HTTP, чтобы подключить их к серверу приложений (через реализацию HTTP сервера приложений).
Мне интересно узнать о влиянии HTTP на производительность по сравнению с другими протоколами, используемыми в соединителе, как я упоминал выше. Я предполагал, что эти другие разъемы будут работать на гораздо более низком уровне и в результате будут иметь более высокую производительность. Очевидно, что они могут принести новые «функции», такие как раскрытие функциональности балансировки нагрузки сервера приложений, как я упоминал выше.
Так что ты думаешь? Является ли простота и гибкость HTTP для связи между веб-уровнями и уровнями приложений более привлекательными, чем дополнительные функции более настраиваемого коннектора? Есть ли другие проблемы при планировании такой многоуровневой архитектуры, которые я не рассматривал?
Есть много примеры HTTP обратное проксирование на больших сайтах, поэтому я бы сказал, что у него нет проблем с производительностью, масштабированием или простотой администрирования.
Добавление nginx или его эквивалента для балансировки нагрузки перед вашими текущими серверами мало что изменит, и вы сможете постепенно заменять apache + mod_whatever, когда он больше не добавляет ценности.
Прежде чем вы зайдете слишком далеко, я должен признать, что у меня нет реальных данных, чтобы ответить на ваш вопрос. Я провел относительно небольшое тестирование mod_proxy_http по сравнению с mod_proxy_ajp, но результаты были неубедительными.
Насколько я понимаю, mod_jk устарел в пользу mod_proxy_ajp; также mod_jk (по моему опыту) сложнее настроить.
Способ взаимодействия mod_proxy_ajp и mod_jk между интерфейсным веб-сервером и сервером приложений, по сути, представляет собой двоичную форму HTTP, которая в идеале была бы быстрее для веб-сервера и сервера приложений как для отправки, так и для приема. Для балансировки нагрузки семейство mod_proxy использует mod_proxy_balancer, который работает с mod_proxy_http или mod_proxy_ajp. Суть в том, что между ними нет разницы в характеристиках.