Bus messaggi v Schema mediatore v In bus di memoria

Question

Bus messaggi v Schema mediatore v In bus di memoria

#1 da (2 voti)

0

Sto facendo fatica a capire quando usare ognuno di questi:

1) Bus messaggi: utilizzato per inviare eventi di integrazione tra microservizi. Ad esempio, Microservice A potrebbe pubblicare un evento di integrazione, gestito da Microservice B e Microservice C. Il vantaggio di un Message Bus, ad es. RabbitMQ è che potrebbe essere durevole nel senso che se uno dei Microservices non funziona, può gestire l'evento in un secondo momento. Garantisce anche la consegna.

2) Mediatr (modello di mediazione): utilizzando CQRS, il pattern Mediatr può essere utilizzato per disaccoppiare comandi ed eventi rendendo il controller MVC / servizio più sottile.

Vedo come entrambi questi pattern possono essere utilizzati nello stesso ambiente. Vedo quindi un codice come questo:

3) In bus di memoria: link . È un bus in memoria.

Qual è la differenza tra l'uso di Mediatr e un In Memory Bus? Il modo in cui sto pensando al momento è che Mediatr è più appropriato quando si usa il pattern Observer e un In Memory Bus è più adatto quando si utilizza il pattern publisher / subscribe. Ho capito bene?

È appropriato utilizzare un bus InMemory per un singolo Microservice (per eventi di dominio) e un bus messaggi durevole per eventi di integrazione (tra microservizi)?

domain-driven-design microservices message-queue

posta w0051977 28.09.2018 - 12:20

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design microservices message-queue

In quale livello un microservizio dovrebbe inviare un messaggio a un altro microservizio Tabelle dei codici di ricerca in DDD

score 2 · Accepted Answer

Un modello di mediatore crea un'interfaccia flessibile disaccoppiata tra due microservizi. I messaggi vengono inviati da e verso ciascun microservizio senza dover necessariamente conoscere tutti i meccanismi espliciti dell'altro.

Questo modello è ideale se pensi che la relazione tra i due potrebbe cambiare in modo significativo in futuro. Il mediatore potrebbe essere autonomo e potrebbe mantenere i messaggi in caso di mancata consegna, quindi potenzialmente può essere altrettanto stabile del bus dei messaggi.

Un modello di pubblicazione-sottoscrizione che è fondamentalmente il bus dei messaggi, non è solo per due interfacce. È potenzialmente per più interfacce, consentendo la massima flessibilità. La flessibilità si estende anche al messaggio stesso, il che significa che il messaggio deve essere facilmente inviato e ricevuto da chiunque sia interessato a ricevere tale messaggio quando si verifica un evento. Ciò implica anche che potresti avere problemi lungo il percorso con il controllo delle versioni se non stai attento, poiché le modifiche ai messaggi che vengono trasmesse devono essere coerentemente interpretate attraverso i microservizi, a differenza del mediatore. Quando il messaggio cambia, anche solo il mediatore deve deve essere aggiornato affinché tutto funzioni correttamente.

Un bus in memoria non è in realtà un modello tanto quanto un bus dei messaggi senza persistenza. È più veloce, ma non è l'ideale anche in caso di guasti imprevisti, in quanto non si sa dove si è verificato l'errore e si sarebbe seriamente tentata di ripristinare la situazione precedente. In qualsiasi contesto di produzione, non lo consiglierei, anche se ha scritto su un file di registro.

Spero che risponda alla tua domanda!