Ma vraie question est la suivante :la pile technologique ci-dessus peut-elle évoluer jusqu'à 1 000 000 messages par seconde (texte, images, vidéos) ?
Bien sûr que c'est possible. Avec le bon design et suffisamment de matériel. La question que votre client devrait se poser n'est vraiment pas de savoir si cela peut être fait pour aller aussi gros, mais à quel coût et à quel point cela peut-il être fait et sont-ils les meilleurs choix.
Examinons chaque élément que vous avez mentionné :
node.js - Pour une application centrée sur les E/S, c'est un excellent choix pour une grande échelle et elle peut évoluer en déployant de nombreux processeurs dans un cluster (à la fois multi-processus par serveur et multi-serveur). La praticité de ce type d'échelle dépend beaucoup du type de données partagées auxquelles tous ces processus serveur ont besoin d'accéder. Habituellement, le magasin de données finit par être le goulot d'étranglement le plus difficile dans la mise à l'échelle, car il est facile de lancer plus de serveurs lors du traitement de la demande. Il n'est pas si facile de jeter plus de matériel dans un magasin de données centralisé. Il existe des moyens de le faire, mais cela dépend beaucoup des exigences de l'application, de la façon dont vous le faites et de la difficulté.
socket.io - Si vous avez besoin d'un push serveur efficace de petits messages, alors socket.io est probablement la meilleure solution car c'est le push le plus efficace vers le client. Ce n'est pas génial dans tous les types de transport. Par exemple, je ne déplacerais pas de grandes images ou des vidéos via socket.io car il existe d'autres moyens spécialement conçus pour le faire. Ainsi, l'utilisation de socket.io dépend beaucoup de l'utilisation que l'application souhaite en faire. Si vous vouliez envoyer une vidéo à un client, vous pouviez également n'envoyer qu'une URL et demander au client de se retourner et de demander la vidéo via une URL http normale en utilisant une technologie à grande échelle bien connue.
Redis - Encore une fois, génial pour certaines choses, pas génial pour tout. Donc, cela dépend vraiment de ce que vous essayez de faire. Ce que j'ai expliqué plus tôt, c'est que la conception de votre magasin de données et le nombre de transactions qui le traversent sont probablement là où résident vos véritables problèmes d'échelle. Si je commençais ce travail, je commencerais par comprendre les besoins de stockage de données d'un serveur, les transactions par seconde de différents types, la stratégie de mise en cache, la redondance, le basculement, la persistance des données, etc. étendre d'abord l'accès aux données. Je ne serais pas tout à fait sûr que redis était le choix préféré. Je suggérerais probablement que vous ayez besoin d'un spécialiste des bases de données à grande échelle en tant que consultant au début du projet.
Nginx - Beaucoup de sites à grande échelle utilisant nginx, c'est donc certainement un bon outil. Que ce soit exactement le bon outil pour vous dépend de votre conception. Je travaillerais probablement sur cette partie en dernier car elle semble moins centrale dans la conception et une fois que le reste du système est présenté, vous pouvez alors réfléchir à ce dont vous avez besoin ici.
Amazon EC2 - Un choix parmi plusieurs possibles. Ces choix sont difficiles à comparer directement dans une comparaison de pommes à pommes. Des systèmes à grande échelle ont été construits à partir d'EC2, il y a donc une preuve de concept et l'architecture générale semble être une correspondance appropriée. Si vous vouliez savoir où se trouvent les vrais gremlins, vous auriez besoin d'un consultant qui a fait des choses à grande échelle sur EC2.
Amazon S3 - Je connais personnellement des sites de stockage et de bande passante très élevés utilisant S3 pour la vidéo et les images. Ça marche pour ça.
Donc ... ce sont généralement de bons outils à utiliser s'ils sont utilisés de la bonne manière. Redis serait un point d'interrogation en fonction des besoins de stockage de l'application réelle (vous avez fourni zéro exigence et une base de données ne peut pas être sélectionnée avec zéro exigence). Une réponse plus raisonnée serait basée sur la mise en place d'un ensemble d'exigences de haut niveau qui analysent ce que le système doit être capable de faire pour servir 1 000 000 de personnes. Ces exigences pourraient être comparées aux capacités connues de certaines de ces pièces pour démarrer un stade approximatif de mise à l'échelle d'un système. Ensuite, vous devrez mettre en place des tests d'analyse comparative pour exécuter des tests sur certaines parties du système. Le succès d'un échec dépendrait autant de la manière dont l'application a été créée et de la manière dont les outils ont été utilisés que des outils sélectionnés. Vous pouvez probablement faire une échelle réussie avec de nombreux types d'outils différents. Heck, Facebook fonctionne sur PHP (enfin, un PHP hautement modifié et personnalisé qui n'est pas du tout du PHP typique au moment de l'exécution).
