Configurazione del mio server per un'API molto utilizzata

Presto comprerò un sacco di server per un'applicazione che sto per lanciare ma ho delle preoccupazioni sulla mia configurazione. Apprezzo qualsiasi feedback che ricevo.

Ho un'applicazione che utilizzerà un'API che ho scritto. Anche altri utenti / sviluppatori faranno uso di questa API. Il server API riceverà le richieste e le inoltrerà ai server di lavoro. L'API conterrà solo un dq mysql di richieste a fini di registrazione, autenticazione e limitazione della velocità.

Ogni server di lavoro svolge un lavoro diverso e in futuro, in scala, aggiungerò altri server di lavoro per renderli disponibili. Il file di configurazione API verrà modificato per prendere nota dei nuovi server di lavoro. I server di lavoro eseguiranno alcune elaborazioni e alcuni salveranno un percorso di un'immagine nel database locale per essere successivamente recuperati dall'API per essere visualizzati sulla mia applicazione, alcuni restituiranno stringhe del risultato di un processo e lo salveranno in un database locale .

Questa configurazione ti sembra efficiente? C'è un modo migliore per ristrutturarlo? Quali problemi dovrei considerare? Si prega di vedere l'immagine qui sotto, spero che aiuti a capire.

Maggiore disponibilità

Come menziona Chris, il tuo server API è l'unico punto di errore nel tuo layout. Quello che stai configurando è un'infrastruttura di accodamento dei messaggi, qualcosa che molte persone hanno implementato in precedenza.

Continua lungo lo stesso percorso

Si menziona la ricezione di richieste sul server API e si inserisce il lavoro in un DB MySQL in esecuzione su ciascun server. Se vuoi continuare su questo percorso, ti suggerisco di rimuovere il livello del server API e di progettare i Lavoratori affinché accettino i comandi direttamente dai tuoi Utenti API. È possibile utilizzare qualcosa di semplice come il DNS round robin per distribuire ogni connessione utente API direttamente a uno dei nodi di lavoro disponibili (e riprovare se una connessione non riesce).

Utilizzare un server della coda messaggi

Le infrastrutture di accodamento dei messaggi più robuste utilizzano software progettato per questo scopo come ActiveMQ . È possibile utilizzare l'API RESTful di ActiveMQ per accettare richieste POST dagli utenti API e i lavoratori inattivi possono ottenere il messaggio successivo nella coda. Tuttavia, questo è probabilmente eccessivo per le tue esigenze: è progettato per latenza, velocità e milioni di messaggi al secondo.

Usa Zookeeper

Come via di mezzo, potresti voler guardare Zookeeper , anche se non è specificamente un server di code di messaggi. Usiamo a $ work per questo preciso scopo. Abbiamo un set di tre server (analogo al tuo server API) che eseguono il software del server Zookeeper e hanno un frontend Web per la gestione delle richieste da parte di utenti e applicazioni. Il front-end Web e la connessione back-end Zookeeper ai lavoratori dispongono di un bilanciamento del carico per assicurarsi che continuiamo a elaborare la coda, anche se un server non è attivo per manutenzione. Al termine del lavoro, il lavoratore comunica al cluster Zookeeper che il lavoro è completo. Se un lavoratore muore, quel lavoro verrà inviato a un altro lavoro per il completamento.

Altre preoccupazioni

• Assicurarsi che i lavori vengano completati nel caso in cui un lavoratore non risponda
• Come farà l'API a sapere che un lavoro è completo e a recuperarlo dal database del lavoratore?
• Cerca di ridurre la complessità. Hai bisogno di un server MySQL indipendente su ciascun nodo di lavoro o potrebbero parlare al server MySQL (o al cluster MySQL replicato) sui server API?
• Sicurezza. Qualcuno può presentare un lavoro? C'è autenticazione?
• Quale lavoratore dovrebbe ottenere il prossimo lavoro? Non devi dire se le attività dovrebbero durare 10ms o 1 ora. Se sono veloci, è necessario rimuovere i livelli per mantenere bassa la latenza. Se sono lenti, dovresti fare molta attenzione per assicurarti che le richieste più brevi non rimangano bloccate dietro a quelle più lunghe.

Il problema più grande che vedo è la mancanza di pianificazione del failover.

Il tuo server API è un grande singolo punto di errore. Se si interrompe, allora nulla funziona anche se i server di lavoro sono ancora funzionali. Inoltre, se un server di lavoro si arresta, il servizio fornito dal server non è più disponibile.

Ti suggerisco di guardare il progetto Linux Virtual Server ( http://www.linuxvirtualserver.org/ ) per avere un'idea di come funziona il bilanciamento del carico e il failover e per avere un'idea di come questi possano essere utili alla tua progettazione.

Esistono molti modi per strutturare il sistema. In che modo è migliore è una chiamata soggettiva che ti risponde meglio. Ti suggerisco di fare qualche ricerca; soppesare i compromessi dei diversi metodi. Se hai bisogno di informazioni su un metodo di impianto, invia una nuova domanda.