Informazioni sull'architettura dei microservizi
Se si desidera progettare un'applicazione multilingue, facilmente scalabile, facile da gestire e distribuire, altamente disponibile e che minimizzi gli errori, utilizzare l'architettura dei microservizi per progettare e distribuire un'applicazione cloud.
In un'architettura di microservizi, ogni microservizio è proprietario di un'attività semplice e comunica con i client o con altri microservizi utilizzando meccanismi di comunicazione leggeri, quali le richieste delle API REST.
Il seguente diagramma mostra l'architettura di un'applicazione composta da più microservizi.
Descrizione dell'immagine microservice_architecture.png
I microservizi consentono di progettare la tua applicazione come una raccolta di servizi liberamente accoppiati. 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 layer API consente inoltre ai microservizi di comunicare tra loro tramite HTTP, gRPC e TCP/UDP.
- Il livello 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 layer del data store fornisce un meccanismo di persistenza, ad esempio un motore di memorizzazione del database, file di log e così via. Utilizzare un data store persistente separato per ogni microservizio. Oracle offre contenitori di database con più database collegabili che semplificano l'isolamento dei dati per la sicurezza, l'HA e la scalabilità dei microservizi. Inoltre, le applicazioni SaaS possono usufruire della multi-tenancy in modo sicuro. Inoltre, un database convergente porta la varietà di dati sotto un unico tetto per informazioni più ricche dai dati.
In genere, ogni microservizio viene eseguito in un contenitore che fornisce un ambiente runtime leggero.
Differenze tra Microservizi e Architetture Monolitiche
Prima di iniziare a progettare applicazioni utilizzando l'architettura microservizi, è necessario comprendere come questa architettura differisca 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 aziendale. Nell'architettura dei microservizi, la logica aziendale è organizzata come molteplici servizi liberamente accoppiati.
La seguente illustrazione mostra le architetture monolitiche e microservizi.
Descrizione dell'immagine monolithic_vs_microservice.png
La tabella seguente riassume le differenze tra i microservizi e le architetture monolitiche.
| Caratteristica | Microservizi Architettura | Architettura monolitica |
|---|---|---|
| Progettazione unità | L'applicazione è costituita da servizi liberamente accoppiati. Ogni servizio supporta un singolo task aziendale. | L'intera applicazione è progettata, sviluppata e distribuita come un'unica unità. |
| Riutilizzo funzionalità | I microservizi definiscono le API che espongono la loro funzionalità a qualsiasi client. I client potrebbero anche essere altre applicazioni. | L'opportunità di riutilizzare le funzionalità in tutte le applicazioni è limitata. |
| Comunicazione all'interno della domanda | Per comunicare tra loro, i microservizi di un'applicazione utilizzano il modello di comunicazione richiesta-risposta. L'implementazione tipica utilizza le chiamate API REST in base al protocollo HTTP. | Le procedure interne (chiamate di funzione) facilitano la comunicazione tra i componenti dell'applicazione. Non è necessario limitare il numero di chiamate interne alla procedura. |
| Flessibilità tecnologica | Ogni microservizio può essere sviluppato utilizzando un linguaggio e un framework di programmazione che meglio si adattano al problema che il microservizio è progettato per risolvere. | Di solito, l'intera applicazione è scritta in un unico linguaggio di programmazione. |
| Gestione dei 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 pregiudicare gli altri microservizi nell'applicazione. | Qualsiasi modifica, per quanto piccola, richiede la ridistribuzione e il riavvio dell'intera applicazione. |
| Mantenibilità | I microservizi sono semplici, focalizzati e indipendenti. Quindi l'applicazione è più facile da mantenere. | Man mano che l'ambito dell'applicazione aumenta, mantenere il codice diventa più complesso. |
| Flessibilità | La funzionalità dell'applicazione viene distribuita su più servizi. Se un microservizio non riesce, la funzionalità offerta dagli altri microservizi continua ad essere disponibile. | 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 è per ridimensionare solo alcune parti dell'applicazione. |
Per ulteriori dettagli su queste caratteristiche, vedere Microservices: una definizione di questo nuovo termine architettonico (Martin Fowler e James Lewis, 2014).
Considerazioni per l'adozione dell'architettura dei microservizi
Quando si progetta una nuova applicazione, considerare l'architettura dei microservizi per applicazioni che richiedono elevati livelli di scalabilità, flessibilità e affidabilità. È possibile utilizzare un linguaggio e un framework di programmazione diversi per sviluppare ogni componente.
Eseguire la migrazione di un'applicazione monolitica ai microservizi se è possibile suddividere la funzionalità dell'applicazione in servizi focalizzati, ognuno con un ambito limitato. Per applicazioni monolitiche complesse che non possono essere migrate all'architettura dei microservizi, considerare lo sviluppo solo delle nuove funzionalità come microservizi.
Le interdipendenze tra i servizi possono influire sulla quantità di applicazione non disponibile durante la ridistribuzione di un servizio. Risolvere eventuali problemi di dipendenza durante la progettazione dell'applicazione.
Riflettere un'applicazione monolitica è difficile. Se si intende utilizzare l'architettura dei microservizi, pianificarla fin dall'inizio del progetto.
Considerare la complessità dei sistemi distribuiti quando si sviluppano microservizi e ricordare che le chiamate remote sono lente e possono fallire. A seconda del caso d'uso, è necessario bilanciare coerenza, disponibilità e tolleranza delle partizioni.
Preparatevi alla complessità operativa che l'architettura dei microservizi comporta. Secondo Martin Fowler, i seguenti prerequisiti devono essere soddisfatti prima di spostare un'applicazione monolitica nell'architettura di microservizi:
- Provisioning rapido: capacità di provisioning rapido dei server
- Monitoraggio di base: capacità di rilevare problemi di servizio e problemi aziendali. I problemi di servizio includono disponibilità del servizio, errori funzionali e problemi di prestazioni
- Distribuzione rapida delle applicazioni: capacità di distribuire rapidamente qualsiasi servizio negli ambienti di test e produzione
Assicurarsi che i vantaggi dell'architettura dei microservizi superino i costi.
Per ulteriori informazioni, vedere Prerequisiti Microservice (Martin Fowler, 2014).
Informazioni sul meccanismo di comunicazione in un'architettura di microservizi
In un'architettura 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'API REST per i Web Service utilizza comunemente 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 (Resource Locator) uniforme.
I client inviano una richiesta a un servizio tramite un'API REST che rappresenta un punto di accesso alla funzionalità dell'applicazione. I client possono comunicare con i microservizi direttamente o tramite un gateway API.
Un pattern 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 backend per il pattern frontend, che definisce un gateway API separato per ogni tipo di client (ad esempio, un gateway per i client mobili e un altro per le applicazioni Web).
Ridurre al minimo la comunicazione tra i servizi è una pratica raccomandata. Quando la comunicazione è essenziale, la comunicazione asincrona è preferibile. 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 comunicazione asincrona e, quando integrati nel database, forniscono semantica transazionale per un'operazione di dati e l'invio di un messaggio. Ciò rende i microservizi più semplici e scalabili da distribuire. L'utilizzo delle API REST rende sincrona esclusivamente la comunicazione tra microservizi e di solito limita la scalabilità.
Informazioni sui servizi e i ruoli richiesti
Questa soluzione richiede i seguenti servizi:
- Oracle Cloud Infrastructure Database
- Oracle Cloud Infrastructure Container Engine for Kubernetes
Definire criteri che consentano almeno al gruppo di utenti di gestire i tipi di risorse instance-family, volume-family, virtual-network-family, cluster-family, object-family e database -family nel compartimento. Concedere inoltre l'accesso al tipo di risorsa repos nella tenancy.
Vedere Informazioni su come ottenere i servizi Oracle Cloud per Oracle Solutions per ottenere i servizi cloud necessari.