Microservizifornaia/lectures/LISD/L6_Microservizi.pdf · Definizione • Architetturaa...
Transcript of Microservizifornaia/lectures/LISD/L6_Microservizi.pdf · Definizione • Architetturaa...
MicroserviziAndrea Fornaia, Ph.D.
Department of Mathematics and Computer ScienceUniversity of Catania
Viale A.Doria, 6 -‐ 95125 Catania [email protected]
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