Загрузка...

How to write scalable web applications

Thread in Web development created by NK_TRIPLLE Mar 11, 2026. (bumped Yesterday at 12:08 PM) 283 views

  1. NK_TRIPLLE
    Как писать веб-приложения, которые не падают под нагрузкой — введение (1/5)
    [IMG]

    Я начинаю небольшой цикл из 5 статей о том, как строить веб-приложения, которые не разваливаются, когда приходит много пользователей.

    Мы поговорим не только о масштабировании, но и о практических вещах, с которыми сталкивается любой разработчик:

    • как правильно масштабировать серверы
    • как тестировать приложение под нагрузкой
    • основы security operations
    • как отслеживать атаки
    • как реагировать на инциденты безопасности

    Цель цикла — показать понятные принципы архитектуры, которые позволяют приложениям работать стабильно даже при большом количестве пользователей.

    В этой первой статье разберём базовые вещи: что такое масштабирование и какие у него виды.

    Когда вы запускаете веб-приложение, сначала всё работает отлично.
    Но со временем появляется больше пользователей.

    В какой-то момент сервер начинает:

    • медленно отвечать
    • падать под нагрузкой
    • или просто перестаёт справляться

    Тогда появляется вопрос: как увеличить мощность системы?

    Существует два основных способа.

    Вертикальное масштабирование — это увеличение мощности одного сервера.

    Проще говоря: если сервер не справляется, мы делаем его сильнее.

    Пример:

    Code

    Было:
    2 CPU
    4 GB RAM

    Стало:
    8 CPU
    32 GB RAM
    или просто переносим приложение на более мощный сервер.

    Простой пример

    Представьте маленький интернет-магазин.

    Сначала на сайт заходит 50 человек в день.
    Обычный сервер справляется без проблем.

    Через несколько месяцев приходит 5000 пользователей.

    Сайт начинает тормозить.

    Самое простое решение — добавить серверу больше RAM и CPU.

    Это и есть вертикальное масштабирование.

    Плюсы

    • очень просто реализовать
    • не требует сложной архитектуры
    • быстрое решение проблемы

    Минусы

    • есть предел мощности
    • мощные серверы стоят дорого
    • Single Point of Failure — если сервер упадёт, упадёт всё приложение

    Горизонтальное масштабирование — это когда мы добавляем больше серверов, а не делаем один сервер мощнее.

    То есть вместо одного большого сервера мы используем несколько обычных серверов.

    Нагрузка распределяется между ними.

    Простой пример

    Представьте кафе.

    Есть один бариста.

    Если приходит 10 клиентов — он справляется.

    Но если приходит 100 клиентов — очередь становится огромной.

    Есть два варианта:

    Вариант 1 — вертикальное масштабирование

    Нанять одного супер-бариста, который работает быстрее.

    Вариант 2 — горизонтальное масштабирование

    Нанять 5 обычных бариста, и каждый обслуживает часть клиентов.

    Очередь исчезает.

    Пример архитектуры:

    Code

    Пользователи


    Load Balancer
    (балансировщик)
    / | \
    / | \
    Server1 Server2 Server3
    Балансировщик нагрузки принимает все запросы пользователей и распределяет их между серверами.

    Пример:

    Code

    User 1 → Server 1
    User 2 → Server 2
    User 3 → Server 3
    User 4 → Server 1
    Если один сервер перегружен — балансировщик отправляет запросы на другой.

    Плюсы

    • высокая отказоустойчивость
    • можно масштабировать почти бесконечно
    • система переживает падение одного сервера

    Пример:

    Code

    Server2 crashed
    Система продолжит работать:

    Code

    Server1
    Server3
    Минусы

    Главная проблема — синхронизация данных между серверами.

    Если несколько серверов работают одновременно, нужно следить, чтобы у всех была одинаковая информация.

    Самые распространённые:

    • репликация
    • шардирование
    • партиционирование

    В этой статье разберём репликацию.

    Репликация — это когда у нас есть несколько серверов с одинаковыми данными.

    Проще говоря — мы создаём копии сервера.

    Пример:

    Code

    Server1
    Server2
    Server3
    Все они содержат одинаковое приложение и одинаковые данные.

    Балансировщик распределяет запросы между ними.

    Представьте популярный новостной сайт.

    В день его читают миллионы пользователей.

    Если использовать один сервер — он просто не выдержит.

    Поэтому запускают несколько одинаковых серверов:

    Code

    news-server-1
    news-server-2
    news-server-3
    news-server-4
    Когда пользователь открывает сайт, балансировщик отправляет его на один из серверов.

    Для пользователя всё выглядит как один сайт, хотя на самом деле работает несколько серверов одновременно.

    1. Снижение нагрузки
    Запросы распределяются между серверами.

    2. Отказоустойчивость
    Если один сервер упадёт, остальные продолжат работать.

    3. Простое масштабирование

    Code

    Server5
    Server6
    4. Географическое распределение

    Серверы можно размещать в разных странах, чтобы пользователи подключались к ближайшему.

    Это уменьшает latency.

    1. Задержка синхронизации

    Иногда данные между серверами обновляются не мгновенно.

    Пример:

    Code

    Пользователь изменил пароль →
    другой сервер узнает об этом через несколько секунд
    2. Сложность архитектуры

    Появляются дополнительные компоненты:

    • балансировщик нагрузки
    • системы мониторинга
    • механизмы failover

    3. Выбор нового главного сервера

    Если основной сервер падает, система должна автоматически выбрать новый главный сервер.

    Когда нагрузка на приложение растёт, рано или поздно приходится решать проблему масштабирования.

    Есть два основных подхода.

    Вертикальное масштабирование

    • увеличиваем мощность одного сервера
    • просто, но имеет предел

    Горизонтальное масштабирование

    • добавляем новые серверы
    • сложнее, но позволяет строить большие и устойчивые системы

    В следующей статье:

    • шардирование
    • партиционирование
    • как крупные сервисы распределяют данные
    • архитектурные ошибки, из-за которых падают системы
     
  2. zalupaSlona
    > как писать масштабируемые веб приложения
    > ни единой строчки кода в статье
    :2011_like:
     
    1. View previous comments (3)
    2. NK_TRIPLLE Topic starter
      avatarжди, нету отдельного раздела про веб разработку
    3. NK_TRIPLLE Topic starter
      avatarжди, с телефона не удобно,ща изменю
  3. always_al
    always_al Mar 18, 2026 0 Mar 17, 2026
    Годно, в крации посвятить человека недалекого от разработки. Чисто поднять понимание структуры происходящего :finger_up:
     
Loading...