Dopo aver fatto un po 'più di ricerca, mi sono imbattuto in questo articolo da cui ho tirato fuori alcune citazioni che penso siano utili per ciò che voglio realizzare (e per eventuali lettori futuri). Ciò offre un modo per adottare un modello di programmazione reattiva rispetto a un modello di programmazione imperativo.
Event-sourcing
L'idea qui è quella di rappresentare la transizione di stato di ogni applicazione in una forma di evento immutabile. Gli eventi vengono quindi archiviati in un registro o in un modulo journal quando si verificano (noto anche come "archivio eventi"). Possono anche essere interrogati e archiviati indefinitamente, con l'obiettivo di rappresentare come lo stato dell'applicazione, nel suo insieme, si è evoluto nel tempo.
Ciò che aiuta a realizzare è che se un microservizio scende, ma altri eventi pertinenti ad esso vengono pubblicati e gli eventi vengono consumati, ad esempio, da altre istanze di quel microservizio, quando il microservizio viene ripristinato, può fare riferimento a questo event storeper recuperare tutto il eventi che ha perso durante il periodo in cui è andato giù.
Apache Kafka come Event Broker
Considera l'uso di Apache Kafka che può archiviare e inviare migliaia di eventi al secondo e ha meccanismi di replica e tolleranza d'errore integrati. Ha un archivio persistente di eventi che possono essere memorizzati su disco indefinitamente e consumati in qualsiasi momento (ma non rimossi) dall'argomento (la coda elaborata di Kafka) a cui sono stati consegnati.
Agli eventi vengono quindi assegnati offset che li identificano in modo univoco all'interno dell'argomento: Kafka può gestire gli offset stessi, fornendo facilmente semantiche di consegna "al massimo una volta" o "almeno una volta", ma possono anche essere negoziate quando un consumatore di eventi si unisce a un argomento , consentendo ai microservizi di iniziare a consumare eventi da qualsiasi luogo arbitrario nel tempo, di solito da dove il consumatore aveva interrotto. Se l'ultimo offset dell'evento consumato è persistentemente transazionale nella memoria locale dei servizi quando le istruzioni vengono "completate correttamente", tale offset può essere facilmente utilizzato per ottenere una semantica di consegna dell'evento "esattamente una volta".
Infatti, quando i consumatori si identificano in Kafka, Kafka registra quali messaggi sono stati recapitati a quale consumatore in modo che non vengano più pubblicati.
Sagas
Per casi d'uso più complessi in cui la comunicazione tra diversi servizi è effettivamente necessaria, la responsabilità di completare il caso d'uso deve essere ben riconosciuta - il caso d'uso è decentralizzato e termina solo quando tutti i servizi coinvolti riconoscono il loro compito come completato con successo, altrimenti l'intero caso d'uso deve fallire e misure correttive devono essere attivate per ripristinare qualsiasi stato locale non valido.
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 fallisce perché viola una regola aziendale, la saga esegue una serie di transazioni compensative che annullano le modifiche apportate dalle precedenti transazioni locali. Leggi questo per maggiori informazioni.