CCI2019 - Microservizi: Idee per un'architettura con al centro l'utente
- 2. SPONSOR
- 3. MICROSERVIZI: IDEE PER UN’ARCHITETTURA CON AL CENTRO L’UTENTE Federico Carrer Matteo Varotto
- 4. WHO WE ARE? Matteo Varotto QA Architect Quid Informatica Federico Carrer [email protected] MatteoVarotto [email protected] Federico Carrer Cloud Architect Quid Informatica
- 5. GOOD OLD DAYS... ▪ Semplice da comprendere ▪ Semplice da implementare ▪ Semplice da testare
- 7. OGGI Semplice da comprendere Semplice da implementare Semplice da testare Scalabilità limitata Difficile da evolvere Aggiornamenti rischiosi
- 10. MICROSERVIZI ▪ Scomposizione in servizi autonomi e indipendentemente: ▪ scalabili ▪ rilasciabili ▪ evolvibili ▪ testabili ▪ Team indipendenti che lavorano su moduli indipendenti ▪ Problema scomposto in parti più facilmente gestibili ▪ Scalabilità a livello di funzionalità ▪ Stack tecnologico selezionabile per esigenze singolo componente
- 14. WITH GREAT POWER COMES GREAT RESPONSIBILITY Consistenza dei dati Partial Failure Distributed Transaction
- 15. WITH GREAT POWER COMES GREAT RESPONSIBILITY Consistenza dei dati Partial Failure Distributed Transaction Comunicazione asincrona Race conditions
- 16. WITH GREAT POWER COMES GREAT RESPONSIBILITY Consistenza dei dati Partial Failure Distributed Transaction Comunicazione asincrona Race conditions Performance Network latency
- 17. TORNIAMO DAL NOSTRO UTENTE ▪ 503 Service Unavailable ▪ Please wait ▪ Timeout ▪ Session expired
- 18. TORNIAMO DAL NOSTRO UTENTE Cosa percepisce l'utente? ▪ Fragilità del sistema ▪ Lentezza ▪ Scarsa affidabilità
- 19. COSA POSSIAMO FARE? ▪ Limitare le conseguenze ▪ monitoraggio attivo ▪ interventi automatici (restarts, mail a backoffice, ecc.) ▪ circuit breaker ▪ bulkheading
- 20. COSA POSSIAMO FARE? ▪ Limitare le conseguenze ▪ monitoraggio attivo ▪ interventi automatici (restarts, mail a backoffice, ecc.) ▪ circuit breaker ▪ bulkheading ▪ Ridurre l'impatto su UX ▪ caching ▪ architettura ad eventi ▪ layer di resilienza
- 21. COSA POSSIAMO FARE? ▪ Limitare le conseguenze ▪ monitoraggio attivo ▪ interventi automatici (restarts, mail a backoffice, ecc.) ▪ circuit breaker ▪ bulkheading ▪ Ridurre l'impatto su UX ▪ caching ▪ architettura ad eventi ▪ layer di resilienza ▪ Intervenire sui processi ▪ CAP Theorem
- 22. COSA POSSIAMO FARE? ▪ Limitare le conseguenze ▪ monitoraggio attivo ▪ interventi automatici (restarts, mail a backoffice, ecc.) ▪ circuit breaker ▪ bulkheading ▪ Ridurre l'impatto su UX ▪ caching ▪ architettura ad eventi ▪ layer di resilienza ▪ Intervenire sui processi ▪ CAP Theorem Design (for failure)
- 23. ESPERIENZA UTENTE E RESILIENZA All’utente interessa un “sistema che funziona” Disponibile ad esempio al 99,9% Affidabile capace di riprendersi dopo un’anomalia Resiliente capace di funzionare in modo accettabile anche in presenza di qualche malfunzionamento L’utente ci giudica anche in base a come risolviamo i problemi Service Recovery Paradox
- 24. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione REST ?
- 25. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione REST ?
- 26. ESPERIENZA UTENTE E RESILIENZA Retry ?
- 27. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione Event-Driven
- 28. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione Event-Driven
- 29. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione Event-Driven
- 30. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione Event-Driven
- 31. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione Event-Driven
- 32. ESPERIENZA UTENTE E RESILIENZA Pattern di comunicazione Event-Driven
- 35. MONITORAGGIO
- 36. MONITORAGGIO
- 37. MONITORAGGIO
- 38. MONITORAGGIO
- 39. TIMEOUT
- 40. CIRCUIT BREAKER
- 42. CONSISTENZA Sistemi monolitici ACID L’asse del tempo è una retta unica Sistemi distribuiti Difficile garantire consistenza dei dati Ogni componente ha la sua visione del tempo
- 43. THE GUARANTEE THAT ANY TRANSACTIONS STARTED IN THE FUTURE NECESSARILY SEE THE EFFECTS OF OTHER TRANSACTIONS COMMITTED IN THE PAST CONSISTENZA?
- 44. COORDINAMENTO - TWO PHASE COMMIT
- 45. COORDINAMENTO - TWO PHASE COMMIT
- 46. COORDINAMENTO - TWO PHASE COMMIT
- 47. COORDINAMENTO - TWO PHASE COMMIT
- 49. 2PC Scambio di molti messaggi Network latency Throughput limitato Coordinator rappresenta un Single point of failure Protocollo bloccante Se uno dei partecipanti fallisce abbiamo deadlock, non possiamo procedere con altre transazioni
- 50. COME POSSIAMO FARE? Il mondo nel quale viviamo è inconsistente
- 51. COMPENSAZIONE In genere nel mondo reale quando qualcosa non funziona: Ci riprovo Provo ad annullare gli effetti di quello che ho fatto
- 52. COMPENSAZIONE - SAGA Consiste nel riscrivere la nostra transazione “lunga” come una sequenza di transazioni In Saga o tutte le transazioni sono completate con successo oppure vengono eseguite le transazioni di compensazione
- 53. SAGA
- 54. SAGA
- 55. SAGA
- 56. SAGA RINUNCIA A ISOLAMENTO PER OTTENERE UNA MIGLIORE AVAILABILITY
- 57. RINUNCIARE ALL’ISOLAMENTO???? NON SAREBBE MEGLIO AVERE UN SISTEMA CHE GARANTISCA SIA ISOLAMENTO CHE CONSISTENZA?
- 58. COSA VUOLE IL NOSTRO UTENTE? un sistema perfettamente transazionale? che vengano garantite le regole di business dell’applicazione e le invarianti applicative?
- 59. CAP THEOREM Un qualunque sistema distribuito può garantire solo 2 su 3 tra Consistency Availability Partition Tolerance
- 60. CAP THEOREM – PARTIAL KNOWLEDGE In questo momento abbiamo partitioning I messaggi di Catalog non vengono recapitati Cosa possiamo fare? Consistency over Availability Availability over Consistency
- 61. CAP THEOREM – CONSISTENCY OVER AVAILABILITY Potremmo decidere di progettare il sistema per garantire la consistenza In questo caso possiamo scusarci e chiedere all’utente di riprovare più tardi Abbiamo rinunciato alla AVAILABILITY
- 62. CAP THEOREM – AVAILABILITY OVER CONSISTENCY Abbiamo rinunciato alla Consistency In questo caso completo l’ordine anche se non conosco le scorte di magazzino Si tratta di gestire il rischio
- 63. CAP THEOREM – GESTIONE DEL RISCHIO Blocco la possibilità di fare ordini Rischio di bloccare le vendite Non blocco gli ordini Aspetto di ricevere nuove scorte del prodotto prima di spedire Il prodotto è andato fuori commercio e non riesco a reperirlo? Chiedo scusa
- 64. DESIGN FOR FAILURE Partial knowledge spesso ci porta a dover fare scelte basate su conoscenza locale Un sistema distribuito spesso è portato a fare congetture invece che prendere decisioni …congetture che potrebbero essere corrette come no Quindi?
- 65. GRAZIE!