Architettura di applicazioni Web per app in tempo reale

1

Usecase : l'utente finale effettua un ordine sul sito Web dell'azienda, l'ordine deve essere trasferito alla schermata dell'amministratore dell'azienda con una piccola latenza. La società ha più filiali (identificate dalla combinazione compId e branchId) quindi l'ordine deve essere inviato per correggere l'amministratore.

Quello che ho fino ad ora : un'API REST che accetta l'ordine, la mantiene su MongoDB e scrive il messaggio su gateway di messaggistica . Il gateway di messaggistica disaccoppia il mio servizio di invio e-mail dalla mia app Web.

Con cosa sto combattendo : come inviare ordini al client di amministrazione basato su browser dove la consegna è garantita e in tempo reale? Sto pensando di utilizzare il polling lungo per il client admin, in quanto il volume degli ordini non è abbastanza grande da giustificare WebSockets (è corretto?). E Apache Kafka o Redis per la consegna garantita e lo streaming degli ordini in tempo reale sul lato server.

Soluzione che ho trovato : quando l'amministratore esegue l'accesso SseEmitter viene creato sul server e archiviato in una mappa in cui la chiave è composta da compID e BranchId. Quando arriva un ordine, viene aggiunto all'argomento o Redis di Kafka. Un listener ( kafka o redis ) ascolta questi eventi e cerca di ottenere l'SSE per questo ordine dalla mappa, se trovato, scrive l'ordine sull'SSE. E rimuovi l'ordine dall'argomento o Redis DB.

Domande :

  1. Che cosa è più adatto per questo Kafka o Redis? Non ho un precedente esperienza per entrambi.
  2. Quali potrebbero essere i problemi con questo approccio? lunghi sondaggi, messaggistica, ecc. C'è qualcosa che sto cercando?
  3. La mia ipotesi relativa alle prese web è corretta?
  4. Qualsiasi altra informazione che potresti avere.
posta Rohit 26.01.2017 - 02:04
fonte

4 risposte

2
  1. Kafka e redis non vengono utilizzati per lo stesso scopo. Redis è un motore di memorizzazione di valore chiave e Kafka è "piattaforma di streaming". Non ho mai usato Kafka ma sembra che funzioni come un broker di messaggi ottimizzato per lo streaming

Ci siamo imbattuti in una richiesta simile presso la società per cui lavoro. Abbiamo dovuto contrassegnare i posti come occupati su un piano di posti a sedere insieme a persone che hanno i loro biglietti scansionati all'ingresso del teatro. Ecco una versione semplificata della nostra soluzione:

  • hai bisogno di un broker di messaggi (rabbitMQ), un daemon nodeJS, un client websocket.
  • ogni volta che viene scansionato un ticket, i dati corrispondenti vengono inviati a rabbitMQ creando così un nuovo messaggio in coda
  • il daemon nodeJS controlla costantemente la coda rabbitMQ per i nuovi messaggi.
  • ogni volta che un supervisore si connette all'interfaccia display, viene aperto un websocket con il daemon nodeJS. Questo websocket verrà utilizzato per notificare al client che alcuni nuovi dati devono essere recuperati sul server.
  • ogni volta che un messaggio arriva in coda, viene letto (e distrutto per evitare che venga elaborato due volte) dal daemon nodeJs. Il daemon notifica a tutti i client connessi tramite le websocket
  • ogni volta che un client riceve una notifica websocket, esegue il polling dei nuovi dati dal server web.
risposta data 26.01.2017 - 20:04
fonte
0

Non penso che questo sia impegnativo come alcuni lo stanno dimostrando. La tua domanda è taggata in Java, quindi lavorerò su questo.

In primo luogo, poiché si tratta di ordini e non di reazione al traffico automobilistico, assumerò che una latenza di un secondo o due sia accettabile e cedibile per il tempo reale.

Direi, usa solo Redis e un'app Web Java; mantienilo semplice I Websocket non sono affidabili quanto le tecnologie più mature e dubito che le notifiche "push" siano realmente necessarie. Suppongo che tu non abbia più di qualche migliaio di amministratori, vero?

Redis è semplice, altamente disponibile, ha una propria implementazione di coda ed è incredibilmente veloce.

Mentre certamente potresti usare mongo, penso che un DB sql regolare sarebbe più appropriato; Sospetto molto che i tuoi dati siano relazionali . Puoi utilizzare i redis per velocizzare le cose, non che un DB progettato correttamente sia lento.

Quando viene effettuato un ordine, il suo sommario viene inserito in una coda redis. È quindi, anche in modo asincrono nel tuo database principale (ti consiglio vivamente di utilizzare Postgres o Oracle per il tuo db principale).

La tua pagina web di amministrazione è un semplice timer javascript, che spara forse ogni mezzo secondo circa, eseguendo il polling di un semplice json api creato in un controllo di primavera. Questa json api controlla la coda redis e invia una minima risposta JSON allo script admin (forse solo ID ordine e titolo). Se la risposta non è vuota, lo script reindirizza a una pagina di ordine più approfondita, o qualsiasi altra cosa ti serva.

Se hai bisogno di un comportamento di accodamento più complesso, rabbitmq è buono, ma tieni solo i redis con un db transnazionale che lo supporta, se puoi.

Non c'è bisogno di pensare troppo a questo; non farti travolgere dall'eccitazione del tuo PM.

    
risposta data 13.12.2017 - 23:28
fonte
-1

La creazione della nostra architettura può essere utile per la manutenzione. Penso che possiamo creare un'architettura orientata ai servizi con REST + angularjs e anche websocket api per spingere i dati in tempo reale sull'interfaccia utente. Allo stesso tempo ci sono anche alcuni framework java come webfirmframework che fornisce aggiornamenti ui in tempo reale garantiti senza alcun trigger da ui. Apache Kafka è un sistema di messaggistica distribuito che può raccogliere in modo affidabile i messaggi da più fonti e inviare in modo affidabile messaggi a miliardi (o più) di utenti abbonati a causa della sua natura distribuita può gestire un carico pesante. Kafka da solo non sarà sufficiente per visualizzare messaggi nella pagina del browser, da server a client (pagina browser), dati che spingono abbiamo bisogno del supporto di websocket o di altri metodi come il polling lungo ecc.

Redis è una memoria dati in-memory che può essere usata come database, un nosql db, supporta varie strutture di dati come, set, map, list ecc ..

Possiamo anche considerare RethinkDB, riferito dal suo sito web: che spinge continuamente i risultati delle query aggiornati alle applicazioni in tempo reale . Pertanto, la combinazione RethinkDB + webfirmframework sarà un modo semplice per l'architettura delle app web in tempo reale.

    
risposta data 12.08.2017 - 10:53
fonte
-1

Forse feathers.js (basato su espresso) può aiutarti. Con le piume puoi facilmente implementare CRUD / Rest Apis che memorizzano i loro dati nel tuo db preferito (mongo è ufficialmente supportato da mangusta). Inoltre, può inviare automaticamente queste notifiche di eventi CRUD ai client sottoscritti tramite socket.io. Per questo, hanno un client facile da configurare che svolge gran parte del lavoro.

    
risposta data 14.09.2017 - 20:00
fonte

Leggi altre domande sui tag