⇧

Dossier d'Architecture logicielle - module Communication - Etude préliminaire

Retour

Projet : Avenirs-ESR / ePortfolio.
Objet : Module Communication - Notifications et temps réel - Etude préliminaire.

Révision : 1.0.1
Date : 25/04/2024
Auteur : A. Deman
Commentaire : Refactoring lors de la mise en oeuvre du syteme de notification et temps réel : séparation des parties etudes préliminaire et mise en oeuvre.**

Contexte

Etude préliminaire sur la faisabilité et les différentes possibilités d’architecture pour la partie notification et temps réel.

Objectifs

Déterminer la faisabilité, les contraintes techniques et servir de point de départ pour la mise en peuvre d’une architecture de notification et temps réel.

Notifications

Une expérimentation a été menée concernant les notifications temps réel autour de Kafka, APISIX et une API développée Java/Spring Boot.
Remarques : les fonctionnalités d’APISIX liées à Kafka sont trop limitées pour notre cas d’utilisation (c.f. GitHub issue).

Communication - Notifications
Communication - Notifications

Modification des données et temps réel

Cas d’usage :

  • prendre en compte au niveau UI des modifications de données, ciblées pour les utilisateurs.
  • au niveau systeme prendre en compte les modifications de privileges par exemple.

Notes : ne couvre pas l’envoi de notification d’utilisateur à utilisateur mais peut servir de mécanisme de base sur lequel appuyer cette fonctionnalité.

Intérêt : Pas de logique à reproduire au niveau des services associés aux features, logique unifiée quel que soit le système qui interragit avec la base de données, couplage fort entre la donnée et le temps réel.

Possibilités de mise en oeuvre

Objectif : rendre Postgres réactive pour pouvoir déclencher des traitements lors de la création/modification/suppression de données en base.

Approches envisagées :

  • Utiliser le mécanisme Notify / Listen. Trop limité pour ce cas d’usage :
    • taille de messages limitée,
    • pas de vérification de livraison,
    • non adapaté à une mise à l’échelle (les perf se dégradent si le volume augmente),
    • mode broadcast uniquement,
    • nécessité de mettre en place des triggers assez complexes pour constituer le paylod,
    • pas de possiblité native de connaitre la valeur précédente pour les modifications/suppression (à gérer dans les triggers si c’est possible).
  • Utiliser Debezium afin de s’appuyer sur le mécanisme de réplication logique de Postgres qui utilise un système de publication/abonnement. Debezium est connecté à postgres et à Kafka pour emettre les changements de données dans les topics spécifiques associés aux tables impliquées. Les topics créés et alimentés pas Debezium sont ensuite consommé soit directement par l’APS de notification soit par Redis ou un équivalent qui va s’interfacer avec l’API de notification. L’intérêt de cette deuxième approche apporte plus de robutesse et de résilience : mise à l’échelle horizontale, possiblité de rejouer les notifications, etc, mais au coût d’une plus grande complexité.
    Remarque : s’il est nécessaire d’avoir les informations concernant les données avant modifications, pour les update et delete, il faut paramétrer postges : 
    ALTER TABLE nom_de_la_table REPLICA IDENTITY DEFAULT;

    En pratique, une ligne en plus est écrite dans le WAL avant d’effectuer la modification, ce qui peut avoir un impacte sur les performances.


Shéma d’architecture

Remarque : L’API Manager n’est pas représenté. Son rôle, dans cette architecture, est à déterminer, notament par rapport au flux SSE.

Notification et temps réel - Architecture sans Redis
Notification et temps réel - Architecture sans Redis


Cette architecture pourrait constituer un point de départ et évoluer enuite vers une architecture plus complète telle que celle représentée ci-dessous.



Notification et temps réel - Architecture avec Redis
Notification et temps réel - Architecture avec Redis


Communication vers le client

L’envoi des notifications vers le client peut se faire par web sockets ou en utilisant les Server-Sent Events

Limitations du SEE par rapport aux web sockets :

  • Unidirectionnel : pas de réponse du client donc mécanisme d’acquitement à prévoir si nécessaire.
  • Transporte uniquement du text (pas de binaire ou de sous protocole).
  • Moins de fonctionnalités (e.g.:négotiation), mais à priori, celles présentes devraient suffire.
  • Un peu plus de latence.

Avantages du SSE par rapport aux web sockets :

  • Protocole http : moins de risque de blockage sur des routeurs, load balancers, etc.
  • Plus légér que les web sockets, en terme de bande passante et de ressources serveur (sur le papier, à confirmer).
    Dans les deux cas, il possible de transmettre un token d’authentification qui pourra être utiliser pour le contôle d’accès et le routage des notifications.

Considérations par rapport à la consomation de ressources :

  • Il pourrait être intéressant de mettre en place des mécanismes qui permettent de limiter les consommations. Exemples :
    • Déconnexion si client inactif pendant n minutes puis reconnexion automatique à la reprise d’activité.
    • Regrouper les notifications.
    • Stratégie de communication en deux temps : notifier le besoin de mise à jour mais sans données et le client effectue ensuite une requête traditionnelle pour récupérer les données.
  • Prévoir une stratégie de repli, par exemple long / short polling.
  • Avoir la possiblité de désactiver complètement le système de notifications sans compromettre le fonctionnement global de l’application.