Inhoudsopgave[Zich verstoppen][Laten zien]
WhatsApp is een programma voor sociale berichten waarmee gebruikers berichten met elkaar kunnen uitwisselen.
Heb je er ooit over nagedacht hoe WhatsApp werkt?
Wat zijn de concepten die ten grondslag liggen aan de oprichting en werking ervan?
Dit artikel gaat over de basisprincipes van WhatsApp systeem ontwerp.
We zullen ook de algemene architectuur van WhatsApp doornemen, die kan worden gebruikt om elke vorm van chatsoftware te bouwen.
Dus, zonder verder oponthoud, laten we eens kijken naar het systeemontwerp van WhatsApp!
1. Belangrijkste vereisten
WhatsApp is een zeer schaalbare technologie die door veel mensen over de hele wereld wordt gebruikt. Daarom moet het goed ontworpen zijn om vrijwel altijd betrouwbaar en functionerend te zijn.
Daarom is het bepalen van de kritieke behoeften van het systeem van cruciaal belang.
Dit zijn de minimale vereisten voor de WhatsApp-messenger:
- In staat om een-op-een interacties te faciliteren.
- Berichtbevestiging en laatst gezien zijn beide mogelijk (verzonden, afgeleverd en gelezen).
- Sta end-to-end-codering en media-ondersteuning (afbeeldingen/video's) toe.
Laten we eens kijken hoeveel capaciteit onze noodzakelijke service nodig heeft.
2. Capaciteit schatten
Ons doel is om een platform te creëren dat in staat is om een grote hoeveelheid verkeer te verwerken. Stel dat er 10 miljard sms'jes per dag worden verzonden. Wij hebben:
- Elke dag worden er 10 miljard sms'jes verzonden door een miljard mensen.
- Op piekmomenten (per seconde) waren 700,000 mensen actief (6x gemiddeld)
- Tijdens piekgebruik worden er 40 miljoen berichten per seconde verzonden.
- De gemiddelde lengte van een bericht is 160 tekens: 10B * 160 = 1.6TB aan data wordt elke dag gegenereerd.
- Neem als voorbeeld tien dienstjaren: 10 * 1.6B * 365 PB
- De hele applicatie zal bestaan uit microservices, die elk een gespecialiseerde taak zullen uitvoeren. Stel dat het verzenden van een bericht 20 milliseconden duurt en dat er 100 gelijktijdige verbindingen per server zijn. Als gevolg hiervan is het verwachte aantal vereiste chatservers = (chatberichten per seconde Latency) / gelijktijdige verbindingen per server = 40M * 20ms / 100 = 8000 servers.
3. Architectuur op hoog niveau
Dit systeem is gebouwd op twee kernservices. Chatservice en overgangsservice bijvoorbeeld. De chatservice verwerkt al het verkeer dat wordt gegenereerd door de online berichten van gebruikers. Tegelijkertijd verwerkt de tijdelijke service het verkeer wanneer de gebruiker offline is.
Als de gebruiker online is, is de chatservice verantwoordelijk voor het bezorgen van berichten.
Het zal verifiëren of de ontvanger van het bericht online is of niet; als de ontvanger online is, bezorgt deze service het bericht onmiddellijk; als de ontvanger niet online is, stuurt de tijdelijke dienst het bericht naar hen wanneer ze weer online zijn.
De tijdelijke service houdt een apart opslaggebied aan om tijdelijk toegankelijke gegevens te bewaren totdat de offline gebruiker opnieuw verbinding maakt.
Ontwerpen van API's op hoog niveau
Deze service heeft twee goed functionerende API's voor het verzenden en lezen van berichten. Het systeem kan worden geïmplementeerd met behulp van de REST-architectuur.
Parameters voor het verzenden van berichten
Deze API wordt gebruikt om berichten tussen twee gebruikers te verzenden.
Parameters van gesprek
Deze API wordt gebruikt om threaded chats weer te geven. Beschouw dit als het eerste dat je ziet als je WhatsApp opent. We willen maar een paar berichten ontvangen voor één gebruiker in een enkele API-query. Om dit aan te kunnen, zijn de offset- en message count-parameters nodig.
Wat zijn de functies van functies zoals laatst gezien, enkel vinkje en dubbel vinkje?
De belangrijke rol bij de inzet van deze diensten is de bevestigingsdienst. Deze functies zijn ontwikkeld omdat deze service doorgaat met het genereren en verifiëren van bevestigingsantwoorden.
- Enkele tik: Wanneer een bericht van gebruiker A gebruiker B bereikt, stuurt de server een enkel vinkje ter bevestiging dat het bericht is verzonden.
- Dubbel vinkje: Nadat het bericht van de server via de juiste verbinding naar gebruiker B is verzonden, bevestigt gebruiker B de ontvangst van het bericht aan de server. De server zal vervolgens gebruiker A een andere bevestiging geven. Als gevolg hiervan verschijnt er een dubbel vinkje.
- Blauw vinkje: Gebruiker B stuurt nog een bevestiging naar de server nadat hij het bericht heeft gecontroleerd. De server stuurt vervolgens een extra bevestigingsbericht naar gebruiker A. Daarna verschijnt er een blauw vinkje op het scherm van gebruiker A.
- Laatst gezien: Het hartslagmechanisme is volledig verantwoordelijk voor de laatst geziene eigenschap. Elke 5 seconden wordt er een hartslag verzonden naar de server, die de laatst geziene status van elke gebruiker bijhoudt in een tabel die gemakkelijk toegankelijk is voor elke andere gebruiker.
4. Ontwerpen van belangrijke functies
Gepersonaliseerde interactie
Dit is een noodzakelijk onderdeel van de Chat-service. Een gebruiker kan via deze service eenvoudig berichten naar een andere gebruiker sturen. Laten we eens kijken hoe dit werkt:
Stel dat Jay met Aayush wil communiceren. Jay is gekoppeld aan een chatserver waarmee hij het bericht ontvangt. Jay ontvangt een bevestiging van de chatserver dat het bericht is verzonden. De chatserver vraagt nu informatie op bij de datastore over de chatserver waarmee Aayush is verbonden. De chatserver van Jay stuurt het bericht nu door naar de chatserver van Aayush en Aayush ontvangt het bericht via een pushmechanisme. Aayush stuurt nu een bevestiging naar de chatserver van Jay, die Jay laat weten dat het bericht is afgeleverd. Als Aayush het bericht opnieuw las, kreeg Jay een nieuwe bevestiging dat het bericht was gelezen.
Status van gebruikersactiviteit
De laatste keer dat een persoon actief was, is een vast kenmerk van instant messengers.
In dit diagram wordt een systeem weergegeven voor het onderhouden van een verbinding tussen de client en de server. Websockets werden gebruikt om een bidirectionele verbinding tussen de server en de client tot stand te brengen. Deze verbindingen sturen hartslagen, die worden gebruikt om de activiteitsstatus van de gebruiker te controleren.
End-to-end-privacy
End-to-end encryptie is een belangrijk kenmerk dat ervoor zorgt dat alleen de converserende gebruikers de communicatie kunnen lezen. Een openbare sleutel wordt gedeeld door alle gebruikers die betrokken zijn bij de communicatie en is van cruciaal belang voor het behoud van end-to-end-codering. Stel dat er twee gebruikers op het kanaal zijn, Jay en Aayush, die met elkaar communiceren.
Jay heeft de openbare sleutel van Aayush en Aayush heeft zowel de openbare sleutel van Jay als hun niet-gedeelde privésleutel. Als gevolg hiervan, wanneer Jay het bericht verzendt, versleutelt hij het met de openbare sleutel van Aayush, die alleen kan worden gedecodeerd met de privésleutel van Aayush.
Evenzo zal Jay alleen de communicatie van Aayush kunnen decoderen. Als gevolg hiervan kunnen alleen Jay en Aaysuh elkaars communicatie zien en zal de server in het hele proces gewoon als gateway fungeren.
5. Knelpunten
Elk systeem is gevoelig voor storingen. Om zo'n grote hoeveelheid verkeer te beheren, moet de service te allen tijde operationeel en fouttolerant blijven om knelpunten te voorkomen. Omdat onze service volledig afhankelijk is van Chat- en Transient-servers, moeten we alle problemen oplossen die voortvloeien uit hun werking.
Storing van de chatserver: Dit is het hart van ons systeem. Wanneer gebruikers online zijn, is het verantwoordelijk voor het beheren en bezorgen van berichten. Hierdoor onderhoudt dit systeem banden met zijn gebruikers.
Als deze service faalt, zal de hele architectuur eronder lijden. Er zijn twee manieren om het falen van de chatserver te beheren. Eén methode is om TCP-verbindingen naar een andere server te verplaatsen, terwijl een andere is om gebruikers in staat te stellen automatisch verbindingen tot stand te brengen in het geval van een verbindingsverlies.
Falen van tijdelijke opslag: Een ander onderdeel dat gevoelig is voor storingen en uiteindelijk de hele service kan beschadigen, is tijdelijke opslag. Berichten onderweg naar offline gebruikers gaan verloren als deze service uitvalt.
We kunnen berichtverlies voorkomen door de tijdelijke opslag van elke gebruiker te repliceren. Als gevolg hiervan kan de replica worden gebruikt om de functies te verwerken wanneer de gebruiker weer online is. Als de oorspronkelijke server toegankelijk wordt, worden zowel de originele als de replica-exemplaren van de tijdelijke opslag van de gebruiker gecombineerd in één enkele opslag.
6. Optimalisatietechnieken
Wachttijd: Om een naadloze en verbeterde klantervaring te bieden, moet de koeriersdienst real-time zijn. Als gevolg hiervan moet de latentie worden verminderd door een deel van de vaak gebruikte gegevens in de cache op te slaan. We kunnen de status van gebruikersactiviteit en recente gesprekken in het geheugen cachen met behulp van een gedistribueerde cache zoals Redis.
Beschikbaarheid: We hebben onze service nodig om het grootste deel van de tijd beschikbaar te zijn. Ons systeem moet fouttolerant zijn, dus we kunnen meerdere kopieën van tijdelijke berichten bewaren, zodat elk verloren bericht snel kan worden hersteld van de duplicaten. Hierdoor kan de beschikbaarheid van het systeem niet in gevaar komen.
Conclusie
Ons systeem ondersteunt nu slechts een paar mogelijkheden, maar we kunnen het eenvoudig uitbreiden om groepschats toe te voegen om berichten naar meerdere individuen te verspreiden. U kunt ook video- en telefoongesprekken bieden. Dit systeem kan ook zo worden ontwikkeld dat gebruikers statusupdates of verhalen kunnen publiceren en elkaar kunnen lezen.
Ik heb hard gewerkt om je een overzicht op hoog niveau te geven van het WhatsApp-systeemontwerp. Ik hoop dat je ervan genoten hebt en er goed gebruik van zult maken.
Laat een reactie achter