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

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

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

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

Discovery дает список приоритетных сценариев, технических ограничений и проверок перед реализацией. Команда понимает, какие риски важно устранить в первую очередь и по каким критериям оценивать результат. Это снижает вероятность вложений в инфраструктуру, которая не влияет на критический путь.

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

Технологии выбираются после согласования сценариев и ограничений. C# / .NET, Node.js / NestJS и Rust решают разные задачи серверной части, а PostgreSQL и MongoDB подходят для разных типов данных. Выбор инструмента сам по себе не решает проблему производительности: решение должно быть проверяемым и поддерживаемым в эксплуатации.

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

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

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

Нужно управлять временем выполнения операций, тайм-аутами и правилами повторных запросов. Часть состояния выносится в подходящее хранилище или правила взаимодействия с ним пересматриваются. Иначе увеличение числа экземпляров только быстрее приведет к ошибкам в базе данных или во внешнем API.

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

Для реляционных сценариев Nomium использует PostgreSQL, а MongoDB применяется там, где это соответствует модели продукта. Также проверяются индексы, объем передаваемых данных и границы между синхронными и отложенными действиями. Иногда для оптимизации высоконагруженных систем достаточно корректировки запросов или порядка записи, не меняя систему хранения.

Нагрузочное тестирование проверяет согласованный сценарий до запуска изменения. Заранее фиксируются действия, ожидаемое время ответа, допустимая доля ошибок и правила восстановления. После теста фиксируются ограничение, его причина и следующий шаг, затем проверка повторяется на обновленном сценарии.

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

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