Почему PHP не лучший выбор для микросервисной архитектуры?

А знаешь, что самое смешное? Когда начинаешь говорить про PHP в микросросервисах, половина народа сразу делает такое лицо, будто я предлагаю на табуретке через Ла-Манш переплыть. "Он же для веба! Он же каждый раз всё с нуля грузит!". Ну да, ёпта, грузит. И что? Не всё так однозначно, друзья мои.

Вот смотри, с какими косяками придётся бодаться, если решишься.

Первое — производительность и память. Это, блядь, главная засада. В классическом режиме (этот твой FPM) каждый запрос — это как будто заново всю программу запускать. Автозагрузку, фреймворк, конфиги — всю эту муть. По сравнению с теми же долгоживущими процессами в Go или Java — это, конечно, небо и земля. Latency больше, память жрёт овердохуища. Чтобы не охуеть совсем, приходится эти FPM-воркеры пулами держать, что свою головную боль добавляет в оркестрацию.

// Вот этот цирк происходит каждый раз, блядь, на каждый чих:
require_once 'vendor/autoload.php';
$app = new FrameworkApp(); // Опять всё инициализируем! Снова!
$app->run();

Второе — асинхронность, её родная мать. В теории есть ReactPHP, есть Swoole. Но вся экосистема-то, сука, заточена под "запрос-ответ". Возьмёшь какую-нибудь популярную ORM — она вся в блокирующих операциях. Хочешь сделать шустрый асинхронный сервис? Готовься к тому, что половину стандартных библиотек нахуй выкидывать и искать альтернативы, а это доверия ебать ноль.

Третье — долгоживущие процессы. Запустил воркер, чтобы из очереди сообщения таскать. Работает он себе час, два, сутки. А PHP к такому не привык, он из коробки — "прибежал, отработал, сдох". Начинаются утечки памяти, потому что где-то что-то не почистили. За этим надо следить, как за маленьким ребёнком, а волнение ебать — упадёт ведь.

Но! Не спеши хоронить старичка. Я его брал в работу, и вот когда:

• Быстрый прототип, ёбана-рот. Нужно за неделю наколотить работающий сервис, а у всей команды руки из жопы в PHP. Берёшь Laravel/Lumen, и поехали — куча готовых пакетов, всё знакомо.
• Сервис с умной логикой, но без запредельной нагрузки. Допустим, сервис расчёта скидок или управления документами. Там не 50 тысяч запросов в секунду, а важнее, чтобы бизнес-логику правильно и быстро написать. Тут PHP ещё тот работничек.
• Чтобы команде не ебать мозг. Если у тебя основной монолит на PHP, то тащить в проект ради двух микросервисов Go с его горутинами — это, простите, мудя. Проще на одном стеке всё держать, меньше контекстов переключать.

А вот если делать что-то новое, с прицелом на хайлоад — какой-нибудь API-гейтвей или процессор событий, который должен не просто работать, а летать — тут я уже сам смотрю в сторону Go или Rust. Потому что там с производительностью и памятью всё предсказуемо и красиво, да и конкурентность из коробки. Но это уже другая история, с другими граблями.