Информационный портал по безопасности

В предыдущей части мы улучшили нашу систему логгирования. Вместо использования обменника типа fanout мы использовали обменник типа direct, позволившему нам выборочно принимать сообщения. Не смотря на улучшения, наша система до сих пор имеет ограничения, например мы не можем принимать сообщения основываясь на нескольких критериях. Например в нашей системе мы могли бы хотеть перенаправлять сообщения основываясь не только на уровне строгости сообщения, но и на источнике сообщения. Например как в unix-инструменте syslog, который перенаправляет сообщения не только в зависимости от уровня строгости (info/warn/crit..), но и в зависимости от источника (auth/cron/kern...). Это может дать нам дополнительную гибкость, например мы сможем получать только критические сообщения от 'cron', но также все сообщения от 'kern'. Для реализации такой системы нам предстоит познакомиться с более сложным типом обменника — topic.

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

Десять лет назад у нас был классический LAMP-стек: Linux, Apache, MySQL, и PHP, который работал в медленном режиме mod_php. Мир менялся, а с ним и важность скорости. Появился PHP-FPM, который позволил значительно увеличить производительность решений на PHP, а не срочно переписывать на чем-то побыстрее.



Параллельно велась разработка библиотеки ReactPHP с применением концепции Event Loop для обработки сигналов от ОС и представления результатов для асинхронных операций. Развитие идеи ReactPHP — AMPHP. Эта библиотека использует тот же Event Loop, но поддерживает корутины, в отличие от ReactPHP. Они позволяют писать асинхронный код, который выглядит как синхронный. Возможно, это самый актуальный фреймворк для разработки асинхронных приложений на PHP.






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



Об этом и поговорит Антон Шабовта (zloyusr) — разработчик в компании Onliner. Опыт больше 10 лет: начинал с десктопных приложений на С/С++, а потом перешел в веб-разработку на PHP. «Домашние» проекты пишет на C# и Python 3, а в PHP экспериментирует с DDD, CQRS, Event Sourcing, Async Multitasking.

Сегодня, наконец, вышел релиз PHP 7.4!


Его новые фичи уже были многократно описаны, в том числе и на Хабре. Это стрелочные функции, типизированные свойства классов и ещё много всякого синтаксического сахара. Но больше всего мы ждали новый релиз из-за производительности: в версии 7.4 не только появился preload, но и сам PHP стал значительно быстрее.



Плохая (или хорошая?) новость — с выходом PHP 7.4 прекращается активная поддержка PHP 7.2. Его последний релиз запланирован на середину декабря. Мы давно проводим эксперименты с PHP 7.4, а недавно активно занялись переходом на него, так как сейчас мы на уже почти не поддерживаемой версии 7.2.



Поздравляю всех с долгожданным релизом! А ниже расскажу немного о том, как мы переходим на новую версию.

Swoft is a PHP high performance microservice coroutine framework. It has been published for many years and has become the best choice for php. It can be like Go, built-in coroutine web server and common coroutine client and is resident in memory, independent of traditional PHP-FPM. There are similar Go language operations, similar to the Spring Cloud framework flexible annotations.

Github

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



Сайт работает на WordPress актуальной версии 5.1



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

После выхода PHP7 появилась возможность сравнительно небольшой ценой писать долгоживущие приложения. Для программистов стали доступны такие проекты, как prooph, broadway, tactician, messenger, авторы которых берут на себя решение наиболее частых проблем. Но что если сделать небольшой шаг вперёд, углубившись в вопрос?

Попробуем разобрать судьбу ещё одного велосипеда, который позволяет реализовать Publish/Subscribe приложение.

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

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

Выбор тогда пал на два движка ImageCMS и HostCMS. Сейчас пройден уже достаточно немалый путь, но чем дальше я иду, тем больше сомневаюсь, правильный ли выбираю путь.

Мы в PushAll обрабатываем несколько тысяч запросов в секунду для получения статистики доставки и открытия уведомлений и для передачи контента оповещений. Обычная БД вроде MySQL не справляется с таким потоком запросов и не может так быстро отвечать.

Стараясь все больше операций перенести на быстрые NoSQL хранилища вроде Redis, мы хотим знать как эффективнее его использовать и не будет ли у нас проблем с большим количеством соединений.
Также для работы мы используем форки PHP и нам было интересно, а как поведет себя Redis, если мы будем делать несколько тысяч соединений в одновременно в нескольких потоках. Мы решили поделиться с сообществом нашими тестами.

В самом начале этой недели, в понедельник, состоялся официальный релиз Laravel 5.2.
В новой версии были улучшены такие вещи, как авторизация, «связывание» модели с route и другие.
Более подробно под катом.