Scaling out: divisione del lavoro o la ridondanza?

Question

Questa è una cosa che ho sempre chiesto. Capisco che scala orizzontale è di aggiungere più macchine nel mix. Ma mi viene in mente due approcci a questo. Supponiamo che io sono 20 server che voglio usare (più un database). Posso:

1. Fare tutti i 20 server eseguiti come application server.
2. Fai server diversi fanno diverse parti di un compito. Per esempio, hanno un insieme di server gestire la richiesta, poi un altro set di applicare la logica di business, e poi un altro per effettuare la chiamata del database.

Numero 1 sembra essere più comune e più facile da capire, ma il numero 2 sembra essere considerati "best practice" (come è per lo più un'architettura n-tier). Come si fa a scegliere tra questi due modelli? E quali sono i pro ei contro di ogni approccio?

Answer 1

Dipende dal compito, e quali sarebbero i vostri colli di bottiglia.

Quasi senza eccezione, si sta andando ad avere bisogno di almeno due tipi di server di: 1) Applicazione e 2) di database. Se si distribuiscono i server applicativi, è ancora necessario per sincronizzare i dati tra di loro, facendo uno di quei server (o un server separato) sia il server di database.

Se si conosce il database non verrà colpito con molto traffico (ad esempio: si esegue un sito di chat-based dal vivo, e non molto i dati vengono memorizzati in modo persistente o sincronizzato) allora la scelta di fare nulla, ma i server di applicazioni potrebbe andare bene .

La scelta # 2 è meglio, comunque, per la maggior parte dei siti, soprattutto se non si sa in anticipo che i server saranno i colli di bottiglia. Se non si consente per ogni tipo di server in scala, poi ti verrà bloccato dover riscrivere il codice sorgente durante scatti di crescita inaspettati. Poi si dovrà prendere decisioni difficili come "Quali caratteristiche dobbiamo disattivare in modo che il sito può ancora funzionare mentre lavoriamo su scala?"

Onestamente, però, vorrei non spendere troppo tempo a preoccuparsi di scalabilità. Una volta raggiunto un punto in cui i carichi dei server stanno diventando troppo alto, si sarà in grado di permettersi alcune riscritture di origine. Sia attraverso le fonti di recente scoperta di finanziamento, oppure attraverso i profitti diretti dal sito. Caso in questione:. Twitter sta ancora facendo grande