Il modo migliore per separare le funzionalità di amministrazione da un sito pubblico?

Question

Sto lavorando a un sito che è cresciuto sia in termini di base di utenti e funzionalità al punto in cui diventa evidente che alcune delle attività di amministrazione devono essere separate dal sito web pubblico. Mi stavo chiedendo quale sarebbe il modo migliore per farlo.

Ad esempio, il sito ha una grande componente sociale e un'interfaccia di vendita pubblica. Ma allo stesso tempo, ci sono attività di back office, elaborazione di caricamento collettivo, dashboard (con query a lunga esecuzione) e strumenti di relazioni con i clienti nella sezione di amministrazione che non vorrei essere influenzato da picchi nel traffico pubblico (o influenzare il pubblico- di fronte al tempo di risposta).

Il sito è in esecuzione su uno stack Rails/MySQL/Linux abbastanza standard, ma penso che si tratti più di un problema di architettura che di un'implementazione: principalmente, come si mantengono sincronizzati i dati e la business logic tra questi diversi applicazioni?

Alcune strategie che sto valutando:

1) Creare un database schiava del database rivestimento pubblico su un'altra macchina. Estrai tutto il codice modello e libreria in modo che possa essere condiviso tra le applicazioni. Crea nuovi controller e viste per le interfacce di amministrazione.

Ho una esperienza limitata con la replica e non sono nemmeno sicuro che sia usato in questo modo (il più delle volte l'ho visto, è stato per ridimensionare le capacità di lettura della stessa applicazione, piuttosto che avere più diversi). Sono anche preoccupato per il potenziale di problemi di latenza se lo slave non si trova sulla stessa rete.

2) Creare nuove ulteriori applicazioni task/reparto e utilizzare un middleware orientato ai messaggi per integrarle. Ho letto Enterprise Integration Patterns da un po 'di tempo e sembravano sostenere questo per i sistemi distribuiti. (In alternativa, in alcuni casi la funzionalità RESTful API Rails di base potrebbe essere sufficiente.) Tuttavia, ho incubi sui problemi di sincronizzazione dei dati e la massiccia riprogettazione che ciò comporterebbe.

3) Una miscela dei due. Ad esempio, le uniche informazioni pubbliche necessarie per alcune delle attività di back office sono un tempo di completamento o uno stato di sola lettura. Avrebbe senso averlo su un sistema completamente separato e inviare i dati a pubblico? Nel frattempo, la funzionalità di amministrazione utente/gruppo verrebbe eseguita su un sistema separato che condivide il database? Il lato negativo è che sembra trattenere molte delle preoccupazioni che ho con le prime due, in particolare la riprogettazione.

Sono sicuro che le risposte dipenderanno molto dalle esigenze specifiche di un sito, ma mi piacerebbe sentire storie di successo (o di insuccesso).

Answer 1

Per quanto ne so dalla descrizione, se si vuole veramente assicurarsi che le prestazioni di pubblica visibilità e le prestazioni di amministrazione non si influenzino a vicenda, sarà necessario utilizzare database separati su server separati.

La chiave è ottenere una buona comprensione di quali dati vengono utilizzati dove e come i dati sono coinvolti nel processo. Se puoi farlo, prova a determinare se puoi creare un database come "principale". Questi sarebbero i tuoi dati live e l'altro database sarebbe il tuo archivio dati operativo (ODS). L'ODS è sempre un derivato dai tuoi dati live. Il processo di aggiornamento dell'ODS dai dati in tempo reale può avvenire a intervalli e può sia semplificare i dati sia eseguire un'ulteriore elaborazione per renderlo più appropriato per l'applicazione utilizzando l'ODS.

Ora, se si riscontra un notevole salto di qualità per la situazione attuale, è possibile provare e almeno separare i dati all'interno del database, in modo da non affrontare problemi di prestazioni come blocchi di tabelle, ecc. Può anche essere un passo nella giusta direzione per se è necessario passare a un modello simile a ODS in futuro.

Answer 2

Non sono un fan della replica di ciò che non deve essere. Contrassegnerei ciò che è solo admin e costruirò quella parte come un DB separato con un IP interno o una porta diversa. Quindi rendi le relazioni con le chiavi esterne al sito pubblico per l'accesso amministrativo. Trattarlo come una tabella indicizzata sarebbe molto più semplice da amministrare piuttosto che replicare e lo sviluppo dell'API è un compito non necessario quando non si parla con i sistemi legacy. Anche perché replicare quando si desidera mantenere separati i sistemi. I miei due centesimi.