Compte-rendu de la présentation de Chris Richardson en décembre 2014 lors du hack.summit [video]
- why build event-driven microservices?
- overview of event sourcing
- designing microservices with event sourcing (event sourcing)
- implementing queries in an event sources application (CQRS)
- building and deploying microservices (docker)
Difficile à maintenir, intimidant pour les développeurs, obstacle aux déploiements fréquents, engagement à long terme à des choix de plateforme
solution
Utiliser une architecture basée sur les microservices.
Scalabilité, mise à jour des schémas, maintenir des données semi-structurées
solution
Bases de données NoSQL : empêche les limitations des RDBMS. Par exemple : les recherches plain texte avec Solr/Cloud Search, les données sociales (graphe) avec Neo4J, ... Différents modules de l'application utilise différents types de bases de données. Mais entraine un problème de cohérence des données.
Les transactions métier doivent mettre à jour des données hébergées par de multiples services. Certaines données sont répliquées.
solution
- NoSQL, bases de données dénormalisées, ACID-Free.
- architecture basée sur les événements : les microservices envoient et reçoivent les événements des autres microservices.
To maintain consistency a service must atomically publish an event whenever a domain object changes. Event sourcing solves key data consistency issues with microservices & partitioned SQL/NoSQL databases. Use CQRS to implement materialized views for queries. Docker is a great way to package microservices
Ce qui conduit à l'utilisation de l'event sourcing.
Pour chaque agrégat : identifier les événements métier, définir des classes d'événements. Par exemple, dans une app bancaire ou d'ecommerce :
- Account : AccountOpenedEvent, AccountDebitedEvent, AccountCreditedEvent
- ShoppingCart : ItemAddedEvent, ItemRemovedEvent, OrderPlacedEvent
Au lieu de stocker les données, on stocker les événements. Pour retrouver l'état des données à un moment M, on rejoue tous les événements intervenu jusqu'au moment M. Avec une architecture monolithique, on met à jour les états puis on publie les événements (2 phase commit "2PC"). Avec l'event sourcing, on stocke et publie les événements. Donc atomique.
La suite de la vidéo présente les pros/cons des différentes parties de l'approche que je résume ci-dessous avec des images.
