Към съдържанието

Самостоятелна употреба

Преглед като Markdown Редактиране в GitHub Документация за 2cc7b2b

Queuety е пакетиран като плъгин за WordPress, но по-голямата част от средата за изпълнение всъщност не се нуждае от активна заявка към WordPress.

Опашката, системата за работни процеси, машините на състоянията, сигналите, артефактите, пакетната обработка, планирането, регистрирането, метриките и управлението на ресурсите работят с едни и същи таблици на MySQL. Ако друг процес на PHP може да отвори същата база данни, той може да използва директно тази основна функционалност.

Това е границата на самостоятелната работа в Queuety. Двигателят за оркестрация, базиран на база данни, може да се използва извън WordPress. Мостовете WordPress все още са част от WordPress.

Какво работи извън WordPress

При директна връзка с Connection самостоятелен процес може да инициализира Queuety и да използва същите методи на фасадата като плъгина за основната среда за изпълнение:

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

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

Пуловете от работници засега са единственото изключение: Queuety::run_worker_pool() и Queuety::run_auto_scaling_worker_pool() четат константите WordPress DB_HOST, DB_NAME, DB_USER и DB_PASSWORD вместо инициализираната връзка, затова самостоятелен процес трябва да дефинира тези константи, преди да стартира пул (#5).

Какво остава в WordPress

Слоят от мостове, специфичен за WordPress, все още зависи от зареждането на WordPress.

Това включва:

  • началното зареждане и поведението при активиране на плъгина в queuety.php
  • Queuety::on_action(), за което е необходим add_action()
  • Queuety::replace_wp_cron() и Queuety::restore_wp_cron(), които зависят от филтрите WordPress cron и do_action()
  • реалният път за регистриране на командите wp queuety ..., който зависи от зареждането на WP-CLI WordPress

Тези компоненти са адаптери около основната среда за изпълнение. Те не са самата среда за изпълнение.

Инициализация

Самостоятелният път е умишлено опростен. Отворете Connection, свързана с база данни, инициализирайте фасадата и се уверете, че схемата съществува.

PHP
use Queuety\Connection;
use Queuety\Queuety;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Queuety::init( $conn );
Queuety::ensure_schema();

След това е налична обичайната среда за изпълнение API:

PHP
Queuety::dispatch( 'send_email', [ 'to' => 'user@example.com' ] );

$workflow_id = Queuety::workflow( 'report' )
    ->then( FetchReportData::class )
    ->then( RenderReport::class )
    ->dispatch( [ 'report_id' => 42 ] );

$machine_id = Queuety::machine( 'agent_session' )
    ->state( 'awaiting_input' )
    ->on( 'message', 'planning' )
    ->state( 'planning' )
    ->action( PlanSessionAction::class )
    ->dispatch();

Именуване на таблиците

Самостоятелната употреба не изисква конкретно имена на таблици за WordPress. Необходима е само стабилна стратегия за префикси.

Ако свържете Queuety с база данни на WordPress, използвайте същия префикс като плъгина. Ако използвате Queuety в отделна база данни, префиксът на връзката може да е какъвто очаква хост приложението ви. Частта от имената на таблиците, специфична за Queuety, все още се контролира от QUEUETY_TABLE_PREFIX и настройките за отделните таблици.

Вградени среди за изпълнение, които споделят една база данни, могат да зададат тази част, специфична за Queuety, за всяка връзка:

PHP
$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
    table_prefix: 'themequeue_',
);

Така префиксът на базата данни на WordPress остава непроменен, а таблици като queuety_jobs се преобразуват в wp_themequeue_jobs.

Модел на работа

Най-ясно е разделението да се разбира така:

  • ядро на Queuety = опашка, работници, работни процеси, машини на състоянията, сигнали, артефакти и метаданни на средата за изпълнение
  • адаптер на WordPress = начално зареждане на плъгина, мостове за куки, замяна на WP-Cron и регистриране на WP-CLI

Така се запазва един двигател за оркестрация, а интеграцията със събитията и заявките, специфична за WordPress, остава там, където ѝ е мястото.