Архитектура веб-приложения определяет не только расположение серверов и технологий. Она задаёт, как система хранит данные, обрабатывает нагрузку, интегрируется с внешними сервисами, восстанавливается после сбоев и меняется вместе с бизнесом.
Две системы с одинаковым количеством экранов могут заметно различаться по сложности. Личный кабинет с одним источником данных и внутренняя платформа с ролями, платежами, CRM и обменом документами требуют разных архитектурных решений. Поэтому схему приложения стоит проектировать от сценариев и рисков, а не от списка модных инструментов.
Базовые компоненты веб-приложения
Типовая система состоит из нескольких уровней. Их состав меняется от проекта к проекту, но роли остаются похожими.
Клиентский уровень
Пользователь взаимодействует с приложением через браузер, мобильное приложение или встроенный интерфейс партнёра. Клиент отображает данные, проверяет очевидные ошибки ввода и отправляет запросы на сервер. Критичные бизнес-правила нельзя оставлять только здесь: пользовательский код доступен для изменения, а разные клиенты должны получать одинаковый результат.
Точка входа
Запросы проходят через домен, CDN, балансировщик нагрузки или API-шлюз. Этот уровень может завершать защищённое соединение, ограничивать частоту запросов, направлять трафик и отсеивать часть некорректных обращений.
Для небольшого продукта необязательно собирать сложную цепочку инфраструктурных сервисов. Но точка входа должна позволять безопасно публиковать приложение и наблюдать, куда направляется трафик.
Прикладная логика
Backend выполняет операции, ради которых существует продукт: рассчитывает стоимость, меняет статус заказа, назначает исполнителя, проверяет права или формирует документ. Логику полезно разделять по предметным областям, даже если приложение развёртывается как единый процесс.
Такое разделение уменьшает связанность. Изменение расчёта не должно случайно ломать авторизацию, а интеграция с CRM — определять внутреннюю модель всей системы.
Хранение данных
Основная база хранит состояние продукта. Рядом могут находиться файловое хранилище, поисковый индекс, аналитическая база и кеш. Каждый инструмент решает отдельную задачу: кеш ускоряет повторное чтение, но не заменяет надёжное хранилище; поисковый движок помогает находить документы, но не обязан быть источником истины.
Архитектура должна явно отвечать на вопрос, где находится достоверная версия каждой сущности. Иначе после нескольких интеграций разные системы начинают считать себя владельцами одного статуса или профиля клиента.
Асинхронная обработка
Не каждую операцию нужно завершать внутри пользовательского запроса. Отправку уведомлений, генерацию тяжёлого отчёта, обработку файла или синхронизацию с внешним сервисом можно передать в очередь.
Пользователь быстрее получает ответ, а временный сбой внешней системы не блокирует весь сценарий. За это приходится платить дополнительными состояниями: задача может ожидать, выполняться повторно или завершиться ошибкой. Повторный запуск не должен создавать второй платёж, заказ или документ.
Как проходит один запрос
Рассмотрим сохранение заявки. Клиент отправляет данные через защищённое соединение. Точка входа передаёт запрос приложению, которое проверяет пользователя, формат полей и бизнес-ограничения. После успешной проверки данные сохраняются в основной базе.
Только затем система подтверждает результат и создаёт асинхронные задачи: уведомить менеджера, записать событие аналитики, передать лид в CRM. Если CRM недоступна, заявка остаётся сохранённой, а передача повторяется контролируемо.
Такая последовательность отделяет критичный результат от вторичных действий. Если отправлять всё синхронно, недоступность почты или аналитики может помешать пользователю создать заявку, хотя основной продукт способен её принять.
Монолит, модульная система и микросервисы
Архитектурный стиль определяет, как прикладная логика собирается и развёртывается.
| Подход | Сильная сторона | Основное ограничение | Когда уместен | |---|---|---|---| | Монолит | Простая разработка и эксплуатация на старте | Связанность растёт без дисциплины | Новый продукт, одна команда, единый цикл релизов | | Модульный монолит | Чёткие границы внутри простого развёртывания | Границы нужно поддерживать архитектурно | Продукт растёт, но независимые сервисы пока не оправданы | | Микросервисы | Независимые релизы и масштабирование частей | Распределённые данные, сеть и сложная эксплуатация | Несколько автономных команд и действительно независимые области |
Обычный монолит не обязательно плох. Проблема возникает, когда его части связаны через случайные зависимости, общие таблицы и неявные правила. Модульный монолит часто даёт достаточно свободы без стоимости распределённой системы.
Микросервисы оправданы, когда организационные и технические границы уже существуют. Разделение одного небольшого продукта на десятки сервисов увеличивает количество развёртываний, сетевых отказов, логов, прав доступа и сценариев согласования данных.
Критерии выбора архитектуры
Основные сценарии и критичность
Сначала определяют операции, остановка которых влияет на деньги, обязательства или безопасность. Для системы бронирования критично не продать один слот дважды. Для внутренней аналитики допустима задержка обновления, но нельзя показывать незаметно устаревшие данные как актуальные.
Архитектура должна поддерживать конкретный уровень надёжности, а не абстрактное стремление «никогда не падать».
Нагрузка и её профиль
Среднее количество пользователей говорит меньше, чем характер нагрузки. Короткий пик после запуска акции, постоянная обработка файлов и тысячи лёгких чтений требуют разных решений.
До появления реальных данных разумнее проектировать понятный запас и возможность масштабирования, а не дорогую инфраструктуру под гипотетические миллионы запросов.
Команда и частота изменений
Архитектура должна соответствовать способу работы команды. Если три разработчика выпускают продукт единым релизом, независимые сервисы могут замедлить их. Если несколько команд отвечают за разные бизнес-направления и постоянно блокируют друг друга, разделение границ способно ускорить изменения.
Интеграции
Внешние системы имеют собственные ограничения, версии и периоды недоступности. Для каждой интеграции определяют контракт данных, авторизацию, ограничение частоты, повторы, защиту от дублей и способ сверки.
Особенно важно не допустить, чтобы формат одного поставщика проник во все уровни продукта. Изолированный интеграционный слой облегчает замену сервиса и тестирование.
Безопасность и права
Архитектура описывает не только вход пользователя, но и доступ между компонентами. Следует определить роли, границы организаций, хранение секретов, журналирование значимых действий и минимальные права сервисов.
Добавить безопасность после разработки сложнее: модель доступа связана со структурой данных, интерфейсами и операциями.
Эксплуатация
Каждый новый компонент нужно разворачивать, обновлять, резервировать и наблюдать. Если система использует очередь, команда должна видеть размер отставания. Если есть кеш — уметь безопасно работать при его недоступности. Если данные копируются в поиск — контролировать расхождения.
Наблюдаемость как часть архитектуры
Работающий интерфейс ещё не означает, что система здорова. Команде нужны метрики, структурированные логи и трассировка ключевых операций. Они помогают ответить, где возникла задержка: на клиенте, в приложении, базе или внешнем API.
Полезные сигналы выбирают по пользовательскому результату. Время ответа сервера важно, но ещё важнее доля заявок, которые успешно сохранены и переданы. Техническая метрика должна помогать понять влияние сбоя на процесс.
Как документировать решение
Для начала достаточно нескольких актуальных артефактов: контекстной схемы систем, диаграммы основных компонентов, модели ключевых данных, описания интеграционных контрактов и короткого журнала архитектурных решений.
Документация должна объяснять не только итог, но и причину: какие ограничения рассматривались, почему выбран этот подход и при каком изменении решение следует пересмотреть. Такая запись особенно полезна при росте команды или передаче продукта.
Как AVENIR подходит к проектированию
Мы начинаем со сценариев, данных, интеграций и рисков эксплуатации. Затем определяем минимальную схему, которая поддерживает текущую задачу и допускает развитие без преждевременного усложнения.
Архитектура не должна быть самой технологичной на схеме. Она должна оставаться понятной команде, выдерживать нужную нагрузку, защищать критичные данные и позволять выпускать изменения с контролируемым риском.
Если вы проектируете веб-приложение или пересматриваете существующую систему, можно обсудить архитектуру с командой AVENIR. Для первого разбора достаточно основных сценариев, списка интеграций, ожидаемой нагрузки и известных ограничений.