MicroserviziAndrea  Fornaia,  Ph.D.

Department  of  Mathematics  and  Computer  ScienceUniversity  of  Catania

Viale A.Doria,  6  -­‐ 95125  Catania  Italyfornaia@dmi.unict.it

http://www.cs.unict.it/~fornaia/

Definizione• Architettura a Microservizi: design di

un’applicazione come insieme di serviziindipendenti a livello di deploy

• Una modifica (o un fallimento) in una parte del sistema non deve implicare l’aggiornamento (o l’arresto) di tutta l’infrastruttura in produzione

• Possibile promuovendo il lasco accoppiamento:– A livello funzionale (separation of concerns)– A livello di dati (persistenza decentralizzata)– A livello di sviluppo (piccoli team dedicati)– A livello di processo di esecuzione (container/VM)

4  FORZE

Monolite VS Microsevizi

[https://wordpress.stackexchange.com/questions/253635/are-­‐there-­‐any-­‐initiatives-­‐to-­‐work-­‐wordpress-­‐as-­‐microservices]

Monolite VS Microsevizi

Principi• Componentization via services• Organized around business capabilities• Products not projects• Smart endpoints and dumb pipes• Decentralized governance• Decentralized data management• Infrastructure automation• Design for failure• Evolutionary design

Svantaggi di un monolite• Al crescere della dimensione del sistema la

produttività degli sviluppatori diminuisce(complessità)

• Difficile introdurre l’uso di nuove tecnologie• Se una parte del sistema va in errore, l’intero

sistema ne risente (fault localization)• Se una parte del sistema viene aggiornata,

bisogna fare il deploy dell’intera applicazione(EAR/WAR/JAR)

• Se una parte del sistema consuma troppe risorse, l’intera applicazione deve essere replicata(scalabilità)

Scalabilità e ottimizzazione risorseUn’applicazione monoliticaesegue tutte le funzionalitàin un singolo processo…

… e scala replicando il“monolite” su più server.

Un’architettura a microserviziesegue ogni funzionalità in un servizio separato…

… e scala distribuendo iservizi tra più server, replicandoli se necessario.

Replico solo  le  parti che richiedono più risorse

Eterogeneità e Decentralizzazione

Posts<<ruby>>

Friends<<go>>

Pictures<<java>>

Document  Store

Graph  DB

BlobStore

governancedecentralizzata dei dati

Vantaggi dei Microservizi• Decentralizzati• “Do one thing well”• Black box• Eterogeneità• Fault isolation• Agilità• Scalabilità

• Resilienza• Riusabilità• Più semplice

comprendere ilcomportamento del singolo servizio

• Favorisce il rilasciocontinuo (CI/CD)

Quanto “Micro”?• Tanto piccolo da svolgere un solo compito e bene• Minore è la dimensione dei servizi, maggiori sono:

– i vantaggi: parti autonome– gli svantaggi: aumenta la complessità

• Euristiche:– Two Pizza Team (tutto il team deve essere sfamato con due

pizze americane)– Tanto piccolo da poterlo rifare da zero in due settimane

• In realtà, è fondamentale:– dividere ed organizzare i servizi attorno a concetti di business– promuovere il lasco accoppiamento a più livelli (funzionale, dati,

sviluppo, deploy)– allineare I servizi alla struttura organizzativa

Legge di Conway

Any  organization  that  designs  a  system  (defined  broadly)  will  produce  a  design  whose  structure  is  a  copy  of  the  organization’s  communication  structure.

Melvyn  Conway,  1967

Cross-functional teams

Il team di sviluppo ha la responsabilità dellagestione del proprio software in produzione (“you build, you run it”)– Resa più semplice dalla maggiore granularità dei

servizi

Quindi devo usare i microservizi?

• I microservizi aiutano a gestire sistemi complessi…• … ma introducono allo stesso tempo tutta la

complessità dei sistema distribuiti– Inter-service communication– Automated deployment– Testing

– Monitoring– Failure – Eventual Consistency

Produttività & Complessità

Monolith First

You  shouldn’t  start  with  a  microservices architecture.  Instead,  begin  with  a  monolith,  keep  it  modular,  and  split  it  into  microservices once  the  monolith  becomes  a  problem.

-­‐-­‐-­‐-­‐Martin  Fowler

Dividere il monolite:Bounded Context

[https://martinfowler.com/bliki/BoundedContext.html]

Domain-­‐Driven  Design  (Evans,  2003)

Complessità e strumentiComponente/Ruolo StrumentoRESTful Web  Service Spring  Boot,  Flask

Message  Queue RabbitMQ

Service  Discovery Netflix  Eureka

Dynamic  Routing  e Load  Balancer Netflix  Ribbon

Circuit Breaker Netflix  Hystrix

Monitoring Netflix  Hystrix dashboard  e  Turbine

API Gateway  (Edge  Server) Netflix  Zuul

Central  Configuration Server Spring  Cloud Config Server

Authentication  e  API  protection Spring Cloud  +  Spring  Security  OAuth2

Centralised log  analysis Logstash,  Elasticsearch,  Kibana (ELK)

Service isolation/deployment Docker, Vagrant,  AWS,  Openstack…

Data Store MySQL, MongoDB,  Redis,  Cassandra,  Neo4j…

Esempio• Vogliamo creare un’applicazione per permettere agli studenti del

corso di “Ignegneria del Software” di esercitarsi in vista dell’esame.

• R1: Lo studente, dopo aver inserito un alias identificativo (es. matricola), potrà rispondere ad una o più domande tipiche d’esame(a risposta chiusa), ottenendo l’esito “corretto” o “sbagliato”.

• R2: Si vuole inoltre incoraggiare lo studente ad esercitarsigiornalmente tenendo traccia dei progressi e fornendo dei badge di ricompensa:– es. ”costante: effettuato l’accesso per 7 giorni di fila”– es. “instancabile: risposto a 30 domande in un giorno”– es. “preciso: risposto a più di 100 domande con correttezza dell’80%”

Iniziamo con un Monolite• Cominciamo lo sviluppo implementato il

primo requisito funzionale (R1).• Il requisito suggerisce un servizio che

chiameremo Training.• Scegliamo un database relazionale (MySQL)

Training ServiceTraining  Service

UI

Business  Logic(Training)

Business  Logic(Auth)

Training  /  AuthDB

componente funzionalità DB

Considerazioni• Possiamo usare Spring Boot per la creazione di servizi REST indipendenti

• Per il momento le funzionalità di identificazione dell’utente sono minimali, non è necessaria la creazione di un servizio a parte (es. Auth Service)

• Assumiamo che le domande siano state precaricate nel DB con strumentiesterni

• Attualmente non sono richieste funzionalità di gestione delle domande(Aggiunta/Modifica/Cancellazione), quindi non è richiesta una business logic separata

• Se in futuro fossero aggiunte le operazioni CRUD sulle domande, sipotrebbe separare la nuova business logic in un servizo separato (es. Question Service) assieme ai suoi dati– Richiederebbe la divisione delle tabelle in DB distinti

Aggiunta del Badge ServiceTraining  Service

UI

Business  Logic(Training)

Business  Logic(Auth)

Training  /  AuthDB

Badge  Service

Business  Logic(Badge)

BadgeDB

• Stiamo facendo evolvere il sistema aggiungendo la gestione dei badge• Invece di aggiungere altre funzionalità al sistema esistente (monolite)

decidiamo di creare un servizio indipendente• Inseriamo un controllo decentralizzato dei dati: ogni servizio gestisce i

propri dati• Le funzionalità saranno accessibili tramite l’UI di Training (per ora)• I servizi adesso devono comunicare. Come?

Coordinamento tra servizi

Registrazione utente

Crea record  cliente

Inizializza puntifedeltà

Spedisci kit  di  benvenuto

Invia email  di  benvenuto

Registrazionecompletata

Supponiamo di  voler realizzare un  business  process per  la  registrazionedi  un  nuovo utente,  dovendo coordinare più microservizi

Database Condiviso

Servizio Clienti

Servizio Punti

Servizio Spedizione

Servizio Email

DB  Clienti

Tecnica di  integrazione spesso usata per  la  sua semplicità.Usato anche per  integrare sistemi di  terze parti.

I  dati vengono scritti e  letti all’interno delle entità del  database  condiviso.Espone i dettagli interni (anche a  terze parti).

Una  modifica alla rappresentazione dei dati si ripercuote su tutto il sistema.L’intero DB  diventa di  fatto un’API.

Troppo semplice creare delle “eccezioni alla regola”,  perdendo il lasco accoppiamento.

Orchestrazione

Servizio Clienti

Servizio Punti

Servizio Spedizione

Servizio Email

inizializza punti fedeltà

spedisci kit

invia email  di  benvenuto

crea cliente

Viene utilizzata una comunicazione request-­‐response  (sincrona o  asincrona).Interfaccia di  comunicazione esplicita (API),  maggiore separazione.La  logica di  coordinamento risiede in  uno dei servizi (Servizio Clienti).

Si  possono usare tecnologie di  RPC (RMI,  CORBA).Si  possono usare tecniche basate su API  REST.

Coreografia

Servizio Punti

Servizio Spedizione

Servizio Email

subscribe

creacliente subscribe

subscribe

<<evento>>cliente creatoServizio Clienti

publish

Viene utilizzata una comunicazione event-­‐based  (asincrona)  basata su message  broker.Detto anche event-­‐based  architecture o  reactive  system.

La  logica di  coordinamento è decentralizzata,  ogni servizio sa come  reagire all’evento.”Servizio Clienti”  si limita a  generare l’evento (fatto compiuto).

Potrebbe non  sapere chi  lo  consumerà.Nuovi consumatori possono essere aggiunti per  cambiare il comportamento del  sistema.

Event  Bus

Event Driven VS Request Response

Comunicazione ibrida

Combinare event bus e REST API

Training  Service Badge  Service

Message  Broker

AnswerEvent

GET  /esito/{id}

1

3

Mostra DomandaOttieni RispostaMostra EsitoGenera  Evento

Controlla EsitoAssegna PuntiAggiorna Badge

4

62

5

L’evento potrebbe non  contenere tutte le  informazioni necessarie (minimale).  Badge  richiederà ciò che gli serve  in  risposta all’evento usando le  API  REST di  Training.  Gliidentificatori vengono usati per  operare in  maniera disambigua sulla stessa richiesta.

syncasync

Separare la UIbrowser

Badge  Service

Business  Logic

Badge  DB

REST  API

Trainig Service

Business  Logic

Training  DB

REST  API

UI  Server

Serve  static  content(HTML,  JS,  CSS)

Message  Broker

8080

link link

9090 9091

Prendicontenutostatico

Nginx,Tomcat

…

RabbitMQ

http://localhost:8080

Service Discovery• Allo stato attuale ogni riferimento ad un servizio è hardcoded (es.

Training Service: http://localhost:9090).

• Questo causa problemi di scalabilità:– se un servizio viene spostato dovrei aggiornare ogni riferimento– se un servizio viene replicato, contatterei sempre lo stesso

• Un Service Discovery (es. Netflix OSS Eureka, integrato con Spring Cloud) permette di risolvere il problema, associando un nome, invece che un indirizzo in rete, a ciascun servizio.

• Un sistema di Service Descovery è composto da:– Service Registry: il registro che associa nomi a indirizzi (unico)– Registry Agent: usato da ciascun servizio per registrarsi (all’avvio)– Registry Client: usato da ciascun servizio per risolvere i nomi

Service Discoverybrowser

Trainig Service

UI  Server

Serve  static  content(HTML,  JS,  CSS)

Message  Broker

8080

9090 9091

http://localhost:8080

Badge  Servicehttp://training/esito

Service  Registry

RegistryAgent

RegistryClient

RegistryClient

RegistryAgent

registrati registrati

risolvi http://training

Load Balancing• Che succede se abbiamo più istanze di uno stesso servizio?• Serve un load balancer in modo da distribuire il carico delle

richiesta tra più istanze

• Netflix OSS Ribbon (sempre in Spring Cloud) è un load balancer client-side integrato con Eureka

• Più istanze di uno stesso servizio (in ascolto su porte diverse, es. http://localhost:9090 e http://localhost:9092) verrannoregistrate con lo stesso nome (es. training)

• In fase di risoluzione, Eureka manderà al client tutte le risoluzioni per il nome richiesto

• Lato client, Ribbon (usando una strategia round robin) sceglierà solo una di questa per risolvere il nome

• Il meccanismo è client side ma trasparente al microservizio

Load Balancingbrowser

Trainig Service

UI  Server

Serve  static  content(HTML,  JS,  CSS)

Message  Broker

8080

9090 9091

trainig:   http://localhost:9090http://localhost:9092

badge: http://localhost:9091

Badge  Servicehttp://training/esito

Service  Registry

risolvi http://training

Trainig Service

9092

lista completa risoluzioni

Service  Registry  Table

LoadBalancer

API Gateway• Service Discovery e Load Balancing nel backend

promuovono il lasco accoppiamento, rendendo ilsistema scalabile

• Al momento però:– il client web (sul browser) non può interagire con il

service discovery e non beneficia del load balancing (i riferimenti sono ancora hardcoded)

– non abbiamo al momento un servizio di autenticazione che gestisca il contesto distribuito

– le API REST sono fortemente accoppiate con l’architettura del sistema. Qualsiasi modifica siripercuoterebbe anche sui client (struttura internaesposta)

API Gateway

• Netflix OSS Zuul è un API Gateway disaccoppia iclient dalle API REST dei singoli microservizi

• Funge da router per le richieste da parte deiclient, associando le API esterne (applicazioneunica) alle API interne (vari microservizi)

• Sarà un microservizio separato in ascolto su di una porta specifica (es. 8000)

API Routing

/nuovadomanda -­‐-­‐> training/domanda/risposta -­‐-­‐> training/risposta/badge/{id_utente}   -­‐-­‐> badge/lista/{id_utente}

Integrando Zuul,  Eureka  e  Ribbon,  le  richieste vengono risolte e  smistate ad  una delle possibili istanze del  servizio richiesto,  ottenendo così anche il service  descovery e  il load  balancing

1. Il  client  web  chiederà http://localhost:8000/nuovadomanda2. L’API  gateway  farà il routing  della richiesta su http://training/domanda3. L’API  gateway  chiede al  Service  Registry  di  risolvere training4. Il  Service  Registry  fornisce la  lista di  possibli risoluzioni5. Il  Load  Balancer  ne  sceglie una,  es.  http://localhost:90926. La  richiesta viene inoltrata a  http://localhost:9092/domanda

API Gatewaybrowser

Trainig Service

UI  Server

Message  Broker

8080

9090 9091

Badge  Service

Service  Registry

Trainig Service

9092

API  GatewayLB RC

8000

Edge Server• API Gateway può essere usato come unico

punto di accesso per l’intero sistema a microservizi (edge server)

• Altri servizi di accesso, come autenticazione o filtro possono essere inseriti a questo livello (es. Spring Security OAuth2)

• Non bisogna esagerare con le responsabilità, richieremmo di creare un single point of failure

Circuit Breaker

[https://martinfowler.com/bliki/CircuitBreaker.html]

• I servizi possono fallire:– andare in errore– non rispondere in tempo

• Cicuit Breaker isola temporaneamente un servizionon funzionante

• Wrapper della chiamata remota (serve un intermediario, es. API Gateway)

• Se il numero di timeout supera una soglia, il circuitoviene aperto

• Le successive richieste seguiranno un fallback path (messaggio di errore di default, chiamata ad altra istanza del servizio…)

• Il circuito verrà chiuso dopo alcuni tentativi andati a buon fine (test stabilità)

• Netflix OSS Hystrix fornisce un’implementazione• Turbine aggrega le informazioni sullo stato dei

circuiti su più servizi (monitoraggio)• Hystrix Dashboard per visualizzare lo stato globale

Hystrix Dashboard

[https://medium.com/netflix-­‐techblog/hystrix-­‐dashboard-­‐turbine-­‐stream-­‐aggregator-­‐60985a2e51df]

Log Analysis

• Mantenere i servizi sotto  controllo• Analisi degli eventi e  delle prestazioni del  sisema• Ricostruzione situazioni di  errore può essere complesso in  un  sistema distribuito• Soddisfare una richiesa può coinvolgere più microservizi (workflow)• L’dentificativo di  una richiesta può essere usato per  ricostruire il flusso di  operazioni

ElasticSearchLogStashKibana

Kibana

Stateless Microservices• Service discovery, load balancing ed API Gateway

non bastano a garantire la scalabilità

• I microservizi devono essere stateless: non devono mantenere dati o uno stato in memoria(es. sessione utente)

• Evitare affinità di sessione: forza tutte le richiestedi uno stesso utente ad essere inoltrate allastessa istanza di servizio (poiché ha mantenutointernamente le informazioni sul contesto)

Affinità di sessione

TrainigService  1

TrainigService  2

Load  Balancer

cnt

es.  “lo  studente deve rispondere a  due  domande prima  di  ottenere il risultato”

answer  1,  answer  2

answer  1answer  2

TrainigService  1

TrainigService  2

Load  Balancer

answer  2answer  1

cnt

answer  1,  answer  2

DB condiviso tra le istanze dellostesso servizio

• Nel nostro esempio, i database erano incorporati(embedded) con il servizio, impedendo unacorretta scalabilità

• Il database deve essere esterno al servizio(istanza separata) ma ad uso esclusivo del servizio

• Tutte le istanze di uno stesso servizio devonocondividere lo stesso database

• La scalabilità del database è tipicamente gestitadal database engine, che fornirà un unico puntodi accesso per le istanze (trasparente)

Servizi diversi, DB diversi

• Promuove lasco accoppiamento (a livello dei dati)• Altrimenti il DB diventerebbe una “API condivisa”

VM e Container

Service isolation & deployment(sia VM che container)

CLIENT

colleagues

instances  &  relationstext  description

HOST

DEAMON

IMAGESJava:8

Centos:7

codeartifacts

INSTANCEScontainers

VMs

REGISTRYJava:8

Centos:7

newbase

cachedbase

run

Destinazione: cloud!

e (tanti)  altri…

Riferimenti• M. Fowler: “Microservices: a definition of this new architectural item”

https://martinfowler.com/articles/microservices.html• M. Fowler: “Microservices Resource Guide”

https://martinfowler.com/microservices/• M. Fowler: “Microservice Premium”

https://martinfowler.com/bliki/MicroservicePremium.html• S. Newman: “Building Microservices”. O’Reilly, 2015• M. Macero: “Learn Microservices with Spring Boot”. Apress, 2017• B. Stopford: “Microservices in the Apache Kafka Ecosystem”

https://www.slideshare.net/ConfluentInc/microservices-in-the-apache-kafka-ecosystem