Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Comunicazione asincrona
Al contrario, nella comunicazione asincrona, il client invia una richiesta a un servizio ma non riceve una risposta immediata. In questo caso, il client di solito riceve solo una conferma dell'accettazione della richiesta.
I vantaggi della comunicazione asincrona includono:
-
Supporto dell'architettura basata sugli eventi: soluzione naturale per i modelli di event-sourcing e Command Query Responsibility Segregation (CQRS).
-
Migliore gestione delle risorse: capacità dei servizi di elaborare le richieste in base alla loro capacità.
-
Migliore isolamento dei guasti: disaccoppiamento dei servizi, che previene i guasti a cascata.
-
Gestione dei picchi di carico: migliore gestione dei picchi di traffico grazie all'accodamento dei messaggi.
Gli svantaggi includono la complessità. Esempio:
-
Se il client richiede il risultato dell'operazione asincrona, l'implementazione di un meccanismo per recuperare o ricevere tale risultato richiede uno sforzo maggiore.
-
La risoluzione dei problemi relativi alle operazioni asincrone può essere più difficile, poiché la risoluzione dei problemi richiede l'esame dei log su più sistemi.
-
Può essere più difficile testare le operazioni asincrone, poiché il test richiede il coordinamento tra più sistemi e servizi.
Gli approcci alla comunicazione asincrona includono fire and forget, claim check, callback e comunicazione bidirezionale.
Spara e dimentica
Nello schema fire and forget, un client invia una richiesta al server e riceve in modo sincrono una conferma che indica che il server ha ricevuto il messaggio e lo elaborerà. Tuttavia, l'elaborazione effettiva non è ancora avvenuta e il client non ha alcuna visibilità su quando o come verrà eseguita. Il diagramma seguente illustra questo schema.
In questo caso, il servizio non deve inviare la conferma finché l'oggetto non viene mantenuto in modo duraturo. Questa persistenza può essere implementata come operazione di scrittura nel database o inserendo un elemento in una coda.
Ulteriori considerazioni:
-
Implementa l'idempotenza per gestire messaggi duplicati. Cioè, ogni messaggio deve essere elaborato una sola volta.
-
Prendi in considerazione le code di lettere morte
in caso di elaborazione non riuscita. -
Monitora le percentuali di successo dell'elaborazione dei messaggi.
Verifica dei reclami
Se un cliente ha bisogno del risultato di una chiamata di assistenza, puoi creare il servizio in modo che emetta un assegno di reclamo quando riceve una richiesta. Il diagramma seguente illustra questo modello. Il controllo del reclamo viene implementato come identificatore che il servizio restituisce nella sua conferma. Il client può utilizzare questo identificatore in un secondo momento per verificare lo stato della richiesta e recuperare il risultato quando la richiesta è completa.
I clienti devono implementare un meccanismo per verificare i risultati. Questo può essere automatizzato (ad esempio, un controllo può essere eseguito ogni n minuti) o implementato manualmente, dove il controllo viene eseguito in risposta a un altro evento o a un'altra azione dell'utente. I servizi che implementano il modello di controllo dei reclami devono indicare esplicitamente il periodo di validità del controllo dei reclami.
Migliori pratiche:
-
Implementa il backoff esponenziale per i sondaggi.
-
Imposta un orario di vita appropriato (TTL) per i controlli dei reclami.
-
Fornisci endpoint di stato per il monitoraggio dei progressi.
Richiamata
Nello schema di callback, un cliente invia una richiesta a un servizio e fornisce al servizio un luogo a cui contattare il servizio una volta completata l'elaborazione. Il client non attende un risultato e l'elaborazione continua. Il servizio ha la responsabilità di contattare la sede una volta completata l'elaborazione e di fornire il risultato. I tipi più comuni di ubicazioni per le risposte sono REST APIs o code. Il diagramma seguente illustra lo schema di callback.
Implementazione:
-
Implementa meccanismi di ripetizione per i callback falliti.
-
Proteggi la posizione di callback come faresti con altri servizi.
-
Gestisci i timeout di callback.
Comunicazione bidirezionale
Per implementare la comunicazione bidirezionale, è necessario creare una connessione statica tra un client e un servizio, che consenta sia al client che al servizio di inviare ed elaborare messaggi. Il diagramma seguente ne è l'illustrazione. Sebbene la comunicazione sia asincrona, il servizio deve essere in grado di supportare una connessione aperta per ogni client.
Considerazioni sull'implementazione:
-
Ordine dei messaggi
-
Numeri di sequenza
-
Strategie di partizione
-
Ordine dei messaggi
-
-
Gestione dello stato
-
Modelli di approvvigionamento degli eventi
-
Riconciliazione tra Stati
-
Modelli di consistenza
-
-
Gestione degli errori
-
Policy di ripetizione
-
Strategie di fallback
-
Monitoraggio e osservabilità
-
Correlazione IDs
-
Monitoraggio dei messaggi
-
Metriche delle prestazioni
-
Indicatori dello stato del sistema
-
