Benefícios tangíveis de manter aplicativos da web e servidor da web separados?

Question

Desenvolvemos e mantemos aplicativos da web; e na nossa configuração atual; Estamos usando um sistema de três camadas de servidor de banco de dados, servidor de aplicativos e servidor da Web.

Até agora, tudo bem.

O problema que estamos enfrentando é que, embora em teoria , essa configuração foi projetada para nos ajudar a equilibrar a carga entre essas máquinas e inserir novos fragmentos conforme necessário; na prática, a tensão que isso está colocando em nossa rede de bastidores está se tornando um gargalo severo.

Há também a questão de servir arquivos estáticos; devido à nossa configuração atual; eles precisam ser atendidos pelo aplicativo (consumindo nossos processos FastCGI disponíveis para manipular solicitações de entrada) ou usando um servidor da Web como um proxy local na máquina que executa o aplicativo, em primeiro lugar.

A pergunta então se torna:

Seria simplesmente o recolhimento da web e do servidor de aplicativos em um só; com a simplificação da configuração que ele traz; e a objetividade do acesso (sockets locais em vez de TCP); bem como o aumento da capacidade de fornecer arquivos estáticos através do servidor da web, provavelmente, proporcionando melhor desempenho; ou existem fatores indiretos que eu perdi?

    

Answer 1

De modo geral, sou fã de arquiteturas divididas: um farm de servidores de banco de dados, um farm de servidores "público" (site comercial) e um farm de servidores de aplicativos, possivelmente com outras camadas de middleware, conforme necessário. A lógica por trás disso é antiga - basicamente, que o servidor público www não precisa ter acesso a nenhum dado confidencial, então algum hacker curioso pesquisando em www.mycompany.com pode comprometer nosso site de marketing, mas eles não conseguiram algo mais.

Aqui estão algumas outras ideias gerais ...

Re: carga de rede do backroom, se estamos falando de carga de tráfego de entrar em contato com seus hosts FastCGI, eu diria que colocar um servidor web nessas máquinas e deixá-los falar diretamente com o mundo exterior pode ser uma boa idéia. Uma coisa a ter em mente é manter o isolamento / proteção de seu banco de dados no caso de um comprometimento de segurança, o que poderia ser um argumento para empurrar seu material FastCGI para os servidores web e escrever algo mais leve para conversar com seu banco de dados ... / p>

(Se estamos falando de algo mais, deixe-me saber e eu vou dar um pulo nisso: -)

Re: o problema dos arquivos estáticos, há várias maneiras de resolver esse problema.

• Coloque uma cópia dos dados estáticos em todos os servidores que precisam enviá-los.
  Vamos chamar isso de método "Disco é barato" - impede que você despeje uma quantidade enorme de carga em uma única caixa que hospeda seu conteúdo estático e elimina esse ponto único de falha. A desvantagem é que você tem que sincronizar esse conteúdo de alguma forma (scripts de implantação, rsync do cron, cvs / git / svn, etc.)

• Instale uma infraestrutura de armazenamento em cache nos servidores front-end
  Essa é uma solução semelhante a "Disco é barato" acima, somente você tem um servidor back-end com o conteúdo estático e, quando os servidores front-end precisam, eles armazenam em cache uma cópia para $ LIFETIME . eliminando assim a necessidade de scripts de sincronização (a infraestrutura de cache faz isso por você).

• Coloque seu conteúdo estático em uma rede de distribuição de conteúdo
  Isso realmente só funciona se você não estiver fazendo coisas SSL - Um CDN comercial resolve o problema de carga e fornece aos usuários pontos geograficamente distribuídos dos quais eles podem pegar seu conteúdo. A desvantagem é que a maioria dos navegadores ajustará um ajuste se você fizer isso com um site que tenha SSL, a menos que seu CDN também esteja protegido (mesmo assim, os navegadores paranoicos devem reclamar corretamente).