Архив метки: php

Бэкенд ВКонтакте — от разработки до продакшена

PHP — очень простой язык, тупой как пробка, идеальный язык для бизнес-логики и прототипов!

ВКонтакте — по сути классическое приложение на PHP. Есть frontend, есть backend, есть база данных и т.п. Но во всех этих частях свои нюансы. В качестве базы данных использются свои внутренние «движки», в качестве основного языка для backend — KPHP. Логи собираются в ClickHouse. В ряде мест вместо HTTP используется QUIC. Весь php-backend — один огромный монолит, возможно, самый большой в мире ) Примерно 25К php-файлов, 9 млн. строк php-кода, около 800К коммитов в git-репозитории! Для ускорения работы KPHP переводит весь пхп-код в 200К C++ файлов, а далее компилирует в бинарник размером 1,5 ГБ. В итоге получаем прирост производительности в 10 раз! Весь backend компилируется за 3-5 минут, статика собирается до полу часа +) Полученный бинарь раскатывается сначала на стейджинг (1 % пользователей ~ около миллиона человек!), далее на 10К production-серверов. Сборка и деплой осуществляется через TeamCity. Раскатка происходит по протоколу Gossip.

Разработчик имеет свою полную копию vk.com, развернутую в контейнере. Правим обычный php-код и после обновления странички видим результат. При необходимости на этом же контейнере можно собрать полноценную kphp-версию. Однако в большом проекте разработчик не только пишет код, точнее даже не столько.

  • 5 % времени — пишешь код
  • 50 % — читаешь свой и чужой код
  • % — думаешь как безпроблемно выкатить правки, как мониторить и следить

Любой проект через два года превращается в легаси или умирает.

Цифры: 1,5 млн rps, 160 ms latency, 99.96 % availability, > 70 % resource utilization, 87 млн MAU, 9 млрд. просмотров контента.

Yii. TAGLINE. 2016

Яндекс.Диск иногда рекомендует посмотреть старые фотографии — классная функция.

Сегодня выпала вот такая.


Мы с Сашей Макаровым (sam_dark) на TAGLINE 2016.
В тот год Yiiframework получил премию как лучший backend-фреймворк в России.

А вот и моя заметка того времени https://yupe.ru/post/yii-luchshiy-po-vresii-tagline.html
Душевные были времена +) 

Мысли про null…

Послушал сегодня очередной «радиот» — довольно такой интересный выпуск получился. Громко кричали и шумели со словами «PHP — говно!», но к этому можно уже привыкнуть и пропускать мимо ушей. Если инструмент меня кормит —  пусть он будет хоть трижды говном. Был там еще очень любопытный момент. Всем известный Бобук рассказывал про такой тип данных как null в  Smalltalk. Хочу заметить, что в этом самом смалтолке реализован этот null довольно интересно. Передам как я это понял. Null в смалталке это такой объект, у которого можно вызвать любой метод и этот метод вернет….правильно null! Гениально! Сразу же отпадает необходимость проверки на возвращаемый тип и сразу же пропадают пхп-шные ошибки типа «null is not object…». Удобно же!

Мысли про проверки, зависимости, фреймворки, php и perl …

Продолжаю выкладывать свои мысли и соображения о php и perl (первая серия вот тут). Сегодня хотелось бы поговорить про проверку зависимостей («чекеры»так называемые). Написать эту заметку меня заставил чекер зависимостей Symfony2. Возьмем, к примеру, пхпшный Yii (или Symfony2) в дистрибутивах всех этих фреймворков есть специальная страничка/скриптик, который проверяет наличие всех необходимых расширений и системное окружение, в которое фреймворк установлен.  Почему таких страничек нет в перловых фреймворках Mojolicious, Catalyst и т.д. ?  На мой взгляд, все эти, так называемые, зависимости должны проверяться  и валидироваться при установке фреймворка/библиотеки. Беда в том, что в мире php установка, в большинстве случаев, сводится к простому копированию файлов на сервер (ну нету пока у php центрального хранилища модулей и библиотек). Как-то же необходимо узнать «правильно» ли мы все скопировали, все ли у нас теперь заработает ? Вот для этого такие странички «чекеры» и необходимы. При таком подходе к установке очень часто возникают ситуации, когда все кажется сделано: фреймворк залит, приложение залито, запускаем….ничего не работает, смотрим наш «чекер» и видим, что не хватает какого-то PDO расширения или драйвера для memcache. Отсутствующие библиотеки — это еще пол беды. Самое интересное когда работа фреймворка зависит от конфигурации php (всем известен php.ini c его сотнями параметров ? ). Т.е. имея установленный php, имея установленные все необходимые модули, наше приложение может не заработать из-за конфигурации языка программирования (!). Вот и чекер Symfony2 выдал мне варнинги (хорошо хоть не фатальные) с просьбой подкорректировать настроечки в php.ini. Наличие у языка программирования централизованного файла настроек, на мой взгляд, очень сомнительная штуковина, добавляющая лишние проблемы при распространении приложения (вот маленький пример, возникший при разработке Юпи! https://github.com/yupe/yupe/issues/203 ). А что же Perl ? А тут все просто: ставим пакеты из CPAN, при установке автоматом проверяются и ставятся все зависимости, если что-то пошло не так — установка просто закончится неудачей и нам не придется гадать «а заработает ли?». Конечно, и тут бывают проблемы, но значительно реже. У перла нет никакого конфигурационного файла, что решает еще одну проблему с установкой. Есть конечно опции компиляции, которые могут отличаться от сервера к серверу, но это настолько редко было в мой практике, что я не беру это в расчет. И снова забыл про тестирование. При установке Mojolicious (как пример) прогоняются все тесты, которые только есть в дистрибутиве фреймворка и зависимостях. Автоматическая проверка зависимостей,  их установка и прогон тестов практически всегда гарантируют работоспособность расширения на данной конкретной машине. Мысли кончились…

В заключении поделюсь ссылкой на статью Фабьена (разработчика Symfony) http://fabien.potencier.org/article/64/php-is-much-better-than-you-think

 

 

 

Брат, вся сила в модулях!

Многие разработчики (и не только они) который год уже твердят, что Perl мертв, холиваров на эту тему хватает на любом форуме/сообществе. О «смерти» Perl-а кричат все кому ни лень, начиная от «питонистов» и «рубистов» и заканчивая «пхпшниками». Так уж получилось, что мне приходится писать и на Perl и на PHP (в связи с этим про Python и Ruby ничего не могу сказать) и я могу сделать кое-какие выводы на основании личного опыта. Поливать гразью я никого не собираюсь =)

Когда перед разработчиком встает какая-либо задача первое, что он делает (должен!)  —  ищет уже готовое решение. Для чего изобретать свой велосипед если уже все изобретено до нас (отговорки про модуль «с барышнями и шампанским» не принимаются) !? И вот встала передо мной простая задачка: необходимо написать  программку, которая бы просто напросто парсила почтовые сообщения на сервере, сообщения эти лежат как простые файлики в файловой системе. Почта приходит от совершенно разных отправителей, в совершенно разных кодировках  и т.д. Писать необходимо на PHP. Вариантов несколько. Взять старые и добрые PCRE и распарсить все самому (не хочу описывать всю головную боль этого подхода — просто возьмите и попробуйте это сделать ) ! Вариант второй — поискать готовый модуль/пакет/класс. И вот тут я начинаю понимать всю силу перла, не зря говорят, что CPAN — это перловская киллер-фича. В случае работы с перлом — все просто. Заходим на https://metacpan.org/, вбиваем в поиск «EMAIL» и получаем второй ссылкой вот такой вот модулек https://metacpan.org/module/Email::MIME, который прекрасно делает все то, что нам необходимо. CPAN — это такое единое и общее  хранилище перловых модулей (для тех, кто не слышал про Perl и CPAN). Отмечу, что слова «единое» и «общее» выделены не просто так. Что мы имеем когда необходимо проделать тоже самое, но для PHP !? Идем на http://pear.php.net/ — это вроде как «CPAN для PHP» и пытаемся там найти нужный нам модуль. Находим вот такую «штуковину» http://pear.php.net/package/Mail_mimeDecode (на мой взгляд это единственное, что может подойти для нашей задачи). Я даже не беру в расчет тот факт, что последнее обновление этого модуля было в 2010 (работает — не тронь), мне хватает просмотра документации (http://pear.php.net/manual/en/package.mail.mail-mimedecode.mail-mimedecode.php) из которой, лично мне, абсолютно ничего не понятно (сравните с примерами из https://metacpan.org/module/Email::MIME)! Итак, на  http://pear.php.net/ нам ничего не подошло, тогда мы идем в гугл и ищем «php email parser», в выдаче видим ссылку на http://stackoverflow.com/questions/12896/parsing-raw-email-in-php (я, как правило, доверяю stackoverflow), читаем и видим ссылку на https://github.com/plancake/official-library-php-email-parser

Как вам название «official-library-php-email-parser» !? Если ты «official» почему тебя нет на pear !? Как мне поставить, а потом при необходимости обновлять модуль (git pull — для меня зло) !? Ну да ладно. Скачал, поставил. Попробовал использовать. Если коротко — адский ад! Проблемы с кодировкой и перекодировкой писем, проблемы с использованием строк как массивов (метод «getCc» и прочие).  Нет ни одного теста, НИ ОДНОГО! Сравните с 1364 тестами на разных версия Perl и на разных платфомах (http://www.cpantesters.org/distro/E/Email-MIME.html#Email-MIME-1.910) Плевался, плевался и пошел искать дальше… А дальше я попал на http://www.phpclasses.org/ — ну что это, простите, за помойка !? Для того чтобы скачать архив с кодом необходима регистрация! «The registration requirement is an option of the package author. This package has that option set.» — wtf ? Блоки гугл адсенс постоянно пестрят какими-то банерами, такое ощущение, что попал на какой-то «шаре-варе» сервер, который вот вот насажает тебе пачку троянов!  Теперь сравните все это «добро» с отлично выполненной главной страницей https://metacpan.org/…Есть разница ? Искал я искал и в итоге не нашел ничего более подходящего, чем описанный выше модуль с гитхаба (пришлось вбить в него парочку костылей/заплаток после чего он более или менее заработал).

Подведем итог. PHP — хороший язык (особенно если использовать фреймворки, например Yii), но я вот в упор не понимаю почему нельзя сделать единый репозиторий модулей с удобным консольным клиентом для установки, чтобы из одного источника я мог сразу обновить всю систему в пару кликов (слышал про Composer — но не то это). Почему тот же Yii нельзя поставить и обновлять через что-то похожее на CPAN !? Почему нельзя сделать приятную глазу и функциональную веб-морду для поиска всех этих модулей ?

В качестве финального аккорда приведу ссылку на http://www.modulecounts.com/ — счетчик количества модулей в репозиториях для разных языков. Цифра 588 во всех строчках для PHP — меня поразила. Perl с его 25114 явно выигрывает.

Точка!