architettura per servizi che eseguono calcoli molto costosi

2

Il nostro software ha due servizi, uno che fornisce un'ape di riposo utilizzata dal client e una per i calcoli. Il calcolo è abbastanza esteso e in alcuni casi può richiedere alcune ore o giorni. Esiste solo un'istanza del servizio rest-api e un'istanza del servizio di calcolo. Il servizio Rest-api comunica direttamente con il servizio di calcolo e c'è sempre solo un calcolo in esecuzione.

Ciò di cui abbiamo bisogno ora è di supportare più istanze di entrambi i servizi per poter eseguire più calcoli contemporaneamente. L'idea era di usare il broker dei messaggi (RabbitMQ o altro) e le code. Il flusso sarebbe

  1. rest-api pubblica la richiesta di calcolo sulla coda A
  2. richiesta del broker di messaggi per il calcolo a un'istanza del servizio di calcolo che avvia il calcolo
  3. I servizi di calcolo
  4. pubblicano periodicamente aggiornamenti di stato sulla coda B
  5. una volta terminato il calcolo, il risultato viene pubblicato nella coda B
  6. Il broker di messaggi
  7. passa i risultati dalla coda B a un'istanza di rest-api che memorizza i risultati

Macisonoduecaratteristichechenonsiadattanoaquestaarchitettura:cancellazionedelcalcoloepossibilitàdiottenererisultatiparzialiduranteilcalcolo.

Perlacancellazioneènecessario-inviarelarichiestadicancellazioneaun'istanzaparticolaredelserviziodicalcoloericeverlaimmediatamenteseilcalcoloègiàincorso-per"rimuovere" la richiesta di calcolo se è ancora in coda

Una possibile soluzione potrebbe essere che il servizio di calcolo crea la propria coda e invia la sua "identità" (stringa casuale) usata come chiave di instradamento con gli aggiornamenti di stato.

  1. l'utente annulla il calcolo X
  2. istanza rest-api contrassegna la richiesta di calcolo X nel database come annullata
  3. Il servizio di calcolo
  4. che riceve la richiesta X invierà l'aggiornamento di stato con la sua "identità"
  5. L'istanza
  6. rest-api che ottiene l'aggiornamento dello stato (può essere un'istanza diversa rispetto al passaggio 2) controllerà se la richiesta X è stata annullata e in tal caso prende l'identità dei servizi di calcolo e la utilizza come chiave di instradamento per la consegna del messaggio di annullamento
  7. Il servizio di calcolo
  8. annulla il calcolo

Questa soluzione probabilmente non è adatta per ottenere risultati parziali perché l'utente può chiedere risultati parziali più volte. Qualche idea su come implementarla all'interno dell'architettura suggerita?

L'architettura è adatta per l'attività?

    
posta Martin Barnas 13.08.2018 - 15:14
fonte

1 risposta

2

È adatto e corretto.

Penso che la cosa che ti manca sia il concetto di "fan out routing"

Quindi hai una singola coda di richieste di calcolo che vengono prese e tolte quando gli addetti alla computazione diventano disponibili. Questa coda si abbona al messaggio RequestComputation e tutti i lavoratori ne escono.

Ma hai anche ciascun operatore di calcolo che crea la propria coda che si abbona ai messaggi cancelComputation e requestPartialResult .

Quindi, quando l'API REST pubblica uno di quei messaggi, "fan out" e verrà raccolto da tutti gli addetti alla computazione. Ognuno di questi può controllare per vedere a quale lavoro sta lavorando e rispondere se necessario.

    
risposta data 13.08.2018 - 15:31
fonte

Leggi altre domande sui tag