Dopo aver fatto un po 'più di ricerche, mi sono imbattuto in questo articolo dal quale ho estratto alcune citazioni che ritengo utili per ciò che voglio realizzare (e per eventuali futuri lettori). Questo offre un modo per adottare un modello di programmazione reattivo su un modello di programmazione imperativo.
Evento-sourcing
The idea here is to represent every application’s state transition in
a form of an immutable event. Events are then stored in a log or
journal form as they occur (also referred to as ‘event store’). They
can also be queried and stored indefinitely, aiming to represent how
the application’s state, as a whole, evolved over time.
Ciò che questo aiuta a realizzare è che se un microservizio si interrompe, altri eventi pertinenti ad esso vengono pubblicati e gli eventi vengono consumati, ad esempio, da altre istanze di quel microservizio, quando quel microservizio ritorna su , può fare riferimento a questo event store per recuperare tutti gli eventi mancati durante il periodo in cui è andato giù.
Apache Kafka come broker di eventi
Considerare l'uso di Apache Kafka che può archiviare e inviare migliaia di eventi al secondo e ha meccanismi di replica e tolleranza di errore incorporati. Ha una memoria permanente di eventi che possono essere archiviati su disco a tempo indeterminato e consumati in qualsiasi momento (ma non rimossi) dall'argomento (la coda di fantasia di Kafka) sono stati consegnati.
The events are then assigned offsets that univocally identify them
within the Topic — Kafka can manage the offsets itself, easily
providing “at most once” or “at least once” delivery semantics, but
they can also be negotiated when an event consumer joins a Topic,
allowing microservices to start consuming events from any arbitrary
place in time — usually from where the consumer left off. If the last
consumed event offset is transactionally persisted in the services’s
local storage when the usecases ‘successfully complete’, that offset
can easily be used to achieve an “exactly once” event delivery
semantics.
In effetti, quando i consumatori si identificano con Kafka, Kafka registra quali messaggi sono stati consegnati a quale consumatore in modo che non lo risponda nuovamente.
Sagas
For more complex usecases where the communication among different
services is indeed necessary, the responsibility of finishing the
usecase must be well recognized — the usecase is decentralized and
only finishes when all the services involved acknowledge their task as
successfully completed, otherwise the whole usecase must fail and
corrective measures must be triggered to rollback any invalid local
state.
Questo è quando la saga entra in gioco. Una saga è una sequenza di transazioni locali. Ogni transazione locale aggiorna il database e pubblica un messaggio o un evento per attivare la successiva transazione locale nella saga. Se una transazione locale non riesce perché viola una regola aziendale, la saga esegue una serie di transazioni compensative che annullano le modifiche apportate dalle transazioni locali precedenti. Leggi questo per maggiori informazioni.