Содржина[Крие][Прикажи]
WhatsApp е програма за социјални пораки што им овозможува на корисниците да разменуваат пораки еден со друг.
Дали некогаш сте размислувале како функционира WhatsApp?
Кои се концептите кои го поткрепуваат неговото создавање и функционирање?
Оваа статија ќе ги разгледа основите на WhatsApp дизајн на системот.
Ќе ја разгледаме и општата архитектура на WhatsApp, која може да се користи за изградба на секаков вид софтвер за разговор.
Значи, без понатамошно одложување, ајде да го погледнеме дизајнот на системот на WhatsApp!
1. Клучни барања
WhatsApp е високо скалабилна технологија која ја користат многу луѓе ширум светот. Како резултат на тоа, тој треба да биде добро дизајниран за да биде практично секогаш сигурен и да функционира.
Како резултат на тоа, одредувањето на критичните потреби на системот е критично.
Ова се минималните барања за месинџерот WhatsApp:
- Способни за олеснување на интеракции еден на еден.
- Потврда за порака и последен пат се можни (испратени, испорачани и прочитани).
- Дозволете шифрирање од крај до крај и поддршка за медиуми (слики/видеа).
Ајде да дознаеме колкав капацитет бара нашата неопходна услуга.
2. Проценка на капацитетот
Нашата цел е да создадеме платформа способна да управува со голем број сообраќај. Да претпоставиме дека дневно се испраќаат 10 милијарди СМС. Ние го добивме:
- Секој ден, 10 милијарди СМС испраќаат една милијарда луѓе.
- При максимален сообраќај (во секунда), активни биле 700,000 луѓе (6x во просек)
- За време на максималната употреба, 40 милиони пораки се пренесуваат во секунда.
- Просечната должина на пораката е 160 знаци: 10B * 160 = 1.6 TB податоци се генерираат секој ден.
- Земете десет години услуга како пример: 10 * 1.6B * 365 PB
- Целата апликација ќе биде составена од микросервиси, од кои секоја ќе извршува специјализирана задача. Да претпоставиме дека испраќањето порака трае 20 милисекунди и дека има 100 истовремени врски по сервер. Како резултат на тоа, предвидениот број на потребни сервери за разговор = (пораки за разговор во секунда Латентност)/ истовремени врски по сервер = 40M * 20ms / 100 = 8000 сервери.
3. Архитектура на високо ниво
Овој систем е изграден на две основни услуги. Услуга за разговор и преодна услуга, на пример. Услугата за разговор се справува со целиот сообраќај генериран од онлајн пораките на корисниците. Истовремено, привремената услуга се справува со сообраќајот кога корисникот е офлајн.
Доколку корисникот е онлајн, услугата за разговор е задолжена за доставување пораки.
Ќе потврди дали примачот на пораката е онлајн или не; ако примачот е онлајн, оваа услуга веднаш ќе ја достави пораката; ако примачот не е онлајн, преодната услуга ќе му ја испрати пораката кога ќе се вратат онлајн.
Преодната услуга чува посебна област за складирање за чување привремено достапни податоци додека офлајн корисникот повторно не се поврзе.
Дизајнирање на API на високо ниво
Оваа услуга има две функционални API на високо ниво за испраќање и читање пораки. Системот може да се имплементира со користење на REST архитектурата.
Параметри за испраќање пораки
Овој API ќе се користи за пренос на пораки помеѓу двајца корисници.
Параметри на разговор
Овој API се користи за прикажување разговори со нишки. Сметајте дека ова е првото нешто што го гледате кога ќе го отворите WhatsApp. Би сакале да добиеме само неколку пораки за еден корисник во едно барање за API. За да се справите со ова, потребни се параметрите за поместување и број на пораки.
Кои се функциите на карактеристиките како што се последен пат, единечно штиклирање и двојно штиклирање?
Важна улога во распоредувањето на овие услуги е услугата за потврда. Овие функции се развиени бидејќи оваа услуга продолжува да генерира и потврдува одговори за потврда.
- Единечен крлеж: Кога пораката од корисникот А ќе стигне до корисникот Б, серверот испраќа еден штиклирање потврдувајќи дека пораката е пренесена.
- Двоен штиклирајте: Откако пораката на серверот ќе биде испратена до корисникот Б преку соодветната врска, корисникот Б ќе го потврди приемот на пораката до серверот. Серверот потоа ќе му обезбеди на корисникот А уште една потврда. Како резултат на тоа, ќе се појави дупликат крлеж.
- Син крлеж: Корисникот Б ќе испрати уште едно потврда до серверот откако ќе ја провери пораката. Серверот потоа ќе му испрати на корисникот А дополнителна порака за потврда. После тоа, на екранот на корисникот А ќе се појави сино штиклирање.
- Последна активност: Механизмот за отчукување на срцето е целосно одговорен за последната видена карактеристика. На секои 5 секунди, отчукувањето на срцето се пренесува до серверот, кој го следи последниот виден статус на секој корисник во табела до која може лесно да пристапи секој друг корисник.
4. Дизајнирање на клучни карактеристики
Персонализирана интеракција
Ова е неопходен дел од услугата Чет. Корисникот може едноставно да испраќа пораки до друг корисник користејќи ја оваа услуга. Ајде да погледнеме како функционира ова:
Да претпоставиме дека Џеј сака да комуницира со Ајуш. Џеј е поврзан со сервер за разговор со кој ја прима пораката. Џеј добива потврда од серверот за разговор дека пораката е испратена. Серверот за разговор сега бара информации од продавницата за податоци за серверот за разговор на кој е поврзан Aayush. Серверот за разговор на Џеј сега ја пренесува пораката до серверот за разговор на Ајуш, а Ајуш ја прима пораката преку механизам за туркање. Аајуш сега испраќа потврда до серверот за разговор на Џеј, кој го известува Џеј дека пораката е доставена. Ако Ајуш повторно ја прочитал пораката, на Џеј му било доставено ново признание дека пораката е прочитана.
Статус на корисничка активност
Последен пат кога некое лице било активно е редовна карактеристика на инстант-месинџерите.
На овој дијаграм е прикажан систем за одржување на врска помеѓу клиентот и серверот. Веб приклучоците беа користени за воспоставување двонасочна врска помеѓу серверот и клиентот. Овие врски испраќаат отчукувања на срцето, кои се користат за следење на статусот на активност на корисникот.
Приватност од крај до крај
Шифрирањето од крај до крај е клучна карактеристика што гарантира дека само корисниците кои разговараат можат да ги читаат комуникациите. Јавниот клуч се дели меѓу сите корисници вклучени во комуникацијата и е од клучно значење за одржување на шифрирањето од крај до крај. Да претпоставиме дека има двајца корисници на каналот, Џеј и Ајуш, кои комуницираат меѓу себе.
Џеј го има јавниот клуч на Ајуш, а Ајуш го има јавниот клуч на Џеј, како и нивниот незаеднички приватен клуч. Како резултат на тоа, кога Џеј ја пренесува пораката, тој ја шифрира со јавниот клуч на Ајуш, кој може да се дешифрира само со приватниот клуч на Ајуш.
Слично на тоа, Џеј ќе може само да ја декодира комуникацијата на Ајуш. Како резултат на тоа, само Џеј и Ајсух ќе можат да ги гледаат меѓусебните комуникации, а серверот само ќе функционира како порта во целиот процес.
5. Тесни грла
Секој систем е подложен на дефект. За да управува со толку голем обем на сообраќај, услугата мора да остане оперативна и толерантна на грешки во секое време за да избегне тесни грла. Бидејќи нашата услуга е целосно зависна од серверите за разговор и минливи, мора да ги решиме сите проблеми што произлегуваат од нивното работење.
Неуспех на серверот за разговор: Ова е срцето на нашиот систем. Кога корисниците се онлајн, тој е одговорен за управување и доставување пораки. Како резултат на тоа, овој систем одржува врски со своите корисници.
Како резултат на тоа, ако оваа услуга не успее, целата архитектура ќе страда. Постојат два пристапа за управување со неуспехот на серверот за разговор. Еден метод е да се префрлат TCP конекциите на друг сервер, додека друг е да им се овозможи на корисниците автоматски да започнат конекции во случај на губење на врската.
Неуспех на минливо складирање: Друга компонента склона кон дефект што на крајот може да ја оштети целата услуга е минливото складирање. Пораките на пат до офлајн корисници се губат ако оваа услуга не успее.
Можеме да спречиме губење на пораката со реплицирање на привременото складирање на секој корисник. Како резултат на тоа, репликата може да се користи за обработка на функциите секогаш кога корисникот ќе се врати онлајн. Ако оригиналниот сервер стане достапен, и оригиналниот и примерокот на репликата на преодното складирање на корисникот се комбинираат во една продавница.
6. Техники за оптимизација
Латентност: За да се обезбеди беспрекорно и подобрено искуство на клиентот, услугата за месинџер мора да биде во реално време. Како резултат на тоа, доцнењето мора да се намали со кеширање на дел од често пристапуваните податоци. Можеме да го кешираме статусот на корисничката активност и неодамнешните разговори во меморијата користејќи дистрибуирана кеш меморија како Redis.
Достапност: Потребно ни е нашата услуга да биде достапна во поголемиот дел од времето. Нашиот систем мора да биде толерантен за грешки, така што можеме да задржиме неколку копии на преодни пораки, така што секоја порака што е изгубена може брзо да се врати од нејзините дупликати. Како резултат на тоа, достапноста на системот не може да биде загрозена.
Заклучок
Нашиот систем сега поддржува само неколку можности, но можеме лесно да го прошириме за да додадеме групни разговори за да дистрибуираме пораки до неколку поединци. Можете исто така да обезбедите можности за видео и телефонски повици. Овој систем, исто така, може да се развие така што корисниците можат да објавуваат ажурирања на статусот или наративи и да се читаат едни со други.
Работев напорно за да ви дадам преглед на високо ниво на дизајнот на системот WhatsApp. Се надевам дека уживавте и добро ќе го искористите.
Оставете Одговор