Mit egentlige spørgsmål er, kan ovenstående teknologistak skalere 1.000.000 beskeder pr. sekund (tekst, billeder, videoer)?
Selvfølgelig kan det. Med det rigtige design og nok hardware. Spørgsmålet, din klient bør stille, er virkelig ikke, om det kan få det til at blive så stort, men til hvilke omkostninger og praktiske forhold kan det gøres, og er det de bedste valg.
Lad os se på hvert stykke, du har nævnt:
node.js - For en I/O-centreret app er den et glimrende valg til høj skala, og den kan skaleres ved at implementere mange CPU'er i en klynge (både multiprocesser pr. server og multiserver). Hvor praktisk denne type skala er, afhænger meget af, hvilken slags delt data alle disse serverprocesser skal have adgang til. Normalt ender datalageret i sidste ende med at blive den sværere flaskehals i skalering, fordi det er nemt at smide flere servere efter anmodningsbehandlingen. Det er ikke så nemt at smide mere hardware i et centraliseret datalager. Der er måder at gøre det på, men det afhænger meget af appens krav til, hvordan du gør det, og hvor svært det er.
socket.io - Hvis du har brug for et effektivt server-push af små beskeder, så er socket.io nok den bedste vej at gå, fordi det er den mest effektive til at skubbe til klienten. Det er dog ikke fantastisk til alle typer transport. For eksempel ville jeg ikke flytte store billeder eller video rundt gennem socket.io, da der er flere specialbyggede måder at gøre det på. Så brugen af socket.io afhænger meget af, hvad appen præcis vil bruge den til. Hvis du ville skubbe en video til en klient, kunne du også skubbe en URL og få klienten til at vende om og anmode om videoen via en almindelig http URL ved hjælp af velkendt højskalateknologi.
Redis - Igen, fantastisk til nogle ting, ikke god til alting. Så det afhænger virkelig af, hvad du prøver at gøre. Det, jeg forklarede tidligere, er, at designet af dit datalager og antallet af transaktioner gennem det sandsynligvis er der, hvor dine reelle skalaproblemer ligger. Hvis jeg startede dette job, ville jeg starte med en forståelse af datalagringsbehovene for en server, transaktioner pr. sekund af forskellige typer, cachingstrategi, redundans, fail-over, datavedholdenhed osv... og designe den høje skaler adgang til data først. Jeg ville ikke være helt sikker på, at redis var det foretrukne valg. Jeg vil nok foreslå, at du har brug for en databasefyr i høj skala som konsulent tidligt i projektet.
Nginx - Masser af højskala websteder, der bruger nginx, så det er bestemt et godt værktøj. Om det er det helt rigtige værktøj til dig afhænger af dit design. Jeg ville nok arbejde på denne del sidst, fordi den virker mindre central for designet, og når resten af systemet er lagt ud, kan du overveje, hvad du har brug for her.
Amazon EC2 - Et af flere mulige valg. Disse valg er svære at sammenligne direkte i en æble til æbler sammenligning. Systemer i stor skala er blevet bygget ud af EC2, så der er proof of concept der, og den generelle arkitektur synes at være et passende match. Hvis du ville vide, hvor de rigtige gremlins er der, skulle du bruge en konsulent, der havde lavet ting i høj skala på EC2.
Amazon S3 - Jeg kender personligt nogle websteder med meget høj lagring og båndbredde, der bruger S3 til både video og billeder. Det virker til det.
Så ... disse er generelt sandsynligvis gode værktøjer at bruge, hvis de bruges på den rigtige måde. Redis ville være et spørgsmålstegn afhængigt af lagerbehovene for den faktiske applikation (du har angivet nul krav, og en database kan ikke vælges med nul krav). Et mere begrundet svar ville være baseret på at sammensætte et højt niveau af krav, der analyserer, hvad systemet skal kunne gøre for at betjene 1.000.000 uanset hvad. Disse krav kan sammenlignes med kendte muligheder for nogle af disse brikker til at starte en boldbane med at skalere et system. Derefter skal du sammensætte nogle benchmarking-tests for at køre nogle tests på bestemte dele af systemet. Lige så meget af succesen med fiasko ville afhænge af, hvordan appen blev bygget, og hvordan værktøjerne blev brugt, som det ville afhænge af, hvilke værktøjer der blev valgt. Du kan sandsynligvis lave en vellykket skala med mange forskellige typer værktøjer. For pokker, Facebook kører på PHP (nå, en meget modificeret, tilpasset PHP, der slet ikke er typisk PHP under kørsel).