O que devo fazer para expandir um site de alto tráfego?

Quais práticas recomendadas devem ser adotadas para um site que precisa ser "escalonado" para lidar com a capacidade? Isso é especialmente relevante agora que as pessoas estão considerando a nuvem, mas podem estar perdendo os fundamentos.

Estou interessado em ouvir sobre qualquer coisa que você considere uma prática recomendada, desde tarefas em nível de desenvolvimento até infraestrutura e gerenciamento.

Design para simultaneidade

Ou seja, enquanto você codifica, planeje ter vários threads em funcionamento. Planeje o estado compartilhado (geralmente apenas o banco de dados). Planeje vários processos. Planeje a distribuição física.

Isso permite que você distribua seu sistema em várias máquinas e em vários processos com balanceamento de carga. Ele permite que você execute processos redundantes em caso de falha e, caso precise modificar o sistema no local, não é necessário interromper todos os serviços para fazê-lo.

Algumas coisas que você pode considerar:

• Separando os lados de leitura e gravação do seu armazenamento de dados.
  
  • CQRS / Fonte de Eventos
  • CQS
  • Passagem de mensagem / Atores
• Evitando processo compartilhado e estado do encadeamento
  • Portanto, evitando o bloqueio
  • Você pode evitar isso através do sistema de tipos, criando suas classes, estruturas e outros tipos de dados para serem imutáveis, ou seja, sem alterações após a construção. Especialmente para tipos de dados abstratos complexos, funciona surpreendentemente bem (por exemplo, implementação do jQuery)
• Não está bloqueando os encadeamentos do servidor da Web no IO. Se você estiver usando o ASP.Net, use páginas / ações assíncronas com o padrão APM / TPL (Biblioteca Paralela de Tarefas)
• Não salvando cargas de estado no dicionário da sessão do usuário
  • Isso deve ser movido pelos threads quando ocorrerem migrações de threads no IIS.
  • Possuir roteamento inteligente, para que recursos estáticos / não protegidos não sejam atendidos com a mesma estrutura de aplicativo (por exemplo, ASP.Net) que adiciona sobrecarga. Veja como ter servidores da web diferentes, por exemplo.
• Gravando código de passagem de continuação com um padrão de fluxo de trabalho assíncrono (por exemplo, bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
• Use a teoria das filas para calcular onde seus gargalos podem ocorrer
• Use atualizações push-pull em vez de pull para modelos de leitura e outro estado do aplicativo. Por exemplo, através do RabbitMQ / nServiceBus
• Use o 'manipulador http' com menos recursos
• Para arquivos estáticos, atenda a tags eletrônicas e políticas de expiração de cache para permitir que a infraestrutura da Web funcione como deveria (por exemplo, com o squid proxy)
• (Contrate-me para resolver seus problemas de dimensionamento e obter tutoriais no local;))

Arquitetura Share Nothing.

Com isso em mente, e ao contrário do que você imagina, não pule imediatamente para uma solução em expansão. A sobrecarga fora do sistema vs. uma chamada no sistema não deve ser sub-ponderada. Por exemplo, leva muito mais tempo para estabelecer uma conexão com o banco de dados em qualquer interface de rede do que para fazer uma chamada local. Orçar quanto tempo em esforço de gerenciamento, energia e ajuste é necessário em expansão, em comparação com os dólares extras para um verdadeiro sistema grande.

Independentemente disso, ainda há um grande valor nas arquiteturas de "não compartilhar nada" e você pode colocar em camadas e dimensionar seus sistemas quando chegar a hora.

Paralelizar solicitações em vários nomes de host

Parte do padrão HTTP é uma seção que diz que os clientes solicitam no máximo 2 sessões por host DNS. Aqui está uma solução em que você e seu alias acessam seu www.domain.com e obtêm uma maior concorrência de solicitações, agilizando o carregamento da página:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

Basicamente, envolve editar o manipulador HTTP do ASP.NET para alternar os hosts de destino para os quais você envia clientes, onde cada host é um CNAME para "www".

DNS seguro, rápido e confiável

Encontrei alguns sites de alta capacidade usando o servidor DNS do registrador, que não tinha SLA para tempo de atividade ou desempenho. Além disso, seus servidores estavam localizados na Índia e a latência sozinha aumenta a chance de um spoofer DNS envenenar o cache de seu cliente ou o ISP intermediário. Isso faria com que até o tráfego protegido por SSL fosse redirecionado sem que ninguém soubesse.

A velocidade do DNS também afeta o tempo de carregamento inicial do seu servidor, antes que os registros sejam armazenados em cache.

Eu uso o DynDNS ou o Neustar para a maioria dos meus clientes, pois eles têm uma infra-estrutura DNS bastante sólida (embora seja cara e eu não tenha outra afiliação a essas empresas).

Eu acho que a chave será simples:

Tenha um código simples. Isso significa algo que você olha e entende. Ao expandir e alterar servidores, você precisa saber o que está acontecendo. Você também pode precisar adicionar codificadores que precisam entender rapidamente. Ganchos e arquivos XML que chamam código aleatório que não é óbvio são muito ruins.

Então você pode testar e encontrar os problemas.

Veja aqui: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

Na stellarbuild, tentamos garantir que nossos sites sejam dimensionados sem tempo ocioso. Isso significa que você precisa saber o que seu código faz e onde ele faz. Mesmo se você estiver testando uma máquina diferente, não poderá demorar muito para dimensionar. A maioria das pessoas só começa quando é quase tarde demais, infelizmente. Você pode otimizar apenas quando fizer isso na minha opinião.