Веб-сервис отличается от набора страниц тем, что постоянно принимает решения: проверяет права, меняет данные, рассчитывает стоимость и взаимодействует с внешними системами. При замене PHP необходимо сохранить эти решения и договорённости с клиентскими приложениями. Поэтому выбор нового языка является только частью задачи. Сначала определяем контракты API, правила обработки операций и требования к доступности. Затем подбираем Go или Node.js и размещение, которое соответствует реальной нагрузке.
Начинаем с границ сервиса
Составляем перечень входящих запросов и исходящих событий. Для каждого сценария выясняем, кто вызывает операцию, какие данные передаёт и что ожидает в ответ. Отдельно фиксируем ошибки, ограничения частоты и требования к повторным обращениям. В старом приложении эти правила нередко существуют только в коде. Перенос становится удобным моментом сделать их явными, чтобы новая реализация не изменила поведение интеграций без ведома пользователей и партнёров.
Примером служит создание заказа. Недостаточно вернуть успешный ответ и добавить строку в таблицу. Нужно сохранить расчёт суммы, связь с клиентом и правила перехода между состояниями. Повторный запрос после сетевого сбоя не должен неожиданно создавать второй заказ. Уведомление и внешняя синхронизация требуют собственного контроля. Мы описываем такую операцию как бизнес-сценарий, а не как отдельный обработчик маршрута: именно так проще проверить полноту новой реализации.
Когда выбираем Go
Go рассматриваем для сервисов с чёткой серверной логикой, конкурентной обработкой запросов и требованиями к управляемому развёртыванию. В проекте заранее определяем структуру модулей, работу с базой и обработку ошибок. Возможность собрать приложение в исполняемый файл упрощает некоторые варианты поставки, но не отменяет конфигурацию и инфраструктуру. Выбор подтверждаем пробным сценарием и измерениями на нагрузке заказчика, особенно если планируется заменить несколько существующих процессов одним сервисом.
Когда выбираем Node.js
Node.js рассматриваем там, где важно использовать JavaScript на сервере, быстро подключать внешние API и сопровождать приложение силами существующей команды. При этом обработчики должны корректно работать с асинхронностью и ограничивать тяжёлые вычисления. Для эксплуатации выбираем поддерживаемую линию выпуска и фиксируем зависимости. Большой каталог пакетов помогает решать задачи, но требует дисциплины выбора: добавлять библиотеку ради одной небольшой функции не всегда оправданно с точки зрения сопровождения.
| Критерий | Go | Node.js |
|---|---|---|
| Навыки команды | Нужна поддержка Go | Удобен JavaScript-команде |
| Поставка | Собранное приложение | Среда исполнения и зависимости |
| Интеграции | Проверяем нужные SDK | Проверяем нужные SDK |
| Выбор архитектуры | VPS, контейнеры, функции | VPS, контейнеры, функции |
Где размещать новый сервис
VPS или VDS подходит, когда нужны понятный постоянный ресурс и контроль окружения. Контейнер облегчает воспроизводимость поставки, если подготовлены образ и конфигурация. Serverless рассматриваем для событийной или переменной нагрузки с подходящей длительностью операций. В каждом случае остаются база, сеть, секреты и наблюдение за ошибками. Размещение не выбираем по обещанию самого дешёвого вызова: считаем весь сценарий, включая хранение, передачу данных и ожидаемые пики обращений.
Фоновые задачи нельзя забывать при замене публичного API. Отчёты, рассылки и синхронизации могут запускаться по расписанию и не проявляться во время короткой демонстрации. Мы составляем реестр таких задач, определяем повторные попытки и фиксируем результат исполнения. Для операций с побочными эффектами предусматриваем защиту от повторной обработки. Это особенно важно при переходе к очередям и функциям, где повторная доставка события должна быть ожидаемым условием проектирования.
- Контракты и бизнес-правила → Выбор Go или Node.js
- Выбор Go или Node.js → Проверка API и данных
- Проверка API и данных → Перенос трафика по маршрутам
- Перенос трафика по маршрутам → Операции подтверждены?
- Операции подтверждены? → Отключение старого backend (Да)
- Операции подтверждены? → Проверка API и данных (Нет)
Как переходить без потери договорённостей
Для сложного сервиса удобно переносить маршруты постепенно. Старый и новый backend могут временно работать за общим входом, если явно определены владельцы операций и правила записи данных. Нельзя позволять двум реализациям независимо менять одну сущность без согласования. Сначала переносим ограниченный сценарий, проверяем ответы и только затем расширяем долю трафика. Такой подход позволяет обнаруживать несовместимости раньше, чем они затронут весь продукт и внешние интеграции.
Приёмка включает успешные и ошибочные запросы. Проверяем работу обычного пользователя, администратора и клиента без доступа к чужим данным. Сравниваем итоговые состояния, а не только коды HTTP. Для платежей используем предусмотренную провайдером тестовую среду, затем выполняем согласованную проверку запуска. Журналы должны помогать найти неудачную операцию без ненужного раскрытия персональных данных. Подготовленные результаты становятся основанием для решения о переключении и последующем отключении PHP.
Один владелец каждой операции
Во время постепенного перехода особенно важно определить, какая система имеет право изменять заказ или баланс. Нельзя считать общую базу достаточным способом координации двух независимых реализаций. Старое и новое приложение могут по-разному трактовать статусы и повторять побочные действия. Мы выбираем владельца записи на каждом этапе и описываем передачу этой обязанности. Читающие запросы иногда переносятся раньше изменяющих, но такое решение проверяется на конкретной модели данных, а не применяется автоматически ко всем сервисам.
Для внешних клиентов сохраняем стабильную точку входа либо согласовываем изменение контракта. Подготавливаем понятное поведение на время обслуживания и не раскрываем внутренние ошибки как пользовательские ответы. Если требуется временная совместимость двух версий API, определяем её срок и условия завершения. Заказчик должен видеть, какие компоненты ещё зависят от PHP и почему они не отключены сразу. Это делает поэтапный переход обозримым и помогает избежать бесконечного существования двух конкурирующих backend без ясной ответственности.
Для наблюдения за переходом заранее выбираем несколько показателей: успешные операции, ошибки и время ответа. Они должны описывать одинаковую нагрузку до и после изменения, иначе сравнение двух реализаций будет вводить в заблуждение и не поможет принять решение о дальнейшем переключении трафика.
Что получает заказчик
Результатом становится сервис с описанными контрактами, перенесёнными данными и воспроизводимой процедурой выпуска. Заказчик получает код и инструкции, понимает правила резервирования и видит ответственных за инфраструктуру. Возможность добавить интеграцию оценивается по понятным границам модулей, а не по наличию очередного плагина. Чтобы выбрать стек, отправьте описание API, внешних связей и нагрузки. Мы подготовим конкретную архитектуру, оценку стоимости и срок, который учитывает сложность вашего сервиса.
Источники
Node.js: линии выпуска и поддержка. Go: управление уязвимостями. AWS Lambda: эксплуатационные рекомендации. Проверено 26 октября 2026 года.
