Quando si parla di Enterprise una delle prime cose che si devono cercare, ancora prima delle ottime prestazioni, è la riduzione del “single point of failure”. Tale riduzione è generalmente ottenibile distribuendo i vari layer dell’architettura su più server e più nodi cercando, dove possibile, di creare un sistema SOA dove i vari componenti parlano tra di loro attraverso web api, messaging system e, perché no, event-driven non blocking I/O dove possibile.
PHP, volendo, offre tutto questo “out of the box”: supporta infatti XML-RPC, SOAP e RESTful senza alcun problema e con opportune estensioni e librerie supporta anche messaging queue e reactor pattern.
Nota: prima di procedere, se sei ancora convinto che il PHP non possa essere multithreading, ti consiglio la lettura di questo post su reddit del creatore dello stesso pthreads.
Cercando un PHP Application Server
Fino a qualche giorno fa su Wikipedia, precisamente sulla pagina contenente l’elenco dei vari PHP Application Server, (dopo una recente rettifica) sono rimaste solo due voci.
Zend Server probabilmente sarà già noto a molti di noi ma Appserver.io rispetto al primo, supporta svariate funzionalità aggiuntive.
Approfondiamo quindi la questione…
Appserver.io
Appserver.io è un’infrastruttura PHP di nuova generazione e non un semplice Web Server come Apache o Nginx, né tanto meno un Timer Service o un Message Queue… è un insieme di servizi che lavorano insieme perfettamente. Il suo obiettivo è creare un nuovo standard nelle applicazioni Enterprise che utilizzano PHP cercando di risolvere le problematiche che nascono nell’affrontare Thread, non bloking IO e programmazione asincrona.
È importante inoltre tenere a mente che Appserver.io non è un Framework: anche se offre molte delle funzionalità che si possono trovare in tutti i più famosi Framework (si, anche alcune di Laravel), non è intenzione del team quella di creare un prodotto che si sostituisca ai Framework esistenti, ma di integrarsi con essi.
La prima release ufficiale 1.0.0 (Iron Horse) è stata rilasciata il 16/02/2015 ed è già prevista una minor release 1.1.0 (Iron Knight) per Maggio 2015 (con delle migliorie che consentiranno, tra l’altro, una più efficace integrazione con Laravel).
Più nel dettaglio, ecco quelle che saranno le principali features di Appserver.io:
- Webserver: Appserver.io Fornisce un Web Server component based, totalmente compatibile con le specifiche HTTP/1.1, in grado di processare richieste HTTP e HTTPS. Le funzionalità base potranno essere estese attraverso moduli indipendenti completamente configurabili;
- Rewrite-Engine: il Rewrite-Engine è stato implementato come modulo del webserver e fornisce moduli per il rewrite delle URL e redirect attraverso l’uso delle classiche espressioni regolari. Le regole possono essere variate, incapsulate e concatenate agli eventi per rispondere anche ai casi più complicati. In più il rewrite engine può anche funzionare come base per complesse rewrite map che possono essere caricate da datasources esterni (come ad esempio un database).
-
Servlet-Engine: il Servlet-Engine fornisce un web container che carica applicazioni ed oggetti (detti servlet) all’avvio dell’application server e li mantiene in memoria costantemente. Come risultato, se ben usato il tempo impiegato nel processare una richiesta può essere significativamente diminuito al confronto con i classici stack LAMP ai quali siamo abituati;
-
Persistence-Container: il Persistence-Container rende possibile il caricamento di oggetti, detti component, in memoria. Questi possono essere definiti come singleton, vincolandoli alla sessione HTTP oppure senza nessuno stato. Inoltre, il Persistence-Container permette di fare un uso trasparente dei componenti della Business Interface sia locale che remota, permettendo di implementare componenti indipendenti, mantenibili e riutilizzabili che possono essere distribuiti attraverso la rete, senza la necessità di modificare il codice sorgente;
-
Message-Queue: la Message-Queue fornisce servizi per processare i Message in maniera asincrona. Pertanto, i Message, che sono semplici oggetti PHP, vengono impilati sulla coda mentre il ricevitore, rappresentato dal MessageDriven bean, li consuma in un ordine cronologico. Tutto questo per un uso ottimale delle risorse a disposizione;
-
Timer-Service: il Timer-Service esegue metodi con inizio e fine entro un preciso arco temporale precedentemente definito. Questo consente una differenziazione maggiore rispetto ai servizi come
CRON: a differenza della maggior parte delle soluzioni disponibili, non dovremo configurare script che saranno essere eseguiti ma configureremo metodi Message Driven, Stateless o Singleton Session Bean. Oltre all’esecuzione pianificata, è possibile schedulare dei processi che richiamano i metodi una volta o ricorsivamente.
Appserver.io e Laravel
Come visto, Appserver.io offre un insieme di feature che consentono, in caso di necessità, di creare una struttura piuttosto complessa sfruttando l’esempio Java, che lavora “Servlet based”, caricando le servlet una sola volta e chiamando un servizio o funzione di dispatch, ad ogni richiesta.
Queste possono essere sfruttate indipendentemente, mentre le nostre applicazioni Laravel possono girare al suo interno come PHP-FPM script. In questo repository Github si possono trovare i sorgenti e una breve descrizione di come funziona.
Il team di sviluppo sta attualmente lavorando ad una più efficace integrazione, perché mentre normalmente le applicazioni PHP eseguono semplicemente uno script da zero, Laravel ha una sua struttura MVC che si occupa di fare il bootstrap dell’applicazione. Quindi anche racchiudendo ora il bootstrap di Laravel in una servlet non se ne trarrebbe un gran beneficio: infatti, Appserver.io eseguirebbe il bootstrap ma la gestione delle richieste e risposte sarebbe comunque effettuata da Laravel.
Il kernel interno di Laravel, che detiene come member property le closure, renderebbe impossibile condividere il kernel tra thread ma nella prossima minor release di Appserver.io (prevista per maggio) è previsto l’aggiornamento di pthreads, il quale supporta la serializzazione delle closure, e la situazione cambierà.
Considerazioni Finali
Appserver.io è decisamente un bel progetto, e si prepara ad essere una soluzione per il mercato Enterprise di tutto rispetto. Riuscirà nell’intento di agevolare ulteriormente la diffusione di PHP anche in ambiti più “elevati”?
E soprattutto ci chiediamo: riuscirà a trovare un punto d’incontro con il nostro framework preferito, permettendo la creazione di applicazioni PHP ancora più potenti e performanti?
Sicuramente, l’attuale livello di integrazione con Laravel può rendere un’idea (seppur “embrionale”) di quello che c’è dietro. Tuttavia, bisogna ancora aspettare la prossima minor release per trarre delle vere conclusioni.
I benefici, certamente, sarebbero molti: applicazioni con funzionalità condivise su uno stesso server, creazione di thread di aggiornamento tra più server o, ancora, routine di pulizia del Database eseguite parallelamente ad un’altra applicazione, senza rallentarla.
Io personalmente (e tutti noi di Laravel-Italia) siamo qui ad aspettare Maggio e vedere cosa succederà.
