Innehållsförteckning[Dölj][Visa]
WhatsApp är ett socialt meddelandeprogram som låter användare utbyta meddelanden med varandra.
Har du någonsin tänkt på hur WhatsApp fungerar?
Vilka är de koncept som ligger till grund för dess tillkomst och drift?
Den här artikeln kommer att gå över grunderna i WhatsApp systemdesign.
Vi kommer också att gå igenom WhatsApps allmänna arkitektur, som kan användas för att bygga vilken typ av chattmjukvara som helst.
Så, utan vidare, låt oss ta en titt på WhatsApps systemdesign!
1. Nyckelkrav
WhatsApp är en mycket skalbar teknik som används av många människor över hela världen. Som ett resultat bör den vara väldesignad för att praktiskt taget alltid vara pålitlig och fungerande.
Som ett resultat är det avgörande att fastställa systemets kritiska behov.
Detta är minimikraven för WhatsApp Messenger:
- Kan underlätta en-till-en-interaktioner.
- Meddelandebekräftelse och senast sett är båda möjliga (skickat, levererat och läst).
- Tillåt end-to-end-kryptering och mediastöd (bilder/videor).
Låt oss ta reda på hur mycket kapacitet vår nödvändiga tjänst kräver.
2. Uppskattning av kapacitet
Vårt mål är att skapa en plattform som kan hantera en stor mängd trafik. Antag att 10 miljarder SMS skickas per dag. Vi har:
- Varje dag skickas 10 miljarder SMS av en miljard människor.
- Vid topptrafik (per sekund) var 700,000 6 personer aktiva (XNUMXX genomsnittet)
- Under maximal användning sänds 40 miljoner meddelanden per sekund.
- Medellängden på ett meddelande är 160 tecken: 10B * 160 = 1.6 TB data genereras varje dag.
- Ta tio års tjänst som exempel: 10 * 1.6B * 365 PB
- Hela applikationen kommer att bestå av mikrotjänster, som var och en kommer att utföra en specialiserad uppgift. Antag att det tar 20 millisekunder att skicka ett meddelande och att det finns 100 samtidiga anslutningar per server. Som ett resultat är det förväntade antalet chattservrar som krävs = (chattmeddelanden per sekund Latency)/ samtidiga anslutningar per server = 40M * 20ms / 100 = 8000 servrar.
3. Högnivåarkitektur
Detta system bygger på två kärntjänster. Chatttjänst och tillfällig tjänst, till exempel. Chatttjänsten hanterar all trafik som genereras av användarnas onlinemeddelanden. Samtidigt hanterar den tillfälliga tjänsten trafik när användaren är offline.
Om användaren är online är det chattjänsten som ansvarar för att leverera meddelanden.
Det kommer att verifiera om meddelandets mottagare är online eller inte; om mottagaren är online kommer denna tjänst att leverera meddelandet omedelbart; om mottagaren inte är online kommer den tillfälliga tjänsten att skicka meddelandet till dem när de återvänder online.
Den tillfälliga tjänsten har ett separat lagringsområde för att lagra tillfälligt tillgänglig data tills offlineanvändaren återansluter.
Designa API:er på hög nivå
Den här tjänsten har två fungerande API:er på hög nivå för att skicka och läsa meddelanden. Systemet kan implementeras med REST-arkitekturen.
Parametrar för att skicka meddelanden
Detta API kommer att användas för att överföra meddelanden mellan två användare.
Konversationsparametrar
Detta API används för att visa trådade chattar. Betrakta detta som det första du ser när du öppnar WhatsApp. Vi vill bara få ett fåtal meddelanden för en användare i en enda API-fråga. För att hantera detta behövs parametrarna för offset och meddelanderäkning.
Vilka funktioner har funktioner som senast sett, enkel tick och dubbel tick?
Den viktiga rollen i utbyggnaden av dessa tjänster är bekräftelsetjänsten. Dessa funktioner utvecklades eftersom den här tjänsten fortsätter att generera och verifiera bekräftelsesvar.
- Enstaka fästing: När ett meddelande från Användare A når Användare B, skickar servern en enda bock som bekräftar att meddelandet har överförts.
- Dubbel bock: Efter att serverns meddelande har skickats till Användare B via rätt anslutning, kommer Användare B att bekräfta mottagandet av meddelandet till servern. Servern kommer sedan att ge Användare A en annan bekräftelse. Som ett resultat kommer en dubblettmarkering att visas.
- bluetick: Användare B kommer att skicka ytterligare en bekräftelse till servern efter att ha kontrollerat meddelandet. Servern kommer sedan att skicka ett ytterligare bekräftelsemeddelande till användare A. En blå bock visas på Användare A:s skärm efter det.
- Senast sett: Hjärtslagsmekanismen är helt ansvarig för den senast visade funktionen. Var 5:e sekund sänds ett hjärtslag till servern, som håller reda på varje användares senast sett status i en tabell som lätt kan nås av alla andra användare.
4. Designa nyckelfunktioner
Personlig interaktion
Detta är en nödvändig del av chatttjänsten. En användare kan helt enkelt skicka meddelanden till en annan användare som använder den här tjänsten. Låt oss ta en titt på hur detta fungerar:
Anta att Jay vill kommunicera med Aayush. Jay är länkad till en chattserver som han tar emot meddelandet med. Jay får en bekräftelse från chattservern att meddelandet skickades. Chattservern begär nu information från datalagret om chattservern som Aayush är ansluten till. Jays chattserver överför nu meddelandet till Aayushs chattserver, och Aayush tar emot meddelandet via en push-mekanism. Aayush skickar nu en bekräftelse till Jays chattserver, som meddelar Jay att meddelandet har levererats. Om Aayush läste meddelandet igen, levererades en ny bekräftelse på att meddelandet hade lästs till Jay.
Status för användaraktivitet
Senast en person var aktiv är ett vanligt inslag i snabbmeddelanden.
Ett system för att upprätthålla en anslutning mellan klienten och servern visas i detta diagram. Webb-sockets användes för att upprätta en dubbelriktad anslutning mellan servern och klienten. Dessa anslutningar skickar hjärtslag, som används för att övervaka användarens aktivitetsstatus.
End-to-end-sekretess
End-to-end-kryptering är en nyckelfunktion som säkerställer att endast de samtalande användarna kan läsa kommunikationen. En offentlig nyckel delas mellan alla användare som är involverade i kommunikationen och är avgörande för att upprätthålla end-to-end-kryptering. Antag att det finns två användare på kanalen, Jay och Aayush, som kommunicerar med varandra.
Jay har Aayushs publika nyckel, och Aayush har Jays publika nyckel såväl som deras icke-delade privata nyckel. Som ett resultat, när Jay sänder meddelandet, krypterar han det med Aayushs publika nyckel, som endast kan avkodas med Aayushs privata nyckel.
På samma sätt kommer Jay bara att kunna avkoda Aayushs kommunikation. Som ett resultat kommer bara Jay och Aaysuh att kunna se varandras kommunikation, och servern kommer bara att fungera som en gateway i hela processen.
5. Flaskhalsar
Varje system är benäget att fungera fel. För att hantera en så stor trafikvolym måste tjänsten alltid vara operativ och feltolerant för att undvika flaskhalsar. Eftersom vår tjänst är helt beroende av chatt- och transientservrar måste vi lösa alla problem som uppstår vid deras drift.
Fel på chattservern: Detta är hjärtat i vårt system. När användare är online ansvarar den för att hantera och leverera meddelanden. Som ett resultat upprätthåller detta system länkar med sina användare.
Som ett resultat, om denna tjänst misslyckas, kommer hela arkitekturen att lida. Det finns två sätt att hantera fel på chattservern. En metod är att flytta TCP-anslutningar till en annan server, medan en annan är att tillåta användare att starta anslutningar automatiskt i händelse av en anslutningsförlust.
Misslyckande med övergående lagring: En annan komponent som är benägen att misslyckas som så småningom kan skada hela tjänsten är övergående lagring. Meddelanden på väg till offlineanvändare går förlorade om den här tjänsten misslyckas.
Vi kan förhindra meddelandeförlust genom att replikera varje användares tillfälliga lagring. Som ett resultat kan repliken användas för att bearbeta funktionerna närhelst användaren återvänder online. Om den ursprungliga servern blir tillgänglig, kombineras både original- och replikinstanserna av användarens tillfälliga lagring till en enda butik.
6. Optimeringstekniker
Latens: För att leverera en sömlös och förbättrad kundupplevelse måste messenger-tjänsten vara i realtid. Som ett resultat måste latensen minskas genom att cachelagra en del av de ofta åtkomliga data. Vi kan cachelagra användaraktivitetsstatus och senaste konversationer i minnet med hjälp av en distribuerad cache som Redis.
Tillgänglighet: Vi behöver vår tjänst vara tillgänglig större delen av tiden. Vårt system måste vara feltolerant, så vi kan behålla flera kopior av tillfälliga meddelanden så att alla meddelanden som går förlorade snabbt kan återställas från dess dubbletter. Som ett resultat kan systemets tillgänglighet inte äventyras.
Slutsats
Vårt system stöder nu bara ett fåtal funktioner, men vi kan enkelt utöka det för att lägga till gruppchattar för att distribuera meddelanden till flera individer. Du kan också tillhandahålla video- och telefonsamtal. Detta system kan också utvecklas så att användare kan publicera statusuppdateringar eller berättelser och läsa varandra.
Jag arbetade hårt för att ge dig en översikt över WhatsApp-systemdesignen på hög nivå. Jag hoppas att du gillade den och kommer att använda den på bästa sätt.
Kommentera uppropet