Imaginați-vă că am făcut site-ul. Procesul a fost fascinant și foarte frumos de urmărit, numărul vizitatorilor crescând.
În plus, serverul dvs. a scăzut și nu rezistă încărcării tot mai mari. În loc să achiziționați noi clienți și / sau vizitatori obișnuiți, ați rămas la jgheabul rupt și, în plus, ați avut o pagină goală.
Toate eforturile dvs. de a vă relua activitatea sunt ineficiente - chiar și după repornire, serverul nu poate face față fluxului de vizitatori. Pierde trafic!
Nimeni nu poate prevedea probleme cu traficul. Foarte puțini sunt angajați în planuri pe termen lung, când lucrează la un proiect potențial cu randament ridicat pentru a respecta termenele limită.
Cum, deci, putem evita toate aceste probleme? Pentru aceasta trebuie să rezolvați două întrebări: optimizarea și scalarea.
optimizare
În primul rând, este necesar să faceți upgrade la cea mai recentă versiune a PHP (în prezent la versiunea 5.5, foloseste OpCache), indicele de baza de date și cache conținut static (rar schimbă pagini, cum ar fi Despre. Întrebări frecvente și așa mai departe).
Optimizarea afectează nu numai cache-ul resurselor statice. De asemenea, este posibil să instalați un server suplimentar non-Apache (de exemplu, Nginx) proiectat special pentru a gestiona conținutul static.
Ideea este aceasta: ai pus Nginx în fața ta Apache-server (Ngiz va -Server front-end, și Apache - backend), și să-l instruiască pentru a intercepta solicitările către resursele statice (de exemplu, * .jpg * .png * ... mp4. * .html ...) și întreținerea acestora fără cerere de direcție pentru Apache.
Această schemă se numește proxy reversibil (adesea menționată împreună cu tehnica de echilibrare a sarcinii, care este descrisă mai jos).
scalare
Există două tipuri de scalare - orizontală și verticală.
Spunem că site-ul este scalabil, când poate rezista creșterii sarcinii fără a trebui să facă schimbări în software.
Scalarea verticala
Imaginați-vă că aveți un server web care servește aplicației web. Acest server are următoarele caracteristici de 4 GB de memorie RAM. i5 CPU și 1TB HDD.
Este bine îndeplinirea sarcinilor care îi sunt atribuite, dar pentru a face față mai bine cu traficul tot mai mare, vă decideți să înlocuiți RAM de 4 GB la 16 GB, instalați noul procesor i7 și adăugați un PCIe vehicul SSD / HDD hibrid.
Serverul a devenit acum mai puternic și poate rezista încărcărilor mari. Aceasta este ceea ce se numește scalare verticală sau "scalare interioară" - îmbunătățiți caracteristicile mașinii pentru ao face mai puternică.
Acest lucru este bine ilustrat în imaginea de mai jos:
Scalarea orizontală
Pe de altă parte, avem capacitatea de a face o scalare orizontală. În exemplul de mai sus, costul de actualizare a hardware-ului este cu puțin mai mic decât costul costurilor inițiale de achiziționare a computerului server.
Acest lucru este foarte scump din punct de vedere financiar și adesea nu dă efectul pe care îl așteptăm - cele mai multe probleme legate de scalare se referă la sarcini paralele.
Dacă numărul de nuclee de procesor nu este suficient pentru a executa firele existente, nu contează cât de puternic este instalat serverul CPU, acesta va funcționa încet și va forța vizitatorii să aștepte.
Scalarea orizontală înseamnă clustere clădirilor provenite de la mașini (adesea cele cu putere redusă) conectate împreună pentru a menține un site Web.
În acest caz, se utilizează un balancer de sarcină, o mașină sau un program care se ocupă de ceea ce determină ce cluster să trimită următoarea solicitare de intrare.
Și mașinile din cluster împărtășesc în mod automat sarcina între ele. În acest caz, lățimea de bandă a site-ului dvs. crește cu un ordin de mărime în comparație cu scalarea verticală. Acest lucru este, de asemenea, cunoscut sub numele de "scalare în lățime".
Există două tipuri de balansoare de încărcare - hardware și software. Balancerul de software este instalat pe o mașină normală și primește toate traficul de intrare, redirecționându-l către un handler adecvat. Ca un balancer de încărcare software, de exemplu, Nginx poate efectua.
Acceptă cereri pentru fișiere statice și le servește în mod independent, fără a împovăra acest Apache. Un alt software popular pentru software-ul de echilibrare este Squid. pe care o folosesc în compania mea. Oferă un control deplin asupra tuturor problemelor posibile printr-o interfață foarte ușor de utilizat.
Balancatorii de hardware sunt o mașină specială separată care efectuează numai sarcina de echilibrare și pe care, de regulă, nu este instalat niciun alt software. Cele mai populare modele sunt concepute pentru a face față unei cantități uriașe de trafic.
Când scalați pe orizontală, se întâmplă următoarele:
Rețineți că cele două metode de scalare descrise nu se exclud reciproc - puteți îmbunătăți caracteristicile hardware ale mașinilor (numite și noduri) utilizate într-un sistem de cluster scalabil.
În acest articol, ne vom concentra pe o scalare orizontală, deoarece în majoritatea cazurilor este preferabilă (mai ieftină și mai eficientă), deși este mai dificil de implementat din punct de vedere tehnic.
Dificultăți legate de schimbul de date
Există mai multe momente alunecoase care apar atunci când scalarea aplicațiilor PHP. Blocajul de aici este baza de date (vom vorbi despre asta în a doua parte a acestei serii).
Sarcină de echilibrare constantă
Un balansor de încărcare persistentă își amintește unde a fost procesată cererea anterioară pentru un anumit client și, la următoarea solicitare, trimite cererea acolo.
De exemplu, dacă am vizitat site-ul nostru și am conectat-o acolo, balancerul de sarcină mă va trimite, de exemplu, la Server1. îmi amintește acolo și data viitoare când fac clic, voi fi redirecționat din nou la Server1. Toate acestea mi se întâmplă destul de transparent.
Dar dacă Server1 a căzut? În mod normal, toate datele de sesiune vor fi pierdute și va trebui să mă înregistrez din nou pe noul server. Acest lucru este foarte neplacut pentru utilizator. Mai mult, aceasta este o sarcină suplimentară pentru balancerul de sarcină: nu numai că va trebui să redirecționeze mii de oameni către alte servere, dar și să-și amintească unde le-a îndrumat.
Aceasta devine un alt obstacol. Și dacă singurul balanser de încărcare se va rupe și toate informațiile despre locația clienților de pe servere vor fi pierdute? Cine va gestiona echilibrarea? O situație complicată, nu-i așa?
Separarea datelor locale
Separarea datelor din sesiune în interiorul unui cluster pare cu siguranță o soluție bună, dar necesită o schimbare în arhitectura aplicației, deși acest lucru merită, deoarece blocajul devine larg. Căderea unui server încetează să fie fatală pentru întregul sistem.
Se știe că datele sesiunii sunt stocate în matricea superglobală PHP $ _SESSION. De asemenea, nu este secret pentru nimeni că această matrice de $ _SESSION este stocată pe hard disk.
În consecință, deoarece discul aparține unei mașini speciale, alții nu au acces la ea. Atunci cum îl împărțiți pentru mai multe computere?
Rețineți că managerii de sesiuni din PHP pot fi înlocuiți - puteți defini propria clasă / funcție pentru gestionarea sesiunilor.
Utilizarea bazei de date
Folosind propriul handler de sesiuni, putem fi siguri că toate informațiile despre sesiuni sunt stocate în baza de date. Baza de date trebuie să locuiască pe un server separat (sau într-un grup propriu). În acest caz, serverele încărcate uniform se vor ocupa doar de procesarea logicii de afaceri.
Deși această abordare funcționează destul de bine, în cazul traficului mare, baza de date devine nu doar un loc vulnerabil (pierzându-l, pierzi totul), vor exista numeroase apeluri la acesta din cauza necesității de a înregistra și citi datele din sesiune.
Acest lucru devine un alt obstacol în sistemul nostru. În acest caz, puteți aplica scalarea în lățime, ceea ce este problematic atunci când utilizați baze de date tradiționale, cum ar fi MySQL. Postgre și altele asemenea (această problemă va fi dezvăluită în a doua parte a ciclului).
Folosind un sistem de fișiere obișnuit
Puteți configura sistemul de fișiere de rețea pe care toate serverele vor accesa și lucra cu datele sesiunii. Deci nu fi. Aceasta este o abordare absolut ineficientă, în care probabilitatea pierderii datelor este mare, în afară de aceasta, toate funcționează foarte încet.
Dacă totuși doriți să implementați o versiune cu un sistem de fișiere obișnuit, atunci există o soluție mult mai bună - GlusterFS.
Puteți utiliza memcached pentru a stoca datele sesiunii în RAM. Aceasta este o metodă foarte nesigură, dat fiind că datele din sesiune vor fi suprascrise odată ce spațiul liber al discului a expirat.
Nu există persistență: datele de intrare vor fi stocate până când serverul memcached este pornit și nu există spațiu liber pentru stocarea acestor date.
S-ar putea să fiți surprins - nu este specific RAM pentru fiecare mașină? Cum se aplică această metodă clusterului? Memcached are capacitatea de a integra virtual toate RAM-urile disponibile ale mai multor mașini într-un singur depozit:
Cu cât mai multe mașini aveți la dispoziție, cu atât dimensiunea spațiului de stocare partajat va fi mai mare. Nu este nevoie să alocați manual memoria în interiorul depozitului, dar puteți controla acest proces prin indicarea cantității de memorie care poate fi alocată de fiecare mașină pentru a crea un spațiu partajat.
Astfel, cantitatea necesară de memorie rămâne la dispoziția calculatoarelor pentru nevoile lor. Restul este utilizat pentru a stoca datele de sesiune pentru întregul cluster.
În cache, în plus față de sesiuni, puteți obține orice alte date în funcție de dorința dvs., principalul lucru este că există suficient spațiu liber. Memcached este o soluție excelentă care a fost adoptată pe scară largă.
Pentru a utiliza această metodă în aplicațiile PHP este foarte ușor: trebuie să modificați valoarea din fișierul php.ini:
Redis Cluster
Redis nu este un magazin de date SQL aflat în memoria RAM, cum ar fi Memcached. dar are consistență și suportă mai multe tipuri de date complexe decât corzile unei matrice PHP sub formă de perechi "key => value".
Această soluție nu are suport pentru clustere, așadar implementarea acesteia într-un sistem de scalare orizontală nu este la fel de simplă pe cât pare la prima vedere, dar este destul de fezabilă. De fapt, versiunea alfa a versiunii cluster a fost deja lansată și o puteți utiliza.
Dacă comparăți Redis cu soluții precum Memcached. atunci este o cruce între baza de date normală și Memcached.
- Zend din Zend este o alternativă bună, dar necesită instalarea serverului Zend pe fiecare nod din cluster;
- Alte depozite non-SQL și sistemele de caching sunt, de asemenea, destul de funcționale - verificați Scache. Cassandra sau Couchbase. toți lucrează rapid și în mod fiabil.
concluzie
Așa cum ați putea înțelege din cele de mai sus, scalarea orizontală a aplicațiilor PHP nu este un picnic în week-end.
Există multe obstacole, modalitățile de a le elimina sunt destul de non-banale și au avantajele și dezavantajele lor. În plus, până în momentul în care traficul crește la un nivel critic, este posibilă o tranziție lină, de regulă, imposibilă.
Traducerea articolului "Scalarea orizontală a aplicațiilor PHP, partea 1" a fost pregătită de o echipă prietenoasă a proiectului Saitostroenie de la A la Z.
Articole similare
Trimiteți-le prietenilor: