Je construis une nouvelle application et lisais sur l'architecture des micro-services. L'architecture elle-même a beaucoup de sens du point de vue du développement, du déploiement et de la gestion du cycle de vie. Cependant, un problème est apparu concernant la façon de gérer les données de base.
Par exemple, j'ai 2 applications - disons l'application Sales et une application Ticketing. Supposons que ces deux applications sont conçues comme des micro-services propres. Cependant, ces deux applications, lorsqu'elles sont déployées (en supposant qu'elles sont déployées séparément, par exemple, Sales utilise MongoDB et Ticketing utilise MariaDB), devraient avoir accès aux mêmes instances de données de base, par exemple Comptes, Produits. Cela signifierait qu'il y aurait une application propriétaire pour une entité de données de base donnée (par exemple pour les comptes, il pourrait s'agir de l'application des ventes) et une partie intéressée (par exemple, l'application de billetterie aurait besoin d'avoir des informations sur les comptes).
Cela peut être réalisé de plusieurs manières: - Réplication des données du maître à la partie intéressée - Lecture synchrone de la partie intéressée au maître (la dépendance de synchronisation n'est pas recommandée par le paradigme de l'architecture des micro-services) - Propre référentiel centralisé
Même dans les comptes, il peut y avoir une partie principale commune aux ventes et à la billetterie (par exemple, nom du compte, adresse, etc.). Cependant, certains aspects du compte peuvent être UNIQUEMENT pertinents pour les ventes et d'autres uniquement pour la billetterie.
Avez-vous des réflexions / meilleures pratiques / opinions concernant l'une des options mentionnées ci-dessus?