Progetta la soluzione scalabile con la coda

1

Supponendo il seguente scenario:

Un'applicazione web che riceve input dall'utente e processa gli input attraverso un algoritmo che richiede da 5 a 25 minuti (a seconda degli input) e fornisce un risultato diverso. Con i risultati diversi intendo, l'utente non aspetterà il risultato dietro l'interfaccia utente e riceverà una notifica via email quando il calcolo sarà completato.

  • La parte dell'algoritmo che elabora gli input dovrebbe essere scalabile.
  • L'applicazione deve essere ospitata nei locali.
  • Le richieste provengono da utenti a pagamento dovrebbero essere in prima fila.


Sto cercando di progettare un'architettura di alto livello e sono nuovo nel mondo del software, dei contenitori e dei microservizi scalabili.
Questo è un progetto di base approssimativo con cui sono arrivato finora:
Insopra:

  • L'appfront-endèresponsabiledellaricezionedegliinputdell'utente.(nonnecessitadiesserescalabileperilmomento)epubblicalerichiestenelserverdimessaggistica.
  • IlserverdimessaggisticaèunservercheospitaunsoftwarecomeRabbitMQ.
  • Il"gestore code" è un software che deve essere sviluppato che è sottoscritto ai messaggi e assegna le richieste quando è disponibile un'istanza non allocata dell'algoritmo runner. Inoltre, è responsabile dell'ordine della coda, a seconda del piano a cui è abbonato anche l'utente, quindi la richiesta dell'utente a pagamento avrà la priorità.
  • L'istanza del corridore di algoritmo si trova all'interno di un container (ad esempio la finestra mobile) che è possibile ridimensionare aumentando il numero delle istanze.

Ecco le mie domande.

  • Questa architettura / design ha senso? Non è eccessivo o viceversa, potrebbe essere troppo semplice?

  • Il mio più grande dubbio è che è necessaria l'app del gestore code o che i contenitori debbano essere sottoscritti direttamente ai messaggi. In questo caso, come funzionerebbe la definizione delle priorità?

posta Shahin 19.10.2018 - 13:12
fonte

1 risposta

1

Solo un commento: personalmente manterrei il servizio Queue Manager.

Mentre potrebbe essere possibile per i contenitori "worker" di sottoscrivere i messaggi stessi per eseguire i compiti dell'algoritmo, è inefficiente / difficile / impossibile implementare diverse funzionalità (che IMHO vorrebbe prima o poi sarà necessario) dall'esecuzione del codice in un contesto "lavoratore":

  • fornire una vista dinamica / globale del sistema / servizio
  • esecuzione della pianificazione prioritaria
  • esecuzione del monitoraggio del contenitore di lavoro e logica di errore / recupero
  • portare i contenitori su e giù secondo le necessità / ridimensionare il pool del contenitore di lavoro
  • ridimensionamento dell'intero servizio

Con un Queue Manager dedicato centralizzato sarebbe molto più facile IMHO implementare gli elementi di cui sopra:

  • ha già la visione centralizzata / globale del servizio
  • possiede la decisione centralizzata della schedulazione del lavoro, è quasi banale implementare la priorità o qualsiasi altra logica di qualità del servizio simile
  • potrebbe essere l'entità centrale che monitora lo stato dei contenitori di lavoro che eseguono i lavori, facile da rilevare i guasti. Potrebbe essere estratto come microservizio separato.
  • le informazioni sul servizio utilizzate per prendere decisioni di pianificazione, integrate da informazioni sullo stato del servizio ottenute dall'attività di pianificazione, sono in genere le informazioni necessarie per prendere decisioni di ridimensionamento del pool di contenitori di lavoro. Il gestore code può a sua volta guidare l'esecuzione di tali decisioni o semplicemente fornire i trigger a un servizio separato dedicato a tale scopo.
  • il ridimensionamento del sistema normalmente non richiederebbe il ridimensionamento dei contenitori worker (che sarebbe necessario se eseguissero la funzionalità del gestore code).
risposta data 20.10.2018 - 20:45
fonte

Leggi altre domande sui tag