Progettazione di un'applicazione basata su microservizi

Scopri le best practice per la progettazione di microservizi

Seguendo alcune procedure ottimali durante la progettazione dei microservizi, è possibile garantire che l'applicazione sia facile da scalare, distribuire e gestire. Si noti che non tutte le best practice discusse qui potrebbero essere rilevanti per l'applicazione.

Ogni microservizio deve implementare un singolo pezzo della funzionalità dell'applicazione. I team di sviluppo devono definire i limiti e le responsabilità di ciascun microservizio. Un approccio consiste nel definire un microservizio per ogni attività richiesta frequentemente nell'applicazione. Un approccio alternativo consiste nel dividere la funzionalità per attività aziendali e quindi definire un microservizio per ogni area.

Considerare i seguenti requisiti nella progettazione:

Microservizi reattivi: i microservizi devono restituire una risposta ai client richiedenti, anche in caso di guasto del servizio.
Compatibilità con le versioni precedenti: quando si aggiunge o si aggiorna la funzionalità di un microservizio, le modifiche dei metodi e dei parametri API non devono influire sui client. L'API REST deve rimanere compatibile con le versioni precedenti.
Comunicazione flessibile: ogni microservizio può specificare il protocollo che deve essere utilizzato per la comunicazione tra i client e il gateway API e per la comunicazione tra i microservizi.
Idempotenza: se un client chiama più volte un microservizio, deve produrre lo stesso risultato.
Funzionamento efficiente: il design deve facilitare il monitoraggio e la risoluzione dei problemi. Un sistema di log viene comunemente utilizzato per implementare questo requisito

Comprendere la metodologia 12-Factor per lo sviluppo di applicazioni

La metodologia a 12 fattori per lo sviluppo delle applicazioni è una serie di regole e linee guida per lo sviluppo di Software as a Service (SaaS) e applicazioni cloud-native.

I microservizi dovrebbero rispettare le seguenti linee guida:

Codebase: ogni microservizio necessita di un unico codebase monitorato nel controllo di revisione. I microservizi non devono condividere codebase.
Dipendenze: ogni microservizio deve dichiarare, isolare e imballare esplicitamente le proprie dipendenze.
Configurazione: la configurazione dell'applicazione, ad esempio le credenziali, potrebbe cambiare tra le distribuzioni. Memorizzare questi dati di configurazione al di fuori del microservizio, in modo che il microservizio utilizzi la configurazione appropriata specifica dell'ambiente di distribuzione.
Servizi di supporto: i clienti devono consumare microservizi tramite URL sulla rete e i microservizi non devono distinguere tra servizi locali e servizi terzi.
Genera, rilascia ed esegui: considera ogni fase del processo di sviluppo e distribuzione dell'applicazione come passo distinto. Nella fase di creazione, il codice viene tradotto in un bundle eseguibile (build). Nella fase di rilascio, la build si combina con la configurazione corrente della distribuzione (sviluppo, test, staging o produzione). In runtime, l'applicazione viene eseguita nell'ambiente di esecuzione rispetto alla release selezionata.
Processi: i microservizi sono senza conservazione dello stato e seguono il modello shared-nothing. Lo stato esiste solo in una cache esterna o in un data store.
Associazione porta: un microservizio viene eseguito in un contenitore ed espone tutte le interfacce tramite porte che ascoltano le richieste.
Concorrenza: un processo microservice viene scalato per gestire la domanda più elevata aggiungendo copie in esecuzione del microservizio. Un motore di orchestrazione contenitore può aiutare in questo processo.
Smaltibilità: i processi di microservice possono essere avviati o interrotti immediatamente quando necessario.
Parità di sviluppo e produzione: mantenere gli ambienti di sviluppo e produzione il più possibile simili.
Log: i log vengono gestiti come flussi di eventi. Un microservizio scrive i log relativi al flusso di eventi, ordinati in base al tempo e non distribuiti. Il microservizio non deve mai gestire l'instradamento o la memorizzazione del flusso di output e non deve gestire i file di log.
Processi di amministrazione: i task di manutenzione e amministrazione devono essere eseguiti come processi singoli (ad esempio migrazioni di database) su un ambiente identico a quello dei microservizi.

Selezionare un pattern Data-Persistence

Il pattern consigliato per implementare la persistenza per un microservizio consiste nell'utilizzare un singolo database. Per ogni microservizio, mantenere privati i dati persistenti e creare il database come parte dell'implementazione del microservizio.

In questo pattern, i dati persistenti privati sono accessibili solo tramite l'API microservice.

L'illustrazione riportata di seguito mostra la progettazione della persistenza per i microservizi.

Descrizione dell'immagine microservices_persistence.png

Le seguenti varianti di questa implementazione di microservizi si applicano ai database relazionali:

Tavoli privati: ogni servizio è proprietario di un set di tabelle.
Schema: ogni servizio è proprietario di uno schema di database privato.
Database: ogni servizio è proprietario di un database server, come mostrato nell'illustrazione.

Un anti-pattern di persistenza per i microservizi consiste nella condivisione di uno schema di database tra più microservizi. È possibile implementare transazioni atomiche, coerenti, isolate e durevoli per garantire la coerenza dei dati. Un vantaggio con questo anti-pattern è che utilizza un database semplice. Gli svantaggi sono che i microservizi potrebbero interferire tra loro durante l'accesso al database, e i cicli di sviluppo possono rallentare perché gli sviluppatori di diversi microservizi devono coordinare le modifiche dello schema, il che aumenta anche le dipendenze tra servizi.

I microservizi possono connettersi a un'istanza di Oracle Database in esecuzione su Oracle Cloud Infrastructure. Il database multi-tenant Oracle supporta più database collegabili (PDB) all'interno di un contenitore. Questa è la scelta migliore per il livello di persistenza per i microservizi, per l'isolamento contestuale limitato dei dati, la sicurezza e per l'alta disponibilità. In molti casi, un minor numero di PDB può essere utilizzato con isolamento a livello di schema.

Comprendere il valore della distribuzione dei microservizi nei contenitori

Dopo aver costruito il microservizio, è necessario containerizzarlo. Un microservizio in esecuzione nel proprio contenitore non influisce sui microservizi distribuiti negli altri contenitori.

Un contenitore è un'unità di software standardizzata, utilizzata per sviluppare, spedire e distribuire applicazioni.

I contenitori vengono gestiti utilizzando un motore contenitore, ad esempio Docker. Il motore contenitore fornisce gli strumenti necessari per raggruppare tutte le dipendenze dell'applicazione come contenitore.

È possibile utilizzare il motore Docker per creare, distribuire ed eseguire le applicazioni microservizi in contenitori. I microservizi in esecuzione nei contenitori Docker hanno le seguenti caratteristiche:

Standard: I microservizi sono portatili. Possono funzionare ovunque.
Leggero: Docker condivide il kernel del sistema operativo (OS), non richiede un sistema operativo per ogni istanza ed viene eseguito come processo leggero.
Sicuro: ogni contenitore viene eseguito come un processo isolato. Quindi i microservizi sono sicuri.

Il processo di containerizzazione di un microservizio comporta la creazione di un Dockerfile, la creazione e la creazione di un'immagine contenitore che includa le relative dipendenze e la configurazione ambientale, la distribuzione dell'immagine su un motore Docker e il caricamento dell'immagine in un registro container per la memorizzazione e il recupero.

Descrizione dell'immagine docker_container_process.png

Informazioni sull'orchestrazione dei microservizi mediante Kubernetes

I microservizi in esecuzione in contenitori devono essere in grado di interagire e integrare per fornire le funzionalità applicative richieste. Questa integrazione può essere raggiunta attraverso l'orchestrazione dei container.

L'orchestrazione del contenitore consente di avviare, arrestare e raggruppare i contenitori nei cluster. Consente inoltre un'elevata disponibilità e scalabilità. Kubernetes è una delle piattaforme di orchestrazione dei container che è possibile utilizzare per gestire i contenitori.

Dopo aver containerizzato i microservizi, è possibile distribuirli in Oracle Cloud Infrastructure Container Engine for Kubernetes.

Prima di distribuire l'applicazione microservizi containerizzata nel cloud, è necessario distribuirla e sottoporla a test in un motore Kubernetes locale, come riportato di seguito.

Creare l'applicazione microservizi.
Creare immagini Docker per containerizzare i microservizi.
Eseguire i microservizi nel motore Docker locale.
Eseguire il push delle immagini del contenitore in un registro container.
Distribuire ed eseguire i microservizi in un motore Kubernetes locale, ad esempio Minikube.

Dopo aver eseguito il test dell'applicazione in un motore Kubernetes locale, distribuirla in Oracle Cloud Infrastructure Container Engine for Kubernetes come segue:

Creare un cluster.
Scaricare il file kubeconfig.
Installare lo strumento kubectl su un dispositivo locale.
Preparare il file deployment.yaml.
Distribuire il microservizio nel cluster.
Provare il microservizio.

Il seguente diagramma mostra il processo di distribuzione di un'applicazione microservizi containerizzata in Oracle Cloud Infrastructure Container Engine for Kubernetes.

Descrizione dell'immagine oke_deployment_process.png