Conception du système WhatsApp : un voyage humoristique à travers une architecture de haut niveau et de bas niveau-javaDidacticiel-php.cn

WhatsApp System Design: A Humorous Journey Through High-Level and Low-Level Architecture

Bienvenue à bord, compagnon de voyage, dans le monde merveilleux et chaotique de WhatsApp System Design ! Cet article démystifiera non seulement l'architecture de haut niveau (HLD) et de bas niveau (LLD) de WhatsApp, mais ajoutera également un peu d'humour (car la conception du système ne doit pas nécessairement être ennuyeuse !) et vous dessinera quelques diagrammes (car nous tous les organigrammes d'amour).

Alors attachez votre ceinture, prenez une tasse de café et embarquons pour un voyage où les serveurs, les bases de données et les protocoles de messagerie s'unissent pour envoyer des milliards de messages sur votre téléphone.

Table des matières:

Architecture de haut niveau (HLD)
Architecture de bas niveau (LLD)
Organigrammes : les héros du design
Répartition des composants de base
Pourquoi ces composants ?
Faits amusants et optimisations spécifiques à WhatsApp

1. Architecture de haut niveau (HLD) : vue d'ensemble

Imaginez WhatsApp comme une symphonie bien orchestrée, mais au lieu de violons, nous avons des serveurs, et au lieu de violoncelles, nous avons des bases de données. À un niveau élevé, nous concevons un système qui prend en charge :

Des milliards d'utilisateurs
Messagerie en temps réel
Partage multimédia
Chiffrement de bout en bout
Haute disponibilité et faible latence (personne n'aime attendre pour "taper...")

Aperçu du HLD :

Chez HLD, nous pensons comme un architecte. Vous ne vous souciez pas encore de la forme de chaque fenêtre, vous voulez juste vous assurer que la maison ne s'effondre pas.

À une vue de 30 000 pieds, l'architecture de WhatsApp se compose de :

Applications clientes (iOS, Android, Web)
Passerelle API
Load Balancers (équilibrant le chaos de millions de messages)
Serveurs d'applications (là où la magie opère)
Couche de base de données (car les données doivent vivre quelque part)
Stockage de fichiers (pour ces GIF de chat)
Files d'attente de messages (systèmes de type Kafka pour la messagerie en temps réel)
Serveurs de notification (je dois vous informer lorsque votre béguin répond)

Éléments fondamentaux du DHN :

Applications client : WhatsApp fonctionne sur les applications mobiles (iOS/Android), Web et de bureau, qui se connectent toutes aux mêmes serveurs backend. Le client est responsable de l'UI/UX, de l'envoi/réception des messages, du cryptage/déchiffrement (nous y reviendrons) et de la reconnexion lorsque votre Wi-Fi décide de prendre une pause-café.
Passerelle API : Il s'agit de l'intermédiaire qui traite les demandes des clients et les transmet au service backend approprié. L'API Gateway vérifie si vous êtes correctement authentifié, enregistre vos demandes de messages et vous envoie au bon serveur.
Équilibreurs de charge : Avec des millions d'utilisateurs en ligne, vous avez besoin d'un chef d'orchestre (ou deux) pour vous assurer qu'aucun serveur ne soit submergé. Les équilibreurs de charge répartissent les requêtes sur de nombreux serveurs d'applications, ce qui évite les surcharges et rend les choses très rapides.
Serveurs d'applications : Ces mauvais garçons sont le cerveau de WhatsApp. Ils traitent les messages, gèrent les sessions utilisateur et effectuent le chiffrement. La clé ici est l’évolutivité ; si plus d'utilisateurs nous rejoignent, nous ajoutons plus de serveurs.
Couche de base de données : Où vont tous vos messages et médias ? C'est là qu'interviennent les bases de données :
- Bases de données NoSQL (Cassandra) : pour stocker des données à grande échelle telles que les profils utilisateur, l'historique des messages, etc.
- Bases de données SQL : dans de rares cas, où des données relationnelles sont requises (comme les dossiers financiers).
Stockage de fichiers : Toutes vos photos, vidéos et notes vocales sont stockées dans des systèmes de stockage de fichiers distribués évolutifs. Pensez à S3 (mais WhatsApp a probablement construit quelque chose de personnalisé, parce qu'ils sont cool comme ça).
Files d'attente de messages (Kafka/Redis) : Pour la messagerie en temps réel, WhatsApp utilise des files d'attente de messages pour gérer la transmission des messages sur différents serveurs. Si un utilisateur est hors ligne, le message est stocké dans une file d'attente jusqu'à son retour.
Serveurs de notifications : Lorsque l'écran de votre téléphone est éteint, WhatsApp envoie une notification via des services tels que les APN (Apple Push Notification Service) et Firebase Cloud Messaging pour Android.

Organigramme DHN :

Voici un organigramme de base pour visualiser l'interaction entre les clients, les services backend et les bases de données dans WhatsApp :

                   +---------------+               +--------------+
Client (Mobile) -->| API Gateway    |---> LB --->   | Application  |
(Client (Web)) --> | (Rate limiting)|               | Servers      |
                   +---------------+               +--------------+
                           |                             |
                           |                             |
                           V                             V
                    +-------------+               +--------------+
                    | Message     |               | Notification |
                    | Queues      |               | Servers      |
                    +-------------+               +--------------+
                           |
                           V
                   +---------------+
                   |   Databases    | (Cassandra, File Storage)
                   +---------------+

Copier après la connexion

2. Architecture de bas niveau (LLD) : les moindres détails

Chez LLD, nous nous concentrons sur la mise en œuvre et les détails techniques des composants individuels. C'est là que nous approfondissons les algorithmes, le partitionnement de bases de données, les méthodes de cryptage et les protocoles réseau.

Concepts clés du LLD :

Système de transmission des messages :
- WhatsApp utilise un protocole XMPP pour la transmission des messages en temps réel. Il s'agit d'un protocole léger et efficace qui gère à la fois la messagerie individuelle et la messagerie de groupe.
- Les messages sont stockés temporairement si le destinataire est hors ligne et remis une fois en ligne.
Cryptage de bout en bout :
Le cryptage de bout en bout de WhatsApp est basé sur le Signal Protocol. L'idée est simple mais géniale :
- Chaque message possède sa propre clé de cryptage unique.
- Ni WhatsApp ni aucun tiers ne peuvent lire vos messages car seuls l'expéditeur et le destinataire détiennent les clés nécessaires.
Si WhatsApp était un roman d'espionnage, le message s'autodétruirait si la mauvaise personne essaie de le lire !
Stockage et réplication des données :
- Cassandra (base de données NoSQL) est utilisée pour stocker les messages de discussion. Pourquoi? Il est distribué, hautement disponible et peut gérer la réplication sur plusieurs centres de données. Cassandra s'assure que même si un serveur tombe en panne (ce qui se produit lorsque les serveurs décident qu'ils ont besoin d'une sieste), les données ne sont pas perdues.
- Les fichiers multimédias (comme les images et les vidéos) sont stockés séparément des messages texte, souvent dans un système de stockage de fichiers basé sur le cloud.
Gestion des utilisateurs hors ligne :
- Si vous envoyez un message et que le destinataire est hors ligne, le message est mis en file d'attente à l'aide d'un système comme Kafka/Redis. C’est comme laisser un message sur la porte de quelqu’un lorsqu’il n’est pas à la maison, sauf que le message est rangé en toute sécurité dans une file d’attente.
Partage de base de données :
- Avec des millions d’utilisateurs, WhatsApp ne peut pas stocker les données de tout le monde dans une base de données géante. Ce serait comme essayer de faire entrer tous les gens du monde dans un seul ascenseur.
- Au lieu de cela, WhatsApp fragmente la base de données. Le partage, c'est comme diviser l'ascenseur en une centaine d'ascenseurs plus petits, chacun responsable de son propre groupe d'utilisateurs.

Organigramme LLD :

Voici un organigramme LLD simplifié axé sur la messagerie en temps réel et les files d'attente de messages :

                   +---------------+               +--------------+
Client (Mobile) -->| API Gateway    |---> LB --->   | Application  |
(Client (Web)) --> | (Rate limiting)|               | Servers      |
                   +---------------+               +--------------+
                           |                             |
                           |                             |
                           V                             V
                    +-------------+               +--------------+
                    | Message     |               | Notification |
                    | Queues      |               | Servers      |
                    +-------------+               +--------------+
                           |
                           V
                   +---------------+
                   |   Databases    | (Cassandra, File Storage)
                   +---------------+

Copier après la connexion

3. Organigrammes : nos héros du design

Ajoutons quelques diagrammes pour que les choses soient très claires. Imaginez les organigrammes comme les plans des architectes ; ils nous aident à comprendre le système visuellement.

Flux d'envoi de messages :

      +------------------+   Send Message   +-------------------+
      | Client App        |---------------->| API Gateway        |
      +------------------+                  +-------------------+
                  |                                  |
                  |         Authenticate User        |
                  V                                  V
          +----------------+                 +------------------+
          | Message Queue   |  <--Store Msg---| Application      |
          | (Kafka/Redis)   |                 | Servers (XMPP)   |
          +----------------+                 +------------------+
                       |                               |
                       |   Offline/Store Msg            |
                       |------------------------------->
                       V
                +-------------+
                |   Database   | (Sharded Cassandra, File Storage)
                +-------------+

Copier après la connexion

Flux de récupération des messages :

Client (Mobile App)
     |
     V
API Gateway  --->  Authenticate ---> Forward to Application Server
     |
     V
Load Balancer ---> Routes to Least Busy Server
     |
     V
Message Queue ---> Holds the message if the user is offline
     |
     V
Database ---> Saves the message for future retrieval

Copier après la connexion

4. Répartition des composants de base

Décomposons plus en détail certains des composants critiques :

XMPP : Le protocole de messagerie utilisé pour envoyer et recevoir des messages en temps réel.
Kafka/Redis : Responsable de la mise en file d'attente des messages lorsque le destinataire est hors ligne.
Cassandra : base de données NoSQL qui stocke les messages, les données utilisateur et l'historique des discussions.
Signal Protocol : alimente le cryptage de bout en bout pour la confidentialité des messages.
Partage : divise la base de données en éléments plus petits et plus faciles à gérer pour gérer des millions d'utilisateurs.

5. Pourquoi ces composants ?

Pourquoi Cassandre ?

Parce que WhatsApp nécessite une haute disponibilité, une faible latence et la capacité de gérer des bases de données distribuées sur plusieurs emplacements, Cassandra est la solution idéale. De plus, il est conçu pour ne jamais tomber en panne, et WhatsApp apprécie cette fiabilité.

Pourquoi XMPP ?

XMPP est léger, efficace et conçu pour la messagerie en temps réel. Parfait pour un système dans lequel vous ne pouvez pas vous permettre d'être en retard, par exemple pour parler à vos amis du film qui commence dans 5 minutes.

Pourquoi Kafka/Redis ?

Les files d'attente de messages garantissent qu'aucun message n'est perdu, même si le destinataire est en vacances dans une zone sans Wi-Fi. Kafka et Redis sont fiables, rapides et évolutifs.

Pourquoi le protocole Signal pour le cryptage ?

WhatsApp ne veut pas lire vos messages (je le promets). Avec le cryptage de bout en bout, ils ne peuvent physiquement pas les lire car seuls vous et votre destinataire possédez les clés.

6. Faits amusants et optimisations spécifiques à WhatsApp

Support multi-appareils : WhatsApp permet aux utilisateurs d'utiliser le même compte sur plusieurs appareils. Cela nécessite une gestion minutieuse des sessions et une synchronisation des messages.
Stockage multimédia efficace : WhatsApp optimise le stockage multimédia en dédupliquant les fichiers multimédias identiques partagés sur différentes discussions (car nous avons tous un ami qui envoie le même mème à chaque groupe).

Conclusion : rassembler tout cela

Alors voilà, une visite guidée de la conception du système de WhatsApp ! Nous avons exploré l'architecture de haut niveau (HLD), approfondi la conception de bas niveau (LLD) et même ajouté un peu d'humour pour rendre le voyage amusant. Des protocoles XMPP aux files d'attente Kafka, en passant par les bases de données Cassandra et le cryptage Signal, WhatsApp est un chef-d'œuvre de messagerie évolutive en temps réel qui maintient nos discussions de groupe vivantes !

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!