Dovremmo utilizzare pub / sub nel nostro stack di messaggistica?

Question

Dovremmo utilizzare pub / sub nel nostro stack di messaggistica?

#1 da (2 voti)

1

Fondamentalmente questa domanda riguarda la varietà "Posso verificare che non stiamo per fare qualcosa di stupido?"

Stiamo impostando un nuovo sistema che deve garantire la consegna delle email.

Abbiamo un sistema esistente che elabora le transazioni finanziarie e che vogliamo disaccoppiare dall'invio delle ricevute (che attualmente sta gestendo da solo), quindi stiamo impostando un secondo servizio per scaricare le ricevute di invio. Il servizio di posta elettronica è completamente indipendente, ha un proprio database, riceve solo eventi dal sistema finanziario per dirgli quali email inviare.

Inizialmente pensavamo di utilizzare un pub / sub (probabilmente Google) per le comunicazioni tra i sistemi.

Ma mentre progettavamo i sistemi attorno ad esso, ci siamo resi conto che il processo di lavoro nel sistema di posta elettronica stava semplicemente togliendo messaggi da pub / sub e inserendoli in una tabella Postgres, che un altro processo poi inoltra tramite e-mail.

Abbiamo anche il buffering dei messaggi da pubblicare sul lato di pubblicazione, poiché anche se google pub / sub è molto affidabile, potrebbe non essere al 100%.

Quindi ci siamo chiesti perché abbiamo persino bisogno del pub / sub, perché non avere un sistema webhooks e avere l'operatore di messaggistica nel sistema finanziario ping un webhook sul sistema di posta elettronica?

Dato che pub / sub è un modello di progettazione così comune per risolvere questo tipo di problema, sono preoccupato che ci sia qualcosa che ci manca nei nostri pensieri?

Le prestazioni sembrano l'ovvia ragione, ma dato che il sistema finanziario deve fare quanto segue:

Inserisci una transazione nel suo database
Contatta il gateway di pagamento
Contrassegna la transazione come pagato
Coda che invia un messaggio nel DB

(Quindi un lavoratore annulla il messaggio e colpisce il webhook)

Mentre il processo webhooks nel servizio email deve solo

Inserisci l'evento del messaggio nel database

(lascia che un processo worker si occupi di elaborare quell'evento)

Mi sembra che il sistema finanziario non sarà mai in grado di muoversi abbastanza velocemente da sovraccaricare il webhook al servizio di posta elettronica. L'elaborazione delle transazioni dovrebbe sempre essere un collo di bottiglia più grande.

message-queue message-passing

posta ChristopherJ 09.11.2017 - 03:49

fonte

1 risposta

Leggi altre domande sui tag message-queue message-passing

Quale è un modo più efficiente di memorizzare i dati in un database usando Oggetti o stringhe (progettazione del database) Qual è l'architettura di sistema di un'applicazione reattiva non-SPA?

score 2 · Accepted Answer

Ho scritto un sistema simile circa un mese fa, e proprio come te ho scoperto che questo è meglio risolto con una affidabile tecnologia di coda con un redrive.

Mentre alcuni potrebbero argomentare usando SQL come la tua coda non è il modo più affidabile, sicuramente funziona in molti casi.

La ragione per usare pub-sub sistemi è quando hai più differenti cose che devono accadere da un evento. Per esempio. se hai ricevuto due email diverse da una transazione, potresti avere un sistema dove

|====|    |====| => [UserEmail Sub]
|Tran| => |=Pub|
|====|    |====| => [ReceiptEmail Sub]

Ma anche in quel caso, quei piccoli componenti Sub accoderebbero un diverso insieme di dati al meccanismo Queue, che alla fine avrebbe più processi di lavoro failover che estraevano dataset e inviavano email effettive.