Как мы пересадили всю команду на другой язык за один день (на самом деле нет)


    Начало шаблона для быстрого «заземления» PHP-разработчиков в Go

    15 лет мы делали бэкенд на PHP. И вот однажды было принято стратегическое решение: сначала переписать самые высоконагруженные места на Go, а потом разрабатывать новые сервисы на нём.

    Представьте: вы хотите рассказать про новый язык команде из 40 разработчиков, которые настолько хорошо готовят PHP, что собрали на нём многопоточную систему реального времени и высокой доступности. В худшем случае вас сожгут, в лучшем — прислушаются, но продолжат делать как раньше. Это если вводить язык насильно.

    Поэтому мы решили сначала устроить хакатон, а потом позвать на тёмную сторону всех желающих. Если бы их набралось хотя бы человек десять, то со временем они показали бы всем остальным личным примером, как это круто.

    Расскажу по шагам, как повторить такой опыт у вас. И про результаты нашего внедрения. И про то, что случается в голове у PHP-разработчика при виде нового языка.

    Мы начали с подготовки шаблона и CI/CD, который позволяет задеплоиться за 15 секунд. Чтобы его написать самому, нужно где-то недели две. Мы сделали его заранее.

    Шаг 1. Рассказать про Golang


    У нас часто и много проводятся внутренние семинары. Кто-то хочет что-то рассказать, пишет объявление, собирает людей и рассказывает. Бывает, это особенности регулирования авиатрафика в России, бывает, рассказ про путешествие, но куда чаще речь идёт про какую-то технологию или фичу, которая была реализована. И может быть полезна ещё кому-то. Так вот, мы собрали внутренний семинар по Go, где рассказали про преимущества языка. Быстрый (компилируемый без бубна: PHP тоже можно скомпилировать, но сложнее), многопоточный из коробки, довольно просто поддерживаемый, можно писать без фреймворка прямо в блокноте, то есть нет геморроя с зависимостями третьего уровня, которые тащит за собой развитый фреймворк. Деплой за 15 секунд. И вроде даже нет никаких очевидных недостатков именно в нашей ситуации. Предлагаем попробовать. Это было как рассказ о другом мире: вот язык, смотрите, чем он отличается, на следующих выходных будет хакатон для тех, кому интересно.

    Шаг 2. Документация


    За три дня до хакатона рассылаем ссылку на получасовой вводный курс по синтаксису, основным типам данных и функциональности. И базовую документацию. Вот что получили разработчики:

    golang.org/doc
    tour.golang.org

    Плюс контакты Go-senior внутри.

    Шаг 3. Группы


    Дальше мы предложили разбиться на группы и принести задачи, которые хотелось бы здесь и сейчас реализовать на новом языке. Сразу предупредили, что хакатон будет в офисе в нерабочее время (в субботу), дело добровольное, но можно будет решить боевую задачу и поучиться на практике в почти парном режиме с человеком, который знает нюансы языка. Это заинтересовало 40 человек, и они начали биться на группы и набирать задачи. С группами получилось не у всех: многие пришли с задачей только на себя одного, группы были по два, реже — по три человека. Сами задачи были сверху бэклогов или относились к дублированию какого-то тормозящего места.

    Конечной целью было сделать задачу на хакатоне, которую потом можно будет докрутить немного и «продать» владельцу продукта (руководителю направления). В духе: «Вот смотрите, оно раньше 40 секунд работало, а теперь за две всё делает». Эта часть — важнейшая для стратегического успеха внедрения языка в командах: нужна маленькая победа в самом начале.

    Шаг 4. Невидимая работа


    Подготовили шаблон, про который я говорил выше, под нашу инфраструктуру, который позволял бы запускаться сразу без плясок по сборке и подключению всего нужного. Этот шаблон как бы заменяет фреймворк. Выкладывать его особого смысла нет: повторюсь, он очень заточен именно под нас.

    Перечислю лишь функционал, который был заложен в шаблон:

    • Интеграция с k8s.
    • Экспорт метрик в prometheus.
    • Конфигурация через переменные окружения.
    • Http-сервер.
    • Opentracing.
    • Логгер.

    У нас уже задолго велась работа по изучению Kubernetes и в качестве решения мы выбрали OpenShift, который предлагал большие возможности по кастомизации и настройке CI/CD. Так мы заточили шаблон сразу под k8s. Созданное приложение в OpenShift создает репозиторий, собирает скелет приложения, сервис в k8s, применяет политики безопасности, собирает бинарник, деплоит в k8s и меньше чем через минуту сервис доступен в сети. Так хакатон стал еще и мероприятием, на котором разработчиков познакомили с нашей будущей PaaS.

    Также подготовили дашборд в Grafana с основными метриками, настроили экспорт логов для Kibana и агенты для Jaeger. Для каждого сервиса генерируются ссылки на сервисы, по которым можно сразу получить всю необходимую информацию.

    Дальше нужно было договориться про доступы к базам данных, которые нужны для решения задач участниками хакатона. Это неправильно, но мы подключались к боевым базам в read-only на время работы. Это ещё причина, почему суббота — нагрузка в этот день наименьшая.

    Предупредили кухню (напомню, она у нас бесплатная на перекусы — творог-фрукты, но не на горячую еду) про мероприятие. Еду подвезли в офис, чтобы мы не отвлекались.

    Шаг 5. Сам хакатон


    По очевидным причинам (семья, отдых) некоторые не смогли в ту субботу, поэтому мы разбили на заходы по 15 человек.

    Рассказали про нашу PaaS-платформу, как создавать из шаблона приложение, как пользоваться шаблоном. Это каркас, в котором есть обёртки для сбора метрик, хелс чеков и метрик, подключения к базе данных и так далее, показали, как подключать всякое разное. Можно было всё удалить на месте или заранее (шаблон тоже раздали до хакатона). Это готовое приложение, которое надо расширять.

    Рассказали про деплой и особенности разработки под Kubernetes (конфигурирование, логирование, метрики, работа с ready-пробами, выделение ресурсов по процессору и памяти и т. д.). Попробовали задеплоить «Hello, world!».



    Ребята сами создали сервисы. Приятно удивились простоте и удобству использования шаблона. Кто-то уже успел попрактиковаться на Golang, кто-то просто пролистал документацию.



    У нас не было цели показать, как писать хорошо, нужно было получить грубый функциональный код и показать, как всё быстро может уйти в препрод, как всё быстро работает и как легко вносить правки.

    План был такой: команды пишут, если есть вопросы — отвечаем. Потом сессия ревью и помощь по тому, как можно на Golang сделать что-то правильнее по архитектуре.

    Из когнитивных искажений PHP-мидлов стоит отметить «старый» способ мышления в одном потоке. В Go хорошая встроенная конкурентная модель и многопоточность «из коробки», чего не было на PHP. Код получается очень читаемый, чего тоже мало кто ждал.

    Мы на практике не всегда используем многопоточность. Зависит от задачи. Но под капотом она тоже есть, и, где нужно, скорость растёт за счёт неё. Например, на любой входящий запрос REST создаётся отдельная горутина. Golang может обрабатывать несколько запросов одновременно, когда большинство других языков (включая PHP) по умолчанию строят их в очередь и обрабатывают в один поток на каждый воркер.

    Вторая особенность — большая боль с возвратом ошибок. Если многопоточность — это просто другая архитектура и к ней легко привыкнуть за час-два, то в случае с ошибками при переходе с PHP — это изменение всей модели мышления. Возврат ошибок из функций — основная парадигма в Go. В PHP всё привычно оборачивают try-catch. А тут требуется обработать явно в теле функции. Некоторых людей зверски бомбило от этого «замедления», они активно сопротивлялись. Всё потому, что подход довольно близок к TDD, а TDD требует терпения во время написания кода, но зато прост в отладке. Это увеличивает код по строчкам «если — ошибка», зато один раз пишешь и не возвращаешься. Это очень важно в архитектуре микросервисов, потому что микросервисы растут как грибы и один разработчик может написать десятки микросервисов. Постоянно переключать контекст и дебажить ошибки — это очень дорого и неэффективно. Если сделать все правильно, то приложение будет работать годами, так же эффективно, как и во время разработки. А на PHP в такой же ситуации велика вероятность, что при неправильном написании кода будут постоянно всплывать новые ошибки, после чего надо будет отлаживать всё заново.

    Получились портянки в main. Когда функциональная часть была запущена — уже разбирались, как лучше это разбить по пакетам. Потом было ревью. Когда тебе помогает Go-senior, это сразу очень полезно. Кому-то показали, как постоянные походы в базу заменить на кеш в оперативной памяти. Кому-то помогли переписать код в параллельное исполнение. Где-то были мелкие затыки вроде того, что HTTP-сервер на PHP традиционно поднимается и умирает, а тут остаётся висеть.

    Шаг 6. Репозиторий


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

    Итоги


    Восемь часов хакатона в два потока по плюс-минус 15 человек (напомню, из 70 разработчиков 40 хотели попробовать Go и получили документацию и шаблон, но не все могли в один день или хотели участвовать физически).

    Четверть сервисов давали ожидаемый результат сразу. Ещё часть либо требовала долгих доработок со стороны монолита PHP, либо просто была обширнее восьми часов. Ещё примерно половина сервисов была доделана до прода позже.

    В итоге все познакомились с языком, платформой OpenShift, как их женить вместе и так далее. Увидели шаблон приложения и новый CI/CD, получили весь набор инструментов, чтобы дальше решать свои задачи на Go.

    Дальше «продавали» фичи владельцам продуктов. Мы отвечали на вопросы по архитектуре от руководителей команд.

    В течение следующего месяца примерно все вместе дописывали шаблон (который мини-фреймворк) под потребности подразделений. В итоге он стал побольше. Да, ещё одна особенность шаблона: вся конфигурация — через переменные окружения, то есть при локальной разработке и при переходе на препрод-прод всё идеально одинаково работает. Докер этим и хорош.

    Из хакатона пошёл в массы не только Go. Появились шаблоны в PaaS-платформе для PHP и Node.js, но всё равно при прочих равных разработчики чаще выбирают Go как язык для микросервиса. В итоге на практике все новые микросервисы прода, написанные после хакатона, написаны именно на Go. То есть мы распиливаем монолит и сразу всё новое пишем под Kubernetes. К концу года переедем туда почти полностью.

    Те, кто не пришёл, расспросили коллег, что это было. Потом подходили и спрашивали по языку, сделали несколько задач в фоновом режиме (к основной работе), дальше положили код в репозиторий и получали пулл-реквесты от других только что обученных разработчиков и от Go-специалистов. Интересовались книгами. То есть мы были ещё несколько недель техподдержкой второй линии.

    Для тех, кто хотел продолжать обучение, создали группу в Телеграме с книгами и прочим. Также организовали гильдию Golang-разработчиков, где еженедельно обсуждаем возникшие вопросы в работе, разрабатываем общие компоненты, делимся хорошими практиками. Вступить может любой разработчик.

    Самое большое следствие — через месяц мы переписали один из самых нагруженных участков, и он стал работать примерно в шесть тысяч раз быстрее в проде. Но про это я лучше расскажу отдельно: там не только особенности языка, но и реализация многопоточности, пара архитектурных улучшений и немного шаманства. Самое главное — вот наш опыт знакомства с языком, и его в целом легко повторить у вас, если есть хотя бы один Go-специалист, который потратит пару недель на обучение.

    Другие посты про нашу разработку: история 15-летнего монолита, продуктовый подход к кухне, что должен знать разработчик про бизнес, особенности возврата авиабилетов.
    Туту.ру
    364,42
    Tutu.ru — сервис путешествий №1 в России.
    Поделиться публикацией

    Похожие публикации

    Комментарии 38

      –2
      Спасибо, «вкусно» написано, сразу почему-то захотелось пойти потыкать палкой в ту сторону — а то про Go вяло почитывал, а тут вполне понятный кейс с хорошим результатом. Даже на два порядка меньшее итоговое ускорение — уже интересно :) плюс более актуальная архитектура…
        0
        Ускорение обычно на полпорядка или порядок, это редкий случай, где мы чуть ли не Джона Бентли вспоминали для оптимизации.
        +17
        Возможно я не прав, но мне видится некоторое противоречие между:
        40 разработчиков, которые настолько хорошо готовят PHP

        и
        мы переписали один из самых нагруженных участков, и он стал работать примерно в шесть тысяч раз быстрее в проде

        Я подозреваю, что 6000х это не соотношение скоростей работы Go и PHP, а, скорее, указывает на грубую ошибку в варианте PHP
          0
          Мы отрефакторили логику, и это дало кратный прирост. Но go позволяет лучше работать с памятью. Наибольший эффект среди всего прочего дало хранение заранее заготовленных (предобработанных) данных в памяти приложения. Такой роскоши в PHP мы себе позволить не могли.
            +5

            Поздно давать совет, но phpreact уже давно существует и писать с его помощью асинхронные приложения (к сожалению в один поток) очень легко.


            6к прирост, это значит у вас там сильно устаревший подход, когда каждый запрос запускает php скрипт и оно заново грузит все откуда то, и не удивляюсь, если из бд, без хотя бы кеширования.

        +10

        Очень удобно получилось — и работали в нерабочее время и в рабочее время выгода получилась для компании.

          –4
          Польза для обеих сторон, не только для компании. Если вам предложат посмотреть на другой язык, за которым может быть будущее, и который точно поднимет вашу ценность как профессионала в интенсиве с senior’ом, готовым шаблоном и готовой средой, реальных задачах — вы откажетесь? К тому же это было всецело по желанию, да и организовать встречу в рабочее время было слишком сложно (у всех команд свои планы и ритмы).
            +10

            Да, если это в выходные то откажусь и посмотрю на это в рабочее время. Работники IT в России не так много требуют чтоб ещё экономить на их образовании, которое очевидно пошло на пользу компании.

              +5

              Во внерабочее? Предложу более интересный мне язык.

                +1
                Если как курсы, с получением сертификата, доказывающий «ценность», то не откажусь наверное.
                А так для «поглазеть и пощупать» больше нравится вариант
                Те, кто не пришёл, расспросили коллег, что это было.
              +2
              у вас на скриншоте нет gofmt
                +1
                Мы пошли по другому пути, я пишу на Go и на Swoole. Так вот мы свою команду разработчиков не стали мучать Go, и они пишут на Swoole теперь — тот же PHP, вид сбоку, и работает так же быстро как и сервисы на Go, всё асинхронно, и мне не пришлось переучивать народ особо.

                Кое-что для примера выложил недавно, это черновики пока по сути — github.com/eltaline/swoole-pool/tree/master/examples — доработаю еще пулеры, попрячу логику в классы в отдельные файлы, поудобнее сделаю. Производительность так же по сравнению с PHP-FPM выросла в сотни раз.
                  0
                  Когда у нас была конвертация из VB в C#, мы написали простенький конвертор из одного языка в другой, в котором учитывалась специфика нашего проекта и конвертация получилась очень лёгкая. По крайней мере большая часть рутинной работы была убрана. VB -> C# конечно сильно проще, чем PHP -> Go, но я думаю что вполне осуществимо.

                  Плюс если выложить конвертор в opensource, то это послужит популяризации языка.
                    +1
                    Не взлетит.
                    PHP: отработал и умер, один поток, память в лайф-цикле не шарим, потому что шарить не с чем, и цикл короткий, смысла нет.
                    Go: долгоживущий процесс, многопоточность/асинхронность, а значит есть кеши в памяти, примитивы синхронизации и вся многопоточная кухня.
                    Разница не столько в языке, сколько в архитектуре. Конвертер языка — реализуемо, конвертер архитектуры… Ну, они есть, называются `senior architect`, просят много денег за работу и не любят сверхурочных.
                      0
                      Во-первых как я написал, конвертор который учитывает специфику проекта, 80% кода это не уникальные наукоёмкие методы, а обычный CRUD, для которого легко можно автоматизировать перенос, с правильной конвертацией.

                      Во-вторых, даже для переноса на совершенно другую архитектуру есть части кода которые можно переиспользовать и затраты на написание конвертора могут с лихвой окупиться.

                      В-третьих, иногда имеет смысл в переносе некоторых некритичных частей AS-IS, т.е. с минимальными изменениями, пусть даже это неправильно, но поддержка двух технологий может быть более затратной. И сэмулировать простое поведение PHP в Go гораздо проще, чем сэмулировать Go в PHP.

                      Так что вполне реалистично, если конечно не теоретизировать и быть реалистом, а не перфекционистом.
                        0
                        конвертор который учитывает специфику проекта


                        Не окупится, т.к.:
                        а) пилить лексический анализатор и синтаксическое дерево силами команды опытных веб-разработчиков заради миграции одного проекта — неэффективно;
                        б) заказывать у разработчиков лексических анализаторов и строителей синтаксических деревьев транслятор веб-проекта на другой язык заради миграции одного веб-проекта — дорого.

                        При любых раскладах эффективнее и дешевле «тупо переписать», тем более, что у вас, при наличии готового веб-проекта нуждающегося в миграции, видимо, команда веб-разработчиков, которые «в теме», уже есть. А опыта в написании трансляторов языков у этой команды, вероятно, нет. Не то, чтобы нельзя было обучить, но поднимать такой пласт заради миграции проекта, а потом тупо «забывать как страшный сон» с целью вернуться к веб-разработке на «немного другом языке»… Ну, такое себе.

                        Во-вторых, даже для переноса на совершенно другую архитектуру есть части кода которые можно переиспользовать и затраты на написание конвертора могут с лихвой окупиться.


                        Не окупятся. Трансляторы = дорого.

                        В-третьих, иногда имеет смысл в переносе некоторых некритичных частей AS-IS, т.е. с минимальными изменениями, пусть даже это неправильно, но поддержка двух технологий может быть более затратной. И сэмулировать простое поведение PHP в Go гораздо проще, чем сэмулировать Go в PHP.


                        Осталось понять, какого эффекта вы хотите добиться от миграции на Go. «Переведите в лоб» на Go PHP-шный проект, и прирост производительности составит… ничего. Возможно, даже просядете. Выигрыш будет исключительно в архитектуре, сам по себе в линейной логике Go не очень быстрый.

                        Так что вполне реалистично, если конечно не теоретизировать и быть реалистом, а не перфекционистом.


                        Не, это, конечно, реалистично, я не отрицаю. Только нерентабельно, шописец.
                          0
                          пилить лексический анализатор и синтаксическое дерево силами команды опытных веб-разработчиков заради миграции одного проекта — неэффективно
                          Поэтому надо взять существующий и на его базе расширить. У нас на всё-про-всё заняло в общем три дня одного человека (Пара дней сразу и потом понемножку допиливали).

                          Чем бояться, надо просто взять и потратить пару часов на попробовать и если будет какой-то эффект, то продолжить. Потом само попрёт, будет реально вставлять как оно классно получается. Мы в конце концов даже плагин для IDE сделали, выделяешь блок на VB, из контекстного меню выбираешь «Сделать C#» и у тебя в clipboard сконвертированный код лежит. Не идеальный конечно, но это сильно лучше чем тупо синтаксис переводить.

                          Я конечно с PHP уже лет десять неработал, но поискав, нашёл что-то похожее https://www.php.net/Tokenizer и https://github.com/nikic/PHP-Parser. Должно хватить на простенький конвертор.
                          Осталось понять, какого эффекта вы хотите добиться от миграции на Go.
                          Перевести 5% самого тормозного правильно, перевести всё остальное как есть и по мере работы, потихоньку рефакторить. Гигантоманские проекты всё сразу перевести не работают, а оставить часть там и часть здесь, это растянется на десятилетие.
                            –1
                            Перевести 5% самого тормозного правильно
                            Почти никогда РНР и даже Руби (намного более медленный ЯП) и не являются узкими местами приложения. В отдельных случаях можно сделать микросервис, использовать ReactPHP/RoadRunner/Nginx-unit и т.п.
                        0

                        Не есть, а могут быть, но могут и не быть.

                          0
                          Ну, ладно, переформулирую: есть возможность. С одним нюансом: если возможности, которые есть, не использовать, нафига мигрировать?
                            0

                            Чтобы потом начать использовать. Постепенное улучшение. Сначала переносим "в лоб", главная задача — перенести без потери функциональности и нарушения нефункциональных требований. А уж потом начинаем в узких местах улучшать, использовать новые возможности.

                      +1
                      Я вот тоже пытался разобраться и пописать код, документация в целом норм и все понятно. Но не хватает best practices по организации кода. Подскажите пожалуйста какие нибудь книги а лучше достаточно большие проекты где много бизнес логики, чтобы посмотреть как надо
                        0

                        prometheus посмотрите

                        +8
                        Можно писать без фреймворка прямо в блокноте, то есть нет геморроя с зависимостями третьего уровня, которые тащит за собой развитый фреймворк.


                        Вот я php разработчик, и данная рекламная фраза рождает у меня смутное беспокойство, что развитый фреймворк, от которого мы так легко отказались, на golang придется потом писать заново и самому. Т.к. потому на php у него столько зависимостей и есть, что эту работу какой-то хороший человек сделал за тебя и выложил в общий доступ. Поэтому мне правда очень интересно, что в golang такого особенного, что позволяет безболезненно обходиться без него.

                        P.S. В nodejs, на мой взгляд, похожая идеология «фреймворк не нужен, хватит библиотек. А в итоге надо сначала это все вместе как-то собрать, а потом все равно получается конструктор „сделай сам“, где самые простые и нудные вещи нужно прописывать вручную, попутно изобретая один велосипед за другим.
                          0

                          Как минимум аналоги PSR response, request, handlers, Middlewareи и роутеров в терминах популярных php фреймворков — часть стандартной библиотеки. То есть микрофреймворки, включая "голую" симфонии по сути уже точно не нужно, он уже есть из коробки. На нодовский экспресс по моим впечатления похож.

                            +1
                            Вот я php разработчик, и данная рекламная фраза рождает у меня смутное беспокойство, что развитый фреймворк, от которого мы так легко отказались, на golang придется потом писать заново и самому.


                            Ну, не сгущайте краски. Эта фраза — действительно рекламная, и имеет достаточно мало общего с реальностью и здравым смыслом. На самом деле, тут чутка иначе все:

                            1. «прямо в блокноте» — ну, такое можно про любой язык сказать. В конце-концов код — это просто текст, и сама возможность писать его в блокноте, на листочке, на стене в подъезде и т.д. и т.п. — неотъемлемое право любого программиста. Однако здравый смысл подсказывает, что IDE лишними не бывают, и родить что-то крупное без IDE можно, только плохо, медленно, в страданиях, да и зачем? IDE эффективности реально прибавляет.

                            2. «Можно писать без фреймворка» — а вот это чистая правда. Стандартная библиотека достаточно богата — это раз. Ну и не взлетают монструозные фреймворки на Go — это два. Фишка вся в том, что мидлвари, роутеры, сериализаторы, хендлеры, обертки над запросом/ответом в Go есть. Они есть в стандартной библиотеке, они есть альтернативные, хорошие (и не только) и разные, много их.

                            Вопрос большого фреймворка в том, что у вас все «в одной большой коробке», т.е. для того, чтобы замутить CRUD, для которого ценность модулей сложнее роутера сомнительна, вы один фиг принесете весь фреймворк, вместе со всеми мидлварями, ормами и т.д. и т.п. Так уж разработчики упаковали.

                            В Go больше принято «мухи отдельно, котлеты отдельно». У вас есть http Request/Response, у вас есть маршаллер/анмаршаллер, у вас есть мидлвари, у вас есть роутер. И все это отдельно. Да, мидлварь или роутер попросит, чтобы вы дали ей http.Request и контекст. Только дать вы можете не только реализацию стандартной библиотеки, но и любую альтернативную, до тех пор, пока она реализует интерфейс. Вот в этом месте у вас появляется а) выбор, б) возможность притащить в проект только и исключительно то, что вам нужно, ни каплей больше.

                            В nodejs, на мой взгляд, похожая идеология


                            Ну, с нодой трабла-то, собственно, в чем: отсутствие типизации не позволяет определить интерфейс, который необходимо реализовать для совместимости имплементации. Ну, т.е. да, там немножко жопа.
                            +2
                            туда где документация(шаг 2) я бы добавил еще gobyexample.com
                              0

                              Спасибо. Сохранил.

                              +3
                              1) Язык Go — весьма специфичный и писать на нем нужно любить (это какой-то гибрид функционального стиля из Python и С).
                              2) Парадигма разработки на GO отличается от того, что требуется в PHP.
                              3) Разработка на Java гораздо ближе к PHP, чем к GO — если уж нужно стать супер оплачиваемым.

                              Я к тому, что если вы волевым решением говорите PHP разработчикам пересаживаться на GO, то определенная часть (я бы сказал большая), откажется и уйдет в другое место.

                              Вакансий на GO не так много, и все эти вакансии идут в «жопные» места, где реально надо сидеть думать и писать «умный» код, и так каждую задачу. И если человеку не нравится такой темп работы, то проще поменять энтерпрайз PHP на энтерпрайз на Java и добрать свои деньги по зп.

                              Для каких-то задач Go, конечно, хорош. Но переводить какой-то условный CRUD уровня пхп на него — да ну нахер.
                                0
                                (это какой-то гибрид функционального стиля из Python и С)


                                Функциональности там ни на грамм, если честно. Обычный процедурный стиль.
                                +1
                                Хочу поблагодарить вашу компанию за то, что до сих пор работают страницы www.tutu.ru/01.phpwww.tutu.ru/10.php, с помощью которых даже на самом слабом железе, не поддерживающем javascript, можно легко узнать расписание московских электричек.
                                  0

                                  Круто, молодцы!


                                  А шаблончиком полным поделитесь? Хотя бы go частью, с k8s думаю всё индивидуально.


                                  А то сижу и пилю первый сервис на Go, взамен пхп прототипу, архитектуру, если можно это так назвать, менял уже раз 10. Вот про контекст узнал, теперь ещё раз переделывать.

                                    0
                                    Наш вам не сильно поможет. Шаблон сильно интегрирован в текущую инфраструктуру и для вас он будет не приминим.

                                    Все-таки шаблон зависит от проекта, окружения и т.п. Важнее построить правильную архитектуру. Мы опирались на 12 факторов.

                                    В целом в статье перечислена основаная функциональность. Для k8s cтоит отметить следующие:

                                    • ручки с хелсчеками (liveness- и readiness-пробы);
                                    • ручка для выгрузки метрик (для prometheus);
                                    • логи экспортируем в формате json в stdout (для fluentd);
                                    • конфигурация пакетов через переменные окружения (локально .env);
                                    • настройка GOMAXPROCS по ресурсам выделеным на docker-контейнер (пакет automaxprocs от uber).
                                      0

                                      Да с вот этой функциональностью проблем как раз нет, я уже лет 5 так пишу сервисы, но не Go, а на PHP (Symfony и немного Laravel). Вот всё что вы назвали я уже реализовал на Go (кроме GOMAXPROCS — ещё не встречалось). Но мне страшно смотреть на свой код, воняет жутко. Ну такие вещи, как передача значения http заголовка Request-Id в функцию, делающую SQL INSERT структуры в базу, чтобы она смогла в if err != nil сделать log с ним через всё приложение. Или подобное таскание за собой коннекшена к БД, чтобы там же откатить транзакцию. Хочется посмотреть именно лучшие практики для такой инфраструктурной функциональности. С бизнес-логикой особых проблем нет как раз, хотя и есть бесящие детали.

                                        0
                                        Ну такие вещи, как передача значения http заголовка Request-Id в функцию, делающую SQL INSERT структуры в базу, чтобы она смогла в if err != nil сделать log с ним через всё приложение


                                        Погуглите context.

                                        Или подобное таскание за собой коннекшена к БД, чтобы там же откатить транзакцию.


                                        Там один фиг пул, так что, вероятно, зря таскаете. Таскать надо не коннекшен, а транзакцию.
                                          0
                                          Погуглите context.

                                          Спасибо, чуть раньше успел узнать о нём и теперь в процессе очередного переписывания с нуля. Как раз вот просил шаблончик, чтобы избежать очередного переписывания из-за того, что узнал о какой-то штуке слишком поздно. Или узнать-узнал, но применяю, скажем так, не эффективно. Вот у меня сейчас в контексте логгер, транзакция (думал коннекшен, а разобрался по вашему совету и понял, что транзакция, там при старте клонируется коннекшен), MQ коннекшен, http request id (в основном для логгера), надо бы добавить что-то для метрик типа клиента прометеуса и, наверное, сам реквест и респонс райтер. Даже не просто сервис-локатор, а прямо глобальный неймспейс PHP с суперглобальными переменными, причём ближе к PHP4, чем к PHP7.


                                          Тут нагуглил фреймворк go-kit, но как-то очень громоздко віглядит вся єта система миддлваров без дженириков.

                                    0

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое