Rottura di un monolite: bilanciamento del carico di lavoratori VS

Question

Rottura di un monolite: bilanciamento del carico di lavoratori VS

#1 da (2 voti)
#2 da (1 voti)

3

Attualmente la mia architettura è guidata da molti eventi. Ogni richiesta API viene pubblicata il più rapidamente possibile inviando eventi che vengono eseguiti dopo la risposta.

Tuttavia questo è un monolite e i gestori di eventi vengono eseguiti con lo stesso processo che gestisce l'API. Rispondere a una singola richiesta API è efficiente, ma la CPU del processo si strozzerà rapidamente gestendo il lavoro di background su API +.

Ho due modi per ridimensionarlo:

Offset le attività in background ai lavoratori
Crea un cluster e bilancia il carico dello stesso processo

Sebbene entrambi gli approcci dovrebbero essere implementati a lungo termine: quale dovrebbe essere il primo a ridimensionare?

Il mio assunto è che un monolite non sano sarebbe più facile da risolvere con l'opzione (1), mentre l'opzione (2) copre le precedenti importanti esigenze infrastrutturali (quindi sarà ottimale per monoliti ben strutturati)

architecture web-development

posta SystematicFrank 31.12.2017 - 09:04

fonte

2 risposte

Leggi altre domande sui tag architecture web-development

Si dovrebbe creare un membro di classe privato condivisibile o mantenere variabile nell'ambito del metodo per passarlo come secondo argomento del metodo? Dove vado ad assumere un programmatore freelance? [chiuso]

score 2 · Answer 1

Ho troppe poche informazioni per dare una risposta definitiva, ma ho un'applicazione di elaborazione dei pacchetti in cui l'approccio (2) è preferito rispetto all'approccio (1). Ho ottenuto oltre un milione di pacchetti al secondo più prestazioni con approccio (2) rispetto all'approccio (1). La ragione di questo miglioramento delle prestazioni è la riduzione dei costi di comunicazione tra le CPU.

L'approccio (1) richiede di inviare attività ai lavoratori da un thread centrale. Ciò significa che il thread centrale deve allocare memoria che i thread worker quindi liberano. Ciò significa che esiste un flusso di allocazione sbilanciato (un thread alloca, un altro thread libera) che rende praticamente qualsiasi allocatore ragionevole lento, ovvero solo pochi milioni di blocchi al secondo di prestazioni.

Inoltre, non puoi usare code di blocco per trasferire i blocchi di lavoro da un thread a un altro thread a una performance di più di qualche milione di operazioni al secondo a meno che non si eseguano alcuni strani trucchi per migliorare le prestazioni.

Ora, non so quanto è grande il tuo compito. Migliaia di compiti al secondo? Milioni di compiti al secondo? Riesco a vedere i benefici nell'approccio del lavoratore se il tuo tasso di attività è semplicemente migliaia di compiti al secondo. A milioni di attività al secondo, inizierai a scoprire che l'approccio del lavoratore è inefficiente.

score 1 · Answer 2

Vado sempre con l'approccio lavoratore.

Dato che sei arrivato al punto in cui hai riscontrato un problema con il design del monolite esistente, duplicare semplicemente e avere 2 è improbabile che risolva il problema sottostante.

Inoltre, essendo stato costruito come un monolite piuttosto che come un processo di lavoro; probabilmente non è progettato per essere eseguito come più istanze. Potresti scoprire che sono necessarie modifiche prima che tu possa semplicemente avviare un'altra istanza.

Inoltre, dato che hai appena colpito il problema, probabilmente c'è un singolo evento che sta lanciando la CPU e causando il rallentamento.

Puoi fare una piccola modifica per spostare solo questo evento su un lavoratore e lasciare il resto del monolite così com'è.