Problema di doppia scrittura  Creare un sistema distribuito affidabile, altamente disponibile e scalabile richiede l'aderenza a tecniche, principi e modelli specifici. La progettazione di tali sistemi implica l'affrontare una miriade di sfide. Tra i problemi più diffusi e fondamentali c'è   . il problema della scrittura duale  Il   è una sfida che si presenta nei sistemi distribuiti, principalmente quando si ha a che fare con più fonti di dati o database che devono essere mantenuti sincronizzati. Si riferisce alla difficoltà di garantire che le modifiche dei dati vengano scritte in modo coerente su vari archivi dati, come database o cache, senza introdurre problemi come incongruenze nei dati, conflitti o colli di bottiglia nelle prestazioni. "dual write problem"  L'architettura dei microservizi e il database di pattern per servizio ti offrono molti vantaggi, come distribuzione e scalabilità indipendenti, guasti isolati e un potenziale aumento della velocità di sviluppo. Tuttavia, le operazioni richiedono modifiche tra più microservizi, costringendoti a pensare a una soluzione affidabile per affrontare questo problema.   Quasi un esempio reale  Consideriamo uno scenario in cui il nostro dominio comporta l'accettazione di richieste di prestito, la loro valutazione e l'invio di avvisi di notifica ai clienti.  Nello spirito del principio di responsabilità unica, della legge di Conway e dell'approccio di progettazione basato sul dominio, dopo diverse sessioni di event storming, l'intero dominio è stato suddiviso in tre sottodomini con contesti delimitati definiti, con confini chiari, modelli di dominio e linguaggio onnipresente.    è incaricato di onboarding e compilazione di nuove domande di prestito.   sistema valuta queste domande e prende decisioni in base ai dati forniti. Questo processo di valutazione, inclusi i controlli KYC/KYB, antifrode e di rischio di credito, può richiedere molto tempo, rendendo necessaria la capacità di gestire migliaia di domande contemporaneamente. Di conseguenza, questa funzionalità è stata delegata a un microservizio dedicato con il proprio database, consentendo un ridimensionamento indipendente. Il primo Il secondo  Inoltre, questi sottosistemi sono gestiti da due team diversi, ciascuno con i propri cicli di rilascio, accordi sul livello di servizio (SLA) e requisiti di scalabilità.    , è attivo un servizio di notifica specializzato per inviare avvisi ai clienti.  Infine Ecco una descrizione dettagliata del caso d'uso principale del sistema:  Un cliente invia una richiesta di prestito.  Il Servizio Richiesta Prestito registra la nuova domanda con lo stato "In sospeso" e avvia il processo di valutazione inoltrando la domanda al Servizio di Valutazione.  Il Servizio di valutazione valuta la domanda di prestito in arrivo e successivamente informa il Servizio di richiesta di prestito della decisione.  Dopo aver ricevuto la decisione, il Servizio di richiesta di prestito aggiorna di conseguenza lo stato della richiesta di prestito e attiva il Servizio notifiche per informare il cliente dell'esito.  Il Servizio Notifiche elabora questa richiesta e invia le notifiche al cliente tramite e-mail, SMS o altri metodi di comunicazione preferiti, in base alle impostazioni del cliente.  A prima vista sembra un sistema piuttosto semplice e primitivo, ma analizziamo nel dettaglio come il servizio di richiesta di prestito elabora il comando di invio della richiesta di prestito.  Possiamo considerare due approcci per le interazioni di servizio:    con questo approccio, il servizio aggiorna il suo database locale (esegue commit) e poi pubblica un evento o un messaggio su altri servizi. First-Local-Commit-Then-Publish:    al contrario, questo metodo prevede la pubblicazione di un evento o di un messaggio prima di confermare le modifiche nel database locale. First-Publish-Then-Local-Commit:  Entrambi i metodi presentano degli svantaggi e sono solo parzialmente sicuri per la comunicazione nei sistemi distribuiti.     Questo è uno schema sequenziale dell'applicazione del primo approccio.  In questo scenario, il Loan Application Service impiega l'approccio   , in cui prima esegue una transazione e poi tenta di inviare una notifica a un altro sistema. Tuttavia, questo processo è suscettibile di fallimento se, ad esempio, ci sono problemi di rete, l'Assessment Service non è disponibile o il Loan Application Service incontra un errore Out of Memory (OOM) e si blocca. In tali casi, il messaggio andrebbe perso, lasciando l'Assessment senza notifica della nuova richiesta di prestito, a meno che non vengano implementate misure aggiuntive. First-Local-Commit-Then-Publish     E il secondo.  Nello scenario   , il Loan Application Service affronta rischi più significativi. Potrebbe informare l'Assessment Service di una nuova domanda ma non riuscire a salvare questo aggiornamento localmente a causa di problemi come problemi di database, errori di memoria o bug del codice. Questo approccio può portare a significative incongruenze nei dati, che potrebbero causare seri problemi, a seconda di come il Loan Review Service gestisce le domande in arrivo. First-Publish-Then-Local-Commit  Pertanto, dobbiamo identificare una soluzione che offra un meccanismo robusto per pubblicare eventi su consumatori esterni. Ma, prima di addentrarci in possibili soluzioni, dovremmo prima chiarire i tipi di garanzie di recapito dei messaggi ottenibili nei sistemi distribuiti.  Garanzie di recapito dei messaggi  Esistono quattro tipi di garanzie che potremmo ottenere.  Nessuna garanzia  Non c'è alcuna garanzia che il messaggio verrà recapitato a destinazione. L'approccio   riguarda proprio questo. I consumatori possono ricevere messaggi una volta, più volte o mai. First-Local-Commit-Then-Publish  Al massimo una consegna  La consegna al massimo una volta significa che il messaggio verrà consegnato alla destinazione al massimo 1 volta. L'approccio   può essere implementato anche in questo modo con la politica di ripetizione dei tentativi con valore uno. First-Local-Commit-Then-Publish  Almeno una volta consegnato\I consumatori riceveranno ed elaboreranno ogni messaggio, ma potrebbero ricevere lo stesso messaggio più di una volta.  Consegna esattamente una volta\La consegna esattamente una volta significa che il consumatore riceverà il messaggio una sola volta.  Tecnicamente, è possibile ottenerlo con transazioni Kafka e con l'implementazione idempotente specifica di produttore e consumatore.  Nella maggior parte dei casi, le garanzie di consegna   affrontano molti problemi assicurando che i messaggi vengano recapitati almeno una volta, ma i consumatori devono essere idempotenti. Tuttavia, dati gli inevitabili guasti di rete, tutta la logica del consumatore deve essere idempotente per evitare di elaborare messaggi duplicati, indipendentemente dalle garanzie del produttore. Pertanto, questo requisito non è tanto uno svantaggio quanto riflette la realtà. "almeno una volta"  Soluzioni  Esistono numerose soluzioni a questo problema, ciascuna con i suoi vantaggi e svantaggi.   Commit in due fasi  Secondo Wikipedia, il Two-Phase Commit (2PC) è un protocollo di transazione distribuito utilizzato in informatica e nei sistemi di gestione di database per garantire la coerenza e l'affidabilità delle transazioni distribuite. È progettato per situazioni in cui più risorse (ad esempio, database) devono partecipare a una singola transazione e garantisce che tutte eseguano il commit della transazione o che tutte eseguano l'interruzione, mantenendo così la coerenza dei dati. Sembra esattamente ciò di cui abbiamo bisogno, ma il Two-Phase Commit presenta diversi svantaggi:  Se una risorsa partecipante non risponde o subisce un errore, l'intero processo può essere bloccato finché il problema non viene risolto. Ciò può portare a potenziali problemi di prestazioni e disponibilità.  Two-Phase Commit non fornisce meccanismi di tolleranza agli errori incorporati. Si basa su meccanismi esterni o interventi manuali per gestire gli errori.  Non tutti i database moderni supportano il Two-Phase Commit.   Database condiviso  La soluzione più evidente per l'architettura dei microservizi è quella di applicare un pattern (o talvolta anche un anti-pattern) — un database condiviso. Questo approccio è molto intuitivo se hai bisogno di coerenza transazionale su più tabelle in database diversi, usa semplicemente un database condiviso per questi microservizi.  Gli svantaggi di questo approccio includono l'introduzione di un singolo punto di errore, l'inibizione della scalabilità indipendente del database e la limitazione della capacità di utilizzare diverse soluzioni di database più adatte a requisiti e casi d'uso specifici. Inoltre, modifiche alle basi di codice dei microservizi sarebbero necessarie per supportare tale forma di transazione distribuita.   Posta in uscita transazionale  Il "   " è un modello di progettazione utilizzato nei sistemi distribuiti per garantire una propagazione affidabile dei messaggi, anche di fronte a sistemi di messaggistica inaffidabili. Comporta l'archiviazione degli eventi in una tabella "OutboxEvents" designata all'interno della stessa transazione dell'operazione stessa. Questo approccio si allinea bene con le proprietà ACID dei database relazionali. Al contrario, molti database No-SQL non supportano completamente le proprietà ACID, optando invece per i principi del teorema CAP e della filosofia BASE, che danno priorità alla disponibilità e alla coerenza finale rispetto alla coerenza rigorosa. transactional outbox  Una casella di posta in uscita transazionale fornisce   e può essere implementata con diversi approcci: almeno una garanzia  Registrazione del registro delle transazioni  Editore di sondaggi  L'approccio   implica l'utilizzo di soluzioni specifiche del database come CDC (Change Data Capture). I principali svantaggi di tale approccio sono: di tailing del registro delle transazioni  Soluzioni specifiche per database  Aumento della latenza dovuto alle specificità delle implementazioni CDC  Un altro metodo è   , che facilita l'offload della posta in uscita interrogando la tabella della posta in uscita. Lo svantaggio principale di questo approccio è il potenziale aumento del carico del database, che può portare a costi più elevati. Inoltre, non tutti i database No-SQL supportano query efficienti per segmenti di documenti specifici. L'estrazione di interi documenti può, quindi, causare un degrado delle prestazioni. Polling Publisher  Ecco un piccolo diagramma sequenziale che spiega come funziona.    Ascolta te stesso  La sfida principale con il modello Transactional Outbox risiede nella sua dipendenza dalle proprietà ACID del database. Potrebbe essere semplice nei tipici database OLTP, ma pone delle sfide nel regno NoSQL. Per risolvere questo problema, una possibile soluzione è sfruttare il log di aggiunta (ad esempio, Kafka) fin dall'avvio dell'elaborazione della richiesta.  Invece di elaborare direttamente il comando "submit loan application", lo inviamo immediatamente a un argomento Kafka interno e quindi restituiamo un risultato "accepted" al client. Tuttavia, poiché è altamente probabile che il comando debba ancora essere elaborato, non possiamo informare immediatamente il cliente del risultato. Per gestire questa eventuale coerenza, possiamo impiegare tecniche come il long polling, il client-initiated polling, gli aggiornamenti UI ottimistici o l'utilizzo di WebSocket o Server-Sent Events per le notifiche. Tuttavia, questo è un argomento completamente diverso, quindi torniamo al nostro argomento iniziale.  Abbiamo inviato il messaggio su un argomento Kafka interno. Il Loan Application Service quindi consuma questo messaggio, lo stesso comando ricevuto dal client, e inizia l'elaborazione. Innanzitutto, esegue una logica aziendale; solo dopo che questa logica è stata eseguita correttamente e i risultati sono stati resi persistenti, pubblica nuovi messaggi su un argomento Kafka pubblico.  Diamo un'occhiata a un po' di pseudo-codice.   public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }    Nessun problema, poiché l'offset non è ancora stato eseguito, il messaggio verrà ritentato. Cosa succede se l'elaborazione della logica aziendale fallisce?    Nessun problema, poiché la logica aziendale è idempotente, non creerà una richiesta di prestito duplicata. Invece, tenterà di inviare nuovamente i messaggi all'argomento pubblico di Kafka. Cosa succede se l'invio di nuovi eventi a Kafka fallisce?    Nessun problema, poiché la logica aziendale è idempotente, non creerà una richiesta di prestito duplicata. Invece, invierà nuovamente i messaggi al topic pubblico di Kafka e spererà che il commit offset questa volta vada a buon fine. Cosa succede se i messaggi vengono inviati a Kafka, ma il commit offset fallisce?  Gli svantaggi principali di questo approccio includono la maggiore complessità associata a un nuovo stile di programmazione, la coerenza finale (poiché il cliente non conoscerà immediatamente il risultato) e il requisito che tutta la logica aziendale sia idempotente.  Ricerca di eventi  Cos'è l'event sourcing e come potrebbe essere applicato qui? L'event sourcing è un modello di architettura software utilizzato per modellare lo stato di un sistema catturando tutte le modifiche ai suoi dati come una serie di eventi immutabili. Questi eventi rappresentano fatti o transizioni di stato e servono come unica fonte di verità per lo stato attuale del sistema. Quindi, tecnicamente, implementando un sistema di event sourcing, abbiamo già tutti gli eventi in EventStore e questo EventStore può essere utilizzato dai consumatori come unica fonte di verità su ciò che è accaduto. Non c'è bisogno di una soluzione di database specifica per tracciare tutte le modifiche o preoccupazioni sull'ordinamento, l'unico problema è sedersi sul lato di lettura poiché per essere in grado di ottenere lo stato effettivo dell'entità è necessario riprodurre tutti gli eventi.  Conclusione  In questo articolo, abbiamo esaminato diversi approcci per la creazione di messaggistica affidabile nei sistemi distribuiti. Ci sono diverse raccomandazioni che potremmo prendere in considerazione durante la creazione di sistemi con queste caratteristiche  Sviluppare sempre consumatori idempotenti poiché il guasto della rete è inevitabile.  Utilizzare con attenzione   avendo ben chiaro in mente i requisiti di garanzia. il metodo First-Local-Commit-Then-Publish  Non utilizzare mai   poiché potrebbe causare gravi incongruenze nei dati del sistema. l'approccio First-Publish-Then-Local-Commit  Se la decisione sulla scelta del database esistente molto probabilmente potrebbe cambiare o la strategia tecnica implica la selezione della migliore soluzione di archiviazione per il problema, non creare librerie condivise vincolandole a soluzioni di database come   . CDC  Utilizzare l'approccio   come soluzione standard per ottenere garanzie almeno una volta. Transactional Outbox  Si consiglia di adottare l'approccio   quando si utilizzano database No-SQL. Ascolta te stesso  La prossima volta esamineremo un esempio più pratico di implementazione di una posta in uscita transazionale. Vedere  Voi!

Read My Stories

Questo audio è prodotto nella lingua originale della storia!

Messaggistica affidabile nei sistemi distribuiti

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

Coding with Latenode's AI + JavaScript Assistant: A Low-Code Platform for Simplified Development

I Built an AI Copilot That Thinks in Exploits, Not Prompts

HackerNoon - A User Experience Analysis: Part 2

New Year, New Exciting Features: Mint Your Name, Watch Web 2.5 and Meet The Top Startups of The Year

Coding with Latenode's AI + JavaScript Assistant: A Low-Code Platform for Simplified Development

I Built an AI Copilot That Thinks in Exploits, Not Prompts

HackerNoon - A User Experience Analysis: Part 2

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps