Microserivizi Flashcards
Come posso decomporre un sistema in microservizi, quali proprietà dovranno rispettare?
Possono essere sviluppati in parallelo
Facilmente replicabili, runnabili in parallelo
Sono stateless
Dato un input viene prodotto output senza side effects
Possiamo modificarli e rideployarli senza fermare altri services
Come identificare microservizi in cui dividere un sistema
Funzioni macro divise in funzioni più specifiche
Analizza i dati utilizzati da ciascun microservizio
Diminuire amount dei dati replicati
Quando sviluppo microservizio devo tener conto di:
Self contained: nessuna dipendenza esterna
Utilizzo per la comunicazione di protocolli lightweight
Non dipendenti della tecnologie
Deployabili indipendentemente
Orientati a funzionalità business
Cos’é coupling
Indica relazione con altri services (conosciamo direttamente come questi sono formati)
Es. classe che chiama con interface oppure direttamente
minore é migliore
Cos’é coesione
indica numero di componenti interni che vengono riutilizzati
Alta é migliore
Quattro attributi dei services
Coupling, coesione, singola responsabilitá, gruppi di 8 - 10 persone
Quanti microservizi occorrono
Non troppi (low coesione -> comunicazione overhead)
Troppo pochi ( high accoppiamento -> più interdipendenza e facilità update)
Parti dai dati a cui hanno accesso services
Service comunicazione
Diretta
Indiretta
Da preferire, messaggi passano tramite message broker
Best practice con i dati tra microservizi
Ogni microservizio dovrebbe manage i propri dati
Se non possibile read only
Cap Theorem
Se abbiamo dati distribuiti non possiamo avere
Consistenza
Disponibilità
Network partition
Saga pattern
Per coordinare un saga utilizziamo saga
Sequenza di local transactions
Ogni transazione avvenuta ne scatena un’altra
Vengono effettuate operazioni in caso di errore
Retry later Forward model
Annulla modifiche effettuate Backward model
Pro
Short tempi di sviluppo
Scaling efficace
Cons
Complesso
Comunicazione tra servizi
Data duplication
REST principi
Interfacce POST PUT DELETE GET
Si accede tramite uri
Richieste in formato prestabilito
Interazioni stateless
Gestione errori
Failure tipologia
Internal service si rende conto internamente di errore e gestisce con messaggio di errore
External service aspetta un servizio esterno, perdita di performance, probabile riavvio
Circuit breaker si inserisce tra service e service esterno gestendone gli errori, es. timeout
Service performance failure, si risolve tramite monitor per trovare cosa scatena load eccessivo
Talvolta basta nascondere errore ad utente come fa spotify
Test bravely spegne microservizi volutamente
