Java Разработка | Spring Boot Backend & Architecture. Программирование на Джава для Developer. IT Собеседования, Алгоритмы и Coding задачи. Уроки и курсы для роста в Tech.

@bookjava

От 1 до миллиона пользователей (Масштабирование) Представьте: вы написали крутой стартап. Он крутится на дешевом сервере за $5 в месяц. База данных, бэкенд и фронтенд лежат в одном месте. Вдруг о вас снимает ролик популярный блогер. Трафик вырастает в 10,000 раз. Сервер ложится через 3 секунды от OutOfMemoryError. Бизнес теряет деньги. Что делать? У вас есть два пути масштабирования (Scaling). 📈 1. Вертикальное масштабирование (Scale Up) Это самый простой и интуитивный подход. Сервер не справляется? Давайте купим сервер мощнее! Было 2 ГБ оперативки - поставим 128 ГБ. Был 1 ядерный процессор - купим 64-ядерный. 🔴 Плюсы: Не нужно менять ни строчки кода. Всё просто работает быстрее. 🔴 Минусы: 1. Физический предел. Вы не можете купить сервер с бесконечной памятью. Самый мощный сервер рано или поздно закончится. 2. SPOF (Single Point of Failure). Единая точка отказа. Каким бы мощным ни был сервер, если уборщица выдернет шнур питания в дата-центре - ваш бизнес остановится. 🌐 2. Горизонтальное масштабирование (Scale Out) Это путь настоящих джедаев и BigTech-компаний. Вместо покупки одного суперкомпьютера за миллион долларов, мы покупаем 1000 дешевых обычных серверов и заставляем их работать вместе. 🔴 Плюсы: Масштабирование практически бесконечно. Упал один сервер? Ничего страшного, трафик подхватят остальные 999. 🔴 Минусы: Архитектура становится в разы сложнее. Появляется куча новых проблем: как делить трафик, как синхронизировать данные, как хранить сессии. ⚖️ 3. Балансировщик нагрузки (Load Balancer) Допустим, мы выбрали горизонтальное масштабирование и запустили 5 одинаковых серверов с нашим Spring Boot приложением. Но пользователи (клиенты) знают только один домен: mysite.com. Как сделать так, чтобы запросы распределялись между этими пятью серверами равномерно? Перед нашими серверами встает Load Balancer (Балансировщик) - например, Nginx, HAProxy или облачный AWS ALB. Пользователь стучится в Балансировщик, а тот перенаправляет запрос на наименее загруженный сервер. 🔴 Round Robin: Самый простой алгоритм. Запросы раздаются по кругу: первому серверу, второму, третьему, первому, второму... 🔴 Least Connections: Запрос уходит на тот сервер, у которого сейчас меньше всего активных соединений. 🧠 4. Главное правило: Stateless (Без состояния) Горизонтальное масштабирование ломает старый подход к хранению сессий. Если пользователь залогинился и попал на Сервер №1, этот сервер сохранил его данные в оперативной памяти. При следующем клике балансировщик может кинуть пользователя на Сервер №2. А Сервер №2 скажет: "Я тебя не знаю, авторизуйся заново". Решение: Серверы приложения должны быть "глупыми" и ничего не помнить (Stateless). Состояние должно храниться в общем внешнем хранилище (например, в Redis, как мы обсуждали в прошлых сезонах), либо передаваться прямо в запросе с помощью токенов (JWT). 🔥 Итог 1. Vertical Scaling (вверх) - купить "железо" помощнее. Дорого, есть предел. 2. Horizontal Scaling (вширь) - поставить больше дешевых серверов. Требует изменения архитектуры. 3. Load Balancer - дирижер, который распределяет трафик между клонами. 4. Stateless - обязательное условие. Приложение не должно хранить локальное состояние. #SystemDesign #Architecture #Scaling #LoadBalancing #Backend 👉 @BookJava

Перейти к посту Открыть в браузере

Если у вас установлено приложение,
вы можете сразу перейти в канал