Introduzione Spring Boot e Microservizi

Introduzione a Spring Boot e Microservizi

L’architettura a microservizi consiste nel dividere un’unica applicazione monolitica in tante piccole mini applicazioni, appunto detti microservizi.

Ogni microservizio deve saper svolgere un solo compito, o una serie di piccoli compiti inerenti ad esso.
La collaborazione tra questi microservizi genera il servizio finale che diamo all’utente.

Questo semplice principio scatena una serie di corollari, alcuni vantaggiosi, altri un po’ meno. Per esempio:

  • ogni servizio ha la propria base dati e deve accedere solo ad essa. Se ha bisogno di altre informazioni le chiede via HTTP o via scambio di messaggi ad altri servizi.
  • è possibile replicare (su più processi) un certo servizio ritenuto critico o che è maggiormente stressato: la scalabilità è un grande vantaggio dell’architettura a microservizi.
  • ogni servizio può essere realizzato con una tecnologia diversa dall’altra visto che possono comunicare solo via HTTP o messaggi.
  • visto che il sistema è distribuito, il suo aggiornamento può essere parziale: ogni modulo (servizio) infatti ha un proprio ciclo di vita e può essere sostituito senza impattare (quasi) nessuno degli altri servizi correlati.

Fin qui sembra che i microservizi sia la panacea per tutti i mali, ma ovviamente non così!

Se questo approccio risolve e migliora i problemi che abbiamo appena descritto ne apre di nuovi. Dobbiamo sempre tenere in mente che si passa da una architettura monolitica di questo tipo:

ad una composta da tante piccole applicazioni:

Questo passaggio comporta le seguenti criticità:

  • ogni servizio deve sapere dove sono gli altri. C’è quindi bisogno di una specie di registro dei servizi disponibili.
  • le configurazioni del sistema sono anch’esse distribuite in tutti i moduli. Nasce allora la necessità di uno strumento che permetta di centralizzarle e ridistribuirle “a caldo”, senza stoppare il microservizio.
  • un sistema distribuito deve essere tollerante al fallimento di una delle sue parti. Se uno o più moduli risultano non disponibili, il sistema deve essere in grado di isolare quella parte.
  • l’entrypoint del sistema è bene che rimanga sempre uno, in modo da non percepire l’atomicità dei sistemi sottostanti.
  • ogni sistema ha i propri log: dobbiamo quindi preoccuparci di recuperare e aggregare tutti i log per capire cosa sta succedendo.
  • in un sistema distribuito con queste caratteristiche, è difficile riuscire a mantenere una transazionalità di tipo ACID.
  • la gestione di un rilascio di una nuova versione può diventare più complessa perché può coinvolgere diverse applicazioni che vanno aggiornate insieme.

Queste sono le problematiche principali nell’uso di questo nuovo paradigma architetturale: ne vale veramente la pena? Dipende dal problema che dobbiamo affrontare: se una dei primi requisiti è la scalabilità, allora siete sulla strada giusta, altrimenti è una scelta da ponderare molto seriamente.

MicroServizi e Java

Come può essere fatto un microservizio in Java? Diciamo che in generale, quando si pensa ad un microservizio, l’idea è quella di produrre una applicazione stand-alone che espone una API via HTTP, cioè ha un server HTTP embedded per farlo… tutto l’opposto di quanto fatto fino oggi in pratica! Nel mondo Java infatti siamo cresciuti a pane e Application Server (come JBoss, WAS, ecc…) o Servlet Container (come Tomcat). Lo sviluppo era quindi finalizzato ad un artefatto deployabile in unico ambiente dove giravano altre applicazioni.

Nel mondo dei microservizi invece è necessario un ribaltamento del punto di vista: è l’artefatto stesso ad eseguire un server (Application Server o Servlet Container che sia) che ha il ciclo di vita pari a quello dell’applicazione. 

Ma come vengono risolti, in java, le problematiche viste nel paragrafo precedente?

Utilizzando l’accoppiata Spring Boot + Spring Cloud. In particolare, Spring Boot permette di creare i microservizi e Spring Cloud invece li gestisce.

Spring è sempre stato una garanzia e non sorprende se oggi sia riuscito a ritagliarsi nel giro di poco tempo il ruolo di framework leader quando si pensa ai microservizi nel mondo Java.

Cominciamo con l’analizzare Spring Boot e, in un secondo momento, l’immenso mondo di Spring Cloud.

Spring Boot

Spring Boot ha letteralmente fatto riesplodere l’uso di Spring: se infatti il mondo Java EE aveva bene o male quasi colmato il gap almeno con Spring Framework, con l’uscita di Spring Boot c’è stato un nuovo salto in avanti perché è proprio lo strumento ideale per creare microservizi in Java!!

Come avevamo già accennato, il risultato di un’applicazione Spring Boot è un file JAR con all’interno un embedded server. Questo vuol dire che non avremo bisogno di configurare un servlet container come Tomcat o un Java EE server come JBoss per eseguire la nostra applicazione; basterà eseguire il jar e Spring Boot tirerà su un embedded server che fungerà da container per la tua web application. 

Quali sono i requisiti di sistema per Spring Boot?

Per poter creare un progetto Spring Boot possiamo utilizzare qualsiasi IDE; esiste anche una versione personalizzata per Spring di Eclipse chiamata Spring Tool Suite, scaricabile qui

https://spring.io/tools

Lo staff di Spring mette a disposizione anche una web page, che permette di creare nuove applicazioni Spring, al seguente link:

https://start.spring.io/

Come strumenti di build si può usare Maven o Graadle. Per quanto riguarda i server si ha disposizione Apache TomCat, Jetty e UnderTow.

Per vedere un esempio pratico di creazione di un microservizio con Spring Boot cliccate qua

(Visited 21 times, 1 visits today)

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *