Treci la conținut

Utilizare autonomă

Vizualizați ca Markdown Editați pe GitHub Documentație la 2cc7b2b

Queuety este distribuit ca plugin WordPress, însă cea mai mare parte a mediului de execuție nu are nevoie propriu-zis de o cerere WordPress activă.

Coada, motorul fluxurilor de lucru, mașinile de stări, semnalele, artefactele, procesarea în loturi, planificarea, jurnalizarea, valorile metrice și gestionarea resurselor folosesc toate aceleași tabele MySQL. Dacă un alt proces PHP poate deschide aceeași bază de date, poate folosi direct acel nucleu.

Aceasta este delimitarea utilizării autonome în Queuety. Motorul de orchestrare bazat pe baza de date poate fi folosit în afara WordPress. Punțile WordPress rămân însă specifice WordPress.

Ce funcționează în afara WordPress

Cu o conexiune Connection directă, un proces autonom poate inițializa Queuety și poate folosi aceleași metode ale fațadei ca pluginul pentru mediul de execuție principal:

  • trimiterea joburilor
  • rularea workerilor și a grupurilor de workeri
  • construirea și trimiterea fluxurilor de lucru
  • trimiterea semnalelor, a aprobărilor și a datelor de intrare pentru fluxurile de lucru
  • construirea și trimiterea mașinilor de stări
  • inspectarea stării fluxurilor de lucru și a mașinilor
  • stocarea și citirea artefactelor
  • gestionarea procesării în loturi, a înlănțuirii și a programărilor recurente
  • interogarea jurnalelor, a valorilor metrice, a cozilor și a stării mediului de execuție

Asta înseamnă că un produs extern poate accesa aceeași stare de orchestrare fără să pornească mai întâi WordPress, atât timp cât folosește aceeași bază de date și aceleași nume de tabele.

Grupurile de workeri sunt momentan singura excepție: Queuety::run_worker_pool() și Queuety::run_auto_scaling_worker_pool() citesc constantele WordPress DB_HOST, DB_NAME, DB_USER și DB_PASSWORD, în loc să folosească conexiunea inițializată, așa că un proces autonom trebuie să definească aceste constante înainte să pornească un grup (#5).

Ce rămâne în WordPress

Stratul de punte specific WordPress depinde în continuare de încărcarea lui WordPress.

Aici intră:

  • inițializarea și comportamentul de activare a pluginului în queuety.php
  • Queuety::on_action(), care necesită add_action()
  • Queuety::replace_wp_cron() și Queuety::restore_wp_cron(), care depind de filtrele WordPress cron și de do_action()
  • calea reală de înregistrare a comenzii wp queuety ..., care depinde de încărcarea de către WP-CLI a lui WordPress

Aceste componente sunt adaptoare pentru mediul de execuție principal. Ele nu sunt mediul de execuție în sine.

Inițializare

Calea autonomă este concepută să fie simplă. Deschideți un Connection susținut de o bază de date, inițializați fațada și asigurați-vă că schema există.

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();

După aceea, API obișnuit al mediului de execuție este disponibil:

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();

Denumirea tabelelor

Utilizarea autonomă nu necesită în mod specific numele tabelelor WordPress. Este necesară doar o strategie stabilă pentru prefixe.

Dacă folosiți Queuety cu o bază de date WordPress, utilizați același prefix ca pluginul. Dacă folosiți Queuety într-o bază de date separată, prefixul conexiunii poate fi cel așteptat de aplicația gazdă. Componenta specifică tabelelor Queuety este controlată în continuare de QUEUETY_TABLE_PREFIX și de suprascrierile pentru fiecare tabel.

Mediile de execuție încorporate care partajează o bază de date pot seta separat, pentru fiecare conexiune, acea componentă specifică Queuety:

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

Astfel, prefixul bazei de date WordPress rămâne neschimbat, iar tabele precum queuety_jobs se rezolvă la wp_themequeue_jobs.

Model mental

O modalitate clară de a înțelege această separare este:

  • nucleul Queuety = coadă, workeri, fluxuri de lucru, mașini de stări, semnale, artefacte și metadatele mediului de execuție
  • adaptorul WordPress = inițializarea pluginului, punți pentru hookuri, înlocuirea lui WP-Cron și înregistrarea lui WP-CLI

Astfel, rămâne un singur motor de orchestrare, iar integrarea specifică WordPress pentru evenimente și cereri este păstrată acolo unde îi este locul.