Esiste un modello o una pratica di progettazione che posso utilizzare per aiutare con servizi che sono giù o in discesa, mentre altri sono stabili?
Cosa succede se ho tre microservizi, e due sono buoni, e uno muore nel bel mezzo di un POST? Due otterranno il POST e non lo faranno. Non penso di poter effettuare transazioni perché sto spedendo le mie richieste a un servizio.
Come posso progettare per questo? Non voglio dati orfani in vari database.
Alcune opzioni.
Invece di HTTP, rilascia messaggi in una coda che è altamente disponibile e persistente. Per esempio. Kafka. Finché il server di destinazione diventa disponibile a un certo punto, riceverà il messaggio.
Hai il compromesso tra provisioning e amministrazione di un sottosistema complesso (la coda). Quindi assicurati di analizzare se questo è utile.
Chiedere al chiamante di mantenere la richiesta non riuscita (eventualmente persistente su disco) e riprovare periodicamente. In questo caso è importante distinguere tra la tua richiesta che causa uno schianto e il servizio che sta appena scendendo. Il primo è probabilmente dovuto a un bug e dovrebbe essere registrato ... i tentativi probabilmente non faranno la differenza fino a quando non verrà effettuata una correzione.
Un controllo periodico delle attività per condizioni di coerenza tra i microservizi. Per esempio. l'errore registra fino in fondo per indirizzare le query API secondo necessità. Se rileva un problema (ad esempio un ordine ma la spedizione non ha mai ricevuto l'elenco di imballaggio), procedi con i passaggi di compensazione. Questi passaggi potrebbero essere la creazione di un ticket di supporto per una correzione manuale o per inviare un'email a qualcuno o altro.
Un caso come questo richiede probabilmente un gateway API per gestire le chiamate ai microservizi interessati. In questo modo controlli quali tattiche vengono utilizzate per mitigare questo problema. Probabilmente non vorrete sovraccaricare i clienti con questi dettagli di implementazione. Vedi Schema dell'interruttore automatico .
Poiché i microservizi sono indipendenti, esiste sempre un caso di errore che può causare incoerenze. Devi essere preparato a fare correzioni manuali quando queste si presentano.
Se hai bisogno di una consistenza strong, i microservizi non saranno adatti. Se hai ancora bisogno di scalabilità, potresti voler esaminare sharding dove i dati correlati possono essere co-localizzati sullo stesso frammento per garanzie di consistenza. Puoi ancora scalare l'IO aggiungendo i frammenti.
Se hai bisogno di consistenza strong e non hai problemi di scalabilità, usa solo i servizi monolitici. Utilizza le librerie come limiti all'interno dell'applicazione per separare le preoccupazioni.
Penso che quello che stai descrivendo sia il problema del consenso: non vuoi impegnarti a meno che ogni partecipante nella transazione distribuita non dica che l'operazione ha avuto successo. La soluzione semplice a questo è il Two Phase Commit. In sostanza, mette in scena la transazione in ciascun sistema fino a quando non viene segnalato che la stadiazione ha avuto successo (fase 1). Se ogni partecipante alla transazione restituisce successo, a ognuno viene detto di impegnarsi; se qualcuno di essi ha invece restituito un errore, viene emesso un rollback (Fase 2). C'è una grinza su questo che ti porta alla più complessa soluzione di tre fasi Commit. Puoi leggere una descrizione molto migliore di ciascuno qui:
Leggi altre domande sui tag database microservices concurrency data-integrity