SDCast #16: в гостях Александр Лисаченко

sd-podcast-logo Если вы любите Symfony2 так же, как люблю его я, то этот выпуск непременно для вас! А так же для всех, кто интересуется PHP, фреймворками и аспектно-ориентированным программированием. У меня в гостях Александр @lisachenko Лисаченко, руководитель отдела проектирования ПО Alpari-RU.

В этом выпуске мы обсуждаем современные PHP-фреймворки, разработку энтерпрайз-приложений на базе PHP-стека. Александр рассказывает про аспектно-ориентированное программирование в целом и своем фреймворке Go! AOP PHP. Так же Александр был в этом году на SymfonyCon 2014 в Мадриде и делится своими впечатлениями от посещения этого мероприятия, какие там были интересные доклады, с кем и о чем ему довелось пообщаться.


Ссылки на ресурсы по темам выпуска:

Скачать (mp3, 28 MB)
  • PHP лучше масштабируется, чем Java?! Это как вообще?

    И да, как уже надоел пример highload-а с fb.com. Это лишь один проект, там уже почти всё 10 раз переписано.

    • Почему PHP лучше масштабируется чем Java. Давайте попробуем взвесить “за” и “против”.

      1. Согласны ли вы, что приложения без состояния (stateless) масштабируются значительно лучше, потому что нет потребности в синхронизации состояния при параллельном доступе, aka IPC?

      2. Согласны ли вы с тем утверждением, что масштабируемые приложения базируется на архитектуре share nothing http://en.wikipedia.org/wiki/Shared_nothing_architecture? Т.е. между двумя идентичными нодами нет никакой связи – они не имеют общей памяти, общей виртуальной машины, общей файловой системы. В этом случае для масштабирования достаточно поставить еще одну машину в сеть – и все заработает, что дает возможность неограниченного роста.

      3. Масштабируемые приложения должны уметь изменяться мгновенно под действием нагрузки. При этом сам процесс масштабирования не должен приводить к прекращению работы сервиса, а просто адаптироваться “на лету”

      Теперь перейдем к деталям.

      1. PHP stateless, что означает, что все ресурсы не хранятся между последовательными запросами, если это специально не сделать (БД, сессии). Это означает, что нет проблем с семафорами, локами, потоками и многим другим, что есть в Java. Из-за наличия состояния процесса в java для достижения полноценного параллелизма нужно правильно использовать специальные функции асинхронного ввода/вывода, которые значительно усложняют разработку масштабируемого кода, тогда как в PHP основной код пишется синхронным и с ним проще работать.
      2. Между двумя процессами в PHP нет ничего общего – они физически разделены по памяти, что дает возможность заложить фундамент для добавления неограниченного количества воркеров/нод для процессинга входящих запросов с балансировкой, допустим, на HAProxy. Java-приложения этим похвастаться не могут, из коробки, кроме использования запуска VM на некотором облаке – была какая-то софтина, которая давала возможность запустить приложение на огромном кластере, но там есть свои ограничения.

      3. Java – компилируемый язык, это означает что на “лету” делать можно ограниченное количество действий, внесение изменений подразумевает пересборку, поэтому если программист не подготовит код, админы ничем не помогут с масштабированием. PHP-компилируемый язык, поэтому можно вносить правки очень оперативно, что актуально для включения/отключения фишек под нагрузкой.
      4. Масштабируемость также подразумевает человеческий ресурс – как быстро можно найти человека для разработки, как быстро он разберется в архитектуре, как быстро его заменить другим. Вот здесь перевес в PHP однозначный. Разобраться в PHP-приложении значительно проще, а, следовательно и больше разработчиков готовы присоединиться в случае необходимости к проекту и расширять его.

      • 1. Да, я полностью согласен с этим утверждением.
        2. Я думаю, что это один из подходов. Но да, с таким архитектурным подходом всё должно быть здорово.
        3. Ну, тут тоже сложно не согласиться.

        Теперь перейдем к деталям.

        1. PHP stateless в идеальном мире, как мне кажется. Всё равно нам нужны сессии пользователей и т.д. Те проблемы, которые вы описали, справедливы только лишь для одного инстанса JVM. Но ведь, когда приложение большое, будет поднято много ВМ-ок, и пользователь уже будет работать за конкретной машиной (благодаря лоадбалансеру).

        3. Ну, это что-то вообще странное, на мой вкус. Даже если считать, что админы == DevOps, то не совсем понятно, зачем им трогать код и т.д. Да и вообще, о каких админах мы говорим, если всё серьезное хостится на каком-нибудь Амазоне. Не хватает мощностей? Подымаем ещё одну VM-ку, запускаем там JVM и стартуем наше приложение.

        4. Очень спорный поинт. По моему мнению, средний java-программист более профессионален, чем средний php-программист. Кроме того, в Java-мире хороший дизайн и разработка на фреймворках – в крови. В тоже время, в PHP-мире, наверное, до сих пор можно найти тех людей, кто пишет свой фреймворк без надобности.

        • По 3 пункту скажу из наболевшего – какого фига энтепрайзный ActiveMQ на Java не умеет на “лету” релоадить конфигурацию? Это просто ахтунг какой-то. Внесли небольшую правку в конфиг бина – и привет, без простоев не применишь никак. Берешь ZooKeeper – опять привет, тулза для фейловера и кластеризации не умеет выбирать активный инстанс мгновенно, так как все коннекторы в Java-приложении инициализируются и это время! В итоге, еще секунд 5 сервис лежит, ибо Java. Не дай бог ребут какого-то сервиса на Java (Jira, Bamboo, ActiveMQ, Saiku) – 20 секунд в дауне в лучшем случае. А сколько раз выжиралась вся память в Rapid-I Analytics и сервер падал – и не счесть. PHP же врубается мгновенно под любую нагрузку – только щелчок по симлинку.

          По 4 пункту вы сами ответили ) Средний java-программист более профессионален, чем PHP-программист и что разработка на фреймворках в крови.

          Однако это и приводит к тому, что я называю оверинжиниринг. Более-менее крупное приложение на Java состоит из тысяч классов, которые непонятно как взаимодействуют между собой. В итоге, стартануть с нуля новому человеку над этим проектом крайне сложно. Фреймворк – только скелет, тогда как язык – это материя. Все эти замечательные шутки наз названиями классов в Java возникли не случайно – он строгий, но крайне негибкий язык с точки зрения лаконичности кода. В PHP же сейчас все очень сильно подтянулось до Enterprise-а, есть DIC, SOA, сервисы и т.д. Сравнивая Spring и Symfony – Symfony круче, за счет того, что не грузится все и можно использовать динамическую компилируемую природу языка на полную катушку, работая только с маленьким кусочком – это все происходит мгновенно.

          Но тут можно долго спорить ) каждый профессионал будет защищать свою сторону и технологии. А я, пожалуй, не буду утверждать, что PHP масштабируется лучше чем Java. Это некорректно. Масштабируются и Java и PHP абсолютно одинаково при правильном подходе. Есть лишь тонкие моменты: что-то проще, что-то удобнее, что-то дешевле.

  • Lebnik

    Спасибо Александру Лисаченко за его доклады и было бы здорово, если бы у нас появился aopphp-бандл, которй можно было попробовать, тем самым начав знакомство с его творением – aop php framework

    • Спасибо вам )

      Я очень рад получить фидбек, возможно, это самое интересное для меня (причем как положительный, так и отрицательный фидбек). Потому что иногда после презентации/доклада никто не говорит докладчику – был ли доклад полезный, какие есть пожелания и замечания. В итоге создается ощущение, что доклад был плохой и новый делать уже хочется меньше.

      Насчет бандла я подумаю, но для Symfony2 аспекты можно сделать куда проще с помощью компилер-пассов и тэгов, примерно так, как это делает JMSAopBundle. Целью моего же фреймворка было не зависеть от контейнеров, а сделать максимально общее решение, надеюсь, мне это удалось.

  • Lebnik

    Александр, подскажите, какую библиотеку используете для борьбы с sql-иньекциями при использовании mysqlnd

    • mysqlnd – это всего лишь один из внутренних драйверов в самом PHP, на “верхнем” уровне в PHP вы это абсолютно никак не увидите. Оберткой к mysqlnd/libmysql являются знакомые вам в PHP pdo_mysql, mysqli. Пример:

      $ php –ri mysqli

      mysqli

      MysqlI Support => enabled
      Client API library version => mysqlnd 5.0.11-dev – 20120503 – $Id: bf9ad53b11c9a57efdb1057292d73b928b8c5c77 $

      Мы видим, что в качестве клиента используется нативная реализация mysqlnd. Если же здесь будет что-то вида external или libmysql – пересоберите PHP с mysqlnd и ваше приложение будет работать намного быстрее и экономичнее по памяти.

      К ORM отношусь спокойно, для бизнес-приложений это очень оправдано, в настоящий момент у нас используется Doctrine2 повсеместно. Но к ней двоякое отношение ) Она ужасна, но это лучшее, что есть в PHP для баз данных. Как-то так )

      • Lebnik

        Я тоже отрицательно отношусь к Doctine2 и пол года назад моему терпению пришел конец, поэтому я обозначил для себя следующие пункты http://yapro.ru/web-master/mysql/doctrine2-ne-podhodit.html и честно говоря думал, что Вы тоже ушли от нее. Если у Вас будет возможность прокомментировать свое согласие/несогласие по пунктам моей заметки, буду благодарен.

        Спасибо за ответ по mysqlnd, уже успел понять, что mysqli вполне подойдет, а от pdo_mysql надо уходить, где-то на хабре была показательная статья о том, что это библиотека не только кушает доп. ресурсы, но и при выборке данных создает промежуточный фрагмент памяти заполненный данными (видимо для приведения к типу данных), тем самым увеличивая использование памяти в 2 раза.