5. DotNetCode.IT
Microsoft .Net Coding Community
Chi Siamo
Fabio Mannis Ivano Scifoni
Software Architect
Delta Progetti 2000 (gruppo
Comdata)
Software Architect
Fincons
6. DotNetCode.IT
Microsoft .Net Coding Community
AGENDA
Cosa sono i Microservizi?
Come funzionano?
Quali pattern utilizzano?
Quando è giusto utilizzarli?
8. DotNetCode.IT
Microsoft .Net Coding Community
SOA (Service Oriented Architecture)
L’architettura a servizi SOA (Service Oriented Architecture) nasce con l’obiettivo di realizzare servizi, chiamati
anche processi di business, disponibili a un qualsiasi richiedente o consumer. Il modello SOA consente una
conversazione semplice basata sul paradigma consumer/provider tramite interfacce e protocolli standard e
l’integrazione di servizi composti.
Nasce fondamentalmente come soluzione al problema dell'integrazione tra macrosistemi operanti su
piattaforme differenti; sono nati cioè con l'obiettivo di fare interoperare in modo organico e non occasionale
sistemi tra loro differenti.
Principi:
• I boundary sono espliciti.
• I servizi sono autonomi.
• I servizi si scambiano schemi e contratti, non classi.
• La compatibilità tra servizi è stabilita via Policy.
9. DotNetCode.IT
Microsoft .Net Coding Community
MICROSERVIZI
Evoluzione di SOA
Lo stile architetturale a microservizi è un approccio allo sviluppo di una singola applicazione come insieme di
piccoli servizi, ciascuno dei quali viene eseguito da un proprio processo e comunica con un meccanismo snello,
spesso una HTTP API. (Martin Fowler)
Uno stile di architettura software in cui le applicazioni complesse sono composte da piccoli processi
indipendenti che comunicano tra di loro utilizzando API.
• Set di Servizi fortemente disaccoppiati. Ogni microservizio è un’entità separata, che può essere rilasciata su
una piattaforma isolata, indipendentemente da tutti gli altri e in maniera trasparente ai sui consumers.
• Ogni servizio implementa un set di funzioni strettamente correlate (SOLID - SRP – Single Responsibility
Principle)
10. DotNetCode.IT
Microsoft .Net Coding Community
• Ogni servizio deve essere conforme al CCP (Common Closure Principle – Le cose che cambiano insieme
devono essere «packaged» insieme, in modo che eventuali combiamenti si riflettono solo su un servizio)
• I servizi comunicano tra di loro tramite protocolli:
• Sincroni : HTTP/REST
• Asincroni: AMQP (Advanced Message Queueing Protocol)
• Ogni servizio ha il suo Database per poter essere disaccoppiato dagli altri.
• Ogni servizio deve essere testabile
• Ogni servizio deve essere abbastanza «micro» da poter essere sviluppato da un team di 6-10 persone e
ognuno di questi team deve poter essere autonomo. (potete sussurrare «ad avercele 6 persone dedicate »
per l’intero progetto… )
11. DotNetCode.IT
Microsoft .Net Coding Community
Patterns
• Decomposition patterns
• Decompose by business capability: Identificare i servizi in base alla struttura aziendale (Reparto
marketing, Magazzino…) ed ogni struttura individua un servizio.
• Decompose by subdomain: Ogni servizio corrisponde a un sottodominio DDD (Domain-Driven Design)
– (Catalogo prodotti, Magazzino)
• Decompose by use case: Ogni servizio è responsabile per una specifica azione (Servizio di spedizione)
• Decompose by Resource: Ogni servizio è responsabile per tutte le azioni compiute da una Risorsa
(Risorsa : Utente – Servizio di Autenticazione e profilazione)
• ROA (Resource-oriented architecture) - Resources with "RESTful" interfaces.
12. DotNetCode.IT
Microsoft .Net Coding Community
Patterns
• API Gateway: Singolo entry point per tutte le request, che si occupa della loro gestione.(Possibile variazione
BackEnd for frontends, specifico API gateway per ogni tipo di client)
• Database per service: Ogni servizio ha il suo database che è parte integrante del servizio stesso e non può
essere acceduto dagli altri servizi.
• API Composition
• Command Query Responsibility Segregation (CQRS)
• Command-side (CRUD operations)
• Query-side (Viste di aggregazione dei dati)
• Client-side service discovery e Server-side service discovery: Meccanisco tramite il quale il nostro API
Gateway trova il servizio che deve eseguire.(viene usato un Service Registry)
14. DotNetCode.IT
Microsoft .Net Coding Community
Vantaggi
• ALM
• Velocizzazione dei tempi di sviluppo e rilascio
• Adattamento alle nuove tecnologie e/o ai team di sviluppo
• Resilienza del sistema
• Un malfunzionamento di una parte non comporta un malfunzionamento di tutto l’ecosistema
• Facilità di debug e analisi del codice
• Scalabilità
• Componibilità
• Sostituibilità
• Testing (si e no)
15. DotNetCode.IT
Microsoft .Net Coding Community
Svantaggi
• ALM (Svantaggio?)
• Alta disponibilità (Forte dipendenza dalla infrastruttura di rete)
• Coerenza dei dati (Gestione di sistemi transazionali.)
• Orchestrazione
17. DotNetCode.IT
Microsoft .Net Coding Community
Integrazione tra servizi
L’integrazione fra i vai microservices della nostra struttura è
uno degli aspetti cruciali della loro implementazione. Se
integriamo nel modo corretto, allora ogni microservice
conserva la propria autonomia, lo possiamo rilasciare in
maniera completamente asincrona rispetto agli altri, e tutto il
nostro sistema ne trarrà beneficio.
La nostra decisione principale da prendere è se implementare
un sistema sincrono o asincrono
18. DotNetCode.IT
Microsoft .Net Coding Community
Integrazione Sincrona
Nell'integrazione Sincrona (Request/Response) il client invia la
sua richiesta al servizio ed attende una risposta
19. DotNetCode.IT
Microsoft .Net Coding Community
Integrazione Asincrona
Nell'integrazione Asincrona il client invia la sua richiesta al
servizio e prosegue la sua esecuzione senza attendere la
risposta.
L’implementazione classica di integrazine asincrona è con
l’ausilio di un message broker.
20. DotNetCode.IT
Microsoft .Net Coding Community
Integrazione Asincrona Message broker
Si tratta di un “componente” che permette a due sistemi,
produttore e consumatore, di comunicare garantento
disaccoppiamento fra i due.
Possiamo suddividere le code di un message broker in
Single receiver
Multi receiver
21. DotNetCode.IT
Microsoft .Net Coding Community
Integrazione Asincrona Single Receiver
Nell'integrazione Asincrona Single Receiver ogni messaggio
puo essere processato esattamente da un solo ricevitore o
servizio
22. DotNetCode.IT
Microsoft .Net Coding Community
Integrazione Asincrona Multi Receiver
Nell'integrazione Asincrona Single Receiver ogni messaggio
puo essere processato da zero a più ricevitore o servizio