Разбираем, почему ИИ предлагает лишние сервисы и как проверить архитектуру. Узнайте, какие строительные блоки нужны вашему проекту, и начните проектировать правильно.
Вы просили ИИ помочь с кодом, и оно завернуло всё в один сервис. Спросите то же ИИ спроектировать систему — и получите пять микросервисов. Как одно и то же ИИ выдаёт противоположные ошибки? Ответ — в строительных блоках, а не в слове «сервис». В этой статье разберём, почему так происходит и как проверить любое архитектурное решение, прежде чем писать код.
Когда вы просите ИИ написать код, оно создаёт одну функцию или один сервис: запрос на вход, ответ на выходе. Всё, что нужно сделать — валидация, запрос к базе, отправка письма — происходит внутри этого сервиса. На демо это работает. В проде шаг отправки письма медленный, и каждый пользователь смотрит на спиннер, пока ваш сервер ждёт ответ от почтового сервиса.
Попросите ИИ спроектировать систему до написания кода — и получите противоположную ошибку. Представьте: вы и ещё один инженер делаете приложение для разделения счетов между соседями. ИИ выдаёт пять сервисов: auth, billing, notifications, API-шлюз и брокер сообщений. Звучит управляемо, пока не посчитаете, что внутри каждого.
Итого минимум 10 блоков, разбросанных по пяти деплоям, для команды из двух человек.
Реальное приложение выглядит иначе. Кто-то логинится и добавляет счёт: один сервис. Счёт должен знать, каким пользователям принадлежит и как разделён: одна реляционная БД. Когда счёт оплачен, нужно уведомить соседей — это не должно происходить синхронно, поэтому кладём в очередь, а воркер забирает через несколько секунд. Итого: один сервис, одна БД, одна очередь и воркер — вся система. Четыре блока, один деплой, против десяти блоков в пяти.
ИИ, когда пишет код, выбирает самую простую форму: одна функция, один сервис, запрос-ответ. Очередь он не использует, потому что очередь — это решение о том, что может подождать, а не простая форма кода. Когда ИИ проектирует систему, оно выбирает самую обсуждаемую форму — как решают проблемы в крупных компаниях, которые к вам не относятся. Одна и та же причина: ИИ подстраивается под жанр вашего запроса, а не под ваши реальные ограничения.
Микросервис — это не строительный блок. Это целый деплой, который может содержать два-три блока. Если считать в сервисах, «пять» звучит как пять задач. Если считать в блоках — это десять частей, которые нужно построить, связать и поддерживать, разбросанных по пяти отдельным деплоям. А нужно четыре части в одном.
Микросервисы окупаются, когда отдельные команды должны выпускать изменения, не дожидаясь друг друга, когда одной части нужно другое железо или когда один сбой не должен ронять всё остальное. У двух человек, делающих одно приложение, нет такого давления. Вам нужно одно место для изменений, один деплой и одна система, которую можно понять в 11 вечера: монолит. Это не «начальный уровень», из которого вы вырастете. На вашем этапе это правильный дизайн.
Проверьте каждую часть ответа ИИ — и когда оно построило слишком мало, и когда слишком много — одним вопросом: существует ли прямо сейчас на моей команде давление, которое оправдывает этот элемент? Несколько команд, мешающих деплоям друг друга. Компонент, которому нужно другое железо. Трафик, который вы уже можете измерить, а не тот, что представляете на следующий год. Если давление нереальное — элемент убираем, будь то недостающая очередь или лишний сервис.
Возьмите последний проект, который вы проектировали (или попросили ИИ спроектировать), и перечислите все строительные блоки: сервисы, базы данных, очереди, воркеры. Задайте вопрос о давлении для каждого блока. Удалите всё, что не проходит проверку. Начните с монолита, добавляйте блоки только когда появится реальная потребность. Так вы избежите и «сервиса-официанта», и «микросервисного зоопарка».
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →