Siirry sisältöön

Erilliskäyttö

Queuety on paketoitu WordPress-lisäosaksi, mutta suurin osa ajonaikaisesta ympäristöstä ei varsinaisesti tarvitse aktiivista WordPress-pyyntöä.

Jono, työnkulkumoottori, tilakoneet, signaalit, artefaktit, eräajot, ajoitus, lokitus, mittarit ja resurssienhallinta toimivat kaikki samoja MySQL-tauluja vasten. Jos toinen PHP-prosessi voi avata saman tietokannan, se voi käyttää ydintä suoraan.

Tämä on ratkaisun Queuety erilliskäytön raja. Tietokantapohjaista orkestrointimoottoria voi käyttää WordPress-ympäristön ulkopuolella. WordPress-sillat kuuluvat edelleen WordPress-ympäristöön.

Mitä toimii WordPress-ympäristön ulkopuolella

Suoralla Connection-yhteydellä erillinen prosessi voi alustaa Queuety-ratkaisun ja käyttää samoja julkisivumetodeja kuin lisäosa ydinaikaisessa ympäristössä:

  • lähetä töitä
  • suorita työntekijöitä ja työntekijäpooleja
  • rakenna ja lähetä työnkulkuja
  • lähetä signaaleja, hyväksyntöjä ja työnkulun syötteitä
  • rakenna ja lähetä tilakoneita
  • tarkastele työnkulkujen ja koneiden tilaa
  • tallenna ja lue artefakteja
  • hallitse eräajoja, ketjutusta ja toistuvia aikatauluja
  • hae lokeja, mittareita, jonoja ja ajonaikaisen ympäristön tilaa

Ulkoinen tuote voi siis käyttää samaa orkestrointitilaa käynnistämättä ensin WordPress-ratkaisua, kunhan se käyttää samaa tietokantaa ja taulujen nimiä.

Työntekijäpoolit ovat tällä hetkellä ainoa poikkeus: Queuety::run_worker_pool() ja Queuety::run_auto_scaling_worker_pool() lukevat WordPress-määrityksen DB_HOST-, DB_NAME-, DB_USER- ja DB_PASSWORD-vakiot alustetun yhteyden sijaan, joten erillisen prosessin on määritettävä nämä vakiot ennen poolin käynnistämistä (#5).

Mikä pysyy WordPress-ympäristössä

WordPress-kohtainen siltakerros edellyttää edelleen, että WordPress on ladattu.

Tähän kuuluvat:

  • lisäosan käynnistys ja aktivointikäyttäytyminen ympäristössä queuety.php
  • Queuety::on_action(), joka edellyttää add_action()
  • Queuety::replace_wp_cron() ja Queuety::restore_wp_cron(), jotka ovat riippuvaisia WordPress-cron-suodattimista ja do_action()-toiminnosta
  • varsinainen wp queuety ...-komennon rekisteröintipolku, joka on riippuvainen WP-CLI-ratkaisun WordPress-latauksesta

Nämä osat ovat sovittimia ydinaikaisen ympäristön ympärillä. Ne eivät itsessään ole ajonaikainen ympäristö.

Alustus

Erilliskäytön polku on tarkoituksella suppea. Avaa tietokantapohjainen Connection, alusta julkisivu ja varmista, että skeema on olemassa.

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

Tämän jälkeen tavallinen ajonaikainen API on käytettävissä:

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

Taulujen nimeäminen

Erilliskäyttö ei edellytä erityisesti WordPress-taulujen nimiä. Tarvitaan vain vakaa etuliitestrategia.

Jos osoitat Queuety-ratkaisun WordPress-tietokantaan, käytä samaa etuliitettä kuin lisäosa käyttää siellä. Jos käytät Queuety-ratkaisua erillisessä tietokannassa, yhteyden etuliite voi olla mikä tahansa isäntäsovelluksen odottama arvo. Queuety-kohtaiset taulujen osat määräytyvät edelleen QUEUETY_TABLE_PREFIX-asetuksen ja taulukohtaisten ohitusten perusteella.

Samaan tietokantaan yhteyttä käyttävät upotetut ajonaikaiset ympäristöt voivat määrittää kyseisen Queuety-kohtaisen osan yhteyskohtaisesti:

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

Näin WordPress-tietokannan etuliite säilyy ennallaan, ja taulut, kuten queuety_jobs, saavat nimekseen wp_themequeue_jobs.

Ajattelumalli

Selkein tapa hahmottaa jako on tämä:

  • Queuety-ydin = jono, työntekijät, työnkulut, tilakoneet, signaalit, artefaktit ja ajonaikaisen ympäristön metatiedot
  • WordPress-sovitin = lisäosan käynnistys, hook-sillat, WP-Cron-korvaus ja WP-CLI-rekisteröinti

Näin käytössä pysyy yksi orkestrointimoottori, ja WordPress-kohtainen tapahtuma- ja pyyntöintegraatio jää sille kuuluvaan paikkaan.