Un codebase: molti servizi in hosting (simili a un servizio in stile basecamp) - struttura di pianificazione

L'opzione # 1 è generalmente l'opzione migliore in termini di manutenzione. Apportate modifiche una volta e applicate immediatamente a tutti i clienti. Credo che il termine per questo sia "multi-tenant". L'unica applicazione PHP che gestisco ha un paio di migliaia di account cliente in un certo numero di siti di 'private label' tutti in un singolo db, ed è attivo da quasi un decennio.

Tieni presente che non devi aggiungere un 'ID sito' alla tabella ogni . In genere è necessario tenerne traccia solo in alcuni tavoli. Ad esempio, se hai una tabella utenti e una tabella indirizzi che ti ricollega, non hai bisogno dell'ID del sito nella tabella degli indirizzi poiché probabilmente hai l'id del sito nella tabella degli utenti.

In realtà non lavoriamo per "sito", ma piuttosto per account cliente: lo stesso utente funziona attraverso tutti i "siti" virtuali. Ma il principio è lo stesso.

Ci sono momenti in cui questo potrebbe non essere il più pratico - dipende da quanta personalizzazione è prevista. Se i clienti si aspettano cambiamenti drastici specifici per loro, a quel punto potrebbe essere meglio tenere tutto separato.

C'è anche l'opzione n. 3, che è semplicemente quella di avere file di configurazione specifici per un singolo sito e di avere quel punto in un altro database. In questo modo rimuovi la necessità di un db "master" condiviso. Se sentissi la necessità di dividere un sistema in più db, questo è probabilmente l'approccio che prenderei per mantenere le cose un po 'meno complicate rimuovendo la necessità di un db "master".

Prima di decidere come organizzare le tabelle del database per più client ("il grande dibattito multi-tenant vs multi-istanza"), dovresti considerare come intendi:

• riduci il tuo servizio man mano che aumenta il numero di clienti / siti brandizzati,
• ridimensiona il tuo servizio man mano che aumenta il numero di utenti (per singoli clienti / siti o in aggregato),
• mantieni il / i sito / i disponibile / i nel caso in cui alcuni componenti hardware non funzionino.

Queste decisioni su come ridimensionare le prestazioni e mantenere la disponibilità faranno una grande differenza nel modo in cui i tuoi dati dovrebbero essere strutturati. Le variabili chiave includono:

• Quanti dati avrai,
• In che misura il servizio potrebbe aumentare rapidamente (numero totale di client, numero totale di utenti o altre metriche),
• Quanta disponibilità di servizi può richiedere voi o i vostri clienti,
• Quanto isolamento e sicurezza possono desiderare i tuoi clienti,
• Che tipo di piattaforme desideri utilizzare per questi servizi (in-house, virtualizzati, cloud o una combinazione) e
• Quali competenze hai a disposizione o potresti prontamente conservare per aiutarti nello sviluppo

Ho scalato con successo i servizi "up" semplicemente acquistando server, storage e istanze di rete più grandi. Anche se questo non ti durerà per sempre, l'aumento graduale è una strategia di ingresso legittima che richiede meno competenze e strutture di dati più semplici. Alla fine non saresti in grado di acquistare economicamente istanze più grandi e avresti bisogno di affrontare la più difficile direzione "out", ospitando il tuo servizio su più nodi cooperanti. Ciò può fornire scalabilità e disponibilità molto migliori, ma anche maggiore complessità e supervisione. Una combinazione di clustering , sharding e di solito è richiesta la replica .

Un passaggio intermedio che può aiutare a colmare il divario tra il semplice ridimensionamento verticale e il ridimensionamento orizzontale / distribuito "completo" è la multiistanza con scalabilità orizzontale. Questo approccio ibrido distribuisce il carico di lavoro su più nodi, ma con una strategia di ridimensionamento in gran parte verticale ("su") per nodo. Richiede più facilità con bilanciamento del carico, mappatura DNS e provisioning / orchestrazione rispetto alle tipiche implementazioni scalabili, ma non il pieno "essere il padrone degli algoritmi e dei paradigmi distribuiti" che sarebbe una progettazione di servizi in stile Twitter, Facebook o Google. Inoltre, si adatterebbe perfettamente al tuo stile di business "marchio privato".

Che hai una scadenza ristretta e che tu (basato sulla tua domanda) non hai molta esperienza di scale-out / sharding, entrambi sostengono la più semplice Opzione # 1 o grandmasterb , insieme a un piano per scalare verticalmente prima, quindi a un modello a più istanze.