Epic 2 : Gestion de la persistance des données Zéphir

Identifier les données devant être persistantes “à long terme”.

Contexte

Définir un modèle de données pour gérer la persistance des données communes à l’ensemble des microservices.

Environnement

  • le serveur Zéphir

Explication

Dans l’application, nous devons gérer :

  • des utilisateurs, leurs droits, leurs rôles

  • des serveurs avec leurs sites, leurs zones, leurs machines. Ces éléments seront regroupés dans des ‘conteneurs’ (UO) permettant de déléguer la gestion de l’ensemble des objets à des rôles.

  • des modèles de configuration (module, variante, service applicatifs). Ces modèles seront :

    • soit modèles EOLE (et mis à jour par EOLE),
    • soit des spécialisations des modèles EOLE,
    • soit des spécialisations de spécialisation.
  • un serveur sera relié à un modèle de configuration

  • un modèle de configuration n’est pas obligatoirement un “module EOLE”. Nous pouvons gérer des serveurs sous un OS non Ubuntu (ex: Centos)

  • le schéma de données devra être multi-version EOLE.

  • Un micro service de mise à jour de la BD sera en charge des modifications

Problématique du partage des données (micro services)

Deux solutions sont envisagées concernant la gestion des données dans l’architecture

  • Une base de données ‘globale’ contient l’ensemble des informations (Database per service), celle-ci étant accessible par l’ensemble des micro services.

    Avantages :
    • Pas besoin de passer par le bus de message pour récupérer les données.
    • pas de problème pour effectuer des requêtes croisées.
    • intégrité de la base plus facile à assurer (transactions possibles).
    Inconvénients :
    • Une modification du schéma de la base peut impacter l’ensemble des micro services.
  • Chaque micro service gère ses propres données (Pattern: Shared database). Ne présage pas de la séparation des données (tables ou bases séparées, ...).

    Avantages :
    • Chaque micro service peut faire évoluer son schéma de données sans impacter les autres.
    • Possibilité d’utiliser des moteurs de stockage différents selon les besoins.
    Inconvénients :
    • Demande de faire passer les données par des messages entre micro services.
    • Maintenir l’intégrité des données est plus compliqué (évènements si changement, ...).
    • Les requêtes sur des données de plusieurs services sont plus complexes (jointures).

Diagramme de classes

Le fichier de référence est créé avec l’outil Dia (en mode non zippé). Il s’agit du fichier ModelZephir.dia