In un'architettura di microservizi liberamente accoppiata, come tenere traccia delle proprie dipendenze?

Una scelta popolare di architettura di alto livello nel programma moderno è un sistema di microservizi basato su REST. Ciò presenta numerosi vantaggi come accoppiamento lento, facile riutilizzo, limitazione limitata alle tecnologie utilizzabili, elevata scalabilità, ecc.

Ma uno dei problemi che prevedo in tale architettura è la scarsa visibilità su quali siano le dipendenze di un'applicazione. Ad esempio, supponiamo che io abbia un'applicazione che utilizza un set di chiamate REST su base giornaliera. Questa applicazione utilizza anche una seconda serie di chiamate REST, ma solo una volta al trimestre. Se dovessi scansionare i registri della scorsa settimana vedrei tutti i cal giornalieri, ma probabilmente non vedrei le chiamate trimestrali. Quando arriva il momento di refactoring, le chiamate trimestrali sono ad alto rischio di rottura.

Quali modelli o strumenti possono essere utilizzati per ridurre questo rischio e fornire una maggiore visibilità su quali sono le dipendenze di un'architettura liberamente accoppiata?

— David dice Reinstate Monica
fonte

Questo è esattamente il motivo per cui l'accoppiamento lento può essere negativo. Quando non ci sono dipendenze in fase di compilazione, l'unico modo per rilevare gli errori e non rilevarli mai è utilizzare il test automatico. La soluzione è un tipo di test automatizzato, che probabilmente include test unitari e test di integrazione.

— Frank Hileman,

@FrankHileman I test ovviamente aiutano, ma trovo difficile credere che questa sia l'unica soluzione là fuori. Inoltre ci sono molte lingue che non hanno controlli in fase di compilazione (ad es. JS o Python), quindi anche con un accoppiamento stretto ci sarebbero ancora problemi.

— David dice di reintegrare Monica il

i sistemi di tipo statico possono rilevare un gran numero di errori durante la fase di compilazione. L'unica compensazione per la mancanza di un tale sistema è il test automatico, per quanto ne so. Il rilevamento statico di errori tramite prove automatiche o semplicemente la compilazione sarà sempre più affidabile dei test.

— Frank Hileman,

Un modo possibile potrebbe essere l'implementazione del client API di ciascun servizio separatamente e, inclusi questi client come dipendenze del progetto. Con i client API sarebbe anche più facile rintracciare quale versione del servizio stiamo consumando.

— Laiv

@Laiv Sono particolarmente curioso dei servizi RESTful, quindi non è un'opzione poiché chiunque può inviare più o meno richieste HTTP.

— David dice di reintegrare Monica il

Risposte:

Quali modelli o strumenti possono essere utilizzati per ridurre questo rischio

Mantenere le API e le capacità aziendali compatibili con le versioni precedenti.

fornire una maggiore visibilità su quali siano le dipendenze di un'architettura liberamente accoppiata

Controlli sanitari.

Il mio servizio è un client per la tua capacità di API mensile. Ma il mio servizio è il tuo client api ogni volta che il mio servizio è in esecuzione. Quindi il mio servizio si attiva ogni 10 minuti, o qualsiasi altra cosa, si collega all'API mensile ed esegue il protocollo per assicurarsi che la capacità di cui il mio servizio ha bisogno sia ancora disponibile.

Quindi i tuoi registri ti mostreranno quanto spesso qualche altro servizio sta controllando per vedere che ogni particolare servizio che offri è ancora disponibile, così come ti mostra quanto spesso viene utilizzato ogni particolare servizio che offri.

— VoiceOfUnreason
fonte

Esistono almeno due posizioni in cui è possibile trovare le dipendenze:

Configurazione. L'accesso alle API esterne richiede la conoscenza di una serie di informazioni su ciascuna di tali API. ID di accesso, chiavi segrete, endpoint. Tutto questo non può essere in codice, in quanto tali informazioni saranno cambiare. Ad esempio, di recente ho iniziato a migrare tutti i miei microservizi su SSL. Ciò significa che ogni servizio che si basa su quello in fase di migrazione deve essere riconfigurato in modo da puntare alla https://versione anziché http://. Sono contento che gli endpoint fossero nella configurazione anziché essere codificati.
Interfacce. Non accedi a un servizio direttamente dal tuo codice, perché la versione dell'API cambierà e potresti persino decidere di passare a un'API diversa. Invece, si crea un livello di astrazione e si utilizza la dipendenza attraverso un'interfaccia. Seguendo una logica comune durante la creazione di quelle interfacce, puoi semplificarti la vita in seguito quando cerchi le dipendenze.

Quando arriva il momento di refactoring, le chiamate trimestrali sono ad alto rischio di rottura.

Ecco a cosa serve il test di regressione.

Non puoi semplicemente guardare il codice, cambiarlo e fidarti di te stesso che nulla è stato rotto. Questo non funzionerà in un'architettura di microservizi. Questo non funzionerà neanche in un'applicazione monolitica. Un compilatore può rilevare alcuni degli errori che introduci quando modifichi il codice. In alcune lingue, come Haskell, il compilatore può essere molto capace e rilevare la maggior parte degli errori; i compilatori per le lingue tradizionali, tuttavia, non faranno molto per te. Se non hai test, sei fregato. La presenza di microservizi è irrilevante.

— Arseni Mourzenko
fonte

-2

Le API REST sono vagamente specificate, quindi a un certo punto può essere utile passare a gRPC, google protobufs o Thrift per definire un'interfaccia RPC e quindi versione.

— Patrick
fonte

Potrebbe essere meglio come commento ... ma onestamente questo non spiega molto.

— David dice di reintegrare Monica il

Giusto. Un'API di riposo non ha una specifica dipendenza del tempo di compilazione da un altro servizio perché il collegamento tra i due è solo una chiamata di riposo HTTP, qualcosa come un host e un percorso. Con gRPC, o Protobuf o Thrift, viene definita un'interfaccia che viene utilizzata per generare codice. Il codice generato viene compilato e aggiornato, quindi i tuoi servizi vengono creati su tali interfacce. Il risultato è che ogni servizio dipende chiaramente da una o più altre interfacce di servizio. Spero che chiarisca la mia risposta!

— Patrick