Appserver: Viacvláknový aplikačný server pre PHP, napísaný v PHP

appserver.io, aplikačný server PHP

Toto je hlavné úložisko projektu appserver.io.

appserver.io je viacvláknový aplikačný server pre PHP, napísaný v PHP. Áno, čisté PHP! Ak viete niečo o PHP, pravdepodobne si myslíte, že by sme sa mohli zblázniť. No nie sme. Myslíme to smrteľne vážne (ale určite sa stále radi bavíme!).

appserver.io prekonáva niektoré z najväčších režijných problémov, ktoré má väčšina programov PHP (CGI) spoločné, a to prostredníctvom neuveriteľne rýchlej a pevnej infraštruktúry a nových konceptov v PHP. Appserver.io zároveň ponúka vývojárom PHP základné základné funkcie, ktoré sa dnes nachádzajú vo väčšine populárnych rámcov, ale vôbec nemajú v úmysle byť rámcom. Je to prekvapivo zábavná infraštruktúra pre vývoj PHP, ktorá vám umožňuje vytvárať výkonné aplikácie bez toho, aby ste potrebovali väčšinu rámca PHP.

appserver.io obsahuje skvelé funkcie ako...

• Vlastný výkonný webový server a základ HTTP.
• Výkonný Servlet Engine so skutočným multi-threadingom
• Závislosť vstrekovacieho kontajnera na vytváranie moderného, ​​modulárneho a testovateľného kódu
• Viacnásobné kontajnery perzistencie pre relácie a iné stavové komponenty
• Systém frontu správ na riadenie vykonávania dlho prebiehajúcich úloh
• Služba časovača na spustenie naplánovaných úloh

a oveľa viac.

appserver.io podporuje aj programovanie orientované na aspekty (AOP), čo je programovacia paradigma, ktorá sa dnes nachádza aj v najpopulárnejších frameworkoch, ako je Laravel. AOP umožňuje oddelenie prierezových problémov v rámci programu, čo umožňuje vývojárom vytvárať ešte modulárnejšie systémy.

S appserver.io je naším cieľom vytvoriť riešenie ako ďalší štandard pre podnikové aplikácie napísané v PHP. S vašou pomocou môžeme dosiahnuť tento cieľ.

Pokúsiť sa!

Sémantické verzovanie

appserver.io sa riadi sémantickým verzovaním. Na účely definovania verejného API sme zaviedli špecifické |_+_| pre appserver.io . Tieto PSR sú jadrom verejného API appserver.io, ale v rámci ich vlastnej definície a verzie, čo znamená, že sémantické verzovanie sa vzťahuje na tieto PSR a nie na samotný balík appserver .

Inštalácia

appserver.io je možné nainštalovať na niekoľko operačných systémov. Podporuje tiež niekoľko metód získavania softvéru. Ak chcete získať balík appserver.io, môžete urobiť jeden z nasledujúcich krokov:

čo je cummie

Stiahnite si jeden z našich vydania priamo z tohto úložiska, ktoré poskytuje testované inštalačné balíčky

Chyťte niektorý z našich nočné večery z našej projektovej stránky, aby ste získali najkrvavejšie inštalačné balíčky (a môžu tiež obsahovať chyby - len na testovanie a nie na produkčné použitie!!)

Zostavte si svoj vlastný balík pomocou ANT! Najprv naklonujte modul runtime. Potom aktualizujte aspoň |_+_| a |_+_| vytvorte vlastnosti podľa vášho prostredia a zostavte aplikačný server pomocou ANT |_+_| a |_+_| cieľ.

Balík sa nainštaluje s týmito základnými predvolenými charakteristikami:

• Inštalačný adresár: |_+_|
• Automatické spustenie po inštalácii, žiadne automatické spustenie pri reštarte
• Dostupný pod vopred nakonfigurovanými portami, ako je popísané tu

Špecifické kroky a charakteristiky operačného systému nájdete nižšie pre testované prostredia.

Mac OS X

Beží a testuje sa na Mac OS X 10.8.xa novšom!

Pre Mac OS X > 10.8.x poskytujeme |_+_| súbor na stiahnutie, ktorý obsahuje runtime a distribúciu. Dvojitým kliknutím na |_+_| spustí a prevedie vás procesom inštalácie.

Windows

Beží a testuje sa na Windows 7 (32-bit) a vyšších!

Keďže aplikačný server pre Windows dodávame ako súbor .jar, ktorý si môžete stiahnuť , nevyhnutnou požiadavkou na jeho používanie je nainštalované prostredie Java Runtime Environment (alebo JDK). Ak JRE/JDK nie je nainštalovaný, musíte tak urobiť ako prvý. JRE môžete získať zo stránky na stiahnutie spoločnosti Oracle. Ak je táto požiadavka splnená, môžete spustiť inštaláciu jednoduchým dvojitým kliknutím na archív .jar.

Debian

Beží a testuje sa na Debian Squeeze (64-bit) a vyšších!

Ak používate systém Debian, môžete tiež vyskúšať naše |_+_| Úložisko:

Voliteľne si môžete stiahnuť |_+_| súbory a nainštalujte ich dvojitým kliknutím na ne. To vyvolá predvoleného správcu balíkov systému a prevedie vás procesom inštalácie. Najprv nainštalujte runtime, pretože ide o závislosť distribúcie.

Fedora

Beží a testuje sa na verziách Fedora 20 (64-bit) a vyšších!

Poskytujeme aj |_+_| súbory pre Fedoru, ktoré si môžete stiahnuť a spustiť proces inštalácie dvojitým kliknutím naň. Toto spustí predvoleného správcu balíkov systému a prevedie vás procesom inštalácie.

CentOS

Beží a testuje sa na CentOS 6.5 (64-bit) a novšom!

Inštalácia a základné použitie je rovnaké ako na Fedore, ale poskytujeme rôzne balíčky. CentOS vyžaduje ďalšie úložiská ako remi alebo EPEL na uspokojenie ďalších závislostí.

Raspbian

Ako experiment ponúkame Raspbian a priniesli sme appserver do prostredia ARM. Čo povieme, podarilo sa! :D S |_+_| = raspbian môžete to skúsiť a postaviť si to sami. Naplánujte si však aspoň 5 hodín, keďže momentálne neponúkame pripravený inštalačný balík.

Základné použitie

Aplikačný server sa automaticky spustí, keď váš sprievodca inštaláciou (alebo správca balíkov) dokončí nastavenie. Po dokončení inštalácie ho môžete používať bez obmedzení..

Nižšie nájdete základné pokyny na používanie servera aplikácií. Po inštalácii si možno budete chcieť pozrieť vzorovú aplikáciu, ktorá je tiež súčasťou inštalácie. K aplikácii sa dostanete na |_+_|

Spustite svoj obľúbený prehliadač a pozrite sa, čo dokáže appserver. :) Pre vstup na stránku použite predvolené prihlásenie |_+_|.

Spúšťacie a zastavovacie skripty

Existuje niekoľko samostatných procesov, ktoré sú potrebné na správne fungovanie rôznych funkcií v rámci servera aplikácií.

V appserveri sú zahrnuté spúšťacie a zastavovacie skripty pre všetky operačné systémy typu *nix. Tieto fungujú rovnako ako na iných *nix systémoch. Oni sú:

|_+_|: Hlavný proces, ktorý spustí samotný aplikačný server

|_+_|: konfigurácia php-fpm + appserver. Náš predvolený backend FastCGI. Iný FCGI systém je možné pridať rovnakým spôsobom.

|_+_|: Strážny pes, ktorý monitoruje zmeny súborového systému a riadi reštarty appserverov

Na bežnom systéme by sa mali spustiť všetky tri tieto procesy, aby sa umožnila úplná sada funkcií. Na spustenie aplikačného servera je potrebný iba proces aplikačného servera. Zmeškáte však jednoduché nasadenie za chodu (|_+_|) a môžete mať problémy so staršími aplikáciami.

V závislosti od backendu FastCGI, ktorý chcete použiť, môžete zrušiť |_+_| pre iné procesy napr. môžete tiež použiť backend hhvm.

V súčasnosti podporujeme tri rôzne typy init skriptov, ktoré podporujú príkazy |_+_|, |_+_|, |_+_| a |_+_| (v iných systémoch môžu byť dostupné ďalšie príkazy).

Mac OS X (LAUNCHD) Spúšťací démoni LAUNCHD sa nachádzajú v inštalácii appserveru na |_+_|. Môžu byť použité so schémou |_+_|

Debian, Raspbian, CentOS, ...(SystemV) Všeobecne známy a nachádza sa v |_+_| podporujú aj vyššie uvedené príkazy poskytnuté vo forme |_+_|.

Fedora, ... (systemd) Skripty systemd init možno použiť pomocou |_+_| príkaz so syntaxou |_+_|.

Windows

V systéme Windows žiaľ neponúkame žiadny z týchto skriptov. Po inštalácii môžete spustiť aplikačný server pomocou |_+_| súbor umiestnený v koreňovom adresári vašej inštalácie. Najlepšie by bolo spustiť príkazový riadok ako správca a spustiť nasledujúce príkazy (za predpokladu predvolenej inštalačnej cesty):

HTTP(S) server

Konfigurácia samotného HTTP(S) Servera je väčšinou samozrejmá, takže sa stačí pozrieť na predvolený konfiguračný súbor a ak chcete, skúste zmeniť nastavenia. Po vykonaní akýchkoľvek zmien sa uistite, že ste reštartovali aplikačný server. :) Podrobný prehľad všetkých konfiguračných nastavení bude nasledovať ...

Nakonfigurujte virtuálneho hostiteľa

Pomocou virtuálnych hostiteľov môžete rozšíriť predvolenú konfiguráciu servera a vytvoriť prostredie špecifické pre hostiteľa na spustenie vašej aplikácie.

Môžete to urobiť pridaním konfigurácie virtuálneho hostiteľa do vášho globálneho konfiguračného súboru servera. Pozrite si príklad konfigurácie založenej na XML nižšie:

Vyššie uvedená konfigurácia je umiestnená v prvku servera a otvára virtuálny hostiteľ |_+_| ktorý má iný koreň dokumentu ako má globálna konfigurácia. Zrodil sa virtuálny hostiteľ. :-)

|_+_| prvok môže obsahovať parametre, pravidlá prepisovania alebo premenné prostredia, ktoré sú dostupné iba pre hostiteľa.

Nakonfigurujte svoje premenné prostredia

Premenné prostredia môžete nastaviť pomocou globálnej alebo virtuálnej konfigurácie založenej na hostiteľovi. Nižšie uvedený príklad ukazuje základné použitie premenných prostredia vo formáte XML.

Existuje niekoľko spôsobov, ako sa táto funkcia používa. Hrubú predstavu môžete získať, keď sa pozriete na moduly Apache mod_env a mod_setenvif, ktoré sme prijali.

Môžete vytvoriť definície premenných prostredia v závislosti od podmienok založených na REGEX, ktoré sa budú vykonávať na takzvaných spätných referenciách. Tieto spätné referencie sú premenné servera súvisiace s požiadavkou ako |_+_|.

Podmienka má formát |_+_|. Ak je podmienka prázdna, premenná prostredia sa nastaví zakaždým.

Definícia, ktorú môžete použiť, má tvar |_+_|. Definícia má aj niektoré špeciality:

• Nastavenie var na |_+_| zruší nastavenie premennej, ak predtým existovala
• Pre hodnotu, ktorú chcete nastaviť, môžete použiť aj spätné referencie. Ale tie sú obmedzené na premenné prostredia procesu PHP
• Hodnoty budú spracované ako reťazce

Servlet-Engine

Pôvodne boli Java servlety náprotivkom Javy k iným dynamickým webovým technológiám ako PHP alebo platforma Microsoft .NET. Na rozdiel od PHP, Servlet napísaný v Jave nie je skript, ktorý bude interpretovaný na základe požiadavky. Namiesto toho je to trieda, ktorá sa vytvorí inštanciou, keď sa spustí Servlet Engine. To znamená, že trieda servletov je už v pamäti a zostáva v pamäti.

Vo väčšine prípadov je to hlavná výhoda v porovnaní s bežným spôsobom PHP, ako neustále načítavať skript pri každej požiadavke. Keďže väčšina aplikácií PHP je založená na rámcoch ako Symfony alebo Laravel, za posledných pár rokov sa nesmierne rozrástla, opätovné načítanie všetkých skriptových súborov požadovaných aplikáciou značne spomaľuje výkon. To je jeden z dôvodov, prečo je ukladanie do vyrovnávacej pamäte hlavnou súčasťou všetkých dobrých rámcov PHP. Na jednej strane ukladanie do vyrovnávacej pamäte dostatočne zlepšuje výkon, takže aplikácia reaguje na požiadavku v prijateľnom časovom rámci. Na druhej strane je to tiež pôvod mnohých problémov, napríklad ako zneplatniť časti vyrovnávacej pamäte počas behu aplikácie.

Servlety vám umožňujú implementovať vašu aplikačnú logiku tak, ako by ste to robili normálne, ale bez toho, aby ste sa museli obávať drahého procesu opätovného načítania, ktorý je bežný pre bežné aplikácie PHP. Servlet je super rýchly a jednoduchý spôsob, ako implementovať vstupný bod na spracovanie požiadaviek HTTP, ktorý vám umožňuje vykonávať všetky úlohy kritické z hľadiska výkonu, ako je bootstrapping (jednoduchou metódou nazvanou |_+_|), keď sa spustí Servlet Engine. .

Čo je Servlet

Servlet je jednoduchá trieda, ktorá musí siahať od |_+_|. Vaša aplikačná logika môže byť potom implementovaná prepísaním |_+_| metódu alebo lepšie prepísaním metód špecifických pre požiadavku ako |_+_| ak chcete spracovať požiadavku GET.

Vytvorte jednoduchý Servlet

Napíšme si jednoduchý príklad a začnime známym |_+_| servlet

a uložte ho ako |_+_|.

Je to všetko? Áno! Reštart aplikačný server a otvorte |_+_| vo vašom obľúbenom prehliadači a ... vóila :)

Po zmene kódu vo vašom servlete je vždy potrebný reštart, pretože servlet sa načíta a inicializuje pri spustení aplikačného servera. Bez reštartu sa aplikačný server nedozvie, že ste vykonali nejaké zmeny.

Anotácie

Keďže jedným z našich hlavných cieľov je čo najjednoduchšia konfigurácia, rozhodli sme sa použiť anotácie všade tam, kde je to možné. Keďže anotácie nie sú natívne podporované PHP, poskytujeme podporu anotácií cez náš jazykový balík.

Okrem používania anotácií v našich komponentoch aplikačného servera bude možné vašu aplikáciu rozšíriť o anotácie pomocou funkcií, ktoré appserver poskytuje hneď po vybalení.

Ak napríklad uvažujete o rozšírení akcií komponentu radiča vo vašom rámci MVC pomocou anotácie @Route, môžete to urobiť nasledujúcim spôsobom

Väčšina implementácií anotácií, ktoré poskytuje naša Enterprise Beans PSR a používa sa pre Injekcia závislosti , ktoré budú opísané nižšie, sú založené na tejto implementácii anotácie.

Injekcia závislosti

Dependency Injection (DI) umožňuje vývojárom písať čistejší, opakovane použiteľný a udržiavateľný kód s menšou väzbou vložením potrebných inštancií za behu, namiesto ich vytvárania v samotnej triede. V rámci aplikačného servera má každá aplikácia svoj vlastný rozsah a teda aj vlastný kontajner na vstrekovanie závislostí. Toto zabráni vašej aplikácii fatálnym chybám ako |_+_|.

Čo je možné podať injekčne

Všeobecne všetko! Samotný aplikačný server nepoužíva DI, namiesto toho poskytuje DI ako službu pre aplikácie v ňom bežiace. Ale predtým, ako budete môcť nechať DI kontajner vložiť inštanciu do vašej triedy, musíte ju zaregistrovať. Registrácia triedy pre DI je celkom jednoduchá. Najbežnejším spôsobom na registráciu triedy v kontajneri DI je použitie anotácií.

Keď sa aplikačný server spustí, analyzuje |_+_| a |_+_| triedy priečinkov s podporovanými anotáciami. Ak sa trieda nájde, trieda sa zaregistruje v názvovom adresári aplikačných serverov pod názvom, ktorý zadáte v anotáciách |_+_| Atribút v tomto príklade |_+_|.

Ako vložiť inštanciu

DI môže byť v podstate manuálny proces, kde |_+_| inštanciu, ktorú potrebuje iná trieda, jej odovzdaním konštruktorovi. Vnútri aplikačného servera je injekcia proces, ktorý nevidíte, je to skôr druh mágie, ktorá sa deje v zákulisí. Takže namiesto manuálneho odovzdávania potrebných inštancií do konštruktora tried to za vás urobí kontajner DI.

Jednoducho musíte povedať DI kontajneru, čo potrebujete. Poďme sa pozrieť, ako sa to robí.

Property Injekcia

Prvá možnosť, ktorú máme, je anotovať vlastnosť triedy

S |_+_| atribút |_+_| anotáciu, máte možnosť zadať názov fazule, ktorú ste predtým zaregistrovali, anotáciou. Podrobnejší popis dostupných anotácií je súčasťou Perzistencia-kontajner .

Setter Injection

Druhou možnosťou vstrekovania inštancie je vstrekovanie nastavovača.

Táto metóda je uprednostňovaná, pretože bude prerobená tak, aby v ďalších verziách nepoužívala odraz.

rozbaľovací zoznam s možnosťou vyhľadávania v exceli

Perzistencia-kontajner

Ako je popísané v úvode, aplikácia je navrhnutá v prostredí runtime, akým je aplikačný server, akým je appserver.io. Nasledujúci príklad vám poskytuje krátky úvod o tom, ako môžete vytvoriť stavovú reláciu bean a ako môžete vyvolať jej metódu na strane klienta.

Prvá vec, ktorú môžete urobiť, je vytvoriť svoj SessionBean. Čo je to SessionBean? SessionBean je v podstate obyčajná trieda PHP. Avšak NESMIETE ho vytvárať priamo, pretože aplikačný server sa stará o jeho celý životný cyklus. Preto, ak potrebujete inštanciu SessionBean, musíte požiadať aplikačný server, aby vám dal inštanciu.

Kontajner persistencie vám poskytne proxy pre session bean, ktorý vám umožní vyvolať všetky metódy, ktoré SessionBean poskytuje, rovnako ako by ste to robili s bežnou inštanciou. Proxy vám však tiež umožňuje volať túto metódu cez sieť ako vzdialené volanie metódy. Používanie klienta kontajnera trvalej platnosti vám uľahčí prácu, ak je váš SessionBean na rovnakej inštancii aplikačného servera alebo dokonca na inom serveri aplikácií vo vašej sieti. To vám dáva možnosť distribuovať komponenty vašej aplikácie cez vašu sieť, čo znamená skvelú a bezproblémovú škálovateľnosť.

Musíte povedať kontajneru persistencie, aký typ SessionBean by ste chceli mať. MUSÍ sa to urobiť jednoduchým pridaním anotácie do bloku dokumentu triedy. Možné anotácie teda sú

• @Singleton
• @Bezstavový
• @Štátny

@Singleton SessionBean

SessionBean s anotáciou @Singleton sa vytvorí iba raz pre každú aplikáciu. To znamená, že vždy, keď požiadate o inštanciu, dostanete rovnakú inštanciu. Ak nastavíte premennú v SessionBean, bude dostupná, kým ju neprepíšete alebo kým sa nereštartuje aplikačný server.

@Stateless SessionBean

Na rozdiel od singleton session bean, SessionBean s anotáciou @Stateless sa vytvorí vždy, keď o to požiadate. Nemá ŽIADNY stav a je platný iba v čase, keď na ňom vyvoláte metódu.

@Stateful SessionBean

@Stateful SessionBean je kompromisom medzi dvoma ďalšími typmi. Je stavový pre reláciu s ID, ktoré odovzdáte klientovi, keď požiadate o inštanciu. Stavový SessionBean je užitočný napríklad, ak chcete implementovať niečo ako nákupný košík. Ak deklarujete inštanciu nákupného košíka, člen vašej triedy SessionBean ju urobí trvalou počas životnosti relácie.

Príklad

Nasledujúci príklad ukazuje skutočne jednoduchú implementáciu stavového SessionBean poskytujúceho počítadlo, ktoré sa zvýši vždy, keď zavoláte |_+_| metóda.

Uložte SessionBean do |_+_|.

Ako je popísané vyššie, NESMIETE ho vytvárať priamo. Ak chcete požiadať o inštanciu SessionBean, MUSÍTE použiť klienta kontajnera perzistencie. S |_+_| dostanete proxy do vášho SessionBean, na ktorom môžete vyvolať metódy ako pri skutočnej inštancii.

Aby sme ďalej rozvíjali náš HelloWorldServlet, zvýšme počítadlo s každou požiadavkou na servlet. Aby sme to dosiahli, musíme refaktorovať |_+_| metóda

To je všetko!

Keďže v tomto príklade používame @Stateful SessionBean, MUSÍME spustiť reláciu, aby kontajner trvalosti mohol naviazať SessionBean. Ak by ste použili @Singleton SessionBean, efekt by bol prakticky rovnaký, ale bolo by možné spustiť SessionBean na reláciu. V dôsledku toho každý servlet, ktorý vyvolá |_+_| metóda na singletone SessionBean by zvýšila počítadlo, čo znamená, že každé volanie na server by zvýšilo počítadlo a nie každé konkrétne volanie pre konkrétnu reláciu.

Front správ

Front správ poskytuje možnosť spracovávať dlho prebiehajúce úlohy v zapuzdrenom kontexte. Napríklad, ak chcete do svojho online obchodu importovať veľa produktov, môžete poslať správu do frontu správ, ktorý potom spustí proces importu na pozadí bez toho, aby bránil pokračovaniu procesu volania.

Použitie frontu správ vám dáva možnosť používať vlákna bez toho, aby ste sa museli starať o úskalia!

Prišla pošta!

Pred odoslaním správy musíme špecifikovať, čo sa má stať, keď správu dostaneme! Front správ vám umožňuje špecifikovať takzvané |_+_|. Každý |_+_| môže mať prijímač, ktorým musí byť tzv. |_+_|. A |_+_| je veľmi podobný a @Stateless SessionBean , ale má iba jeden vstupný bod, |_+_| spôsob správy. Kedykoľvek sa správa odošle do frontu, front správ ju jednoducho vloží do zásobníka. V pozadí |_+_| beží v inom kontexte a dopytuje zásobník na nové správy. Ak je k dispozícii nová správa, bude stiahnutá zo zásobníka ako nová inštancia príjemcu, ktorého |_+_| je viazaný na a bude vytvorený, aby odovzdal správu na spracovanie.

Poďme si teda vytvoriť jednoduchý |_+_| s

a uložte to do súboru s názvom |_+_|. Ďalšia vec, ktorú potrebujeme, je |_+_| ktorý nám umožňuje prijať a spracovať správu v samostatnom vlákne.

Poznámka: okrem funkcií, ktoré musíte implementovať pomocou |_+_| správy, musíte použiť aj anotáciu |_+_| na vašej triede. MUSÍTE anotovať MessageBean týmto spôsobom, aby o ňom kontajner vedel a zaregistroval ho pri spustení.

Je to celkom jednoduché na spustenie importu v samostatnom vlákne? Ale čo tak poslať správu tomuto |_+_|?

Poslať správu

Správy sú POPO (Plain Old PHP Objects), ktoré je možné posielať cez sieť. Ak teda chcete odoslať správu, musíte inicializovať klienta frontu správ a určiť, ktorý |_+_| komu chcete poslať správu.

Opäť predĺžime naše |_+_| na spustenie procesu importu na žiadosť POST

Na uľahčenie procesu môžete použiť |_+_| anotáciu, aby kontajner vložil inštanciu odosielateľa, ktorú môžeme použiť na odoslanie názvu súboru obsahujúceho údaje do |_+_|.

Služba časovača

Vo väčšine vašich projektov máte potrebu naplánovať si úlohy, ktoré sa majú spracovať v pravidelných intervaloch alebo k daným dátumom v budúcnosti. Keďže PHP je sám o sebe skriptovací jazyk, chýba mu takáto funkcionalita a vývojári zvyčajne skončia pomocou utilít ako CRON, keď pracujú na Mac OS X alebo distribúcii Linuxu, ktorá tiež vyžaduje nízkoúrovňový prístup k serveru. A ak pracujete v systéme Windows, je to ešte o niečo komplikovanejšie. V systéme Windows existuje nástroj s názvom Scheduler, ale jeho používanie nie je také jednoduché ako CRON. Žiadna z týchto možností nie je v skutočnosti „programovateľná“ a tu prichádza do hry služba časovača, vďaka ktorej sa plánovanie úloh v rámci aplikácie appserver stáva skutočnosťou.

Rovnako ako CRON, služba časovača vám umožňuje naplánovať spracovanie vašich funkčných úloh k danému dátumu alebo v pravidelných intervaloch. Na rozdiel od CRON vám však umožňuje naplánovať spracovanie metód vašich fazúľ (ktoré si pamätajú, sú už spracované a uložené v pamäti).

Ako sa to dá urobiť?

Odpoveď už možno poznáte jednoduchým pridaním anotácie k vašej metóde, ako je uvedené nižšie

|_+_| anotácia na |_+_| metóda naplánuje vyvolanie tejto metódy každú minútu bez potreby mať nakonfigurovaný alebo spustený CRON. Takéto |_+_| môžu byť vytvorené aj programovo. Ak sa chcete o tejto funkcii dozvedieť viac, pozrite si náš príklad .

AOP

Hoci vo svojich začiatkoch bol AOP módnym slovom. Stal sa však vývojovou paradigmou, po ktorej dnes nasleduje mnoho rámcov PHP. Už mnoho rokov ho nasledovali ďalšie jazyky ako Java. Keďže v skutočnosti neexistuje žiadne stabilné rozšírenie PECL, ani AOP nie je súčasťou jadra PHP, vytvorenie takéhoto prostredia vytvára množstvo výziev, aby aplikácie založené na AOP fungovali dobre. Kvôli svojej povahe musí byť AOP hlboko votkaný do vášho kódu. Väčšina riešení dostupných pre PHP to rieši generovaním tzv. |_+_| ktoré zabalia pôvodné metódy a umožňujú tkať rady pred, po alebo okolo pôvodnej implementácie.

Keďže v appserveri sa nachádzame vo viacvláknovom prostredí a výkon je jedným z našich hlavných cieľov, nemohli sme použiť žiadne z dostupných riešení. Keďže potrebujeme generovať aj triedy proxy, rozhodli sme sa to urobiť pomocou automatického zavádzača. A keďže sme povolili autoloader ako súčasť distribúcie appserver.io, nemusíte nič konfigurovať na používanie AOP vo svojom kóde.

Ako pridať radu

Integráciu AOP do vašej aplikácie je možné vykonať dvoma spôsobmi. Prvým je definovať bodové rezy (a ak chcete aj rady) v tej istej triede, do ktorej sa budú tkať, druhým spôsobom je ich oddelenie. V nasledujúcej časti chceme opísať druhý prístup.

Povedzme, že chceme zaznamenať všetky požiadavky GET na náš HelloWorldServlet bez pridania akéhokoľvek kódu do samotného servletu. Aby sme to dosiahli, musíme najprv vytvoriť triedu aspektov ako

Uložte triedu do |_+_| a reštart aplikačný server.

Ak chcete zobraziť správu denníka, otvorte konzolu (Linux/Mac OS X) a zadajte

Potom otvorte |_+_| vo svojom obľúbenom prehliadači a pozrite sa na konzolu.

AOP je veľmi výkonný nástroj, ktorý obohatí vašu aplikáciu o funkčnosť s „riadenou“ väzbou. Ale ako vo väčšine prípadov, veľká moc prichádza s veľkou zodpovednosťou. Takže je naozaj potrebné mať na pamäti, kde sú vaše triedy Aspektov a čo robia. Ak nie, niekto sa bude čudovať, čo sa stane, a môže potrebovať veľa času, aby zistil problém. Aby sme tomu zabránili, v budúcich verziách poskytneme vyhlásenie o odporúčaní založenom na XML.

Návrh podľa zmluvy

Okrem AOP je ďalším zaujímavým prístupom, ktorý podporujeme hneď po začiatku, keď sa zamyslíte nad architektúrou vášho softvéru, návrh podľa zmluvy.

Prvýkrát, ktorý predstavil Bertrand Meyer v súvislosti s jeho návrhom programovacieho jazyka Eiffel, Design-by-Contract vám umožňuje definovať formálne, presné a overiteľné špecifikácie rozhrania softvérových komponentov.

Design-by-Contract rozširuje bežnú definíciu tried, abstraktných tried a rozhraní pridaním pre-/postconditions a invariantov označovaných ako |_+_|. Keďže Design-by-Contract nie je, rovnako ako AOP, súčasťou jadra PHP, na špecifikáciu týchto zmlúv používame aj anotácie.

Čo sa dá robiť?

Ako je uvedené vyššie, cieľom tejto knižnice je poskytnúť vám silu návrhu podľa zmluvy, čo je prístup, vďaka ktorému budú vaše aplikácie robustnejšie a ľahšie sa ladia. Obsahuje základné funkcie ako:

• Použite svoje základné |_+_| anotácie |_+_| a |_+_| ako rady typu (skalárne a založené na triede/rozhraní), vrátane špeciálnych funkcií ako |_+_| pomocou e. g. |_+_| (momentálne funguje iba pre kolekcie s komplexnými typmi)
• Zadajte zmluvy komplexnej metódy v syntaxi PHP pomocou |_+_| ako predpoklad a |_+_| ako dodatočná podmienka
• Zadajte stav platnosti pre vaše triedy (napr. |_+_|), ktorý bude vždy pravdivý pomocou |_+_|
• Vyššie uvedené (okrem bezpečnosti typu) zdedí každá podradená štruktúra, čím sa posilnia vaše hierarchie objektov
• Knižnica vás upozorní (výnimkou alebo správou protokolu) na porušenie týchto zmlúv

Ako to funguje?

Používame systém automatického načítavania a vytvárania kódu, aby sme zabezpečili dodržiavanie našich anotácií. Tento proces zahŕňa 4 kroky:

• Autoloader : Zvláda automatické načítanie a bude vedieť, či je pre určitý súbor potrebné vynútenie zmluvy. Ak áno (a vyrovnávacia pamäť je prázdna), volanie bude presmerované na kombináciu generátora/analyzátora
• Analyzátor: analyzuje potrebný súbor pomocou |_+_| a poskytnúť informácie pre ďalšiu manipuláciu.
• Generátor : Použije filtre prúdov na vytvorenie novej definície štruktúry súboru obsahujúcej nakonfigurované presadzovanie
• Cache : Umožní nám vynechať Parser a Generator pre budúce hovory, aby sa výrazne zrýchlilo používanie.

Použitie

Predpokladajme, že sa chceme uistiť, že počítadlo v našom stavovom SessionBean bude vždy celé číslo, môžeme definovať jednoduchý kontrakt, preto

V závislosti od vašej konfigurácie, ak by sa metóda pokúsila nastaviť reťazec na premennú počítadla, implementácia Design-by-Contract by buď vyvolala výnimku alebo zapísala chybové hlásenie do nášho log súboru pod |_+_|.

Runtime prostredie

Prostredie runtime appserver.io je dodávané modulom runtime balíka . Tento balík poskytuje runtime, ktoré je nezávislé od systému a zahŕňa skompilované PHP prostredie bezpečné pre vlákna. Okrem najnovšej verzie PHP 5.5.x sa balík dodáva s nasledujúcimi nainštalovanými rozšíreniami:

• pthreads
• appserver (obsahuje niektoré náhradné funkcie, ktoré sa správajú zle v prostredí s viacerými vláknami)

Okrem toho sú rozšírenia PECL XDebug a ev kompilované ako zdieľané moduly. |_+_| je potrebné vykresliť podrobné správy o pokrytí kódu pri spustení jednotkových a integračných testov. |_+_| sa použije na integráciu služby časovača v jednej z budúcich verzií.

Konfigurácia

Veríme, že appserver by mal byť vysoko konfigurovateľný, takže si s ním môže pohrať každý, kto má záujem. Preto poskytujeme centrálny konfiguračný súbor umiestnený na |_+_|.

Tento súbor obsahuje úplné architektúra ako XML štruktúru.

Takže ak chcete zmeniť používané komponenty, zaviesť nové služby alebo škálovať systém pridaním ďalších serverov, môžete tak urobiť pomocou niekoľkých riadkov XML. Môžete sa pozrieť na základné |_+_|.

Architektúra

V tomto príklade máme skrátenú časť |_+_| aby ste pochopili, ako je architektúra riadená konfiguráciou.

Vo vyššie uvedenom príklade môžete vidieť tri dôležité komponenty architektúry appserver, ktorá sa používa. The kontajner , server a a protokol (ak ste nečítali o našich zákl architektúra teraz by ste mali). V podstate budujeme kontajner, ktorý obsahuje server využívajúci protokol websocket na spracovanie prichádzajúcich požiadaviek.

Konfigurácia kontajnera

A kontajner sa vytvorí pomocou |_+_| prvok v rámci |_+_| zbierka |_+_| prvok dokumentu. Dve časti XML vytvárajú špecifický kontajner v systéme pri spustení:

|_+_| atribút uvádza triedu rozširujúcu naše |_+_|, ktorá definuje kontajner ako špecifický typ kontajnera.

|_+_| element uvádza triedu obsahujúcu prípravky na spustenie kontajnera. Dá sa považovať za hák, ktorý sa vyvolá skôr, ako bude kontajner k dispozícii.

To je v podstate všetko, čo je potrebné urobiť na vytvorenie nového kontajnera. Aby ste ho mohli použiť, musí obsahovať aspoň jeden server v rámci svojich |_+_| zber.

Konfigurácia servera

The serverov obsiahnutých našimi kontajner môžu byť tiež voľne navrhnuté konfiguráciou XML a budú vytvorené pri spustení kontajnera. Ak chcete povoliť a server musíte spomenúť tri základné atribúty prvku:

|_+_| špecifikuje triedu implementujúcu |_+_|, ktorá implementuje základné správanie servera pri prijatí pripojenia a ako s ním bude zaobchádzať.

|_+_| atribút určuje typ soketu, ktorý by mal server otvoriť. napr. stream alebo asynchrónny soket

|_+_| špecifikuje zdroj konfigurácie servera a kontajner pre informácie o behu, napr. ServerVariables ako |_+_|

Máme teda svoj špecifický server, ktorý otvorí určitý port a bude fungovať v definovanom kontexte. Aby však server spracoval určitý typ požiadavky, musí vedieť, ktorý protokol rozprávať.

Môžete to urobiť pomocou |_+_| prvok. Niektoré serverové obaly dokážu spracovať určité protokoly. Preto môžeme použiť protokoly, ktoré serverový wrapper, napr. |_+_| podpery vo forme spojovacích manipulátorov. WebServer ponúka |_+_| trieda. Jeho použitím je server schopný porozumieť protokolu HTTP.

Konfigurácia aplikácie

Okrem konfigurácie kontajnera a servera je možné nakonfigurovať aj aplikáciu. Každá aplikácia môže mať svoje vlastné automatické zavádzače a správcov. Štandardne sa každá aplikácia nachádza v adresári webovej aplikácie aplikačných serverov |_+_| budú inicializované s predvolenými hodnotami definovanými v |_+_|

Ak vaša aplikácia nepoužíva žiadny z definovaných zavádzačov tried alebo manažérov alebo chcete implementovať svojich vlastných manažérov, môžete ich definovať v |_+_| súbor, ktorý musíte priložiť k žiadosti. Váš vlastný prispôsobený súbor musí byť uložený v |_+_|. Keď sa spustí aplikačný server, tento súbor sa analyzuje a vaša aplikácia sa inicializuje pomocou zavádzačov tried a manažérov, ktoré ste tam definovali.

Uvedomte si prosím: predvolené zavádzače a správcovia tried poskytujú väčšinu funkcií opísaných vyššie. Takže ak ich odstránite z |_+_|, musíte očakávať neočakávané a nesprávne správanie.

Konfigurácia modulu

Webový server je dodávaný s balíkom predvolených modulov. Funkcionalitu, ktorá nám umožňuje konfigurovať napríklad virtuálneho hostiteľa alebo premenné prostredia, poskytujú aj dva veľmi dôležité moduly.

Prepísať modul

Prepisovací modul možno použiť podľa |_+_| rozhranie. Potrebuje počiatočné volanie |_+_| a spracuje každú požiadavku ponúknutú |_+_| metóda. Modul sa najlepšie používa v rámci |_+_| ponúka všetku potrebnú infraštruktúru.

pravidlá

Najdôležitejšou časťou modulu prepisovania je spôsob, akým môže vykonávať prepisy. Všetky prepisy sú založené na pravidlách prepisovania, ktoré pozostávajú z troch dôležitých častí:

reťazec podmienky : Podmienky, ktoré musia byť splnené, aby pravidlo nadobudlo účinnosť. Toto je vysvetlené podrobnejšie pod podmienkou syntaxe

cieľový reťazec : Cieľ, na ktorý sa má prepísať požadované URI. V rámci tohto reťazca môžete použiť spätné referencie podobné modulu Apache mod_rewrite s tým rozdielom, že musíte použiť |_+_| (namiesto |_+_| Apache).

Podmienky pravidiel zhody, ktoré si konkrétne vyberiete prostredníctvom regulárneho výrazu, sú tiež súčasťou dostupných spätných odkazov, ako aj premenných servera a prostredia.

php knižnica web scraper

Jednoduchý príklad : Stav ako |_+_| by vytvoril spätnú referenciu |_+_| s hodnotou |_+_| pre požadované URI |_+_|. Cieľový reťazec |_+_| by preto viedlo k prepísaniu na |_+_|

vlajkový reťazec : Môžete použiť príznaky podobné mod_rewrite, ktoré sa používajú na to, aby pravidlá reagovali určitým spôsobom alebo ovplyvnili ďalšie spracovanie. Viac sa dozviete v sekcii na vločke

Syntax podmienky

Syntax možných podmienok je zhruba založená na možnostiach kombinácie RewriteCondition a RewriteRule Apache.

Ak chcete použiť takúto kombináciu, môžete podmienky spojiť pomocou |_+_| symbol pre kombináciu OR a |_+_| symbol pre podmienky v kombinácii AND.

Uvedomte si, že AND má prednosť pred ALEBO! Podmienky môžu byť regulárny výraz PCRE alebo určité pevné výrazy. Takže reťazec podmienky |_+_| by zodpovedali iba skutočným súborom (cez |_+_|), ktoré začínajú číslami alebo končia veľkými písmenami a príponou .txt.

Ako ste si mohli všimnúť: Spätné lomky áno netreba uniknúť .

Tiež by vás mohlo zaujímať |_+_| stave. Toto je priama kópia Apaches -f RewriteCondition. Podporujeme aj niekoľko ďalších výrazov pre podmienky založené na regulárnych výrazoch, ktorými sú:

• < : Je operand lexikálne predchádzajúci |_+_|?
• > : Je operand lexikálne nasledujúci |_+_|?
• = : Je operand lexikálne rovný |_+_|?
• -d : Je operand adresár?
• -f : Je operand skutočný súbor?
• -s : Je operand skutočný súbor s veľkosťou väčšou ako 0?
• -l : Je operand symbolickým odkazom?
• -X : Je operand spustiteľný súbor?

Ak vás zaujíma, čo |_+_| môže byť: je čokoľvek chcete, aby to bolo ! Môžete zadať ľubovoľný operand pomocou |_+_| symbol. Všetky podmienky v pravidle použijú nasledujúci operand napravo od nich a ak žiadny nedostane požadované URI. Napríklad:

• |_+_| Prevezme požadované URI pre obe podmienky (všimnite si symbol |_+_|)
• |_+_| Otestuje obe podmienky oproti koreňovému adresáru dokumentu
• |_+_| Otestuje iba prvý proti koreňovému adresáru dokumentu a druhý proti požadovanému URI

Možno ste si všimli |_+_| symbol pred |_+_| a zapamätal si ho zo syntaxe spätného odkazu. Je to preto, že všetky bežné serverové varianty Apache môžu byť tiež explicitne použité ako spätné referencie!

To vám nefunguje? Potrebujete presný opak? Žiaden problém!

Všetky podmienky, či už na základe regulárneho výrazu alebo výrazu, možno negovať pomocou |_+_| symbol pred nimi! Takže |_+_| by sa zhodovali so všetkými reťazcami, ktoré NEZAČÍNAJÚ číslom a |_+_| by sa zhodovalo so všetkými neadresármi.

Vlajky

Vlajky sa používajú na ďalšie ovplyvnenie spracovania. Môžete zadať toľko príznakov na prepísanie, koľko chcete, ale uvedomte si ich vplyv! Syntax pre niekoľko príznakov je jednoduchá: stačí ich oddeliť znakom |_+_| symbol. Príznaky, ktoré môžu akceptovať parameter, môžu byť priradené pomocou |_+_| symbol. Aktuálne podporované príznaky sú:

L : Keďže pravidlá sa bežne spracovávajú jedno po druhom, |_+_| príznak urobí z označeného pravidla posledné spracované, ak sa zhoduje.

R : Ak je nastavený tento príznak, presmerujeme klienta na URL zadanú v |_+_|. Ak ide len o URI, presmerujeme sa na toho istého hostiteľa. Môžete tiež zadať vlastný stavový kód medzi 300 a 399, aby ste označili dôvod/druh presmerovania. Predvolená hodnota je |_+_| aka |_+_|

M : Znamená mapu. Pomocou tohto príznaku môžete zadať externý zdroj (pozrite si triedy Injector projektu WebServer) cieľovej mapy. S |_+_| môžete určiť, aký musí byť index mapy, aby sa zhodoval. Toto párovanie je hotové iba ak sa podmienka prepísania zhoduje a bude sa správať ako ďalšia podmienka

Modul virtuálneho hostiteľa

Modul je možné použiť podľa |_+_| rozhranie. Potrebuje počiatočné volanie |_+_| a spracuje každú požiadavku ponúknutú |_+_| metóda. Modul sa najlepšie používa v rámci projektu webového servera, pretože ponúka všetku potrebnú infraštruktúru.

Ak potrebujete nakonfigurovať virtuálneho hostiteľa, mal by vyzerať ako nasledujúci príklad, ktorý umožňuje inštaláciu Magento pod |_+_|.

Predvolené nastavenia konfigurácie

Uvidíte, že poskytujeme základné front-endové implementácie služieb, ktoré poskytuje runtime appserver. Ak chcete tieto služby využívať sami, mali by ste sa pozrieť do kódu našich aplikácií a prečítať si o tom vývoj aplikácií .

Možno vás zaujímajú rôzne porty, ktoré používame. V predvolenom nastavení aplikačný server otvorí niekoľko portov, na ktorých sú dostupné jeho služby. Keďže nechceme blokovať (alebo byť nimi blokované) iné služby, používame porty vo vyššom rozsahu.

Štandardne používame nasledujúce porty:

WebContainer

• HTTP server: |_+_|
• HTTPS server: |_+_|

Perzistencia-MQ-kontajner

• Perzistentný kontajner: |_+_|
• Front správ: |_+_|

Predvolené mapovanie portov môžete zmeniť pomocou konfiguračný súbor . Ak máte záujem o naše pomenovanie, môžete vidieť náš vzor kontajner->server, možno budete chcieť hlbšie nahliadnuť do našej architektúry

Nasadenie

Adresár nasadenia v distribúcii aplikačného servera appserver.io je miesto, kde môžu koncoví používatelia umiestniť svoj obsah nasadenia (napríklad súbory phar), aby ho nasadili do behu servera.

Používateľom, najmä tým, ktorí používajú produkčné systémy, sa odporúča, aby na nahrávanie a nasadzovanie obsahu používali rozhrania API na správu appserver.io AS.

Režimy nasadenia

Skener v skutočnosti podporuje iba režim manuálneho nasadenia, čo znamená, že na spracovanie nasadenia obsahu musíte reštartovať server. V tomto režime sa skener nepokúsi priamo monitorovať obsah nasadenia a rozhodnúť, či alebo kedy si koncový používateľ želá obsah nasadiť alebo zrušiť. Namiesto toho sa skener spolieha na systém súborov značiek, pričom pridanie alebo odstránenie súboru značiek používateľom slúži ako akýsi príkaz, ktorý skeneru povie, aby nasadil, zrušil nasadenie alebo premiestnil obsah.

Rozbalený obsah je tiež možné skopírovať priamo do priečinka webových aplikácií. Po reštartovaní webového servera bude váš obsah nasadený bez akéhokoľvek vplyvu na skener nasadenia, pretože bude rozpoznaný iba zazipovaný (.phar) obsah.

Súbory značiek

Súbory značiek majú vždy rovnaký názov ako obsah nasadenia, na ktorý sa vzťahujú, ale s pridanou príponou súboru. Napríklad súbor značiek, ktorý označuje, že by sa mal nasadiť súbor example.phar, má názov example.phar.dodeploy. Rôzne prípony súboru značiek majú rôzny význam.

Relevantné typy súborov značiek sú:

Základné pracovné postupy

Všetky príklady predpokladajú, že premenná $AS ukazuje na koreň distribúcie appserver.io AS.

Používatelia Windows: nižšie uvedené príklady používajú príkazy shellu UNIX; pozri Poznámky systému Windows nižšie.

1. Pridajte nový zazipovaný obsah (.phar) a nasaďte ho:

1. Zrušiť nasadenie aktuálne nasadeného obsahu vo formáte zip (.phar):

1. Nahraďte aktuálne nasadený obsah vo formáte zip (.phar) novou verziou a znova ju nasaďte:

Poznámky systému Windows

Vyššie uvedené príklady používajú príkazy shellu UNIX. Ekvivalenty Windows sú:

Všimnite si, že správanie |_+_| a |_+_| sú odlišné, ale rozdiely nie sú relevantné pre použitie.

Odinštalovať

Pred odinštalovaním by ste mali zastaviť všetky služby , ktoré sú stále spustené (balíky založené na rpm sa o to postarajú samy), v opačnom prípade môžu nastať problémy s existujúcimi pid súbormi v Linuxe a Macu pri ďalšej inštalácii.

Ak chcete odinštalovať server aplikácií v systéme Linux, môžete sa spoľahnúť na systém správy balíkov. V systéme Windows môžete použiť bežný proces odinštalovania, ktorý poskytuje operačný systém.

V systéme Mac OS X môžete jednoducho odstrániť |_+_| priečinok, ktorý obsahuje všetky nainštalované súbory.

Vonkajšie odkazy

• Všetko o appserver.io na stránke appserver.io

Licencia

Autor: appserver-io
Zdrojový kód: https://github.com/appserver-io/appserver
Licencia: Licencia OSL-3.0

#php