Перейти до вмісту

Автономне використання

Переглянути як 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, залишається там, де їй місце.