Une brève présentation de moi-même?: je suis développeur Web indépendant depuis environ un an et demi. Je n’ai jamais envisagé d’écrire un HLD ou un LLD. Au lieu de cela, je me suis concentré sur le développement d'applications basées sur les exigences spécifiques de mes clients. Alors que j'aspire à évoluer vers un environnement d'entreprise, j'ai hate de perfectionner mes compétences et d'acquérir de nouvelles connaissances.

Alors, voici ma tentative d'écriture d'un HLD

Exigences du client??: une application de chat Web E2EE. évolutif jusqu'à 1 000 utilisateurs simultanés à tout moment.

Architecture système

L'application se compose principalement d'un frontend (react), d'un backend (node), d'une base de données (Redis et SQL).

1. FrontEnd?:

   • Ceci gère ce qu'un utilisateur voit
   • Gestion de la connexion utilisateur, enregistrement des utilisateurs.
   • Gestion de l'envoi et de la réception de messages.
   • Conception réactive.

2. BackEnd?:

   • Ceci gère quoi et comment les messages et la connexion sont effectués
   • Responsable de la gestion des connexions/inscriptions
   • Responsable du stockage des messages et des données utilisateur
   • Gère les itinéraires de pages

3. Base de données?:

   • Ceci stocke les messages cryptés et les données utilisateur/informations de connexion

4. Serveur WebSocket?:

   • Un service dédié à la communication bidirectionnelle en temps réel entre les utilisateurs.

5. Couche de mise en cache (Facultatif)?:

   • Utilisez Redis pour mettre temporairement en cache les utilisateurs actifs, les files d'attente de messages ou les statuts en ligne afin d'améliorer les performances.

Débit de haut niveau

1. L'utilisateur se connecte via le frontend → Le backend authentifie l'utilisateur.
2. Le frontend établit une connexion WebSocket au backend pour une communication en temps réel.
3. Lorsqu'un utilisateur envoie un message?:
   • Le serveur WebSocket le re?oit.
   • Il traite et achemine le message vers le(s) destinataire(s) prévu(s).
   • Le backend stocke le message dans la base de données.
4. Le destinataire re?oit le message en temps réel via la connexion WebSocket.

Schéma d'architecture

Flux de données

1. Enregistrer le flux

   • L'utilisateur crée un compte
   • Un hachage public et privé est généré. Le public est stocké dans des bases de données avec les informations utilisateur.
   • En cas de succès?:
     • Un message de réussite
     • Redirection vers la connexion

2. Flux de connexion

   • L'utilisateur est invité à se connecter avec son e-mail et son mot de passe.
   • Le support authentifie les données lors de la saisie.
   • En cas de succès?:
     • Utilisateur à rediriger vers les chats
   • En cas de rejet?:
     • Une fenêtre contextuelle est lancée pour signaler ce qui ne va pas.

3. Flux de messages de la salle

   • L'utilisateur rejoint une salle?:
     • Frontend envoie l'ID de la salle au backend.
     • L'événement joinRoom est modifié dans la salle spécifique.
   • Messages dans la salle :
     • Les messages de Global Room ne sont pas cryptés pour le moment, ils sont simplement partagés et stockés dans la base de données.
     • Remis à tous les participants présents dans la salle en temps réel.

4. Utilisateur - Flux de messages utilisateur

   1. Front-End?:
      • Le frontend crypte le message à l'aide de la clé publique du destinataire.
      • Le message crypté est partagé via socket vers le backend.
   2. Back-End?:
      • Stocke le message dans PSQL
      • Achemine le message vers l'utilisateur à l'aide de l'ID utilisateur
   3. Le front-end des destinataires décrypte le message

Exemples de flux détaillés

Flux de messages directs en temps réel

• Frontend?:
  • L'utilisateur envoie un message à un autre utilisateur via WebSocket.
  • Le message est crypté avec la clé publique du destinataire avant sa transmission.
• Backend?:
  • Le serveur WebSocket re?oit le message chiffré.
  • Le message est stocké dans PostgreSQL avec des métadonnées (par exemple, expéditeur, destinataire, horodatage).
  • Le backend achemine le message chiffré vers la connexion WebSocket du destinataire.
• Frontend des destinataires?:
  • Le message crypté est re?u via WebSocket.
  • La clé privée est utilisée pour décrypter le message.
  • Le message en clair s'affiche dans le chat.

Pile technologique

1. Frontend?:

   • React?: Pour construire l'interface utilisateur (fenêtres de discussion, boutons, zones de saisie).
   • API contextuelle ou Redux?: pour gérer l'état de l'application (par exemple, l'utilisateur actuel, les discussions actives).
   • GSAP?: pour les animations (par exemple, les bulles de discussion glissent en douceur).
   • Client WebSocket?: Pour établir une connexion en temps réel avec le backend.

2. Backend?: Node.js Express.js?:

   • Pour gérer les API REST (pour la connexion, l'enregistrement, la récupération des messages).
   • JWT (JSON Web Tokens)?: pour sécuriser la communication avec une authentification basée sur des jetons.
   • Passport.js?: pour mettre en ?uvre des stratégies d'authentification (par exemple, connexion Google ou Facebook).
   • Socket.IO?: pour gérer les connexions WebSocket pour la messagerie en temps réel.

3. Base de données :

   • PostgreSQL?: pour stocker des données persistantes telles que des profils utilisateur, des messages et des détails sur les salons de discussion.
   • Redis (facultatif)?: pour mettre en cache les données en temps réel (par exemple, les statuts des utilisateurs actifs, les messages récemment envoyés).

4. Hébergement et déploiement?:

   • AWS (EC2, S3, RDS)?: pour héberger le backend, stocker les fichiers statiques et gérer les bases de données.
   • Nginx ou AWS ELB (Load Balancer)?: pour répartir le trafic sur les serveurs backend.

Exigences non fonctionnelles (NFR)

• Performances?:
  • Ciblez une latence des messages en temps réel inférieure à 100?ms.
  • Assurer des opérations de lecture/écriture cohérentes pour 1?000?utilisateurs.
• évolutivité?:
  • Le backend devrait gérer un nombre croissant d'utilisateurs en évoluant horizontalement (par exemple, en utilisant Redis et AWS ELB).
  • Prise en charge de 10 000 connexions WebSocket actives par serveur.
• Disponibilité?:
  • Assurez une disponibilité de 99,9?% grace aux sauvegardes et à la reprise après sinistre.
• Sécurité?:
  • Utilisez E2EE pour la messagerie privée.
  • Utilisez HTTPS pour toutes les données en transit.
  • Assurez-vous que les données au repos sont chiffrées dans PostgresSQL.

Conclusion

La création d'une application de messagerie cryptée de bout en bout, évolutive et sécurisée, nécessite un équilibre réfléchi entre performances, convivialité et sécurité. Grace à cette conception de haut niveau, mon objectif était de démontrer l'architecture et le flux d'un système de messagerie moderne capable de gérer la communication en temps réel tout en garantissant la confidentialité des utilisateurs.

Ce projet met non seulement en valeur des compétences techniques clés telles que React pour le frontend, Node.js pour le backend et PostgreSQL/Redis pour la gestion des données, mais souligne également l'importance de concevoir pour l'évolutivité et la fiabilité.

Si vous êtes un développeur ou un passionné intéressé par la création de systèmes robustes ou par la découverte des architectures de communication en temps réel, j'espère que cet article vous a fourni des informations précieuses.

J'aimerais entendre vos réflexions ou vos commentaires?! N'hésitez pas à vous connecter, partager vos idées ou poser des questions dans la section commentaires. Continuons à apprendre et à construire?!

Restez également à l'écoute pour mon LLD?!

Chaque projet est un pas de plus vers la ma?trise du métier de développement logiciel. Celui-ci m'a appris l'importance d'équilibrer fonctionnalité et évolutivité, et j'ai hate de construire des systèmes encore plus complexes à l'avenir !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!