Hello !
Suite à ce précédent article je vais aujourd’hui parler gestion des donnés avec des microservices dans Azure Service Fabric.
Cet article est une “réponse” aux questions soulevées ici !
Gestion des données
Il est bien sur possible d’utiliser des bases de données existantes (on prem) et d’héberger tout type de base de données dans Azure si besoin pour répondre aux différentes problématiques Data de vos applicatifs.
- SQL Server
- NoSQL : mongoDB
- MySql
En ce qui concerne la séparation des données par service ASF, il n’y a pas de solutions meilleures qu’une autre. Chaque microservice est responsable de ces données et de leurs cohérences mais il n’y a pas d’obligation de provisionner une base de données pour chaque service. Nos options sont :
- Chaque service à son jeu de tables attribués et ne peut effectuer des opérations CRUD que sur ces tables. Un seul microservice doit avoir accès à une table de la base de données. Il est donc interdit à un service B de réaliser une opération CRUD sur les données dont est responsable le service A.
- Un service pour un schéma de la base.
- Un service : une base de données.
- Découpage lecture/écriture des données avec la mise en oeuvre du pattern CQRS.
L’architecte positionnera en fonction des contraintes et besoins de chaque solution la meilleure gestion de donnée pour le système d’informations.
Gestion des transactions
Les microservices peuvent-ils partager une transaction ?
Si une opération de mon SI nécessite deux microservices, comment font-ils pour se partager la transaction et garantir la cohérence du système en cas d’erreur ? Il faudrait pouvoir faire un rollback en cas d’échec et un commit en cas de succès mais sur les deux services via une même transaction.
Il s’agit d’une problématique purement logicielle à traiter manuellement avec éventuellement :
- Commit en deux étapes : voir MSDN.
- Méthode d’annulation : gestion par le développeur d’une méthode Non A pour chaque méthode A.
Ces deux façons de faire sont compliquées à mettre en œuvre et le risque d’erreur est important … Elles ne sont pas conseillées pour du microservice… Après tout si deux services sont impliqués dans une transaction commune, le découpage en « Bounded Context » de l’approche DDD n’est probablement pas optimal !
Ici nous avons traité de problématiques logicielles qui ne sont pas forcément spécifiques à Service Fabric mais à l’implémentation d’une architecture microservices en général. Il me semblais important d’en parler tout de même.