PHP жив. PHP 7 на практике

https://tech.olx.com/phps-not-dead-php7-in-practice-2c95b7a5c56
  • Перевод

Недавно PHP-проекты Avito перешли на версию PHP 7.1. По этому случаю мы решили вспомнить, как происходил переход на PHP 7.0 у нас и наших коллег из OLX. Дела давно минувших дней, но остались красивые графики, которые хочется показать миру.


Первая часть рассказа основана на статье PHP’s not dead! PHP7 in practice, которую написал наш коллега из OLX Łukasz Szymański (Лукаш Шиманьски): переход OLX на PHP 7. Во второй части — опыт перехода Avito на PHP 7.0 и PHP 7.1: процесс, трудности, результаты с графиками.




Часть 1. PHP 7 в OLX


Компания OLX Europe управляет десятью сайтами, самый большой из которых — OLX.pl. Все наши сайты должны работать максимально эффективно, поэтому миграция на PHP 7 стала для нас основным приоритетом.


В этом посте расскажем, с какими проблемами пришлось столкнуться и чего удалось получить с переходом на PHP 7. Про переход было рассказано на конференции PHPers Summit 2016.


Слайды

Переход


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


Стоит упомянуть, что десять наших сайтов работают в разных странах. И изменения мы выкатываем последовательно: на один сайт за другим. Такой подход особенно важно применять при серьёзных изменениях.


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


Memcache


Отказ от поддержки Memcache в PHP 7 подтолкнул нас к переходу на Memcached. Пришлось поддержать две версии сайта: PHP 5 + Memcache и PHP 7 + Memcached.


Для решения задачи использовали простенькую обёртку. Она выбирает подходящий PHP-модуль для соединения с кэшом, исходя из информации о сервере, на котором выполняется код.


<?php
$factory = new CacheWrapperFactory();
$factory->createServer(
  extension_loaded('memcache') ? 'memcache' : 'memcached',
  $uri
);

Однако, приключения с Memcached на этом не закончились. Выяснилось, что объекты, сериализованные с помощью Memcache, не могут быть десериализованы с помощью Memcached.


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



APC, APCu и OPCache


Немного о терминах.


APC (Alternative PHP Cache) — это кэш байт-кода и пользовательских данных.
APCu (APC User Cache) — только кэш пользовательских данных.
OPCache — только кэш байт-кода.


В PHP 7 нет APC, нам пришлось взять и APCu, и OPCache. Ранее мы использовали API APC во многих критичных частях нашего фреймворка, управляющего кэшем, поэтому мы прикрутили к APCu модуль apcu-bc, совместимый с API APC.


Результаты


Ниже представлены результаты самого большого из наших сайтов, OLX.pl.


CPU на Apache


Наши веб-серверы (Apache) крутятся на 20 физических машинах с 32 ядрами процессора каждая. Пиковое потребление процессора в результате миграции снизилось с 50% до 20%.



LA на Apache


Подобным образом снизился и Load Average на веб-серверах.



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


Причины эффективности PHP 7


Таких поразительных результатов удалось добиться благодаря оптимизации в трёх основных областях.


Меньше операций выделения памяти


PHP 5 расходовал 20% потребляемого им процессорного времени только на операции выделения памяти. Разработчики языка обратили на это внимание, уменьшили количество операций выделения памяти, чем значительно снизили потребление процессора.


Меньше потребление памяти



Этот набросок показывает путь, который процессору нужно пройти для доступа к оперативной памяти (RAM), с указанием времени на каждый шаг. Как видно, отрезок до оперативной памяти — самый длинный. Разработчики PHP снизили потребление памяти, ускорив отклик приложений.


Меньше промежуточных указателей



Последняя причина улучшения эффективности PHP 7 — уменьшение числа промежуточных указателей. Для этого разработчики PHP избавились от множества указателей, ссылающихся на другие указатели; вместо этого они заставили указатели ссылаться непосредственно на запрашиваемые сущности.


Код


Помимо улучшения эффективности, PHP 7 припас небольшую революцию структуры кода.


Скаляры в объявлении функции


До PHP 7 типами аргументов функции могли выступать только объект, интерфейс, массив или функция обратного вызова (callable). Возьмём для примера следующий код.



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


Помимо добавления проверок типов в каждый метод, можно использовать конструкт ValueObject из предметно-ориентированного программирования (DDD).



PHP 7 позволяет просто указать скаляры, такие как string, int, float, bool. Кроме того, можно указать тип возвращаемого значения.



Strict-режим


Но простое добавление вышеуказанных конструкций в код может не дать ожидаемых результатов. Всё потому, что PHP 7 по умолчанию работает в coercive-режиме, в котором происходят обычные преобразования типов. Если вы принудительно не включили strict-режим, можно переписать вышеуказанный метод следующим образом.



К сожалению, даже добавление конструкции declare(strict_types=1) в файл PHPisNotDead.php не включает strict-режим. Объяснение в примере ниже. В комментариях указаны возвращаемые значения.



Почему так происходит? Строгая типизация в методах класса PHPisNotDead включилась только для возвращаемых значений.



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



Больше информации об указании типов и его влиянии на выполнение программы можно прочитать в документации. Чтение этой документации убережёт от сюрпризов при выполнении вашего кода.


Будущее


Если даже сейчас вы всё ещё не решились перейти на PHP 7, загляните в список поддерживаемых версий PHP. Версия 5.6 уже не получает активной поддержки, а в конце 2018 года перестанут выходить даже исправления критических уязвимостей. Активная поддержка продолжается для версий 7.0 и выше.



Следите за новостями мира PHP и планами относительно новых верий. Наиболее интересные посты: дружественные классы, generic-типы и функции. Найти другие предложения о развитии языка можно в PHP RFC.


Итоги


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


— Когда стоит перейти на PHP 7?
— Прямо сейчас.


Часть 2. PHP 7 в Avito


Процесс перехода на PHP 7.0


Мы так же, как и OLX, осуществляли перевод наших сервисов на PHP 7 постепенно. Сначала перевели небольшие отдельностоящие сервисы, протестировали их, исправили возникшие ошибки. Далее перешли к последовательному обновлению серверов админки сайта, после чего раскатывали на PHP 7 оставшиеся сервисы и сайт.


Трудности перехода


Мы прочитали список обратно несовместимых изменений. Однако это не уберегло ото всех бед.


В старом коде нашёлся класс с названием String. PHP 7 выдал ошибку “Cannot use 'String' as class name as it is reserved”. Класс переименовали. Обратите внимание на список зарезервированных слов.


В PHP 7 изменился формат кеш-файла для WSDL-схемы в SoapClient. Можно настроить сохранение кэша в разные директории в зависимости от версии PHP или полностью очищать кэш перед сменой версии интерпретатора.


Расширение mongo, которое мы активно использовали, перестало поддерживаться в новом PHP. Вместо него мы стали использовать официальную библиотеку MongoDB PHP Library. Прошлись по всему коду и заменили MongoCollection::insert() на MongoDB\Collection::insertOne(), MongoCollection::remove() на MongoDB\Collection::deleteMany() и далее по списку. Стали использовать классы для работы с BSON из нового драйвера MongoDB, например, MongoDate вместо MongoDB\BSON\UTCDateTime.


Результат


Админке полегчало.




Бэкенд сайта тоже доволен.




Обновление до PHP 7.1


В PHP 7.1 появилось несколько очень приятных нововведений: тип void для возвращаемых значений, iterable, возможность вернуть null для типизированных возвращаемых значений, область видимости констант и прочее. К тому же, период активной поддержки PHP 7.0 заканчивается уже в конце этого года. Решили обновиться до PHP 7.1.


Неожиданности


При обновлении на ровном месте образовалась проблема. Пакет php-memcached для 7.1 потянул за собой пакет php-igbinary. Когда поставили PHP 7.1 на один из боевых серверов, с остальных серверов начали сыпаться ошибки, в которых фигурировало слово “igbinary”.


Старый друг Memcache, снова различия сериализации, но немного под другим соусом. Выяснилось, что модуль php-memcached по умолчанию использует первый доступный сериализатор из списка: igbinary (в отдельном модуле), msgpack (в отдельном модуле), php (не требует отдельного модуля, доступен всегда). И тот сервер, на котором мы поставили 7.1 с igbinary, начал записывать данные в мемкеш, сериализованные igbinary. А на остальных серверах не было поддержки этого сериализатора, и они не могли прочитать данные, записанные сервером с обновлённым PHP. Локализовали проблему, установили igbinary на всех остальных серверах, ошибки прекратились.


Послесловие


Разработчики PHP взяли хороший курс. Они добавляют полезные инструменты, избавляются от недостатков, связанных с наследием языка, всерьёз задумываются о производительности.


Ранее мы уже рассказывали о переходе Avito на сервисную архитектуру (раз, два). Такая архитектура позволяет писать на любых языках, и новые сервисы мы чаще всего пишем на Go или Python’е. Однако об отказе от PHP речи не идёт: основная логика сайта (монолит) всё ещё на PHP, а команда отлично знает, как с ним работать. Новые версии интерпретатора позволяют сделать код лучше, а его выполнение быстрее.


Делитесь вашим опытом перехода на PHP 7 и выше, будем рады обсудить открытия и грабли, которые встретились вам на этом пути.

Avito 224,46
Avito – сайт объявлений №1 в России
Поделиться публикацией
Комментарии 81
  • –18
    PHP всё же умирает.
    С новыми фичами мы лишились конкурентного преимущества — быстро и дешево. С фреймворками вроде Zend и Symfony и заморочками с типизацией время и объёмы кода стали сравнимы с Java и C#, в которых данные фичи существуют давно и реализованы не так костыльно как в PHP. И пока мы изобретаем гибернейт и играем во взрослый язык, конкуренты наоборот становятся проще и более дружественными к вебу.

    А на рынке «быстро и дешево» позиции заняли nodejs и go, на подходе kotlin. Спасает ещё популярность laravel, но уровень разработчиков там печален.
    • +1
      Все таки не в языке дело, а в архитектуре и навыках разработчика.
      И на Java и на C# можно писать так, что из глаз кровь пойдет

      PHP разрабы дешевле, но все таки будущее за раздельным бэкендом VueJs + GoLang + PostgreSQL допустим для начинающего будет вполне правильным выбором в изучении чем PHP.

      PHP никогда не умрет, я даже встречал веб морду на VisualBasic у одного крупного хостера, а вы тут PHP умирает пишите
      • +2
        Я говорю о проектах с нормальным бюджетом, где php-шники получают как минимум не меньше коллег c других языков. Такие проекты исчезают. За последних пару лет их количество сократилось в разы, отделы php начали сокращать и переучивать на javascript ± node.
        p.s. У меня информация о Минских компаниях, который в основном работают на запад. «Диджитал» и Битрикс конторы с дешёвой и некачественной рабочей силой я не считаю.
        • +3
          Magento будет еще достаточно долго жить. Разрабам М1/2 порой платят и поболе синьер джавистов.
          • +4
            … у меня информация...

            называется невалидная выборка.


            … Битрикс конторы с дешевой и некачественной...

            цеховой снобизм фронтендщика мечтающего о тотальной победе js?)) очень, знаете ли, много кого вы таким образом "не считаете".) в абсолютном отношении нода даже приблизительно не близка к вытеснению php из реального сектора. и квалифицированные разработчики нормально зарабатывают.

            • –3
              Я php-шник, потому хорошо знаю о чём говорю. Среди моих знакомых хороших программистов практически не осталось чистых php-шников, теперь для хорошей зарплаты надо нырять во фронтэнд. Дело не только в джавасрипте, есть ещё джава и шарп.
              Да и в целом веб рынок сжался с приходом фейсбуков, уже не нужно столько типовых стэнд элон сайтиков и магазинов.
              • +3
                1. опытный веб-программист "чистым" не бывает вообще) смещение к фуллстэк это нормально. просто пробить некие очередные планки профессионализма в своей области сложнее, чем добавить фронтовые навыки и, тем самым, меньшими усилиями повысить свой рейт)
                2. джава царит в банковской сфере и дальше, кажется, не уползет уже никогда, шарп, вообще, где-то в еще более корпоративном секторе. а сотни crm как писали так и пишут на php.
                3. чтобы веб-рынок сжался, я совершенно не ощущаю. смена проекта (крупных) при необходимости занимает до недели, редко двух.

                и это при некой "стагнации", а уж теперь, с "новым дыханием"...) так что не переживайте, коллега.

                • –1
                  Ну раз у вас так хорошо с проектами, может со мной поделитесь? Я с легкостью найду исполнителей за хорошие деньги, которые с радостью согласятся бросить адский легаси.
                  • 0
                    По поводу пункта №1 не смог пройти мимо =)
                    Раньше веб-программисты почти всегда были фул-стек, но с усложнением требований бизнеса и соответственно разработки стала происходить специализация на фронт и бекенд разработку.
                    Хоть убейте, но не понимаю, как могут в природе существовать фул-стек разработчики, кроме js-ных.
              • +3

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

                • 0

                  Ну да ну да, сразу все компании, что на рынке, так взяли и инфой поделились. Не городите чушь

              • +13
                — Здравствуйте, PHP уже умер?
                — Как, опять?

                (с) по мотивам OS/2 FAQ
                • –1
                  Понятное дело, что умирать он будет долго, вон даже Fortran, COBOL до сих пор используются в проде. Но с новыми проектами с нормальными бюджетами уже туго, это сильно бросается в глаза.
                  Даже простая проверка трендов это демонстрирует. trends.google.com/trends/explore?date=all&q=%2Fm%2F060kv
                  • +2
                    Полно в Европе новых проектов с нормальными бюджетами, в основном ECommerce.
                    • +2
                      Простая проверка трендов показывает нам график. Просто ломаную линию. Для сравнения нам нужно эту простую линию сопоставить с трендами других языков.

                      Мне не удалось заставить этот странный инструмент показать Питон и ноду как «язык программирования», возможно у вас получится.

                      Но вот мой график. Да, питон набирает популярность. Да, у PHP наблюдаются колебания и медленный спад (его долю отжирают другие ЯП).

                      Но говорить о смерти — преждевременно.

                      К тому же, если пролистать страницу ниже (и включить только поисковые запросы, а не ЯП), мы увидим крайне любопытную картину.

                      Китай впереди планеты всей по потреблению новых трендов.
                      • +1
                        ноду как «язык программирования»

                        Очевидно, что не получилось. Ведь язык — JavaScript
                        • 0
                          Мы то говорим о серверных языках. А простое включение ЯП Javascript добавить нам еще и лишние в данном случае данные об использовании на фронте.
                        • 0
                          График трендов PHP, Ruby, Go, Javascript если PHP умирает, то значит Ruby и Go мертворожденные ЯП.
                          • 0
                            Ну я вам не скажу за Go, а на руби написана прикольная имиджборда. Правда задеплоить эту имиджборду мегаквест, проще докером.

                            Впрочем, я ни с Руби, ни с Го не встречался на практике, некомпетентен, потому спорить не буду.
                            • 0
                              Своим комментарием я хотел показать, что эти графики не показывают популярность или востребованность того или иного ЯП.
                          • 0
                            О.о
                            Забавно.
                            Ну тогда тем более нужно сравнивать. А то получится — «100% опрошенных всё поняли»
                            • 0
                              Нда, судя по этим трендам, нужно переходить на GO.
                              • 0
                                На самом деле пик тренда go был летом 2014-ого и с тех пор постоянно падает, так что переходить смысла уже нету.

                                Вообще, что старанно, согласно трендам с 2004-ого падают все языки: Java, JS, C, C++, C#, Lisp, Haskell, Ruby.

                                Чуть иначе в более современных языках — D, Scala, Go, Elixir. Но если их сравнивать с даже упавшей Java — они все находятся в районе нуля.
                                • 0

                                  Какой ужас. "Видим тренд что очередной язык набирает популярность — надо срочно присоединиться!"
                                  А вообще, php конечно имеет много недостатков, но всякие активно пирящиеся nodejs по-моему намного хуже.

                                  • 0
                                    Это ведь юмор про тренд то, на GO не стоит переходить даже при положительном тренде))
                                    • 0

                                      Почему? Вакансий стало больше, на международном рынке ценники ползут вверх, в США больший ценник только у Java и совсем немного больший.
                                      Сейчас искал работу: PHP или GOlang. На golang нашлись лучшие предложениЯ на удаленку.

                                      • 0
                                        Потому что специалистов относительно мало еще пока, готовы взять и на удаленку. Через пару лет насмотревшиеся на тренды гугла заполнят рынок и проще будет найти человека в офис, чем мучиться с фрилансерами.
                                        • +1
                                          Вы ответили на какой-то другой вопрос.
                                          И тут есть неточности: я не говорил про фриланс, я говорил про полный рабочий день (в моем случае, одни предлагают оформлание по трудовой в России, и две фирмы предлагают контракты на представительства в Европе, сроками от года); PHP вроде давно на рынке, но уменьшения удаленных вариантов (кроме прямой работы на США) я не заметил — у вас есть другая информация?
                                          • 0
                                            Я чет не понял, а что фриланс ограничен только биржами типа фрилансер.ру? Фриланс точно так же может быть и с контрактом и с полным рабочим днем. На западе фрилансерами называют независимых подрядчиков.
                                            • +1
                                              Тогда вы используете свое определение фриланса.
                                              Работник на трудовом контракте — мало свободный работник. Да и фрилансер может работать в офисе, не переставая быть фрилансером.
                                              В любом случае, «почему не go при положительном его тренде» открыт.
                                              • 0
                                                Я использую общепринятое определение фриланса. Фрилансер это просто частный предприниматель, по сути.
                                                Когда я работал удаленно на немецкую контору у меня было аж два контракта — NDA и обычный контракт. И тем не менее, я считался фрилансером по всей отчетности. Контора не имела никакого представительства в СНГ, работал я сам на себя с ними удаленно.

                                                A freelancer or freelance worker is a term commonly used for a person who is self-employed and is not necessarily committed to a particular employer long-term.
                                                While the term «independent contractor» would be used in a higher register of English to designate the tax and employment classes of this type of worker, the term freelancing is most common in culture and creative industries and this term specifically motions to participation therein

                                                • +1

                                                  В ваше определение не попадает мой случай с оформлением по тк рф, но с удаленной работой.

                                  • 0
                                    Если смотреть на эти гугл-тренды — все языки стагнируют! Так что выбираем язык, которые стагнирует медленнее других :)
                                    trends.google.com/trends/explore?date=all&q=%2Fm%2F060kv,%2Fm%2F09gbxjr,%2Fm%2F02p97,%2Fm%2F07sbkfb,%2Fm%2F0jgqg
                                  • 0
                                    Да сcc..., странные результаты.
                                    Вот сравнение за 5 лет php, nodejs и javascript trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F060kv,%2Fm%2F0bbxf89,%2Fm%2F02p97
                                    Популярность php уходит и его вытесняют другие языки.
                                    Но даже это не важно, беспокоят именно хорошие проекты с хорошей оплатой, их стало значительно меньше.
                              • +1
                                Но даже на данный момент это одна из самых простых и популярных платформ бэкэнда
                                Yii в руки и пошёл
                                • 0
                                  Да ну, ерунду вы пишете. Пыха хоть имеет свои болячки, но количество специалистов и проектов несравнимо больше чем у соседних языков, есть поле для манёвров. Бывает такое что попадаются проекты под которые пыха не подходит архитектурно, но это очень нишевые продукты. Опять же, под каждую задачу созданы свои инструменты, сделать всё на пыхе в крупном проекте несомненно странное решение, но то для чего она была создана — бекенд для веба, с этой задачей справляется на отлично.
                                  • +1
                                    Знаете какой самый популярный вопрос по тегу laravel в местном тостере? Про неймспейсы, люди не понимают почему у них не работает как в примерах Foo::bar();

                                    В посте я написал о том, что PHP оброс новыми фичами и так называемые специалисты в них до сих пор не разбираются. Порог входа значительно вырос. Найти специалиста, который знает ООП и может спокойно писать на фреймворке уровня symfony невероятно сложно и дорого, потому и теряется конкурентное преимущество.
                                    • 0

                                      Быть может это проблема "уровня" Symfony?

                                      • +1
                                        И что? Поэтому пыха говно и умирает? :) То что люди «входят в айти» через пыху напрямую определяет язык как говно? У вас очень странная логика.
                                        Найти специалиста, который знает ООП и может спокойно писать на фреймворке уровня symfony невероятно сложно и дорого, потому и теряется конкурентное преимущество.

                                        Найти толкового специалиста — это всегда сложно и дорого и язык тут на самом деле второстепенен. Знаю достаточно крутых специалистов которые легко после пыхи осваивали и питоны и руби и go. Способность учиться и подстраиваться под рынок — это и определяет специалиста как профи, а не то что он знает symfony или ООП. Всё остальное приходит с опытом.
                                        • 0
                                          Ну вот же. Я об этом же, если требование по знаниям такие же как в шарпах и джавах, то зачем писать на костылях и год ждать новую версию, чтобы в возращаемых типах указывать вариант с нулл.

                                          Нормальные PHP-шники достигли потолка и пробили его, влезли на территорию других языков.

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

                                          Сам php становится лучше, более функцинальным, качественным и т.д. Но и вход в него растёт.
                                          • +1
                                            Ну вот же. Я об этом же, если требование по знаниям такие же как в шарпах и джавах, то зачем писать на костылях и год ждать новую версию, чтобы в возращаемых типах указывать вариант с нулл.

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

                                            JS влез на территорию бекенда и что? Не вижу ничего плохого, это развитие. Каждый язык что-то заимствует у другого.
                                            Я писал о том, что получрность и количество хороших проектов на php становится меньше. Если 5 лет назад php-отделы были самыми растущими, то нынче их начали сокращать

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

                                            Это же хорошо. Значит говнокода станет меньше и будет расти кол-во хороших проектов.
                                  • –22
                                    PHP умер для меня с появлением Go ;-) А кто говорит, что на Go нельзя так же быстро создавать web приложения, как на Symfony (или аналогичных фреймворках) просто не умеет грамотно кодить ;-P
                                    • +7

                                      Да ёмаё. Успокойтесь со своим Go уже, мы уже вроде говорили ведь на эту тему один раз с вами.

                                      • +10

                                        Я бежал за вами 5 километров, чтобы сказать, как вы мне безразличны (тм)

                                        • +2
                                          Ну таки сегодня лучше всего из всего перечня бэкэнд задач Go себя показывает в микросервисах, а вот всякие Симфони подобные штуки на нем выглядят громозко, ну как минимум сегодня. Как я понял жизнь скорректировала изначальные планы развития языка и возможно он станет примерно как php/python, но только Go.
                                          Время покажет, но в данный момент мне кажется нецелесообразно тратить ресурсы на разработку мощных штук со сложной бизнес логикой, крудами-шмудами и тд, лучше использовать там где он однозначно силен — к примеру микросервисы, он в этой области показывает и отличную производительность, высокую надежность, прозрачность работы в общем в целом все обычно очень предсказуемо и просто, даже в сравнении с python.
                                          Хотя если откровенно говорить то лично с моей тчк зрения «серебрянной пулей» Go назвать нельзя.
                                          • 0
                                            Позволю не согласиться с Вами, всё зависит от программистов и от их навыков.
                                            Подходя к задаче массовых микросервисов, написал с коллегами специальный фреймворк, для построения микросервисов, вот пример построения на нём микросервиса, согласитесь не выглядит громоздким.
                                            • 0

                                              В микросервисах основная проблема как раз не в том, чтобы написать микросервис )

                                              • 0
                                                Вы наверно намекаете на меж-микросервисное взаимодействие,. так оно тоже реализовано на стороне фреймворка.
                                                Используется обработчик событий, паттерн обсервер.
                                                Если я обращаюсь к какому-нибудь репозиторию, который описан в другом микросервисе, то подключение ресурсов этого микросервиса произойдет автоматически, есть так же ручное подключение ресурсов, в общем проблемы нет.
                                              • 0
                                                И тут внезапно появляется задача внедрить отдельный сервис с очень высокими требованиями к перфомансу. И сервис будет пилится на го, к примеру. И как вы будете его интегрировать со своим фреймворком?

                                                зы. Идея фреймворка для микросервисов абсурдна сама по себе. Основное преимущество микросервисов в том, что под каждую задачу можно выбрать наиболее подходящий инструмент и стек технологий.
                                                • 0
                                                  Ну, речь то про PHP шла, конечно, если если вы написали отдельный сервис на Go при его использовании на стороне микросервиса необходим некий дополнительный инструмент, что-то вроде API адаптера, пока таких задач не возникала, но была обратная задача. Скажем так некая среда сайта не PHP, использовала мои микросервисы через API которое работает по умолчанию.
                                                  По поводу «абсурдности», думаю вы просто ещё не знакомы с приведенной архитектурой. У микросервиса в фреймворке, стеки технологий у каждого остаются свои, но есть некие требования, это использование фреймворка и загрузка ядра, а дальше может быть всё что угодно, любые библиотеки, компоненты подключение в микросервисе. Просто чаще всего нет никакой необходимости писать обработчик запросов для каждого микросервиса свой, работа с данными она тоже везде практически одинакова. Фреймворк хоть и компактен, но в нем есть собственная ORM, DI, логирование, обработка запросов и ошибок.
                                                  Возможно к зиме выкачу вторую версию, опишу на хабре, любопытно узнать, что вообще люди думают о таком подходе.
                                                  • 0
                                                    wdforge поделитесь ссылкой на то что есть, а то с приведенного ошметка кода мало что понятно.
                                                    • 0
                                                      К сожалению разработка фреймворка была в рамках коммерческого проекта, согласно договору не могу делиться кодом.
                                                      Собственно, по этой причине работаю над второй версией, она будет открытой, и гораздо более доработанной.
                                                      Основная идея в том, что если мы работаем с сервисом через HTTP то получаем JSON, если же микросервисы используются в неком существующем сайте на PHP, то отправляя запрос с экшена, мы уже получаем то, что возвращается по существу, а не JSON. При этом м-сервис остается независимым, у него даже может быть собственный хост.
                                                      Подобный подход видел в SocialEngine, но там не было микросервисной архитектуры.
                                                      «Огрызок» накидал за 5 минут, в нем действительно есть 1 экшен который возвращает объект по id, это как ни странно и есть объявление микросервиса, только без настроек.
                                                      • 0
                                                        wdforge Ну тогда линкой на новую версию. Может кто еще поконтрибьютит))
                                                        • 0
                                                          Да, так и сделаю, у меня есть цель вообще привлечь кого-то ещё к этому проекту, так как, сил одного разработчика для такого проекта маловато.
                                                          Помогает что до этого было 1.5 года разработки и сейчас идет просто обратный реинжиниринг.
                                                          Если архитектура будет открытой, то в идеале можно будет разработать какие-то общие микросервисы, сделать некий банк микросервисов…
                                                          Разработка пока на собственном гитлабе, в общих чертах что-то работает, на выходных наверно переложу на github, скину сюда ссылку.
                                                          • 0
                                                            Проект будет доступен по адресу
                                                            github.com/wdforge
                                                            Пока только деланы наброски: ServiceManager и EventManager.
                                              • 0
                                                Go не для web создавался и в качестве бекенда держать его можно чисто как микросервис.
                                                Это конечно круто пихать один инструмент во все стеки, но в реальности такой подход попахивает идиотизмом.
                                              • +1

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


                                                По адаптации кода — на 90% помогла утилита sstalle/php7cc, на остальных 10% ожидаемо упали unit-тесты (изменения в работе бизнес-логики были самые опасные и неочевидные, в отличие от явных несовместимых с php 7 фрагментов кода, выявленных stalle).

                                                • 0
                                                  На самом деле я удивился, что кто-то в таких объемах использует memcache(d), когда есть Redis.
                                                  • 0
                                                    1. Legacy и очень старый.
                                                    2. Зачем менять, пока работает.
                                                    • 0
                                                      1. Тут надо было сработать на опережение, а лучше даже, в случае мемкеша, сериалайзить в php. У Redis, опять же, сериалайзер можно выбрать, я в свое время во многом из-за этого и перешел на него.
                                                      2. Лучше поменять раньше, чем позже. Именно из-за такого подхода я в данное время разгребаю и переписываю совсем уж олдовое legacy наследство, времен этак php4, которое никто не трогал очень долгое время, которое как-то работало даже на 5.3, но уже на 5.6 просто начало трещать по швам.
                                                      • 0
                                                        сериалайзить в php

                                                        Что? Зачем?


                                                        Лучше поменять раньше, чем позже

                                                        Лучше решать проблемы по мере их поступления.


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

                                                • –7
                                                  php не мёртв, он всегда так пахнет
                                                  • 0
                                                    При обновлении на ровном месте образовалась проблема. Пакет php-memcached для 7.1 потянул за собой пакет php-igbinary. Когда поставили PHP 7.1 на один из боевых серверов, с остальных серверов начали сыпаться ошибки, в которых фигурировало слово “igbinary”.

                                                    Раз раз и в продакшен делаете?)) Dev серверы не нужны для тестирования, берешь и пишешь «pacman -Syu or etc» и все, гениально, аплодирую стоя xD
                                                    • +1
                                                      Для каких-то вещей у нас ещё нет стейджинга, полностью повторяющего боевую инфраструктуру (для большинства сервисов, к слову, есть). Эту неприятность поймали как раз из-за расхождения боевых и дев-серверов.
                                                    • +1
                                                      пыхыпы не умрет, кто думает что он умрет, то вам я скажу, что это вы умрете быстрее чем пыхыпы =)
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        • 0
                                                          SOAPUI Вам в руки, на случай если вдруг не в курсе. Куда легче чем придумывать велосипед на похапе.
                                                          • 0

                                                            при чем тут soapui вообще

                                                        • +3
                                                          Графики впечатляют!
                                                          Думаю, производители серверов сильно не довольны выходом PHP 7 :)
                                                          • +3
                                                            Думаю им глубоко пофик, они гребут свое бабло с энторпрайза на жабе, а не с нищебродов на пыхе :D
                                                            • +1
                                                              Думаю, производителям всё равно.
                                                            • –2

                                                              Удивительно. Половина новостей связана с тем, что в язык/платформу добавляются базовые возможности, которые в языках общего назначения (C++, C#, Java, множество других) есть с рождения и "из коробки".


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


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

                                                              • –4
                                                                Плюсую, но я из-за динамичности положил школьный сайт вместе с бд
                                                                Потом пришлось писать тонны регулярных выражений, хотя защиту от иньекций написал до этого
                                                              • 0
                                                                лучше бы int-typecast пофиксили, уже задрали с ним
                                                                • 0

                                                                  В каком смысле "пофиксили"?


                                                                  В плане


                                                                  "1e8" == "01e8" => true

                                                                  ?

                                                                  • 0
                                                                    да там полно адища.
                                                                    "1e" == 1 // true
                                                                    "1e1" == 1 // false
                                                                    (float)"0.00" => 0
                                                                    (bool)"0.00" => true
                                                                    • +1
                                                                      Может, стоит использовать строгое сравнение?
                                                                      • 0
                                                                        применение строгого сравнения никак не умаляет адища с тайпкастом.
                                                                      • +1

                                                                        Это не адище, а неявное преобразование, почитайте PHP Internals Book.

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

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