Può un tipo di carico gestire gli handle Uber da un solo server?

Suppongo che le richieste siano "richiesta di servizio" o ordine. (perché la metrica "richieste completate" è leggermente inferiore)

I loro server vengono costantemente monitorati dai dispositivi dei conducenti (GPS e altre cose), gli utenti che guardano le auto disponibili, il tracciamento gps degli utenti, ecc.

Non posso nemmeno dire quante richieste sarà per 1 viaggio. Ma se ogni macchina fa ping con il GPS ogni minuto, contatela. E questa è solo una cosa.

I server devono elaborare tutti questi dati.

No, non è su 1 server:)

Sì, certo che potrebbe. Se lo fanno è un altro aspetto, dal momento che anche Uber non eseguirà tutte le attività da un singolo server: avranno i server Web per ricevere richieste, i server delle applicazioni per elaborare i dati e un server di database (in cluster?) Per archiviare i dati . (beh, presumo che lo facciano, è probabile che stiano eseguendo tutto da un'unica websever che esegue PHP per tutto quello che so).

I server sono molto potenti al giorno d'oggi, per £ 20.000 puoi avere una CPU da 32 quad-core con gigabyte di RAM e diverse schede di rete. Il gioco di elaborazione del server è cambiato circa dieci anni fa e ha reso disponibile l'elaborazione praticamente illimitata, quindi l'aumento dei servizi cloud in quanto i provider avevano più potere di quanto non sapessero cosa fare!

So che lavoravo per una società di servizi finanziari con un trio di server valutato per 400.000 transazioni all'ora. Il solitario server di test delle prestazioni poteva gestire più di 2 richieste al secondo, e si trattava di transazioni piuttosto complicate che comportavano molti trasferimenti di dati, aggregazione e controllo. Ho anche lavorato per un'azienda che produce sistemi di controllo dei servizi di emergenza, migliaia di veicoli che inviano dati di localizzazione non è un carico pesante come si penserebbe, è molto facile gestire grandi quantità di pacchetti di dati come questo, archiviarli era più di un problema (e semplicemente li metti in cache nella RAM finché non hai un blocco da perseguire insieme, supponendo che Uber abbia gli stessi requisiti di controllo, potrebbero semplicemente mantenere l'ultima posizione nota e gettare via il resto)

C'è un grande pezzo del puzzle che ti manca: il tempo di risposta. Anche se il carico era leggero e gestibile da un server, e non posso davvero commentare se lo sia o meno, avresti potenziali problemi di latenza dall'avere Uber negli Stati Uniti servito da un singolo server residente in Australia o in Bielorussia.

Se guardi i notiziari di Uber che scendono, noterai che Uber tende a scendere a livello regionale con rare interruzioni globali. Il mio pensiero sarebbe quindi che Uber si affida a soluzioni di hosting basate su cloud o forse gestite in data center regionali in tutte le aree in cui operano. È anche possibile che abbiano richiesto pezzi dell'applicazione seduti localmente con alcune funzionalità fondamentali ospitate da un singolo data center. Ciò non inizia nemmeno a toccare i dettagli di storage o SAN, cluster di database, CDN, ecc.

Con l'hosting basato su cloud sempre più diffuso, l'idea di qualcosa che gira su n numero di server diventa meno rilevante mentre idee come il volume delle richieste e il tempo di elaborazione diventano più rilevanti. Guarda i modelli di prezzi per servizi come Amazon EC2. La fatturazione è espressa in ore di tempo di elaborazione, non in quantità di infrastruttura.