Comments 11
Таким образом, вот причины, по которым Java сейчас более популярна как интернет-платформа по сравнению с PHP.
А какие-то подтверждения этому есть? Впервые слышу об этом, если честно. Да и вроде они в разных нишах немного, и Java обычно в энтерпрайзе используется - ну то есть сравнивать их в плане популярности бессмысленно. Того же Wordpress, кстати, на котором крутятся большинство всяких блогоподобных сайтов, для Java нет. А ведь блог - это самая многочисленная разновидность сайта.
Кроме того, соединение с базой данных не может быть использовано повторно и не защищается
Ну внешний пул можно использовать - PgBouncer, например. А от чего соединение не защищается?
Он недостаточно дружелюбен к микросервисным инструментам, таким как docker, и полагается на nginx для предоставления услуг.
Какие проблемы запихнуть php-fpm в Docker и что знает "полагается на nginx для предоставления услуг"?
каждый запрос должен начинаться с нуля, начиная с загрузки процесса
Так ли уж каждый и так ли уж с нуля? Как вы думаете, что такое pm.min_spare_servers в конфиге php-fpm?
Если вы уперлись в ресурсы при использовании FPM, и при этом у вас требования как у высоконагруженного приложения с возможностью асинхронной обработки огромного кол-ва запросов и асинхронной передачи их в дальнейшие сервисы.. То почему просто не сменить инструмент на "нормальный" (в рамках необходимых требований), например тот же GO?
Считаю, что переучивать разработчиков которые годами росли в контексте "PHP рождён, чтобы умереть" с синхронным исполнением кода, на асинхронщину на том же PHP - это дорога в никуда. На рынке очень мало востребованных позиций с асинхронным PHP, и на рынке будет очень сложно найти квалифированного PHP разработчика имеющего опыта %костыль% и умеющего в асинхронщину (удачи).
А вот если говорим про тот же Go (или другой подобный инструмент), то тут сразу понятно, что такой разработчик умеет в асинхронщину, во всякие mutex, потоки, и прочее.. И в таком случае, эффективность решения будет в разы выше, чем костыли (swoole, gorunner и прочее) на PHP. Потому-что на "нормальном" инструменте (опять-таки Go), сможете намного лучше утилизировать доступные ресурсы.
Поэтому, если так сложилось, что в компании только PHP разработчики.., считаю перспективным решением найти пару разработчиков на "нормальном" инструменте в компанию, и вокруг них уже организовать процессы обучения php разработчиков в "нормальный" инструмент.
Лучше немного побуксовать на старте (смена стека), чем потом докупать пачками сервера под PHP, и каждого нового PHP разработчика обучать мертворождённым костылям.
Нормальным в рамках требований может и PHP-FPM быть, просто не надо лепить микросервисную архитектуру как попало. Если у вас сервер который по сути прокси к 20 другим серверам то вылечив проблему скорости запросов вы просто уткнётесь в проблему доступности. А если вы таким не занимаетесь то у вас и PHP тормозить не будет. Конечно есть всякие специальные случаи где нужны специализированные решения, но таких случаев у большинства нет.
Звучит логичино и аргументы понятные, но переписать все на %подставь_свтой_язык% для бизнеса означает потерять кучу времени и не факт, что это окупится, а выгоды мало для бизнеса.
И сейчас все гиганты, которые начинали с PHP (ВКонтатке, facebook, badoo и тд), полностью не переезжают на другие языки, хотя денег найти на рынке Go-шника и обучить у них точно хватает. Они перевозят лишь частями свои сервисы, разгружая узкие места. Именно поэтому все чаще встречаются вакансии PHP+Go, чтобы умел и админку на PHP сделать и API под высокие нагрузки на GO накидать.
И в таком случае, эффективность решения будет в разы выше, чем костыли (swoole, gorunner и прочее) на PHP.
Почему же "костыли"? Swoole позволяет выполняться приложению (на Symfony, например) в режиме сервиса. То есть, скрипт постоянно висит в памяти и не выполняется заново каждый запрос, как при FPM. От этого скорость обработки запросов значительно увеличивается.
А вот если говорим про тот же Go (или другой подобный инструмент), то тут сразу понятно, что такой разработчик умеет в асинхронщину, во всякие mutex, потоки, и прочее.
Сам по себе асинхронный код вряд ли даст значительное ускорение. Зато появится много проблем с поддержкой этого всего.
Автор сам то хоть читал, что гугл-транслейт выдал или сразу на хабр отправил?
Symfony может работать через Swoole: https://www.swoole.co.uk/article/symfony-swoole
При этом он быстрее Spring работает: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=fortune
Так что, не понятно, в чем, собственно, проблема.
Как использовать PHP для создания микросервиса?