Quando e come utilizzare un'architettura di microservizi?

Il architettura dei microservizi sta ricevendo molta attenzione ultimamente, e questa non è una coincidenza. Ci sono alcune grandi aziende come Netflix e Amazon che hanno spiegato come stanno utilizzando a architettura dei microservizi per essere in grado di scalare i propri servizi e garantire che possano fornirli continuamente e senza interruzioni.

Un'architettura di microservizi ha più senso rispetto alla progettazione di applicazioni monolitiche.

Nella progettazione architettonica monolitica, creiamo un'applicazione enorme e pesante con tutti i moduli strettamente accoppiati in un singolo eseguibile che viene generalmente distribuito su un server Web o applicativo. Nonostante questo, questo progetto architettonico ne ha alcuni inconvenienti che hanno consentito l'utilizzo del architettura dei microservizi prendere piede:

• Nessun aggiornamento facile e frequente.

• Problemi di distribuzione continua.

• Difficile gestire team e progetto.

• Prestazioni e scalabilità costose.

• Mancanza di diversità tecnologica.

• Componenti non facili da sostituire.

Che cos'è un'architettura di microservizi?

Uno stile di architettura di microservizi consente di ottenere una configurazione in cui i componenti dell'applicazione sono applicazioni autonome.. Questi componenti indipendenti dall'applicazione comunicano tra loro tramite RMI (Richiamo del metodo remoto), Servizi Web riposanti o Messaggistica Push.

Quando si progettano sistemi in un'architettura di microservizi, dobbiamo identificare i componenti indipendenti. Questi componenti saranno applet, che sarà sviluppato separatamente. Seguiranno il proprio ciclo di sviluppo e distribuzione.

In una configurazione generale possiamo avere scenari in cui abbiamo bisogno di dati da più componenti per una singola richiesta. Idealmente, avremo un gateway API o un controller frontale che aggrega i dati da questi componenti e li restituisce.

Inoltre, dobbiamo avere la comunicazione tra i componenti.. I componenti possono comunicare tramite API REST o messaggistica o RMI (richiamo del metodo remoto).

Le caratteristiche di un'applicazione basata sull'architettura di microservizi sono le seguenti:

• servizio abilitato, esecuzione indipendente dal componente.

• Esecuzione indipendente di componenti attorno ad alcune funzionalità aziendali.

• Mentalità di prodotto anziché di progetto.

• Componenti intelligenti che utilizzano semplici canali di comunicazione come il semplice protocollo RESTish o l'accodamento dei messaggi leggero.

• Standard decentralizzati. Ciascun componente indipendente può utilizzare il proprio standard unico per lo sviluppo e la distribuzione.

• Gestione decentralizzata dei dati. Ogni singolo componente ha il proprio archivio dati.

• Gestione automatizzata dell'infrastruttura. Per l'implementazione di componenti indipendenti, dobbiamo fare affidamento sulla gestione automatizzata dell'infrastruttura per ridurre la complessità.

• Progettazione dell'applicazione tenendo conto di possibili guasti. Ci sono diverse parti mobili indipendenti nelle applicazioni. Nel caso in cui il destinatario non riceva una risposta, deve essere gestito correttamente.

• Design evolutivo per ottenere il miglior sistema di decomposizione realizzabile, che può essere sostituito e aggiornato senza influire sull'ambiente.

Quando usare un'architettura di microservizi

Dovremmo usare un'architettura di microservizi per qualsiasi prodotto o progetto con questi due approcci:

• Solo monolitico o con un primo approccio monolitico. Regolarmente, quando un'applicazione monolitica ha successo o necessita di aiuto per ridimensionare e migliorare le prestazioni, possiamo optare per un'architettura di microservizi in due modi:
• Estendi i componenti modulari ben progettati dell'applicazione monolitica.
• Crea l'applicazione di microservizi da zero e scarica l'applicazione monolitica esistente al suo interno.
• Un approccio incentrato sui microservizi. Dovremmo optare per il primo approccio dei microservizi quando:
• Modularità e decentramento sono un aspetto importante dall'inizio di qualsiasi progetto.
• Prevediamo che l'applicazione avrà un volume elevato di transazioni o traffico.
• Preferiamo i benefici a lungo termine rispetto a quelli a breve termine.
• Abbiamo il giusto gruppo di persone da progettare, sviluppare e distribuire rapidamente le applicazioni, soprattutto durante la fase iniziale.
• Ci impegniamo a utilizzare strumenti e tecnologie all'avanguardia.

Come utilizzare un'architettura di microservizi

Sfortunatamente, La maggior parte delle informazioni disponibili sull'architettura dei microservizi spiega perché dovrebbero essere usati, ma non mangio.. Buono a sapersi che i microservizi potrebbero rivoluzionare il design, implementazione e funzionamento delle applicazioni. Ma, come si crea esattamente un singolo microservizio? È necessario comprendere i componenti fondamentali di un microservizio se si desidera che l'output funzioni correttamente e non assomigli alla stessa applicazione monolitica con una nuova mano di vernice.

Queste sono le Cinque elementi di cui un microservizio avrà bisogno prima di poter essere utilizzato in un'architettura di applicazione distribuita:

1. Funzionalità con ambito corretto. Il primo elemento di un microservizio è stabilire cosa deve fare. Un modo per impostare l'ambito corretto consiste nel dividere i servizi in base alla funzionalità logica. Un altro approccio all'ambito è quello di riflettere la struttura dell'organizzazione di sviluppo. Un terzo approccio consiste nel ridurre un servizio alla quantità di codice che il team potrebbe reintrodurre in un periodo di due settimane..
2. Prepara una API. Dopo aver suddiviso un'applicazione in più servizi cooperativi, in che modo questi servizi dovrebbero comunicare tra loro? Regolarmente, questo viene fatto con le chiamate API del servizio Web REST, sebbene possano essere utilizzati anche altri meccanismi di trasporto. Una buona idea è evitare di saltare subito alla codifica API. Anziché, è meglio lavorare su carta o lavagna per stabilire cosa deve esporre un servizio specifico per funzionare correttamente.
3. gestione del traffico. Dal punto di vista del servizio di chiamata, dovresti sempre tenere traccia delle tue chiamate ed essere pronto a terminare se la soluzione richiede troppo tempo. Dal punto di vista del servizio chiamato, la progettazione dell'API dovrebbe includere la possibilità di inviare una risposta che indica il sovraccarico. I servizi devono inoltre essere in grado di generare ed eliminare nuove istanze del servizio in base alle esigenze per adattarsi alle variazioni del carico di traffico..
4. Download dati. Avere la necessità di un funzionamento continuo è molto diverso da ciò di cui hanno bisogno le applicazioni tradizionali, che spesso smettono di funzionare se l'infrastruttura sottostante si guasta. Per garantire che gli utenti possano continuare a lavorare in caso di errore di un'istanza, i dati specifici dell'utente possono essere migrati da istanze di servizio a un sistema di storage ridondante condiviso raggiungibile da tutte le istanze di servizio. Un altro approccio all'offload dell'archiviazione consiste nell'inserire una condivisione della cache basata sulla memoria tra un determinato servizio e l'archiviazione associata a tale servizio..
5. Sorveglianza. Il sistema di monitoraggio di un'applicazione basata su un'architettura a microservizi deve consentire il continuo cambio di risorse, essere in grado di acquisire i dati di monitoraggio in una posizione centrale e visualizzare informazioni che riflettono la natura mutevole delle applicazioni di microservizi.