Microservices architecture & Service Fabric
Download as PPTX, PDF1 like766 views
Il documento discute l'architettura a microservizi e l'approccio di Microsoft utilizzando Service Fabric, evidenziando i vantaggi come scalabilità, velocità di distribuzione e gestione dei costi. Vengono presentati i benefici e le sfide di questa architettura, comparata con l'approccio monolitico. Infine, il documento esplora le funzionalità di Service Fabric, inclusa la gestione dei microservizi e le modalità di programmazione.
![• Singolo database
• Livelli con tecnologie specifiche
I dati nelle architetture n-layer I dati nell’approccio Microservizi
• Grafo di Microservizi interconnessi
• Lo stato è all’interno del singolo Microservice
• Differenti tecnologie utilizzate
• Database per i dati «cold»
Stateful
services
Web presentation
services
Stateless
servicesSQL DB
or
No-SQL
Mobile
apps
Web Tier
Services Tier
Data Tier
Il database è condiviso
tra tutti i servizi
Stateless services with
separate stores
Ogni microservizio
possiede il proprio
modello dati!
SQL
[…]
La connessione al
database è un collo di
bottiglia
Cache Tier
L’utilizzo di una Cache
non è di aiuto
nell’ingestion di
massicce quantità di
dati (Events, IoT, etc.)](https://image.slidesharecdn.com/microservicesarchitectureservicefabric-170628082241/85/Microservices-architecture-Service-Fabric-10-320.jpg)
Microservices architecture & Service Fabric
- 2. Architettura a Microservizi & Service Fabric Massimo Bonanni SR Consultant - ModernApps EMEA Domain - Microsoft @massimobonanni massimo.bonanni@microsoft.com
- 3. Agenda Concetti di architettura a Microservizi Approccio Microsoft ai Microservizi – Service Fabric Modello di programmazione di Service Fabric Conclusioni
- 4. Concetti di architettura a Microservizi
- 5. Perchè un approccio Microservice? Realizzare e gestire servizi scalabili Applicazioni in continua evoluzione Maggiore velocità di distribuzione delle nuove funzionalità per rispondere ai requisiti del cliente Miglior utilizzo delle risorse per abbattere i costi di gestione
- 6. Definizione di Microservizi Fanno una cosa sola in maniera efficiente ed efficace, sviluppati da un piccolo team di progettazione. Scritti in qualsiasi linguaggio di programmazione e con qualsiasi framework. Costituiti da codice, configurazione e risorse, sottoposti al controllo delle versioni, distribuiti e ridimensionati in maniera indipendente. Interagiscono con altri microservizi tramite interfacce e protocolli ben definiti. Hanno nomi univoci (URL) usati per risolvere la propria posizione. Rimangono coerenti e disponibili in caso di errori.
- 7. Eliminazione di singoli punti di guasto: un bug in un microservizio rimane isolato all’interno dello stesso; Iterazioni più veloci: codice più semplice con modifiche che non impattano tutta l’applicazione; Scalabilità: on-demand, elastica, densità dei servizi; Versionamento: versioning sul singolo servizio in maniera semplice; Flessibilità del linguaggio di sviluppo: minimizza l’impegno a lungo termine sullo stack tecnologico. Quando si sviluppa un nuovo servizio, si è liberi di scegliere qualsiasi linguaggio di programmazione e framework (i servizi sono disaccoppiati tra loro) Benefici dell’architettura basata su Microservizi
- 8. Automazione spinta: mantenere più flussi di distribuzione corretti e coerenti per tutto il ciclo di vita dell’applicazione; Comunicazione tra i servizi: i servizi disaccoppiati hanno bisogno di un modo efficace per comunicare senza rallentare l’intera applicazione; Coerenza dei dati: garantire la coerenza dei dati è una sfida, sia per lo store dei dati che per i dati in transito sulla rete; Alta disponibilità: il tempo di attività di ogni servizio contribuisce alla disponibilità complessiva dell’intera applicazione. Ogni servizio deve quindi avere un proprio sistema di misure distribuite per garantire all’applicazione un ampia disponibilità; Test: non è semplice implementare i test di integrazione. E’ necessario automatizzare il più possibile. Svantaggi dell’architettura basata su Microservizi
- 9. Approccio “Monolitico” Approccio Microservizi Una applicazione a microservizi separa le funzionalità in servizi distinti Questo approccio consente di scalare indipendentemente ogni servizio, creando istanze di ognuno su Server/VM/Container. Una applicazione monolitica raggruppa insieme funzionalità di un dominio ed è normalmente separata in layer, come web, business e data. Viene scalata clonandola su più Server/VM/Container. App 1 App 2App 1
- 10. • Singolo database • Livelli con tecnologie specifiche I dati nelle architetture n-layer I dati nell’approccio Microservizi • Grafo di Microservizi interconnessi • Lo stato è all’interno del singolo Microservice • Differenti tecnologie utilizzate • Database per i dati «cold» Stateful services Web presentation services Stateless servicesSQL DB or No-SQL Mobile apps Web Tier Services Tier Data Tier Il database è condiviso tra tutti i servizi Stateless services with separate stores Ogni microservizio possiede il proprio modello dati! SQL […] La connessione al database è un collo di bottiglia Cache Tier L’utilizzo di una Cache non è di aiuto nell’ingestion di massicce quantità di dati (Events, IoT, etc.)
- 11. Approccio Microsoft ai Microservizi – Service Fabric
- 12. Azure Service Fabric Microservices Azure Windows Server Linux Hosted Clouds Windows Server Linux Service Fabric Private Clouds Windows Server Linux High Availability Hyper-Scale Hybrid Operations High Density Rolling Upgrades Stateful services Low Latency Fast startup & shutdown Container Orchestration & lifecycle management Replication & Failover Simple programming models Load balancing Self-healingData Partitioning Automated Rollback Health Monitoring Placement Constraints
- 13. Il cluster Un cluster è un insieme di macchine (virtuali o fisiche) connesse in rete e in cui è presente il runtime di Service Fabric. Il cluster è composto da nodi e configurabile tramite un manifest. Ogni nodo può avere caratteristiche custom che permettono di posizionare nel migliore dei modi i servizi (constraint). Pensato per limitare l’impatto dei singoli guasti hardware. Un cluster è suddiviso in Upgrade Domain e Fault Domain. https://aka.ms/sfcluster
- 14. Fault Domain e Upgrade Domain Fault Domain: è un insieme di machine che possono avere problemi contemporaneamente. Ad esempio una singola macchina o tutte le machine alimentate dalla stessa presa. Upgrade Domain: un upgrade domain definisce l’insieme dei nodi che vengono aggiornati contemporaneamente. https://aka.ms/sfdomains
- 15. Application Model Un Application Type è un insieme di Service Type e definisce la struttura dell’applicazione. Un Application è un’istanza di un Application Type Il codice delle differenti application viene eseguito in differenti processi anche se le applicazioni girano nello stesso nodo. https://aka.ms/sfappmodel
- 16. I microservizi memorizzano lo stato in partizioni in modo da consentire la scalabilità. Una partizione contiene: • Istanze di servizi senza stato (primarie e secondarie) • Repliche di servizi con stato (primarie e secondarie) Le repliche di un servizio garantiscono l’alta disponibilità: se un’istanza o replica di un servizio primaria non risponde, Service Fabric promuove a primaria una delle secondarie garantendo continuità al servizio. Le partizioni https://aka.ms/sfpartitions
- 18. Modello di programmazione di Service Fabric
- 19. Tipologie di servizi Guest executables & guest containers • Permette di implementare e pubblicare servizi scritti con qualsiasi framework (win32, Java, …). Stateless Services • Servizi il cui stato è persistito esternamente (ad esempio in Azure DB) • Applicazioni web (ASP.NET) esistenti e worker role Stateful Services • Affidabilità dello stato gestita attraverso repliche e persistenza locale • Bassa latenza • Riducono la complessità rispetto al tradizionale approccio n-layer
- 20. Modelli di programmazione Built-In Reliable Service : insieme di API per l’implementazione di servizi con e senza stato. Stateful Service : memorizzano lo stato utilizzando delle reliable collection e sfruttando le repliche per garantire la consistenza dello stesso. Stateless Service : non memorizzano lo stato in repliche. Consentono di hostare service WCF o Web Reliable Actor : insieme di API per l’implementazione di oggetti basati sul concetto di Actor Model. https://aka.ms/sfprogmodel
- 21. Reliable Service Simili ai Web Service ma forniscono alcune caratteristiche out of the box come alta disponibilità, affidabilità, resilienza. Basano la scalabilità sul concetto di partizione dei dati. Possono essere Stateless o Stateful. Lo stato è gestito da uno State Manager che fornisce API per rendere i dati affidabili e replicati nel cluster. I Reliable Service comunicano tra loro (e con gli Attori) tramite messaggi asincroni. https://aka.ms/sfreliableservices
- 22. Reliable Actor Basato su un pattern architetturale (Actor Model) pensato per realizzare un’architettura costruita da processi indipendenti. Ogni attore è individuato da un identificatore univoco attraverso il quale può essere istanziato (ActorId). Ogni attore fornisce azioni che possono essere invocate dall’esterno. Le azioni sono processate nell’ordine in cui vengono invocate. Generalmente Stateful (ma lo stato può essere persistente o volatile). L’affidabilità dello stato è gestita, in maniera trasparente, dal framework. https://aka.ms/sfreliableactors
- 23. Reliable Actor Ha un pattern di esecuzione Single Thread: un singolo attore non è in grado di elaborare altre richieste in arrivo finché la richiesta corrente non è terminata. L’Actor Model è un modello matematico per il calcolo concorrente teorizzato nel 1973 da Carl Hewitt (http://aka.ms/HewittCH9Actor). Gli Attori comunicano tra loro (e con i Reliable Service) tramite messaggi asincroni. https://aka.ms/sfreliableactors
- 24. Reliable Actors & Services https://github.com/massimobonanni/ServiceFabricSamples
- 25. Service Fabric nel cloud Cosmos DB
- 26. Service Fabric Takeaways Service Fabric fornisce “chiavi in mano” tutte le funzionalità di orchestrazione necessarie per i nostri servizi. Utilizzato per molti dei servizi offerti da Azure. Può essere eseguito sia nel Cloud che on Premise. Può lavorare con processi, container o una combinazione dei due. Gira su Linux e Windows. Possibilità di utilizzo di più linguaggi/framework.
- 28. Riferimenti Documentazione ufficiale https://docs.microsoft.com/en-us/azure/service-fabric/ Blog ufficiale https://blogs.msdn.microsoft.com/azureservicefabric/ Github https://github.com/Azure/service-fabric Build2017 - Azure Service Fabric, microservices, containers, and the road ahead https://channel9.msdn.com/Events/Build/2017/B8106 Build2017 - Managing secure, scalable Azure Service Fabric clusters and applications https://channel9.msdn.com/events/Build/2017/T6084 MVA - Service Fabric Patterns and Practices https://mva.microsoft.com/en-US/training-courses/16925 MVA - Building Microservices Applications on Azure Service Fabric https://mva.microsoft.com/en-US/training-courses/16747
- 29. Feedback Form Aiutateci a migliorare la qualità dei nostri eventi compilando il feedback form: https://1drv.ms/xs/s!Au9T1EY0TwHfn6RdsXBllmc3qTesWA
- 30. Thanks to our Sponsor
Editor's Notes
- #36: Link: https://1drv.ms/xs/s!Au9T1EY0TwHfn6RdsXBllmc3qTesWA