Зміст[Сховати][Показати]
WhatsApp — це програма для соціальних повідомлень, яка дозволяє користувачам обмінюватися повідомленнями один з одним.
Ви коли-небудь думали, як працює WhatsApp?
Які концепції лежать в основі його створення та функціонування?
У цій статті будуть розглянуті основи WhatsApp проектування системи.
Ми також розглянемо загальну архітектуру WhatsApp, яку можна використовувати для створення будь-якого програмного забезпечення для чату.
Тож, без зайвих розмов, давайте подивимося на дизайн системи WhatsApp!
1. Основні вимоги
WhatsApp – це технологія, яка дуже масштабується, якою користуються багато людей у всьому світі. У результаті він повинен бути добре спроектований, щоб практично завжди був надійним і функціонуючим.
Як наслідок, визначення критичних потреб системи є критичним.
Ось мінімальні вимоги до месенджера WhatsApp:
- Здатний сприяти взаємодії один на один.
- Можливі як підтвердження повідомлення, так і останнє відвідування (Надіслане, Доставлене та Прочитане).
- Дозволити наскрізне шифрування та підтримку медіа (зображення/відео).
Давайте з’ясуємо, скільки потужності потребує наш необхідний сервіс.
2. Оцінка потужності
Наша мета — створити платформу, здатну обробляти великий обсяг трафіку. Припустимо, що в день надсилається 10 мільярдів SMS. У нас є:
- Щодня один мільярд людей надсилає 10 мільярдів SMS.
- У пік трафіку (за секунду) 700,000 6 людей були активними (в середньому в XNUMX разів)
- Під час пікового використання за секунду передається 40 мільйонів повідомлень.
- Середня довжина повідомлення становить 160 символів: 10 Б * 160 = 1.6 ТБ даних генерується щодня.
- Візьмемо для прикладу десять років служби: 10 * 1.6B * 365 PB
- Весь додаток буде складатися з мікросервісів, кожен з яких виконуватиме спеціалізоване завдання. Припустимо, що надсилання повідомлення займає 20 мілісекунд і що на сервер існує 100 одночасних з’єднань. В результаті очікувана кількість необхідних серверів чату = (затримка повідомлень чату за секунду)/ одночасних з’єднань на сервер = 40M * 20ms / 100 = 8000 серверів.
3. Архітектура високого рівня
Ця система побудована на двох основних сервісах. Наприклад, служба чату та тимчасова служба. Сервіс чату обробляє весь трафік, створений онлайн-повідомленнями користувачів. Одночасно тимчасова служба обробляє трафік, коли користувач перебуває в автономному режимі.
Якщо користувач онлайн, то за доставку повідомлень відповідає служба чату.
Він перевірить, чи перебуває одержувач повідомлення в мережі чи ні; якщо одержувач онлайн, цей сервіс доставить повідомлення негайно; якщо одержувач не в мережі, тимчасова служба надішле йому повідомлення, коли вони повернуться онлайн.
Тимчасовий сервіс зберігає окрему область для зберігання тимчасово доступних даних, поки автономний користувач не підключиться знову.
Розробка API високого рівня
Ця служба має два високорівневі функціонуючі API для надсилання та читання повідомлень. Система може бути реалізована за допомогою архітектури REST.
Параметри відправки повідомлень
Цей API буде використовуватися для передачі повідомлень між двома користувачами.
Параметри розмови
Цей API використовується для відображення ланцюжкових чатів. Вважайте, що це перше, що ви бачите, відкриваючи WhatsApp. Ми хотіли б отримати лише кілька повідомлень для одного користувача в одному запиті API. Для цього потрібні параметри зміщення та кількості повідомлень.
Які функції виконують такі функції, як востаннє побачене, одиночна галочка та подвійна галочка?
Важливу роль у розгортанні цих служб грає служба підтвердження. Ці функції були розроблені, оскільки ця служба продовжує генерувати та перевіряти відповіді підтвердження.
- Одинарний галочка: Коли повідомлення від користувача A досягає користувача B, сервер надсилає одну галочку, що підтверджує, що повідомлення було передане.
- Подвійна галочка: Після того, як повідомлення сервера було надіслано користувачеві B через належне з'єднання, користувач B підтвердить отримання повідомлення на сервер. Потім сервер надасть користувачеві А ще одне підтвердження. В результаті з’явиться галочка-дублікат.
- Синій кліщ: Користувач B надішле серверу ще одне підтвердження після перевірки повідомлення. Потім сервер надішле користувачеві A додаткове повідомлення підтвердження. Після цього на екрані користувача A з’явиться синя галочка.
- Останній раз його бачили: Механізм серцебиття повністю відповідає за останню бачену функцію. Кожні 5 секунд на сервер передається пульс, який відстежує останній статус кожного користувача в таблиці, до якої може отримати доступ будь-який інший користувач.
4. Проектування основних функцій
Персоналізована взаємодія
Це необхідна частина сервісу Чат. Користувач може просто надсилати повідомлення іншому користувачеві, використовуючи цю послугу. Давайте подивимося, як це працює:
Припустимо, Джей хоче поспілкуватися з Ааюш. Джей підключений до сервера чату, з яким він отримує повідомлення. Джей отримує підтвердження від сервера чату, що повідомлення було відправлено. Сервер чату тепер запитує інформацію зі сховища даних про сервер чату, до якого підключено Aayush. Сервер чату Джея тепер передає повідомлення на сервер чату Ааюша, а Ааюш отримує повідомлення за допомогою механізму push. Тепер Ааюш надсилає підтвердження на сервер чату Джея, який сповіщає Джея, що повідомлення було доставлено. Якщо Ааюш знову прочитав повідомлення, Джею було доставлено нове підтвердження того, що повідомлення було прочитане.
Статус активності користувача
Останній раз, коли людина була активною, це звичайна функція месенджерів.
На цій схемі зображена система підтримки зв'язку між клієнтом і сервером. Веб-сокети використовувалися для встановлення двонаправленого з'єднання між сервером і клієнтом. Ці з’єднання надсилають серцеві ритми, які використовуються для моніторингу статусу активності користувача.
Наскрізна конфіденційність
Наскрізне шифрування є ключовою функцією, яка гарантує, що лише ті, хто спілкується, можуть прочитати повідомлення. Відкритий ключ використовується всіма користувачами, які беруть участь у спілкуванні, і є критичним для підтримки наскрізного шифрування. Припустимо, що на каналі є два користувачі, Джей і Ааюш, які спілкуються один з одним.
У Джея є відкритий ключ Ааюша, а у Ааюша відкритий ключ Джея, а також їхній незагальний приватний ключ. В результаті, коли Джей передає повідомлення, він шифрує його відкритим ключем Ааюша, який можна розшифрувати лише за допомогою приватного ключа Ааюша.
Аналогічно, Джей зможе лише розшифрувати спілкування Ааюша. В результаті тільки Джей і Айсу зможуть бачити комунікації один одного, а сервер буде просто функціонувати як шлюз у всьому процесі.
5. Вузькі місця
Кожна система схильна до збоїв. Щоб керувати таким великим обсягом трафіку, служба має залишатися працездатною та стійкою до відмов, щоб уникнути вузьких місць. Оскільки наша служба повністю залежить від серверів чату та Transient, ми повинні вирішити всі проблеми, які виникають під час їх роботи.
Збій чат-сервера: Це серце нашої системи. Коли користувачі онлайн, вони відповідають за керування та доставку повідомлень. В результаті ця система підтримує зв’язки зі своїми користувачами.
В результаті, якщо ця служба вийде з ладу, постраждає вся архітектура. Існує два підходи до управління збоєм сервера чату. Один метод полягає в тому, щоб перемістити TCP-з'єднання на інший сервер, а інший - дозволити користувачам автоматично розпочинати з'єднання у разі втрати з'єднання.
Збій тимчасового зберігання: Іншим компонентом, схильним до збою, який може в кінцевому підсумку пошкодити всю службу, є тимчасове сховище. Повідомлення на шляху до офлайн-користувачів втрачаються, якщо ця служба не працює.
Ми можемо запобігти втраті повідомлень, реплікуючи тимчасове сховище кожного користувача. В результаті репліку можна використовувати для обробки функцій щоразу, коли користувач повертається онлайн. Якщо вихідний сервер стає доступним, оригінальний і репліковий екземпляри тимчасового сховища користувача об’єднуються в одне сховище.
6. Методи оптимізації
Затримка: Щоб забезпечити безперебійну та покращену роботу з клієнтами, служба месенджера має працювати в режимі реального часу. В результаті затримка повинна бути зменшена шляхом кешування частини даних, до яких часто звертаються. Ми можемо кешувати статус активності користувача та останні розмови в пам’яті за допомогою розподіленого кешу, такого як Redis.
доступність: Нам потрібно, щоб наша служба була доступна більшу частину часу. Наша система повинна бути відмовостійкою, тому ми можемо зберігати кілька копій тимчасових повідомлень, щоб будь-яке втрачене повідомлення можна було швидко відновити з його дублікатів. Як наслідок, доступність системи не може бути під загрозою.
Висновок
Наша система тепер підтримує лише кілька можливостей, але ми можемо легко розширити її, щоб додати групові чати для розсилання повідомлень кільком особам. Ви також можете надати можливість відео- та телефонних дзвінків. Цю систему також можна розробити так, щоб користувачі могли публікувати оновлення статусу або описи та читати один одного.
Я наполегливо працював, щоб надати вам детальний огляд дизайну системи WhatsApp. Сподіваюся, вам сподобалося і ви використаєте це з користю.
залишити коментар