INHOUDSOPGAWE[Versteek][Wys]
WhatsApp is 'n sosiale boodskapprogram waarmee gebruikers boodskappe met mekaar kan uitruil.
Het jy al ooit oorweeg hoe WhatsApp werk?
Wat is die konsepte wat die skepping en werking daarvan onderlê?
Hierdie artikel gaan oor die basiese beginsels van WhatsApp stelsel ontwerp.
Ons gaan ook deur WhatsApp se algemene argitektuur, wat gebruik kan word om enige soort kletssagteware te bou.
So, sonder meer, kom ons kyk na WhatsApp se stelselontwerp!
1. Sleutelvereistes
WhatsApp is 'n hoogs skaalbare tegnologie wat deur baie mense regoor die wêreld gebruik word. Gevolglik moet dit goed ontwerp wees om feitlik altyd betroubaar en funksionerend te wees.
Gevolglik is die bepaling van die sisteem se kritieke behoeftes van kritieke belang.
Dit is die minimum vereistes vir die WhatsApp-boodskapper:
- In staat om een-tot-een interaksies te fasiliteer.
- Boodskaperkenning en laas gesien is albei moontlik (gestuur, afgelewer en gelees).
- Laat end-tot-end-enkripsie en media-ondersteuning (prente/video's) toe.
Kom ons vind uit hoeveel kapasiteit ons nodige diens vereis.
2. Skatting van Kapasiteit
Ons doelwit is om 'n platform te skep wat 'n groot hoeveelheid verkeer kan hanteer. Aanvaar dat 10 miljard SMS'e per dag gestuur word. Ons het:
- Elke dag word 10 miljard SMS'e deur een miljard mense gestuur.
- Tydens spitsverkeer (per sekonde) was 700,000 6 mense aktief (XNUMXx gemiddeld)
- Tydens spitsgebruik word 40 miljoen boodskappe per sekonde versend.
- Die gemiddelde lengte van 'n boodskap is 160 karakters: 10B * 160 = 1.6TB data word elke dag gegenereer.
- Neem tien jaar diens as 'n voorbeeld: 10 * 1.6B * 365 PB
- Die hele toepassing sal uit mikrodienste bestaan, wat elkeen 'n gespesialiseerde taak sal uitvoer. Aanvaar dat die stuur van 'n boodskap 20 millisekondes neem en dat daar 100 gelyktydige verbindings per bediener is. As gevolg hiervan, die verwagte aantal kletsbedieners benodig = (kletsboodskappe per sekonde Latency)/ gelyktydige verbindings per bediener = 40M * 20ms / 100 = 8000 bedieners.
3. Hoëvlak argitektuur
Hierdie stelsel is gebou op twee kerndienste. Kletsdiens en verbygaande diens, byvoorbeeld. Die kletsdiens hanteer al die verkeer wat deur gebruikers se aanlynboodskappe gegenereer word. Terselfdertyd hanteer die tydelike diens verkeer wanneer die gebruiker vanlyn is.
As die gebruiker aanlyn is, is die kletsdiens in beheer van die aflewering van boodskappe.
Dit sal verifieer of die boodskap se ontvanger aanlyn is of nie; indien die ontvanger aanlyn is, sal hierdie diens die boodskap onmiddellik lewer; as die ontvanger nie aanlyn is nie, sal die tydelike diens die boodskap aan hulle stuur wanneer hulle aanlyn terugkeer.
Die tydelike diens hou 'n aparte stoorarea om tydelik toeganklike data te hou totdat die vanlyn gebruiker weer koppel.
Ontwerp hoëvlak-API's
Hierdie diens het twee hoëvlak funksionerende API's vir die stuur en lees van boodskappe. Die stelsel kan geïmplementeer word deur die REST-argitektuur te gebruik.
Parameters vir die stuur van boodskappe
Hierdie API sal gebruik word om boodskappe tussen twee gebruikers oor te dra.
Parameters van gesprek
Hierdie API word gebruik om skroefkletse te vertoon. Beskou dit as die eerste ding wat jy sien wanneer jy WhatsApp oopmaak. Ons wil net 'n paar boodskappe vir een gebruiker in 'n enkele API-navraag kry. Om dit te hanteer, is die afset- en boodskaptellingparameters nodig.
Wat is die funksies van kenmerke soos laas gesien, enkelmerk en dubbelmerk?
Die belangrike rol in die ontplooiing van hierdie dienste is die erkenningsdiens. Hierdie kenmerke is ontwikkel aangesien hierdie diens voortgaan om erkenningsantwoorde te genereer en te verifieer.
- Enkelbosluis: Wanneer 'n boodskap van Gebruiker A Gebruiker B bereik, stuur die bediener 'n enkele regmerkie wat erken dat die boodskap versend is.
- Dubbelmerk: Nadat die bediener se boodskap aan Gebruiker B gestuur is deur die regte verbinding, sal Gebruiker B ontvangs van die boodskap aan die bediener erken. Die bediener sal dan vir Gebruiker A nog 'n erkenning gee. As gevolg hiervan, sal 'n duplikaat regmerkie verskyn.
- Blou bosluis: Gebruiker B sal nog 'n erkenning aan die bediener stuur nadat hy die boodskap nagegaan het. Die bediener sal dan vir Gebruiker A 'n bykomende erkenningsboodskap stuur. 'n Blou regmerkie sal daarna op Gebruiker A se skerm verskyn.
- Laas gesien: Die hartklopmeganisme is heeltemal verantwoordelik vir die laaste gesien kenmerk. Elke 5 sekondes word 'n hartklop na die bediener oorgedra, wat rekord hou van elke gebruiker se laas gesien status in 'n tabel wat maklik deur enige ander gebruiker verkry kan word.
4. Ontwerp sleutelkenmerke
Persoonlike interaksie
Dit is 'n noodsaaklike deel van die Chat-diens. 'n Gebruiker kan eenvoudig boodskappe aan 'n ander gebruiker stuur deur hierdie diens te gebruik. Kom ons kyk hoe dit werk:
Gestel Jay wil met Aayush kommunikeer. Jay is gekoppel aan 'n kletsbediener waarmee hy die boodskap ontvang. Jay ontvang bevestiging van die kletsbediener dat die boodskap versend is. Die kletsbediener versoek nou inligting van die datastoor oor die kletsbediener waaraan Aayush gekoppel is. Jay se kletsbediener stuur nou die boodskap na Aayush se kletsbediener, en Aayush ontvang die boodskap via 'n drukmeganisme. Aayush stuur nou 'n erkenning aan Jay se kletsbediener, wat Jay in kennis stel dat die boodskap afgelewer is. As Aayush die boodskap weer lees, is 'n nuwe erkenning dat die boodskap gelees is, aan Jay afgelewer.
Status van gebruikeraktiwiteit
Die laaste keer dat 'n persoon aktief was, is 'n gereelde kenmerk van kitsboodskappers.
'n Stelsel vir die handhawing van 'n verbinding tussen die kliënt en die bediener word in hierdie diagram uitgebeeld. Websockets is gebruik om 'n tweerigtingverbinding tussen die bediener en die kliënt te vestig. Hierdie verbindings stuur hartklop, wat gebruik word om die gebruiker se aktiwiteitstatus te monitor.
Einde-tot-einde privaatheid
End-tot-end-enkripsie is 'n sleutelkenmerk wat verseker dat slegs die gespreksgebruikers die kommunikasie kan lees. 'n Publieke sleutel word gedeel tussen alle gebruikers wat by die kommunikasie betrokke is en is van kritieke belang vir die handhawing van End-to-End-enkripsie. Aanvaar dat daar twee gebruikers op die kanaal is, Jay en Aayush, wat met mekaar kommunikeer.
Jay het Aayush se publieke sleutel, en Aayush het Jay se publieke sleutel sowel as hul nie-gedeelde private sleutel. As gevolg hiervan, wanneer Jay die boodskap oordra, enkripteer hy dit met Aayush se publieke sleutel, wat slegs met Aayush se private sleutel gedekodeer kan word.
Net so sal Jay net Aayush se kommunikasie kan dekodeer. Gevolglik sal slegs Jay en Aaysuh mekaar se kommunikasie kan sien, en die bediener sal net as 'n poort in die hele proses funksioneer.
5. Knelpunte
Elke stelsel is geneig tot wanfunksionering. Om so 'n groot volume verkeer te bestuur, moet die diens te alle tye operasioneel en foutverdraagsaam bly om bottelnekke te vermy. Omdat ons diens geheel en al afhanklik is van Chat en Transient-bedieners, moet ons al die probleme oplos wat uit hul werking voortspruit.
Mislukking van die kletsbediener: Dit is die hart van ons stelsel. Wanneer gebruikers aanlyn is, is dit verantwoordelik vir die bestuur en aflewering van boodskappe. Gevolglik behou hierdie stelsel skakels met sy gebruikers.
As gevolg hiervan, as hierdie diens misluk, sal die hele argitektuur daaronder ly. Daar is twee benaderings om die mislukking van die kletsbediener te bestuur. Een metode is om TCP-verbindings na 'n ander bediener te verskuif, terwyl 'n ander een is om gebruikers toe te laat om verbindings outomaties te begin in die geval van 'n verbindingsverlies.
Mislukking van verbygaande berging: Nog 'n komponent wat geneig is tot mislukking wat uiteindelik die hele diens kan beskadig, is verbygaande berging. Boodskappe op pad na vanlyn gebruikers gaan verlore as hierdie diens misluk.
Ons kan boodskapverlies voorkom deur elke gebruiker se tydelike berging te repliseer. As gevolg hiervan kan die replika gebruik word om die funksies te verwerk wanneer die gebruiker aanlyn terugkeer. As die oorspronklike bediener toeganklik word, word beide die oorspronklike en replika-gevalle van die gebruiker se verbygaande berging in 'n enkele winkel gekombineer.
6. Optimaliseringstegnieke
latency: Om 'n naatlose en verbeterde kliëntervaring te lewer, moet die boodskapperdiens intyds wees. Gevolglik moet latensie verminder word deur 'n gedeelte van die data wat dikwels toegang verkry word, te kas. Ons kan gebruikeraktiwiteitstatus en onlangse gesprekke in die geheue kas deur 'n verspreide kas soos Redis te gebruik.
Beskikbaarheid : Ons het ons diens nodig om die meeste van die tyd beskikbaar te wees. Ons stelsel moet foutverdraagsaam wees, dus kan ons verskeie kopieë van verbygaande boodskappe hou sodat enige boodskap wat verlore gaan, vinnig uit sy duplikate herwin kan word. Gevolglik kan die stelsel se beskikbaarheid nie in gevaar gestel word nie.
Gevolgtrekking
Ons stelsel ondersteun nou net 'n paar vermoëns, maar ons kan dit maklik uitbrei om groepkletse by te voeg om boodskappe na verskeie individue te versprei. Jy kan ook video- en telefoonoproepvermoëns verskaf. Hierdie stelsel kan ook so ontwikkel word dat gebruikers statusopdaterings of narratiewe kan publiseer en mekaar kan lees.
Ek het hard gewerk om vir jou 'n hoëvlakoorsig van die WhatsApp-stelselontwerp te gee. Ek hoop jy het dit geniet en sal dit goed gebruik.
Lewer Kommentaar