Quali sono i potenziali problemi con la dipendenza circolare operativa tra i microservizi

In un'altra risposta , ti consiglio di non farlo.

Il problema principale che riesco a vedere, oltre al problema del bootstrap correlato, è che se uno dei servizi nel ciclo fallisce, falliscono tutti. È un servizio di debug / ripristino scadente quando un servizio non riesce perché uno dei suoi servizi upstream ha avuto esito negativo. In tal caso, è possibile tornare indietro alle dipendenze finché non si trova la dipendenza upstream più vicina che funziona ancora. È possibile correggere tale dipendenza e quindi ripetere il processo se il servizio originale non funziona ancora. In questo caso, hai isolato il secondo servizio non funzionante per essere a valle di quello appena risolto. Continua a ripetere fino a quando il servizio originale non funziona.

Se si hanno delle dipendenze cicliche, non c'è modo di dire quale servizio nel ciclo sta causando il problema. Se due o più servizi stanno avendo problemi, allora sei in una situazione di luci natalizie / serie: se due servizi hanno fallito ma non sai quale, allora non ottieni informazioni se "aggiustare" uno effettivamente aiutato. Solo quando si risolvono entrambi i servizi non funzionanti saprai quali sono stati. Se il problema è operativo e può essere risolto riavviando il servizio, ad esempio, la cosa più rapida da fare per ripristinare il servizio è probabilmente il riavvio dell'intero ciclo. Ciò evita di dover isolare il problema e tratta efficacemente il ciclo come un singolo servizio, almeno dal punto di vista della gestione degli errori. Se il problema è un difetto del software, allora ci si trova in una posizione molto peggiore perché per risolvere il problema è necessario isolare il difetto, e questo è ciò che le dipendenze cicliche rendono difficile. Ovviamente, un buon monitoraggio / registrazione aiuta in modo significativo con questo. Proprio come ovviamente, più piccolo è il ciclo, meno grave è questo problema.

Non sono esattamente sicuro di cosa intenda per dipendenza circolare, ma a livello generale due micro-servizi dovrebbero essere in grado di essere distribuiti, gestiti e controllati in modo interdipendente l'uno dall'altro. Se sei in una posizione in cui un cambiamento nel micro-servizio A provoca un cambiamento nel micro-servizio B, allora stai facendo qualcosa di sbagliato. Ma posso vedere dove due servizi possono avere interdipendenze.

Ma è possibile avere dipendenze "circolari" ed essere comunque un micro-servizio ragionevole. Ad esempio, un servizio gestisce gli utenti e le credenziali e l'altro gestisce le sessioni di accesso. Per cambiare le credenziali di un utente potrebbe essere necessario un token di sessione valido che provi che sei lo stesso utente. Per ottenere un token di sessione, è necessario essere in grado di autenticare un utente con le proprie credenziali. Entrambi i servizi devono essere in funzione affinché la sicurezza funzioni, ma possono avere interfacce chiaramente definite. Per i test è possibile creare una versione stub dell'altro servizio.

L'API per il servizio di credenziali potrebbe consentire a un utente di convalidare credenziali, registrare gli utenti e ottenere dettagli per un utente. Il servizio di sessione ha un'API che restituisce un token di sessione, dato un insieme di credenziali e restituisce l'entità per un determinato token di sessione. Se le definizioni API sono ben ponderate e attentamente rispettate, penso che sarebbe bene avere queste interdipendenze. Ma se non è possibile stabilire contratti chiari e le modifiche a un servizio implicano la modifica dell'altro, probabilmente non si dovrebbero suddividere i servizi.

Come parte del micro-servizio su qualcosa di fondamentale come l'autenticazione dell'utente, si mette un sistema di bilanciamento del carico di fronte a un cluster di contenitori o macchine virtuali che eseguono il servizio. In questo modo è possibile eseguire due o tre copie di ciascun servizio e, se uno è andato giù, il bilanciamento del carico lo nasconderebbe. (Oltre alle ragionevoli riprova delle politiche per i fallimenti transitori, ecc.). Ma non saresti in grado di autenticare a meno che il servizio di credenziali utente fosse disponibile e anche il servizio di sessione fosse disponibile.

Aggiunta di alcuni chiarimenti:

In generale (micro-servizi, dipendenze di classe, ecc.) vuoi che il tuo accoppiamento sia un grafo aciclico diretto. B dipende da A quindi A non dovrebbe avere conoscenza di B. Questo non è un micro-servizio specifico, ma un principio di progettazione generale. Un modo per correggere il mio progetto sopra è dividere la convalida delle credenziali in un servizio separato e recuperare il DAG. Il rischio specifico che stai cercando di evitare è che non puoi cambiare o evolvere A e B indipendentemente l'uno dall'altro. Finirai sempre per apportare modifiche ad entrambi.

Non è mai una parola molto strong e quindi non direi che non dovresti mai fare qualcosa, ma dovresti evitare le dipendenze circolari. Penso che l'accoppiamento sia il vero pericolo.