Eu tenho um aplicativo em execução com:
- uma instância do nginx como frontend (servindo arquivo estático)
- um cluster de aplicativo node.js para o back-end (usando módulos cluster e expressjs)
- uma instância do Postgres como banco de dados
Esta arquitetura é suficiente se o aplicativo precisar de escalabilidade (isto é apenas para solicitações HTTP/REST) para:
500 solicitações por segundo (cada solicitação busca apenas dados do banco de dados, esses dados podem ter vários ko e sem grandes cálculos necessários após a busca).
20.000 usuários conectados ao mesmo tempo
Onde poderiam estar os gargalos?
Responder1
Uma instância do nginx pode lidar com milhares de pequenos arquivos estáticos por segundo sem suar a camisa.
A escalabilidade da camada do aplicativo depende mais do seu aplicativo do que do node.js - se ele estiver armazenando arquivos/dados da sessão/etc localmente, as coisas podem ficar complicadas, mas se você estiver colocando todo o armazenamento em um local central como o banco de dados (ou talvez algo como Redis para armazenar dados de sessão), então dimensionar a camada do aplicativo adicionando mais nós deve ser fácil.
O banco de dados é quase sempre a coisa mais difícil de escalar; se você estiver fazendo principalmente leituras, o postgres 9.1 possui alguns recursos de hot standby muito interessantes que permitem que você tenha um banco de dados mestre de leitura/gravação e vários escravos somente leitura que podem lidar com a maior parte do trabalho de leitura.
Desenvolver um sistema de banco de dados com muitas gravações é provavelmente o problema de escalabilidade mais difícil; quando um servidor de banco de dados super robusto não consegue acompanhar, a maioria das pessoas acaba repensando e reescrevendo totalmente seus aplicativos (a menos que isso tenha sido planejado desde o início, mas planejar vários bancos de dados mestres tornará muitas coisas mais difíceis e lentas para começar). , e é muito raramente necessário - a rede stackoverflow está toda em um banco de dados IIRC)