Native PHP: серверный стек на PHP

Что здесь означает Native PHP

Название «Native PHP» не обозначает отдельный официальный фреймворк или единый стандартный стек. В этой статье так называется подход, в котором серверное приложение работает непосредственно на PHP — без обязательного переноса на Node.js, Java или другой runtime. Это может быть собственное приложение на языке, WordPress, Laravel или другой PHP-инструментарий. Выбор между ними зависит от продукта; «нативность» сама по себе не говорит о качестве архитектуры.

PHP исполняется на сервере и формирует ответ для клиента. Кроме веб-запросов, тот же runtime подходит для командной строки, фоновых задач и обслуживания приложения. Типичный production-стек включает PHP, веб-сервер, PHP-FPM, Composer-зависимости, базу данных, хранилище файлов и средства логирования и мониторинга.

Как проходит запрос

В классической схеме веб-сервер принимает HTTP-запрос и передаёт PHP-обработку менеджеру процессов PHP-FPM по FastCGI. FPM управляет пулом PHP-процессов; приложение обрабатывает запрос и возвращает ответ. Статика часто отдаётся непосредственно веб-сервером или CDN, а не проходит через PHP.

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

Из чего складывается проект

Runtime PHP и расширения. Выбирают поддерживаемую версию языка и только нужные приложению модули. Требования зависимостей фиксируют в composer.json и lock-файле.
Приложение. Это CMS, фреймворк или собственный код. Для сложного домена фреймворк помогает организовать маршруты, валидацию, доступ к данным, фоновые задачи и тесты; для сайта с редакционным управлением может быть рациональнее CMS.
Веб-сервер и обработчик PHP. Частая схема — Nginx или Apache вместе с PHP-FPM. Альтернативы вроде FrankenPHP объединяют HTTP-сервер и PHP runtime; в классическом режиме FrankenPHP может заменить связку веб-сервера и FPM.
Состояние и сервисы. Реляционная база, файловое или объектное хранилище, кэш и очередь подключают по потребности продукта. Внешние сервисы и секреты задают через конфигурацию среды, не помещая чувствительные значения в Git.
Поставка и наблюдаемость. Нужны проверяемая сборка, контролируемый выпуск, резервное копирование состояния, централизованные журналы, метрики и процедура отката.

Обычный PHP и долгоживущие workers

Важно различать классический цикл запроса и worker mode. В традиционном режиме приложение проходит стандартную инициализацию для каждого запроса, а состояние PHP-процесса не следует считать хранилищем между запросами. Это простая модель для большинства приложений.

FrankenPHP в classic mode работает по традиционному запросному циклу. Его worker mode запускает приложение один раз и оставляет процесс в памяти, что может снизить повторные затраты на загрузку. Однако тогда статические свойства, глобальные переменные и другие данные могут сохраняться между запросами. Приложение и используемые библиотеки должны корректно сбрасывать пользовательское состояние, иначе возможны утечки памяти или данных между запросами. Поэтому worker mode — отдельный вариант исполнения с требованиями совместимости, а не синоним обычного Native PHP.

Когда выбирать

Команда уже умеет поддерживать PHP, а нужные CMS и библиотеки доступны в его экосистеме.
Нужен серверный сайт или приложение с предсказуемым HTTP request-response циклом и интеграцией с существующей PHP-инфраструктурой.
Проекту подходят готовые платформы вроде WordPress или фреймворк вроде Laravel; собственное ядро оправдано только при ясной потребности.
Требуется постепенно развивать приложение, сохраняя возможность запускать задачи через CLI, очередь и планировщик на том же языке.

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

Эксплуатация и безопасность

Поддерживайте runtime. Используйте поддерживаемую версию PHP и обновляйте её вместе с приложением и расширениями. Перед обновлением проверяйте совместимость зависимостей и тестируйте миграцию в среде, похожей на production.

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

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

Измеряйте прежде, чем менять runtime. Начните с метрик запросов, медленных SQL-операций и профиля нагрузки. FPM-пулы, кэш и worker mode настраивают по измерениям; увеличение числа процессов или потоков без учёта памяти и соединений к базе способно ухудшить стабильность.

Для общего PHP-подхода полезны каталог стеков разработки, страницы Laravel, WP Stack и локальная разработка. Laravel — один из возможных фреймворков, WordPress — CMS; оба используют PHP, но решают разные задачи.