Eine kurze Vorstellung zu mir selbst: Ich bin seit ca. 1,5 Jahren freiberuflicher Webentwickler. Ich habe nie darüber nachgedacht, ein HLD oder ein LLD zu schreiben. Stattdessen habe ich mich auf die Entwicklung von Anwendungen konzentriert, die auf den spezifischen Anforderungen meiner Kunden basieren. Da ich den übergang in ein Unternehmensumfeld anstrebe, bin ich bestrebt, meine F?higkeiten zu verbessern und neues Wissen zu erwerben.

Hier ist also mein Versuch, ein HLD zu schreiben

Kundenanforderungen?: Eine webbasierte E2EE-Chat-App. Skalierbar auf bis zu 1000 gleichzeitige Benutzer gleichzeitig.

Systemarchitektur

Die App besteht haupts?chlich aus einem Frontend (Reagieren), einem Backend (Knoten) und einer Datenbank (Redis und SQL).

1. FrontEnd:

   • Hier wird verwaltet, was ein Benutzer sieht
   • Verwaltung der Benutzeranmeldung und Benutzerregistrierung.
   • Verwaltung des Sendens und Empfangens von Nachrichten.
   • Responsives Design.

2. BackEnd:

   • Hier wird verwaltet, was und wie die Nachrichten und die Anmeldung erfolgen
   • Verantwortlich für die Verwaltung der Anmeldung/Registrierung
   • Verantwortlich für die Speicherung von Nachrichten und Benutzerdaten
   • Verwaltet Seitenrouten

3. Datenbank:

   • Hier werden die verschlüsselten Nachrichten und Benutzerdaten/Anmeldeinformationen gespeichert

4. WebSocket-Server:

   • Ein dedizierter Dienst für die bidirektionale Echtzeitkommunikation zwischen Benutzern.

5. Caching-Ebene (Optional):

   • Verwenden Sie Redis zum vorübergehenden Zwischenspeichern aktiver Benutzer, Nachrichtenwarteschlangen oder Online-Status, um die Leistung zu verbessern.

Hoher Durchfluss

1. Benutzer meldet sich über das Frontend an → Backend authentifiziert den Benutzer.
2. Frontend stellt eine WebSocket-Verbindung zum Backend für Echtzeitkommunikation her.
3. Wenn ein Benutzer eine Nachricht sendet:
   • Der WebSocket-Server empf?ngt es.
   • Es verarbeitet die Nachricht und leitet sie an den/die vorgesehenen Empf?nger weiter.
   • Das Backend speichert die Nachricht in der Datenbank.
4. Der Empf?nger erh?lt die Nachricht in Echtzeit über die WebSocket-Verbindung.

Architekturdiagramm

Datenfluss

1. Flow registrieren

   • Benutzer erstellt ein Konto
   • Ein ?ffentlicher und ein privater Hash werden generiert. Der ?ffentliche Hash wird zusammen mit den Benutzerinformationen in Datenbanken gespeichert.
   • Bei Erfolg:
     • Eine Erfolgsmeldung
     • Zur Anmeldung weiterleiten

2. Anmeldeablauf

   • Der Benutzer wird aufgefordert, sich mit E-Mail und Passwort anzumelden.
   • Die gesicherten Daten werden bei der Eingabe authentifiziert.
   • Bei Erfolg:
     • Benutzer wird zu Chats weitergeleitet
   • Bei Ablehnung:
     • Es wird ein Popup eingeleitet, das Sie über den Fehler informiert.

3. Raumnachrichtenfluss

   • Benutzer tritt einem Raum bei:
     • Frontend sendet die Raum-ID an Backend.
     • joinRoom-Ereignis wird für den spezifischen Raum bearbeitet.
   • Nachrichten im Raum:
     • Globale Raumnachrichten sind derzeit nicht verschlüsselt, sie werden nur geteilt und in der Datenbank gespeichert.
     • Wird in Echtzeit an alle Teilnehmer im Raum geliefert.

4. Benutzer – Benutzernachrichtenfluss

   1. Frontend:
      • Das Frontend verschlüsselt die Nachricht mit dem ?ffentlichen Schlüssel des Empf?ngers.
      • Die verschlüsselte Nachricht wird über einen Socket an das Backend weitergegeben.
   2. Backend:
      • Speichert die Nachricht in PSQL
      • Leitet die Nachricht mithilfe der Benutzer-ID an den Benutzer weiter
   3. Das Frontend des Empf?ngers entschlüsselt die Nachricht

Detaillierte Beispielabl?ufe

Direktnachrichtenfluss in Echtzeit

• Frontend:
  • Benutzer sendet über WebSocket eine Nachricht an einen anderen Benutzer.
  • Die Nachricht wird vor der übertragung mit dem ?ffentlichen Schlüssel des Empf?ngers verschlüsselt.
• Backend:
  • Der WebSocket-Server empf?ngt die verschlüsselte Nachricht.
  • Die Nachricht wird in PostgreSQL mit Metadaten (z. B. Absender, Empf?nger, Zeitstempel) gespeichert.
  • Das Backend leitet die verschlüsselte Nachricht an die WebSocket-Verbindung des Empf?ngers weiter.
• Empf?nger-Frontend:
  • Die verschlüsselte Nachricht wird über WebSocket empfangen.
  • Der private Schlüssel wird zum Entschlüsseln der Nachricht verwendet.
  • Die Klartextnachricht wird im Chat angezeigt.

Tech Stack

1. Frontend:

   • Reagieren: Um die Benutzeroberfl?che zu erstellen (Chatfenster, Schaltfl?chen, Eingabefelder).
   • Kontext-API oder Redux: Zum Verwalten des App-Status (z. B. aktueller Benutzer, aktive Chats).
   • GSAP: Für Animationen (z. B. flie?end hineingleitende Chat-Blasen).
   • WebSocket-Client: Zum Herstellen einer Echtzeitverbindung mit dem Backend.

2. Backend:Node.js Express.js:

   • Zur Handhabung von REST-APIs (zum Anmelden, Registrieren, Abrufen von Nachrichten).
   • JWT (JSON Web Tokens): Zur Sicherung der Kommunikation mit tokenbasierter Authentifizierung.
   • Passport.js: Zur Implementierung von Authentifizierungsstrategien (z. B. Google- oder Facebook-Login).
   • Socket.IO: Zur Handhabung von WebSocket-Verbindungen für Echtzeit-Messaging.

3. Datenbank:

   • PostgreSQL: Zum Speichern persistenter Daten wie Benutzerprofile, Nachrichten und Chatroom-Details.
   • Redis (optional): Zum Zwischenspeichern von Echtzeitdaten (z. B. aktive Benutzerstatus, kürzlich gesendete Nachrichten).

4. Hosting und Bereitstellung:

   • AWS (EC2, S3, RDS): Zum Hosten des Backends, Speichern statischer Dateien und Verwalten von Datenbanken.
   • Nginx oder AWS ELB (Load Balancer): Um den Datenverkehr auf Backend-Server zu verteilen.

Nichtfunktionale Anforderungen (NFRs)

• Leistung:
  • Ziel ist eine Echtzeit-Nachrichtenlatenz von weniger als 100 ms.
  • Stellen Sie konsistente Lese-/Schreibvorg?nge für 1.000 Benutzer sicher.
• Skalierbarkeit:
  • Das Backend sollte eine wachsende Anzahl von Benutzern durch horizontale Skalierung bew?ltigen (z. B. Verwendung von Redis und AWS ELB).
  • Unterstützt 10.000 aktive WebSocket-Verbindungen pro Server.
• Verfügbarkeit:
  • Stellen Sie mit Backups und Notfallwiederherstellung eine Verfügbarkeit von 99,9 % sicher.
• Sicherheit:
  • Verwenden Sie E2EE für private Nachrichten.
  • Verwenden Sie HTTPS für alle Daten w?hrend der übertragung.
  • Stellen Sie sicher, dass ruhende Daten in PostgresSQL verschlüsselt sind.

Zusammenfassung

Der Aufbau einer skalierbaren und sicheren Ende-zu-Ende-verschlüsselten Messaging-Anwendung erfordert ein durchdachtes Gleichgewicht zwischen Leistung, Benutzerfreundlichkeit und Sicherheit. Mit diesem High-Level-Design wollte ich die Architektur und den Ablauf eines modernen Nachrichtensystems demonstrieren, das in der Lage ist, Echtzeitkommunikation zu handhaben und gleichzeitig die Privatsph?re der Benutzer zu gew?hrleisten.

Dieses Projekt zeigt nicht nur wichtige technische F?higkeiten wie React für das Frontend, Node.js für das Backend und PostgreSQL/Redis für die Datenverwaltung, sondern unterstreicht auch die Bedeutung des Designs für Skalierbarkeit und Zuverl?ssigkeit.

Wenn Sie ein Entwickler oder Enthusiast sind, der daran interessiert ist, robuste Systeme zu erstellen oder mehr über Echtzeit-Kommunikationsarchitekturen zu erfahren, hoffe ich, dass dieser Artikel wertvolle Erkenntnisse liefert.

Ich würde gerne Ihre Gedanken oder Ihr Feedback h?ren! Fühlen Sie sich frei, sich zu vernetzen, Ihre Ideen zu teilen oder Fragen im Kommentarbereich zu stellen. Lasst uns weiter lernen und aufbauen!

Bleiben Sie auch gespannt auf mein LLD!

Jedes Projekt ist ein Schritt n?her an der Beherrschung des Handwerks der Softwareentwicklung. Dadurch habe ich gelernt, wie wichtig es ist, Funktionalit?t und Skalierbarkeit in Einklang zu bringen, und ich freue mich darauf, in Zukunft noch komplexere Systeme zu entwickeln!

Das obige ist der detaillierte Inhalt vonEnd-to-End-verschlüsselte Messaging-App: Design und Architektur auf h?chstem Niveau. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!