Комментарии 41
Поздно давать совет, но phpreact уже давно существует и писать с его помощью асинхронные приложения (к сожалению в один поток) очень легко.
6к прирост, это значит у вас там сильно устаревший подход, когда каждый запрос запускает php скрипт и оно заново грузит все откуда то, и не удивляюсь, если из бд, без хотя бы кеширования.
Ну swoole, например, позволяет параллелить на несколько потоков: https://www.swoole.co.uk/docs/modules/swoole-coroutine-methods
Очень удобно получилось — и работали в нерабочее время и в рабочее время выгода получилась для компании.
Да, если это в выходные то откажусь и посмотрю на это в рабочее время. Работники IT в России не так много требуют чтоб ещё экономить на их образовании, которое очевидно пошло на пользу компании.
А так для «поглазеть и пощупать» больше нравится вариант
Те, кто не пришёл, расспросили коллег, что это было.
PHP: отработал и умер, один поток, память в лайф-цикле не шарим, потому что шарить не с чем, и цикл короткий, смысла нет.
Go: долгоживущий процесс, многопоточность/асинхронность, а значит есть кеши в памяти, примитивы синхронизации и вся многопоточная кухня.
Разница не столько в языке, сколько в архитектуре. Конвертер языка — реализуемо, конвертер архитектуры… Ну, они есть, называются `senior architect`, просят много денег за работу и не любят сверхурочных.
конвертор который учитывает специфику проекта
Не окупится, т.к.:
а) пилить лексический анализатор и синтаксическое дерево силами команды опытных веб-разработчиков заради миграции одного проекта — неэффективно;
б) заказывать у разработчиков лексических анализаторов и строителей синтаксических деревьев транслятор веб-проекта на другой язык заради миграции одного веб-проекта — дорого.
При любых раскладах эффективнее и дешевле «тупо переписать», тем более, что у вас, при наличии готового веб-проекта нуждающегося в миграции, видимо, команда веб-разработчиков, которые «в теме», уже есть. А опыта в написании трансляторов языков у этой команды, вероятно, нет. Не то, чтобы нельзя было обучить, но поднимать такой пласт заради миграции проекта, а потом тупо «забывать как страшный сон» с целью вернуться к веб-разработке на «немного другом языке»… Ну, такое себе.
Во-вторых, даже для переноса на совершенно другую архитектуру есть части кода которые можно переиспользовать и затраты на написание конвертора могут с лихвой окупиться.
Не окупятся. Трансляторы = дорого.
В-третьих, иногда имеет смысл в переносе некоторых некритичных частей AS-IS, т.е. с минимальными изменениями, пусть даже это неправильно, но поддержка двух технологий может быть более затратной. И сэмулировать простое поведение PHP в Go гораздо проще, чем сэмулировать Go в PHP.
Осталось понять, какого эффекта вы хотите добиться от миграции на Go. «Переведите в лоб» на Go PHP-шный проект, и прирост производительности составит… ничего. Возможно, даже просядете. Выигрыш будет исключительно в архитектуре, сам по себе в линейной логике Go не очень быстрый.
Так что вполне реалистично, если конечно не теоретизировать и быть реалистом, а не перфекционистом.
Не, это, конечно, реалистично, я не отрицаю. Только нерентабельно, шописец.
Не есть, а могут быть, но могут и не быть.
Можно писать без фреймворка прямо в блокноте, то есть нет геморроя с зависимостями третьего уровня, которые тащит за собой развитый фреймворк.
Вот я php разработчик, и данная рекламная фраза рождает у меня смутное беспокойство, что развитый фреймворк, от которого мы так легко отказались, на golang придется потом писать заново и самому. Т.к. потому на php у него столько зависимостей и есть, что эту работу какой-то хороший человек сделал за тебя и выложил в общий доступ. Поэтому мне правда очень интересно, что в golang такого особенного, что позволяет безболезненно обходиться без него.
P.S. В nodejs, на мой взгляд, похожая идеология «фреймворк не нужен, хватит библиотек. А в итоге надо сначала это все вместе как-то собрать, а потом все равно получается конструктор „сделай сам“, где самые простые и нудные вещи нужно прописывать вручную, попутно изобретая один велосипед за другим.
Как минимум аналоги PSR response, request, handlers, Middlewareи и роутеров в терминах популярных php фреймворков — часть стандартной библиотеки. То есть микрофреймворки, включая "голую" симфонии по сути уже точно не нужно, он уже есть из коробки. На нодовский экспресс по моим впечатления похож.
Вот я php разработчик, и данная рекламная фраза рождает у меня смутное беспокойство, что развитый фреймворк, от которого мы так легко отказались, на golang придется потом писать заново и самому.
Ну, не сгущайте краски. Эта фраза — действительно рекламная, и имеет достаточно мало общего с реальностью и здравым смыслом. На самом деле, тут чутка иначе все:
1. «прямо в блокноте» — ну, такое можно про любой язык сказать. В конце-концов код — это просто текст, и сама возможность писать его в блокноте, на листочке, на стене в подъезде и т.д. и т.п. — неотъемлемое право любого программиста. Однако здравый смысл подсказывает, что IDE лишними не бывают, и родить что-то крупное без IDE можно, только плохо, медленно, в страданиях, да и зачем? IDE эффективности реально прибавляет.
2. «Можно писать без фреймворка» — а вот это чистая правда. Стандартная библиотека достаточно богата — это раз. Ну и не взлетают монструозные фреймворки на Go — это два. Фишка вся в том, что мидлвари, роутеры, сериализаторы, хендлеры, обертки над запросом/ответом в Go есть. Они есть в стандартной библиотеке, они есть альтернативные, хорошие (и не только) и разные, много их.
Вопрос большого фреймворка в том, что у вас все «в одной большой коробке», т.е. для того, чтобы замутить CRUD, для которого ценность модулей сложнее роутера сомнительна, вы один фиг принесете весь фреймворк, вместе со всеми мидлварями, ормами и т.д. и т.п. Так уж разработчики упаковали.
В Go больше принято «мухи отдельно, котлеты отдельно». У вас есть http Request/Response, у вас есть маршаллер/анмаршаллер, у вас есть мидлвари, у вас есть роутер. И все это отдельно. Да, мидлварь или роутер попросит, чтобы вы дали ей http.Request и контекст. Только дать вы можете не только реализацию стандартной библиотеки, но и любую альтернативную, до тех пор, пока она реализует интерфейс. Вот в этом месте у вас появляется а) выбор, б) возможность притащить в проект только и исключительно то, что вам нужно, ни каплей больше.
В nodejs, на мой взгляд, похожая идеология
Ну, с нодой трабла-то, собственно, в чем: отсутствие типизации не позволяет определить интерфейс, который необходимо реализовать для совместимости имплементации. Ну, т.е. да, там немножко жопа.
2) Парадигма разработки на GO отличается от того, что требуется в PHP.
3) Разработка на Java гораздо ближе к PHP, чем к GO — если уж нужно стать супер оплачиваемым.
Я к тому, что если вы волевым решением говорите PHP разработчикам пересаживаться на GO, то определенная часть (я бы сказал большая), откажется и уйдет в другое место.
Вакансий на GO не так много, и все эти вакансии идут в «жопные» места, где реально надо сидеть думать и писать «умный» код, и так каждую задачу. И если человеку не нравится такой темп работы, то проще поменять энтерпрайз PHP на энтерпрайз на Java и добрать свои деньги по зп.
Для каких-то задач Go, конечно, хорош. Но переводить какой-то условный CRUD уровня пхп на него — да ну нахер.
Круто, молодцы!
А шаблончиком полным поделитесь? Хотя бы go частью, с k8s думаю всё индивидуально.
А то сижу и пилю первый сервис на Go, взамен пхп прототипу, архитектуру, если можно это так назвать, менял уже раз 10. Вот про контекст узнал, теперь ещё раз переделывать.
Все-таки шаблон зависит от проекта, окружения и т.п. Важнее построить правильную архитектуру. Мы опирались на 12 факторов.
В целом в статье перечислена основаная функциональность. Для k8s cтоит отметить следующие:
- ручки с хелсчеками (liveness- и readiness-пробы);
- ручка для выгрузки метрик (для prometheus);
- логи экспортируем в формате json в stdout (для fluentd);
- конфигурация пакетов через переменные окружения (локально .env);
- настройка GOMAXPROCS по ресурсам выделеным на docker-контейнер (пакет automaxprocs от uber).
Да с вот этой функциональностью проблем как раз нет, я уже лет 5 так пишу сервисы, но не Go, а на PHP (Symfony и немного Laravel). Вот всё что вы назвали я уже реализовал на Go (кроме GOMAXPROCS — ещё не встречалось). Но мне страшно смотреть на свой код, воняет жутко. Ну такие вещи, как передача значения http заголовка Request-Id в функцию, делающую SQL INSERT структуры в базу, чтобы она смогла в if err != nil сделать log с ним через всё приложение. Или подобное таскание за собой коннекшена к БД, чтобы там же откатить транзакцию. Хочется посмотреть именно лучшие практики для такой инфраструктурной функциональности. С бизнес-логикой особых проблем нет как раз, хотя и есть бесящие детали.
Ну такие вещи, как передача значения http заголовка Request-Id в функцию, делающую SQL INSERT структуры в базу, чтобы она смогла в if err != nil сделать log с ним через всё приложение
Погуглите context.
Или подобное таскание за собой коннекшена к БД, чтобы там же откатить транзакцию.
Там один фиг пул, так что, вероятно, зря таскаете. Таскать надо не коннекшен, а транзакцию.
Погуглите context.
Спасибо, чуть раньше успел узнать о нём и теперь в процессе очередного переписывания с нуля. Как раз вот просил шаблончик, чтобы избежать очередного переписывания из-за того, что узнал о какой-то штуке слишком поздно. Или узнать-узнал, но применяю, скажем так, не эффективно. Вот у меня сейчас в контексте логгер, транзакция (думал коннекшен, а разобрался по вашему совету и понял, что транзакция, там при старте клонируется коннекшен), MQ коннекшен, http request id (в основном для логгера), надо бы добавить что-то для метрик типа клиента прометеуса и, наверное, сам реквест и респонс райтер. Даже не просто сервис-локатор, а прямо глобальный неймспейс PHP с суперглобальными переменными, причём ближе к PHP4, чем к PHP7.
Тут нагуглил фреймворк go-kit, но как-то очень громоздко віглядит вся єта система миддлваров без дженириков.
Как мы пересадили всю команду на другой язык за один день (на самом деле нет)