Questa è una domanda classica che mi è stata posta recentemente durante un'intervista. Come chiamare più servizi Web e conservare comunque una sorta di gestione degli errori nel mezzo dell'attività. Oggi, nel calcolo ad alte prestazioni, evitiamo impegni in due fasi. Ho letto un documento molti anni fa su quello che era chiamato il "modello Starbuck" per le transazioni: pensa al processo di ordinazione, pagamento, preparazione e ricezione del caffè che ordini a Starbuck ... Semplifico troppo le cose ma un modello di commit in due fasi avrebbe suggerire che l'intero processo sarebbe una singola transazione di avvolgimento per tutte le fasi coinvolte fino a quando non si riceve il caffè. Tuttavia, con questo modello, tutti i dipendenti aspetterebbero e smetterebbero di lavorare fino a quando non si ottiene il caffè. Vedi la foto?
Invece, il "modello Starbuck" è più produttivo seguendo il modello "best effort" e compensando gli errori nel processo. Innanzitutto, si assicurano che tu paghi! Quindi, ci sono code di messaggi con il tuo ordine allegato alla tazza. Se qualcosa va storto nel processo, come se non avessi preso il tuo caffè, non è quello che hai ordinato, ecc., Entriamo nel processo di compensazione e ci assicuriamo che tu ottenga ciò che desideri o ti rimborsi, questo è il modello più efficiente per una maggiore produttività.
A volte, Starbuck sta sprecando un caffè, ma l'intero processo è efficiente. Ci sono altri trucchi da pensare quando costruisci i tuoi servizi web come progettarli in modo che possano essere chiamati un numero qualsiasi di volte e fornire comunque lo stesso risultato finale. Quindi, la mia raccomandazione è:
Non essere troppo bravo quando definisci i tuoi servizi web (non sono convinto dell'hype di micro-servizi che si sta verificando in questi giorni: troppi rischi di andare troppo lontano);
Async aumenta le prestazioni, quindi preferisci essere asincrono, invia notifiche via e-mail ogni volta che è possibile.
Costruire servizi più intelligenti per renderli "richiamabili" un numero qualsiasi di volte, elaborando con un uid o taskid che seguirà l'ordine dal basso verso l'alto fino alla fine, convalidando le regole aziendali in ogni passaggio;
Utilizza le code dei messaggi (JMS o altri) e passa ai processori di gestione degli errori che applicheranno le operazioni al "rollback" applicando operazioni opposte, inoltre, lavorare con un ordine asincrono richiederà una sorta di coda per convalidare lo stato corrente del processo, quindi considera quello;
In ultima istanza, (poiché potrebbe non accadere spesso), inserirlo in una coda per l'elaborazione manuale degli errori.
Torniamo con il problema iniziale che è stato pubblicato. Crea un account e crea un portafoglio e assicurati che tutto sia stato fatto.
Supponiamo che venga chiamato un servizio Web per orchestrare l'intera operazione.
Lo pseudo codice del servizio web sarebbe simile al seguente:
Chiama il microservizio di creazione dell'account, passa alcune informazioni e un ID di attività univoco 1.1 Il microservizio di creazione dell'account controllerà prima se quell'account è già stato creato. Un ID attività è associato al record dell'account. Il microservizio rileva che l'account non esiste, quindi lo crea e memorizza l'id dell'attività. NOTA: questo servizio può essere chiamato 2000 volte, eseguirà sempre lo stesso risultato. Il servizio risponde con una "ricevuta che contiene informazioni minime per eseguire un'operazione di annullamento, se necessario".
Chiama la creazione di Wallet, assegnandogli l'ID account e l'id attività. Diciamo che una condizione non è valida e la creazione del portafoglio non può essere eseguita. La chiamata ritorna con un errore ma non è stato creato nulla.
L'orchestrator viene informato dell'errore. Sa che deve interrompere la creazione dell'account ma non lo farà da solo. Chiederà al servizio portafoglio di farlo superando la "ricevuta di annullamento minima" ricevuta alla fine del passaggio 1.
Il servizio Account legge la ricevuta di annullamento e sa come annullare l'operazione; la ricevuta di annullamento potrebbe anche includere informazioni su un altro microservizio che avrebbe potuto chiamare per svolgere parte del lavoro. In questa situazione, la ricevuta di annullamento potrebbe contenere l'ID conto e, eventualmente, alcune informazioni aggiuntive richieste per eseguire l'operazione opposta. Nel nostro caso, per semplificare le cose, supponiamo che sia sufficiente eliminare l'account usando il suo ID account.
Supponiamo ora che il servizio Web non abbia mai ricevuto l'esito positivo o negativo (in questo caso) dell'annullamento della creazione dell'account. Chiamerà semplicemente di nuovo il servizio di annullamento dell'account. E questo servizio non dovrebbe mai fallire perché il suo obiettivo è che l'account non esista più. Quindi controlla se esiste e non vede nulla da fare per annullarlo. Quindi restituisce che l'operazione è un successo.
Il servizio Web restituisce all'utente che non è stato possibile creare l'account.
Questo è un esempio sincrono. Avremmo potuto gestirlo in modo diverso e inserire il caso in una coda di messaggi indirizzata all'help desk se non volessimo che il sistema ripristinasse completamente l'errore ". Ho visto che questo viene eseguito in un'azienda in cui non è sufficiente gli hook possono essere forniti al sistema back-end per correggere le situazioni.L'help desk ha ricevuto messaggi contenenti ciò che è stato eseguito con successo e aveva abbastanza informazioni per risolvere cose come la nostra ricevuta di annullamento potrebbe essere utilizzata in modo completamente automatizzato.
Ho eseguito una ricerca e il sito Web Microsoft ha una descrizione del modello per questo approccio. Si chiama il modello di transazione compensativa:
Modello di transazione compensativa