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