Разработка высоконагруженных систем

Подробно

Разработка высоконагруженных систем начинается с цифр: сколько пользователей придет в пике, сколько запросов в секунду получит сервис, какой объем данных накопится за год. От этих цифр зависит архитектура, выбор базы данных и то, как система будет масштабироваться. Мы проектируем и пишем такие сервисы для бизнеса, у которого рост трафика не должен превращаться в падения и потерю заказов.

Высоконагруженные приложения

Высоконагруженные приложения - это сервисы, которые обслуживают много одновременных пользователей и не могут позволить себе остановку. Типичные примеры: интернет-магазин в дни распродаж, социальная сеть или сообщество с лентой и уведомлениями, платежный сервис, логистическая платформа с тысячами курьеров в реальном времени, онлайн-школа во время вебинара. У всех одна проблема: нагрузка приходит волнами, и система должна выдерживать пик так же, как обычный день.

Для бизнеса простой стоит денег: минута недоступности магазина в распродажу означает брошенные корзины, а медленный ответ API у партнера - сорванные интеграции. Поэтому требования к доступности и времени ответа фиксируем в начале проекта, и от них зависит вся дальнейшая работа.

Если вы только разбираетесь в теме, почитайте, как устроены высоконагруженные системы и чем они отличаются от обычных сайтов.

Разработка высоконагруженных приложений

В разработке высоконагруженных приложений язык значит меньше, чем инженерная дисциплина. Каждый запрос к базе проверяем на план выполнения, тяжелые операции уводим в фоновые задачи, сетевые вызовы делаем с таймаутами и повторными попытками. Сервис без состояния (stateless, когда сервер не хранит данные сессии у себя) легко размножить на несколько экземпляров за балансировщиком, поэтому состояние держим в базе и кэше. Пулы соединений с базой и лимиты запросов подбираем под реальную нагрузку.

Архитектура высоконагруженных систем

Архитектура высоконагруженных систем строится из нескольких слоев, и у каждого своя задача:

• балансировщик распределяет запросы между экземплярами приложения;
• кэш в Redis отдает частые данные без обращения к базе;
• очереди в Kafka принимают события и сглаживают пики: заказ принят сразу, а обработка идет в фоне без потери сообщений;
• база данных PostgreSQL с репликами на чтение и, если объем растет, с разделением данных на шарды (части базы на разных серверах);
• аналитика и отчеты уходят в отдельное хранилище, чтобы не нагружать рабочую базу.

Горизонтальное масштабирование (добавление серверов вместо покупки одного мощного) настраиваем в Kubernetes: при росте нагрузки система сама поднимает новые экземпляры сервиса, при спаде убирает их.

Выбор технологий зависит от профиля нагрузки. Для потока событий и аналитики подключаем ClickHouse, для полнотекстового поиска Elasticsearch, для файлов - S3-совместимое объектное хранилище.

Разработка микросервисов

Разработка микросервисов оправдана, когда части системы растут с разной скоростью или их ведут разные команды. Каталог, корзина, платежи и уведомления живут отдельно, общаются через API и события, и сбой в сервисе рекомендаций не роняет оформление заказа. Сервисы с большим числом одновременных соединений пишем на Go, бизнес-логику и работу с данными на Python. Для небольшого проекта микросервисы часто избыточны, тогда делаем модульный монолит и делим его, когда появляется реальная причина.

Проектирование высоконагруженных систем

Проектирование высоконагруженных систем мы начинаем с модели нагрузки. Вместе с вами считаем пиковое число пользователей, профиль запросов, рост данных на горизонте двух-трех лет. Затем ищем узкие места заранее: где будет упираться база, какие интеграции отвечают медленно, какие операции нельзя терять. Отдельно продумываем связи с внешними системами: платежи, 1С, службы доставки. Их медленный ответ не должен тормозить пользователя, поэтому такие вызовы идут через очередь с повторами. По итогам готовим схему архитектуры, выбор технологий и план, как система будет расти вместе с бизнесом.

Если система уже работает и не справляется, начинаем с аудита: снимаем метрики, профилируем запросы, находим узкое место и предлагаем, что менять в первую очередь. Часто высокую нагрузку снимают индексы, кэш и вынос тяжелых задач в очередь, без переписывания всего проекта.

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

Процессы разработки программного обеспечения и DevOps

В высоконагруженном проекте процессы разработки программного обеспечения важны не меньше кода. Мы работаем по DevOps-практикам (разработка и эксплуатация как один процесс): каждое изменение проходит автоматические тесты и сборку в CI/CD, выкатывается постепенно и откатывается одной командой. Инфраструктуру описываем кодом в Terraform и Helm-чартах, поэтому окружения для тестов и продакшена собираются одинаково.

Перед релизом проводим нагрузочное тестирование: подаем на систему трафик выше ожидаемого пика и смотрим, при каком числе запросов растет время ответа. Это позволяет найти предел до того, как его найдут пользователи. В продакшене работает мониторинг: метрики, логи и трассировка запросов, оповещения дежурной команде. Платформа, которая сообщает о проблеме раньше клиентов, дешевле в эксплуатации.