Прехвърляне на бекенда на PHP към шината за потоци на Redis и избор на независима от рамката библиотека

предговор

Моят уебсайт, който управлявам като хоби, е предназначен да хоства интересни начални страници и лични сайтове. Тази тема започна да ме интересува в самото начало на моето програмиране; в този момент бях очарован от намирането на страхотни професионалисти, които пишат за себе си, своите хобита и проекти. Навикът да ги откривам за себе си остава и до днес: на почти всеки комерсиален и не много комерсиален сайт продължавам да гледам в долния колонтитул в търсене на връзки към авторите.

Осъществяване на идеята

Първата версия беше просто html страница на моя личен уебсайт, където поставих връзки с подписи в ul списък. След като написах 20 страници за определен период от време, започнах да мисля, че това не е много ефективно и реших да опитам да автоматизирам процеса. В stackoverflow забелязах, че много хора посочват сайтове в профилите си, затова написах анализатор на php, който просто премина през профилите, започвайки с първия (адресите на SO до ден днешен са така: `/users/1` ), извлече връзки от желания таг и го добави в SQLite.

Това може да се нарече втората версия: колекция от десетки хиляди URL адреси в SQLite таблица, която замени статичния списък в HTML. Направих просто търсене в този списък. защото имаше само URL адреси, тогава търсенето беше просто базирано на тях.

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

Съвременна версия

Проект разгърната в Docker, базата данни беше прехвърлена към mongoDb, а наскоро беше добавен radish, който първоначално беше само за кеширане. За основа е използвана една от PHP микрорамките.

проблем

Новите сайтове се добавят от конзолна команда, която синхронно прави следното:

• Изтегля съдържание по URL
• Задава флаг, показващ дали HTTPS е наличен
• Запазва същността на уебсайта
• Изходният HTML и заглавките се запазват в историята на „индексирането“.
• Анализира съдържанието, извлича заглавие и описание
• Записва данни в отделна колекция

Това беше достатъчно просто да съхранявате сайтове и да ги показвате в списък:

Но идеята за автоматично индексиране, категоризиране и класиране на всичко, поддържане на всичко актуално, не се вписва добре в тази парадигма. Дори простото добавяне на уеб метод за добавяне на страници изисква дублиране на код и блокиране, за да се избегне потенциален DDoS.

Като цяло, разбира се, всичко може да се направи синхронно и в уеб метода можете просто да запазите URL адреса, така че чудовищният демон да изпълнява всички задачи за URL адресите от списъка. Но все пак и тук думата „опашка“ се намеква. И ако е внедрена опашка, тогава всички задачи могат да бъдат разделени и изпълнявани поне асинхронно.

Решение

Внедрете опашки и направете управлявана от събития система за обработка на всички задачи. И отдавна исках да пробвам Redis Streams.

Използване на Redis потоци в PHP

защото Тъй като моята рамка не е една от трите гиганта Symfony, Laravel, Yii, бих искал да намеря независима библиотека. Но, както се оказа (при първия преглед), е невъзможно да се намерят отделни сериозни библиотеки. Всичко, свързано с опашките, е или проект от 3 комита преди пет години, или е обвързано с рамката.

Чувал съм много за Symfony като доставчик на отделни полезни компоненти и вече използвам някои от тях. А също така някои неща от Laravel също могат да се използват, например ORM, без наличието на самата рамка.

symfony/messenger

Първият кандидат веднага изглеждаше идеален и без съмнение го инсталирах. Но се оказа по-трудно да се търсят в Google примери за използване извън Symfony. Как да се сглоби от куп класове с универсални, безсмислени имена, автобус за предаване на съобщения и дори на Redis?

Документацията на официалния сайт беше доста подробна, но инициализацията беше описана само за Symfony, използвайки техния любим YML и други магически методи за не-симфонист. Нямах интерес към самия процес на инсталиране, особено по време на новогодишните празници. Но трябваше да правя това неочаквано дълго време.

Опитът да разберете как да създадете инстанция на система, използвайки източници на Symfony, също не е най-тривиалната задача за кратък срок:

След като се зарових във всичко това и се опитах да направя нещо с ръцете си, стигнах до извода, че правя някакви патерици и реших да опитам нещо друго.

осветени/опашка

Оказа се, че тази библиотека е тясно свързана с инфраструктурата на Laravel и куп други зависимости, така че не отделих много време за нея: инсталирах я, погледнах я, видях зависимостите и я изтрих.

yiisoft/yii2-опашка

Е, тук веднага се предположи от името, отново, строга връзка с Yii2. Трябваше да използвам тази библиотека и не беше лошо, но не се замислих, че зависи напълно от Yii2.

Останалите

Всичко останало, което намерих в GitHub, бяха ненадеждни, остарели и изоставени проекти без звезди, форкове и голям брой ангажименти.

Върнете се към symfony/messenger, технически подробности

Трябваше да разбера тази библиотека и след като прекарах още известно време, успях. Оказа се, че всичко е съвсем кратко и просто. За да създам автобуса, направих малка фабрика, защото... Трябваше да имам няколко гуми и с различни манипулатори.

Само няколко стъпки:

• Ние създаваме манипулатори на съобщения, които трябва да могат просто да се извикват
• Обвиваме ги в HandlerDescriptor (клас от библиотеката)
• Ние обвиваме тези „дескриптори“ в екземпляр на HandlersLocator
• Добавяне на HandlersLocator към екземпляра на MessageBus
• Предаваме набор от `SenderInterface` към SendersLocator, в моя случай екземпляри на `RedisTransport` класове, които са конфигурирани по очевиден начин
• Добавяне на SendersLocator към екземпляра на MessageBus

MessageBus има метод `->dispatch()`, който търси подходящите манипулатори в HandlersLocator и им предава съобщението, използвайки съответния `SenderInterface` за изпращане през шината (Redis потоци).

В конфигурацията на контейнера (в този случай php-di), целият този пакет може да бъде конфигуриран по следния начин:

        CONTAINER_REDIS_TRANSPORT_SECRET => function (ContainerInterface $c) {
            return new RedisTransport(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_SECRET),
                $c->get(CONTAINER_SERIALIZER))
            ;
        },
        CONTAINER_REDIS_TRANSPORT_LOG => function (ContainerInterface $c) {
            return new RedisTransport(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_LOG),
                $c->get(CONTAINER_SERIALIZER))
            ;
        },
        CONTAINER_REDIS_STREAM_RECEIVER_SECRET => function (ContainerInterface $c) {
            return new RedisReceiver(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_SECRET),
                $c->get(CONTAINER_SERIALIZER)
            );
        },
        CONTAINER_REDIS_STREAM_RECEIVER_LOG => function (ContainerInterface $c) {
            return new RedisReceiver(
                $c->get(CONTAINER_REDIS_STREAM_CONNECTION_LOG),
                $c->get(CONTAINER_SERIALIZER)
            );
        },
        CONTAINER_REDIS_STREAM_BUS => function (ContainerInterface $c) {
            $sendersLocator = new SendersLocator([
                AppMessagesSecretJsonMessages::class => [CONTAINER_REDIS_TRANSPORT_SECRET],
                AppMessagesDaemonLogMessage::class => [CONTAINER_REDIS_TRANSPORT_LOG],
            ], $c);
            $middleware[] = new SendMessageMiddleware($sendersLocator);

            return new MessageBus($middleware);
        },
        CONTAINER_REDIS_STREAM_CONNECTION_SECRET => function (ContainerInterface $c) {
            $host = 'bu-02-redis';
            $port = 6379;
            $dsn = "redis://$host:$port";
            $options = [
                'stream' => 'secret',
                'group' => 'default',
                'consumer' => 'default',
            ];

            return Connection::fromDsn($dsn, $options);
        },
        CONTAINER_REDIS_STREAM_CONNECTION_LOG => function (ContainerInterface $c) {
            $host = 'bu-02-redis';
            $port = 6379;
            $dsn = "redis://$host:$port";
            $options = [
                'stream' => 'log',
                'group' => 'default',
                'consumer' => 'default',
            ];

            return Connection::fromDsn($dsn, $options);
        },

Тук можете да видите, че в SendersLocator сме задали различни „транспорти“ за две различни съобщения, всяко от които има своя собствена връзка към съответните потоци.

Направих отделен демонстрационен проект, демонстриращ приложение на три демона, комуникиращи помежду си, използвайки следната шина: https://github.com/backend-university/products/tree/master/products/02-redis-streams-bus.

Но ще ви покажа как потребителят може да бъде структуриран:

use AppMessagesDaemonLogMessage;
use SymfonyComponentMessengerHandlerHandlerDescriptor;
use SymfonyComponentMessengerHandlerHandlersLocator;
use SymfonyComponentMessengerMessageBus;
use SymfonyComponentMessengerMiddlewareHandleMessageMiddleware;
use SymfonyComponentMessengerMiddlewareSendMessageMiddleware;
use SymfonyComponentMessengerTransportSenderSendersLocator;

require_once __DIR__ . '/../vendor/autoload.php';
/** @var PsrContainerContainerInterface $container */
$container = require_once('config/container.php');

$handlers = [
    DaemonLogMessage::class => [
        new HandlerDescriptor(
            function (DaemonLogMessage $m) {
                error_log('DaemonLogHandler: message handled: / ' . $m->getMessage());
            },
            ['from_transport' => CONTAINER_REDIS_TRANSPORT_LOG]
        )
    ],
];
$middleware = [];
$middleware[] = new HandleMessageMiddleware(new HandlersLocator($handlers));
$sendersLocator = new SendersLocator(['*' => [CONTAINER_REDIS_TRANSPORT_LOG]], $container);
$middleware[] = new SendMessageMiddleware($sendersLocator);

$bus = new MessageBus($middleware);
$receivers = [
    CONTAINER_REDIS_TRANSPORT_LOG => $container->get(CONTAINER_REDIS_STREAM_RECEIVER_LOG),
];
$w = new SymfonyComponentMessengerWorker($receivers, $bus, $container->get(CONTAINER_EVENT_DISPATCHER));
$w->run();

Използване на тази инфраструктура в приложение

След като внедрих шината в моя бекенд, отделих отделни етапи от старата синхронна команда и направих отделни манипулатори, всеки от които върши своето собствено нещо.

Конвейерът за добавяне на нов сайт към базата данни изглеждаше така:

И веднага след това ми стана много по-лесно да добавя нова функционалност, например извличане и анализиране на Rss. защото този процес също изисква оригиналното съдържание, след което манипулаторът за извличане на RSS връзки, като WebsiteIndexHistoryPersistor, се абонира за съобщението „Content/HtmlContent“, обработва го и предава желаното съобщение по неговия конвейер по-нататък.

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

Сега, вместо да избират от базата данни, необходимите идентификационни номера след вмъкване от persister просто се предават през автобуса до всички заинтересовани манипулатори.

Източник: www.habr.com