Ridimensionamento senza code?

0

Ogni volta che mi viene chiesto come ridimensionare un'applicazione, inevitabilmente tendo verso un modello di accodamento: suddividere le responsabilità dell'applicazione in singoli servizi e aggiungere code tra questi servizi. Ciò significa che puoi attivare più o meno istanze di un dato servizio come richiesto e semplicemente tirare dalla coda per ottenere lavoro.

Ottieni abbastanza di questi servizi con ruoli diversi e quasi inevitabilmente c'è la creazione di un livello di orchestrazione - qualcosa che capisca il flusso necessario di un oggetto di lavoro attraverso le code e lo gestisca da capo a fondo.

Quali sono alcuni degli approcci alternativi per ridimensionare le applicazioni che non utilizzano le code e finiscono con un livello di orchestrazione?

Aggiornamento basato sui commenti

Come sottolineato da @tofro, probabilmente parlerò di elasticità invece di scalabilità link .

Ecco un esempio. Diciamo che ho un servizio che fa codifica video. Un utente carica un file, seleziona uno o più formati di codifica diversi (quicktime, divx), il file viene codificato nei formati e l'utente può scaricare i file di output risultanti.

Un modo per rendere questo elastico utilizzando le code sarebbe avere diversi servizi, QuickTimeEncoder e DivXEncoder, con le code QTEQueue e DivXQueue e mettere i lavori nelle code come richiesto. È possibile aggiungere più istanze degli encoder nel corso del tempo al variare della richiesta.

    
posta user783836 02.11.2016 - 14:07
fonte

2 risposte

0

In assenza di code, è necessario attivare immediatamente un nuovo agente per ogni nuova attività da eseguire; il nuovo agente contiene l'istanza dell'attività invece di una coda.

Il linguaggio di programmazione Erlang è in grado di farlo, perché ha la capacità di far girare milioni di agenti leggeri.

Nota che Erlang ha anche un modulo code , quindi ti dà ancora quell'opzione.

    
risposta data 02.11.2016 - 15:47
fonte
1

Il modo più semplice per ridimensionare un'applicazione nella mia esperienza è renderlo stateless e aggiungere istanze. Questo è il ridimensionamento orizzontale di base. Un approccio un po 'più sofisticato è quello di scomporre il servizio attraverso le risorse e quindi utilizzare l'orchestrazione per comporre questi vari pezzi nella funzionalità necessaria. Non c'è bisogno di code per farlo. HTTP funziona perfettamente.

L'accodamento aveva un ruolo predominante rispetto al design contemporaneo. Quando la memoria era altamente vincolata, era importante poter disporre di un posto in cui memorizzare una massa di transazioni al fine di spingerli attraverso la piccola tubazione di memoria. Ora abbiamo l'indirizzamento della memoria a 64 bit ed è economico e comune avere più memoria del necessario. I sistemi con 1 TB di RAM non sono niente di speciale.

L'altro aspetto dell'accodamento è che potrebbe essere utilizzato per gestire le attese di IO. Cioè, avresti discussioni facendo piccoli pezzi di lavoro e spostando la transazione sulla prossima cosa invece di fare chiamate di blocco e aspettare. Con librerie IO non bloccanti e altri approcci più rapidi alla concorrenza l'accodamento distribuito è diventato più di un approccio di nicchia. Penso che abbia ancora un ruolo nell'elaborazione asincrona, ma come @tofro menziona nei commenti, la necessità di scalabilità non indica necessariamente l'accodamento distribuito. Ci sono un sacco di complicazioni e problemi legati alla messa in coda e un sacco di bagagli sulla "consegna garantita" che non garantisce molto nella realtà. Lo eviterei a meno che tu non abbia problemi specifici che risolve meglio delle altre tecniche a tua disposizione.

    
risposta data 02.11.2016 - 15:50
fonte

Leggi altre domande sui tag