Ho appena letto questo articolo e io m confuso.
Immaginiamo 1 webapp e 1 applicazione distinta che agisce come "worker", entrambi che condividono lo stesso database .
Oh, ho detto "condivisione" ... ma di cosa parla l'articolo? :
Fourthly, sharing a database between applications (or services) is a bad thing. It’s just too tempting to put amorphous shared state in there and before you know it you’ll have a hugely coupled monster.
= > disaccordo. Ci sono alcuni casi in cui applicazioni distinte fanno ancora parte della stessa unità e, quindi, la nozione di "problema di accoppiamento" non ha senso in questo caso.
Continuiamo: la webapp gestisce le richieste HTTP dei client e può aggiornare in qualsiasi momento alcuni aggregati (termine DDD), generando gli eventi di dominio corrispondenti.
L'obiettivo del lavoratore sarebbe gestire quegli eventi di dominio elaborando i lavori necessari.
Il punto è:
Come devono essere trasmessi i dati degli eventi al lavoratore?
La prima soluzione, come promuove l'articolo letto, sarebbe quella di utilizzare RabbitMQ, essendo un ottimo middleware orientato ai messaggi.
Il flusso di lavoro sarebbe semplice:
Ogni volta che il web dyno genera un evento, lo pubblica tramite RabbitMQ, che alimenta il lavoratore.
Lo svantaggio sarebbe che nulla garantisce la consistenza immediata tra il commit dell'aggiornamento aggregato e la pubblicazione dell'evento, senza affrontare i potenziali errori di invio ... o problemi hardware; questo è un altro problema principale.
Esempio: sarebbe possibile che un evento sia stato pubblicato senza successo dell'aggiornamento aggregato ... risultando in un evento che rappresenta una rappresentazione errata del modello di dominio.
Si potrebbe sostenere che esiste un XA globale (commit a due fasi), ma non è una soluzione adatta a tutti i database o middleware.
Quindi quale potrebbe essere una buona soluzione per garantire questa coerenza immediata? :
IMO, memorizzando l'evento nel database, nella stessa transazione locale dell'aggiornamento aggregato.
Verrà creato un semplice programma di pianificazione asincrona e responsabile di eseguire query sugli eventi non pubblicati correnti dal database e inviarli a RabbitMQ, che a sua volta popola l'operatore.
Ma perché necessitare di uno scheduler aggiuntivo nel lato webapp e tra l'altro: perché aver bisogno di RabbitMQ in questo caso?
Da questa soluzione, appare logicamente che RabbitMQ potrebbe non essere necessario, soprattutto perché il database è condiviso.
In effetti, in ogni caso, abbiamo visto che la consistenza immediata implica un sondaggio dal database.
Quindi, perché il lavoratore non dovrebbe essere responsabile direttamente di questo sondaggio?
Pertanto, mi chiedo perché così tanti articoli sul web critichino difficilmente l'accodamento dei database, promuovendo al tempo stesso il middleware orientato ai messaggi.
Estratto dell'articolo:
Simple, use the right tool for the job: this scenario is crying out for a messaging system. It solves all the problems described above; no more polling, efficient message delivery, no need to clear completed messages from queues, and no shared state.
E consistenza immediata, ignorata?
Per riassumere, sembra davvero che qualunque sia il caso, ovvero che il database sia condiviso o meno, abbiamo bisogno del polling del database .
Ho perso alcune nozioni critiche?
Grazie