La mia vera domanda è:lo stack tecnologico di cui sopra può scalare 1.000.000 di messaggi al secondo (testo, immagini, video)?
Certo che può. Con il giusto design e hardware sufficiente. La domanda che il tuo cliente dovrebbe porsi non è davvero se può essere fatto per andare così in grande, ma a quale costo e praticità può essere fatto e sono queste le scelte migliori.
Diamo un'occhiata a ogni pezzo che hai menzionato:
node.js - Per un'app incentrata sull'I/O, è una scelta eccellente per una scalabilità elevata e può essere scalata distribuendo molte CPU in un cluster (sia multiprocesso per server che multiserver). La praticità di questo tipo di scala dipende molto dal tipo di dati condivisi a cui devono accedere tutti questi processi server. Di solito, l'archivio dati finisce per essere il collo di bottiglia più difficile nella scalabilità perché è facile lanciare più server all'elaborazione della richiesta. Non è così facile inserire più hardware in un archivio dati centralizzato. Ci sono modi per farlo, ma dipende molto dalle richieste dell'app per come lo fai e quanto è difficile.
socket.io - Se hai bisogno di un server push efficiente di messaggi piccoli, allora socket.io è probabilmente il modo migliore per andare perché è il più efficiente nel push al client. Tuttavia, non è eccezionale in tutti i tipi di trasporto. Ad esempio, non sposterei immagini o video di grandi dimensioni tramite socket.io poiché ci sono modi più specifici per farlo. Quindi, l'uso di socket.io dipende molto da cosa esattamente l'app vuole usarlo. Se desideri inviare un video a un client, puoi anche inviare solo un URL e fare in modo che il client si giri e richieda il video tramite un normale URL http utilizzando la ben nota tecnologia su larga scala.
Redis - Ancora una volta, ottimo per alcune cose, non eccezionale in tutto. Quindi, dipende davvero da cosa stai cercando di fare. Quello che ho spiegato in precedenza è che il design del tuo archivio dati e il numero di transazioni attraverso di esso è probabilmente il punto in cui risiedono i tuoi veri problemi di scala. Se dovessi iniziare questo lavoro, inizierei con una comprensione delle esigenze di archiviazione dei dati per un server, transazioni al secondo di vario tipo, strategia di memorizzazione nella cache, ridondanza, failover, persistenza dei dati, ecc. scalare prima l'accesso ai dati. Non sarei del tutto sicuro che Redis fosse la scelta preferita. Probabilmente ti suggerirei di avere bisogno di un addetto al database su larga scala come consulente all'inizio del progetto.
Nginx - Molti siti su larga scala che usano nginx, quindi è sicuramente un buon strumento. Che sia esattamente lo strumento giusto per te dipende dal tuo design. Probabilmente lavorerei su questa parte per ultima perché sembra meno centrale per il design e una volta che il resto del sistema è pronto, puoi quindi considerare ciò di cui hai bisogno qui.
Amazon EC2 - Una delle numerose scelte possibili. Queste scelte sono difficili da confrontare direttamente in un confronto tra mele e mele. I sistemi su larga scala sono stati costruiti con EC2, quindi c'è la prova del concetto e l'architettura generale sembra una corrispondenza appropriata. Se volessi sapere dove sono i veri gremlin, avresti bisogno di un consulente che abbia fatto cose su larga scala su EC2.
Amazon S3 - Conosco personalmente alcuni siti di archiviazione e larghezza di banda molto elevati che utilizzano S3 sia per i video che per le immagini. Funziona per quello.
Quindi ... questi sono generalmente probabilmente buoni strumenti da usare se usati nel modo giusto. Redis sarebbe un punto interrogativo a seconda delle esigenze di archiviazione dell'applicazione effettiva (hai fornito zero requisiti e un database non può essere selezionato con zero requisiti). Una risposta più ragionata si baserebbe sul mettere insieme una serie di requisiti di alto livello che analizzino ciò che il sistema deve essere in grado di fare per servire 1.000.000 di qualsiasi cosa. Tali requisiti potrebbero essere confrontati con le capacità note di alcuni di questi pezzi per avviare un campo di gioco sul ridimensionamento di un sistema. Quindi, dovresti mettere insieme alcuni test di benchmarking per eseguire alcuni test su determinati pezzi del sistema. La maggior parte del successo di un errore dipenderebbe da come è stata creata l'app e da come sono stati utilizzati gli strumenti, così come da quali strumenti sono stati selezionati. Probabilmente puoi creare una scala di successo con molti diversi tipi di strumenti. Diamine, Facebook funziona su PHP (beh, un PHP altamente modificato e personalizzato che non è affatto tipico di PHP in fase di esecuzione).
