Scopri di più sull'architettura dei microservizi

Le applicazioni moderne vengono create componendo alcuni servizi creati in modo indipendente. Ciò garantisce agilità e rapidità di immissione sul mercato per la risoluzione dei problemi e l'introduzione di nuove funzionalità.

Questo paradigma è indicato come un'architettura di microservizi, anche se il numero di servizi che si uniscono per un'applicazione completa può essere nelle centinaia (microservizi) o nelle decine (macroservizi). Ci sono nuovi termini utilizzati anche per i monoliti modulari chiamati moduliti, e Spring Modulith è uno di questi esempi.

Sebbene molte organizzazioni abbiano già un'architettura di microservizi, le distribuzioni di microservizi sono caratterizzate da complessità e le implementazioni di successo sono ancora in corso nella maggior parte delle organizzazioni. Questa guida alle soluzioni tenta di semplificare la creazione e l'implementazione di microservizi moderni con la popolare piattaforma Spring Boot insieme all'infrastruttura cloud, ai container, a Kubernetes e alla piattaforma Backend as a Service con Oracle Database.

Se desideri progettare un'applicazione multilingua, facilmente scalabile, facile da gestire e implementare, ad alta disponibilità e che riduca al minimo gli errori, utilizza l'architettura dei microservizi per progettare e distribuire un'applicazione cloud. In un'architettura di microservizi, ogni microservizio possiede un'attività semplice e comunica con i clienti o con altri microservizi utilizzando meccanismi di comunicazione leggeri come le richieste API REST.

Il diagramma riportato di seguito mostra l'architettura di un'applicazione composta da più microservizi.

Descrizione dell'immagine microservice_architecture.png

I microservizi ti consentono di progettare la tua applicazione come una raccolta di servizi accoppiati in modo approssimativo. I microservizi seguono il modello share-nothing ed eseguono come processi senza conservazione dello stato. Questo approccio semplifica la scalabilità e la manutenzione dell'applicazione.

• Il layer API è il punto di accesso per tutte le richieste client a un microservizio. Il livello API consente inoltre ai microservizi di comunicare tra loro tramite HTTP, gRPC e TCP/UDP.
• Il layer logico si concentra su un singolo task aziendale, riducendo al minimo le dipendenze dagli altri microservizi. Questo livello può essere scritto in una lingua diversa per ogni microservizio.
• Il livello del data store fornisce un meccanismo di persistenza, ad esempio un motore di storage del database, file di log e così via. Prendi in considerazione l'utilizzo di un data store persistente separato per ogni microservizio. Oracle offre container di database con più database integrabili che semplificano l'isolamento dei dati per sicurezza, HA e scalabilità da parte dei microservizi. Inoltre, le applicazioni SaaS possono sfruttare la multi-tenancy in modo sicuro. Inoltre, un database convergente offre la varietà di dati sotto un unico tetto per ottenere insight più completi dai dati.

In genere, ogni microservizio viene eseguito in un container che fornisce un ambiente runtime leggero.

Differenze tra microservizi e architetture monolitiche

Prima di iniziare a progettare applicazioni utilizzando l'architettura dei microservizi, è necessario comprendere in che modo questa architettura si differenzia dall'architettura monolitica tradizionale.

La progettazione delle applicazioni si concentra sulla risoluzione dei requisiti aziendali e sull'implementazione della logica aziendale. In un'architettura monolitica, l'intera applicazione è costruita come un'unica unità che contiene tutta la logica di business. Nell'architettura dei microservizi, la business logic è organizzata come più servizi accoppiati in modo approssimativo.

L'illustrazione seguente mostra le architetture monolitiche e dei microservizi.

Descrizione dell'immagine monolithic_vs_microservice.png

La tabella seguente riassume le differenze tra i microservizi e le architetture monolitiche.

Caratteristica	Architettura dei microservizi	Architettura monolitica
Progettazione unità	L'applicazione è costituita da servizi non accoppiati. Ogni servizio supporta un singolo task aziendale.	L'intera applicazione è progettata, sviluppata e distribuita come un'unica unità.
Riutilizzo della funzionalità	I microservizi definiscono le API che espongono le loro funzionalità a qualsiasi client. I clienti potrebbero anche essere altre applicazioni.	L'opportunità di riutilizzare le funzionalità tra le applicazioni è limitata.
Comunicazione all'interno dell'applicazione	Per comunicare tra loro, i microservizi di un'applicazione utilizzano il modello di comunicazione richiesta-risposta. L'implementazione tipica utilizza chiamate API REST basate sul protocollo HTTP.	Le procedure interne (chiamate di funzione) facilitano la comunicazione tra i componenti dell'applicazione. Non è necessario limitare il numero di chiamate di procedura interne.
Flessibilità tecnologica	Ogni microservizio può essere sviluppato utilizzando un linguaggio di programmazione e un framework che meglio si adatta al problema che il microservizio è progettato per risolvere.	Di solito, l'intera applicazione è scritta in un unico linguaggio di programmazione.
Gestione dati	Decentralizzato: ogni microservizio può utilizzare il proprio database.	Centralizzato: l'intera applicazione utilizza uno o più database.
Distribuzione	Ogni microservizio viene distribuito in modo indipendente, senza influire sugli altri microservizi nell'applicazione.	Qualsiasi modifica, per quanto piccola, richiede la ridistribuzione e il riavvio dell'intera applicazione.
Manutenzione	I microservizi sono semplici, mirati e indipendenti. Quindi l'applicazione è più facile da mantenere.	Man mano che l'ambito dell'applicazione aumenta, la manutenzione del codice diventa più complessa.
Flessibilità	La funzionalità dell'applicazione viene distribuita su più servizi. In caso di errore di un microservizio, le funzionalità offerte dagli altri microservizi continuano a essere disponibili.	Un errore in qualsiasi componente potrebbe influire sulla disponibilità dell'intera applicazione.
Scalabilità	Ogni microservizio può essere scalato indipendentemente dagli altri servizi.	L'intera applicazione deve essere scalata, anche quando il requisito aziendale è di ridimensionare solo alcune parti dell'applicazione.

Considerazioni sull'adozione dell'architettura dei microservizi

Quando si progetta una nuova applicazione, considerare l'architettura dei microservizi per le applicazioni che richiedono elevati livelli di scalabilità, flessibilità e affidabilità. È possibile utilizzare un linguaggio di programmazione e un framework diversi per sviluppare ogni componente.

Prendi in considerazione la possibilità di migrare un'applicazione monolitica ai microservizi se puoi dividere la funzionalità dell'applicazione in servizi mirati, ciascuno con un ambito limitato. Per le applicazioni monolitiche complesse di cui non è possibile eseguire la migrazione all'architettura dei microservizi, prendere in considerazione lo sviluppo solo delle nuove funzionalità come microservizi.

Le interdipendenze tra i servizi possono influire sulla quantità di applicazione non disponibile durante una ridistribuzione del servizio. Risolvere tali problemi di dipendenza durante la progettazione dell'applicazione.

Refactoring un'applicazione monolitica è difficile. Se si intende utilizzare l'architettura dei microservizi, pianificarne l'utilizzo dall'inizio del progetto.

Considera le complessità dei sistemi distribuiti quando sviluppi microservizi e ricorda che le chiamate remote sono lente e possono non riuscire. A seconda del caso d'uso, è necessario bilanciare coerenza, disponibilità e tolleranza della partizione.

Preparati alla complessità operativa che comporta l'architettura dei microservizi. Prima di spostare un'applicazione monolitica nell'architettura dei microservizi, è consigliabile soddisfare i prerequisiti riportati di seguito.

• Provisioning rapido: capacità di eseguire rapidamente il provisioning dei server
• Monitoraggio di base: capacità di rilevare problemi di servizio e problemi aziendali. I problemi del servizio includono disponibilità del servizio, errori funzionali e problemi di prestazioni
• Implementazione rapida delle applicazioni: possibilità di distribuire rapidamente qualsiasi servizio negli ambienti di test e produzione

Assicurati che i vantaggi dell'architettura dei microservizi superino i costi.

Informazioni sul meccanismo di comunicazione in un'architettura di microservizi

In un'architettura di microservizi, i servizi vengono eseguiti su più server. La comunicazione tra questi servizi avviene tramite protocolli quali HTTP, AMQP e TCP. HTTP/REST e messaggistica asincrona sono i protocolli più utilizzati.

Un'interfaccia API REST per i servizi Web utilizza in genere il protocollo HTTP. Con i metodi HTTP (ad esempio GET, POST, PUT e DELETE) i client possono accedere e manipolare le risorse dell'applicazione utilizzando un URL (Uniform Resource Locator).

I client inviano una richiesta a un servizio tramite un'API REST che rappresenta un punto di accesso alla funzionalità dell'applicazione. I clienti possono comunicare con i microservizi direttamente o tramite un gateway API.

Un pattern di gateway API definisce un singolo punto di accesso per tutte le richieste ai servizi. Quando arriva una richiesta client, il gateway API instrada la richiesta al servizio appropriato.

Una variante del pattern gateway API è il pattern backend per frontend, che definisce un gateway API separato per ogni tipo di client (ad esempio, un gateway per i client Mobile e un altro per le applicazioni Web).

Ridurre al minimo la comunicazione tra i servizi è una pratica consigliata. Quando la comunicazione è essenziale, è preferibile la comunicazione asincrona. Il servizio che invia la richiesta può continuare a funzionare senza attendere una risposta.

Le code di messaggistica e i sistemi di streaming sono metodi ideali per fornire comunicazioni asincrone e, se integrati nel database, forniscono semantica transazionale per un'operazione dati e l'invio di un messaggio. Ciò rende i microservizi più semplici e scalabili da implementare. L'uso delle API REST rende la comunicazione tra i microservizi sincrona e di solito limita il ridimensionamento.

Informazioni sui servizi e sui ruoli richiesti

Questa soluzione richiede i seguenti servizi:

• Oracle Cloud Infrastructure Database (un'ampia gamma di opzioni tra cui Oracle Autonomous Database)
• Oracle Cloud Infrastructure Container Engine for Kubernetes
• Oracle Backend for Spring Boot and Microservices

Questi sono i ruoli necessari per ogni servizio.

Nome servizio: ruolo	Richiesto per...
Oracle Cloud Infrastructure Database: SYSTEM o ADMIN	Crea un utente da proxy per l'accesso al database durante la configurazione di Oracle Backend for Spring Boot and Microservices. Sebbene SYSTEM o ADMIN funzionino, i privilegi sono eccessivi e non devono essere utilizzati negli ambienti di produzione.
Oracle Cloud Infrastructure Container Engine for Kubernetes: CLUSTER_MANAGE	Crea un cluster Oracle Cloud Infrastructure Container Engine for Kubernetes e un pool di nodi con tre nodi di lavoro.
Oracle Backend for Spring Boot and Microservices: ROLE_ADMIN	Installa Oracle Backend for Spring Boot and Microservices.

Consulta i prodotti, le soluzioni e i servizi Oracle per ottenere ciò di cui hai bisogno.