Come usare Messagequeing in un'applicazione web distribuita

Question

Come usare Messagequeing in un'applicazione web distribuita

#1 da (3 voti)

3

Sono curioso di trovare soluzioni a questo problema:

Supponiamo che costruiremo un negozio online. Per scalare meglio parti dell'architettura, è suddiviso in sottosistemi indipendenti. Lo scenario tipico coinvolgerebbe un server delle applicazioni (o qualcosa di simile), in cui arrivano le richieste dei clienti.

Il flusso per un accesso sarebbe simile a questo:

La richiesta arriva

- > Autentica utente

- > Ottieni gli ultimi prodotti acquistati dall'utente

- > calcola gli annunci appropriati

- > consegna pagina generata al client.

Questo è meno efficiente, perché le query dei sottosistemi avvengono in modo seriale / sincrono. Sarebbe meglio, per effettuare chiamate in parallelo.

Ad esempio si potrebbe usare un server Node.JS e chiamare i sottosistemi in modo asincrono. Durante la richiamata viene chiamata una "funzione di riduzione", che aggrega tutti i dati e, una volta raccolti tutti i dati, rimanda la pagina generata al client.

Quindi questo sistema sembra più efficiente.

Un altro passaggio include l'ulteriore disaccoppiamento e introduce le code dei messaggi.

Quindi c'è da un lato il server delle applicazioni, che riceve le richieste e serve le risposte; e d'altra parte, i componenti indipendenti che comunicano sulle code dei messaggi.

Il flusso sarebbe il seguente:

Richiesta in entrata

- > Messaggio: "L'accesso alla chiave di sessione 1234567890 è garantito"

Quindi con la chiave di sessione, l'utente e i relativi messaggi sono identificabili. Questo messaggio viene preso dal servizio utente e produce la risposta "Utente con chiave di sessione 1234567890 è John Doe di New York". Questo messaggio è pubblicato su tutti gli altri servizi dell'applicazione. Così possono reagire e pubblicare i loro risultati.

Il mio problema è, come posso indirizzare il risultato sul server delle applicazioni che deve attendere un tempo imprecisato? Come fa a sapere quando raccogliere tutti i risultati per la sua richiesta?

Una soluzione potrebbe essere, utilizzando un database in memoria (ad esempio Redis). Tutti i servizi possono scrivere i loro risultati in Redis, che viene costantemente interrogato dal server delle applicazioni in attesa di un risultato da consegnare. Ma questa è la soluzione?

Ci sono altre soluzioni?

web-applications soa message-queue

posta Thomas Junk 24.07.2014 - 01:09

fonte

1 risposta

Leggi altre domande sui tag web-applications soa message-queue

La migliore strategia per scoprire un servizio Web in una rete locale? Eliminazione dei requisiti di affinità del thread durante la conversione di un oggetto COM STA in un oggetto COM MTA

score 3 · Accepted Answer

Nell'esempio che usi non c'è nulla che possa essere parallelizzato. Ogni passaggio richiede dati dal precedente. Spero che tu stia usando un esempio migliore per le tue bozze di progettazione.

La direzione in cui ti stai dirigendo richiede un'orchestrazione abbastanza elaborata (come hai capito tu stesso) e questo è un problema non banale. Una possibile opzione tecnica è l'uso di code temporanee: il front server crea una destinazione temporanea per la sessione utente, quindi la fornisce come destinazione di risposta alle sotto-attività. Questo tipo di soluzione richiede molta cura nella gestione del ciclo di vita della destinazione, pensando a timeout, sessioni abbandonate, destinazioni temporanee pendenti e fail over sul lato del coordinatore (il front server). Ipoteticamente puoi costruire un albero di passi usando questo modello, ma stai molto attento a controllare la complessità dell'interazione.

La trasmissione (nel suo significato ampio) in un sistema altamente distribuito con un carico elevato previsto deve essere evitata. Dovrai considerare un partizionamento naturale (quindi economico) nei disegni del flusso dei messaggi. Esempio di tale partizionamento è il comportamento della coda round-robbin nei broker JMS mainstream.

Non trasmetterei il tentativo di autenticazione in quanto sarebbe molto facile subire un attacco con DOS.

Alternativa sarebbe quella di rendere i segnaposto nella pagina web per ogni portlet (annunci pubblicitari, acquisti recenti, ecc.) che richiedono i dati sul caricamento della pagina e lasciano l'orchestrazione al browser. È così semplice che nessuna altra soluzione batte il suo rapporto costi / benefici.

Non sono sicuro di quanto sia rilevante - stai attento a sapere molto bene perché stai tagliando il sistema nel modo particolare che hai scelto. I confini di un servizio è una decisione estremamente importante perché se fatto male ha un effetto negativo duraturo ed è molto difficile da risolvere. Se non l'hai già fatto, investi il tempo per ricercare la letteratura SOA sulle metodologie per definire i confini del servizio. Indipendentemente dalla tecnologia che intendi utilizzare.