como um aplicativo da web lida com milhares de solicitações?

Question

Eu fui a alguns sites e notei que todos usam a tecnologia AJAX para muitas tarefas, como chat, mensagens e assim por diante. Eles usam um monte de httprequests, obviamente. Minha pergunta é se você cria um site simples usando AJAX e espera apenas poucas pessoas por hora e começa a ter 1.000 membros registrados por hora - pode um único aplicativo da Web manipular mais solicitações por hora se você apenas atualizar para servidores maiores e mais rápidos ou você tem que reescrever o código? Exatamente como você "escala" o aplicativo da web?

    

Answer 1

Essa é uma pergunta muito, muito envolvida, que muitas pessoas inteligentes gastam muito tempo pensando.

Dito isto, existem alguns mecanismos testados e verdadeiros que você pode introduzir para ajudar na escalabilidade. Em última análise, porém, resume-se ao seu aplicativo e como ele deve ser dimensionado especificamente. Por exemplo, você escalaria o Oracle de maneira diferente do que você escalaria o Apache.

Em primeiro lugar, não se preocupe muito com o que pode acontecer. Muitos desenvolvedores se preocupam com o "talvez" em vez de se preocupar com o "agora". A grande maioria dos aplicativos e sites da Web não exige nada fora do comum.

Esse aviso de exceção, geralmente há alguns princípios que devem ser seguidos ao projetar e codificar um aplicativo altamente escalonável. O conceito de "nada compartilhado" vem à mente. Separação de preocupações. Bons desenvolvedores reconhecem isso e podem construir desde o primeiro dia.

Uma lista de técnicas comumente implementadas:

1. Armazenamento em cache. Implementando uma camada front-end para impedir que as imagens e consultas de dados atinjam o back-end. Também novamente em uma camada de objeto via algo como memcached. O objetivo é minimizar a carga de trabalho e responder ao cliente o mais adiante possível.

2. Fragmentação do armazenamento de dados. Isso permite que a camada de dados seja dimensionada horizontalmente, de modo que seja possível adicionar sistemas e servidores de banco de dados adicionais à medida que atingimos a capacidade. Geralmente, há uma 'chave de fragmento' ou classificações que determinam em qual servidor de banco de dados uma determinada parte dos dados está disponível. Isso não pára na camada RDBMS. O armazenamento de arquivos e outros itens também devem ser considerados.

3. Balanceamento de carga. Nos permite adicionar mais clientes front-end (servidores da Web) para lidar com o carregamento da solicitação. É aí que entra toda a abordagem "Compartilhado nada". Esses servidores da Web devem ser sem estado, de modo que a falha não importe. É então possível dimensionar horizontalmente adicionando mais máquinas. Como nossos dados estão espalhados em uma camada de back-end, eles simplesmente aparecem e lidam com solicitações. Algoritmos de balanceamento são usados para escolher um servidor que não esteja ocupado. Espalhe a carga, por assim dizer.

4. CDN. Este tipo de baseia-se em # 1, mas depende de provedores de CDN. Estamos novamente construindo o conceito de responder a solicitação o mais longe possível. Existe até um idioma "Edge Side Includes" completo para gerenciar essas coisas.

5. Replicação de dados. Por exemplo, um único nó de gravação que replica para um par de nós de leitura. Como a maioria dos aplicativos da Web são felizes para leitura, podemos direcionar nossas leituras para os nós lidos enquanto bombeamos gravações através dos nós de gravação. MySQL, Postgres, Oracle, MSSQL, todos suportam isso, assim como as opções NoSQL eventualmente consistentes, como o MongoDB. Isso não é necessariamente mutuamente exclusivo para o número 2.

Tenho certeza de que estou esquecendo de algo, já que estou tirando tudo isso da memória, mas você entendeu. No núcleo, o aplicativo precisa ser projetado para ser dimensionável. Se você tem isso, é possível distribuir a carga e crescer indefinidamente, implantando uma arquitetura inteligente.