Histórico: Eu quero separar as funções do nosso servidor web / servidor de aplicativos em máquinas separadas (logicamente ou fisicamente). Ou seja, eu quero dedicar certos recursos para servir conteúdo estático (HTML estático, imagens, Javascript, CSS, vídeos, etc ...) e quero dedicar outros recursos para gerar HTML dinâmico (meu aplicativo web, que é um ColdFusion app e você pode considerar qualquer aplicativo J2EE).
Estou familiarizado com vários métodos de fornecedores J2EE para conectar seus servidores de aplicativos a servidores da web. Por exemplo, a Adobe fornece mod_jrun, o Tomcat oferece mod_ajp, mod_proxy_ajp, & mod_jk, Caucho (Resin) oferece mod_caucho, etc ... Vários desses conectores permitem a funcionalidade de balanceamento de carga. Eu acho que eles estão se comunicando com uma parte do servidor de aplicativos que pode funcionar como um controlador de cluster.
Uma coisa que eu notei é que esses conectores são feitos para uso com o Apache (e frequentemente o IIS no Windows). Estamos pensando em sair do Apache para um dos servidores web mais leves, como Nginx ou Cherokee. Se eu fizer isso, parece que não terei a opção de usar conectores como mencionei acima. A sugestão consistente na documentação desses servidores é apenas configurar seu recurso de proxy reverso HTTP para conectá-los ao seu servidor de aplicativos (por meio da implementação HTTP do servidor de aplicativos).
Estou interessado em sua experiência com as implicações de desempenho do HTTP em comparação com outros protocolos usados em um conector, como mencionei acima. Presumi que esses outros conectores funcionariam em um nível muito mais baixo e teriam um desempenho maior como resultado. Eles obviamente podem trazer novos "recursos", como a exposição da funcionalidade de balanceamento de carga de um servidor de aplicativos, como mencionei acima.
Então, o que você acha? É a simplicidade & A flexibilidade do HTTP para comunicar-se entre as camadas da Web e de aplicativos é mais atraente do que os recursos adicionais de um conector mais personalizado? Existem outros problemas no planejamento de uma arquitetura multicamadas como essa que eu não considerei?
Existem vários exemplos de HTTP proxy-reverso em grandes sites , então eu diria que não tem problemas em termos de desempenho, escalabilidade ou facilidade de administração.
Adicionar nginx ou equivalente para balanceamento de carga na frente de seus servidores atuais não mudará muito, e você poderá substituir gradualmente o apache + mod_whatever quando ele não agregar mais valor.
Antes de você ir longe demais, tenho que admitir que não tenho dados reais para responder à sua pergunta. Eu fiz alguns testes relativamente pequenos de mod_proxy_http versus mod_proxy_ajp, mas os resultados foram inconclusivos.
Meu entendimento é que o mod_jk foi preterido em favor do mod_proxy_ajp; também o mod_jk é (na minha experiência) mais difícil de configurar.
A maneira como mod_proxy_ajp e mod_jk se comunicam entre o servidor web front-end e o servidor de aplicativos é essencialmente uma forma binária de HTTP, que seria idealmente mais rápida para o servidor web e servidor de aplicativos enviar e receber. Para balanceamento de carga, a família mod_proxy usa mod_proxy_balancer, que funciona com mod_proxy_http ou mod_proxy_ajp. A linha inferior é que não há diferença de características entre os dois.
Tags reverse-proxy http