Arhitectură web scalabilă

Ce este scalabilitatea?
Scalabilitatea este proprietatea dorită a unui sistem, rețea sau proces, care indică capacitatea sa de a reacționa și de a se adapta fără a pierde calitatea sau de a gestiona creșterea continuă a locurilor de muncă într-un mod fluid, de a fi pregătit să crească mai mare fără a pierde calitatea în serviciile oferite .
Ați putea spune care este capacitatea sistemului nostru de a susține o sarcină mai mare cu modificări sau extensii care sunt rezonabile în ceea ce privește costul, timpul, timpul și complexitatea.
Tipuri de scalabilitate
În general putem vorbi de scalare verticală și orizontală sau o combinație a ambelor.

Scalare verticală


Practic, constă în creșterea capacității unuia sau mai multor elemente specifice ale arhitecturii noastre, de exemplu extinderea memoriei serverului nostru central sau înlocuirea CPU-urilor cu alte viteze mai mari. Pe scurt, creșteți capacitățile serverului, ceva foarte obișnuit atunci când folosim virtualizarea și spunem că în acel moment serverul va avea 30% din RAM disponibil.

Scalare orizontală


Este cel pe care îl vom detalia în tutorial, se bazează pe creșterea numărului de noduri care efectuează aceeași sarcină, folosind diferite tipuri de planificare, de exemplu, dacă avem un server web saturat, adăugăm altul pentru a echilibra sarcina.
Tipuri de arhitectură web bazate pe niveluri.
Vom vorbi despre arhitecturi care pot fi aplicate cu sisteme Linux, folosind instrumente open-source vom trece de la cele mai de bază la unele destul de avansate oferind scalabilitate orizontală și rezistență la eșec, toate aceste arhitecturi pot fi aplicate în orice PaaS sau cu propria infrastructură.

1. Arhitectura la un nivel


Este cel mai de bază dintre toate, unde există un singur server cu Apache și MySQL care poate fi accesat de la distanță. Este foarte frecvent în paginile cu marjă redusă de vizite sau medii de testare, nu oferă nicio marjă de toleranță la eșec și este dificil de utilizat pentru a crește orizontal.

2. Arhitectura pe două niveluri


De data aceasta am separat baza de date de serverul web oferind un pic de toleranță la erori. În acest fel, dacă baza de date eșuează, serverul web poate oferi conținut într-un mod static care nu depinde de baza de date. Și în cazul în care serverul web nu reușește, putem accesa informațiile creând din nou un nou server web. Designul oferă mai multe defecte, deoarece nu este un design foarte scalabil.

3. Arhitectura pe trei niveluri


De data aceasta începem să folosim un echilibru de încărcare care va primi toate cererile de la utilizatori. De data aceasta oferim un design mai scalabil, astfel încât, dacă încărcarea noastră crește, putem adăuga mai multe servere web și scala. Putem aplica chiar scalarea automată, astfel încât serverele web să fie adăugate automat la un anumit nivel de încărcare sau la o oră de vârf. Problema cu acest design este că putem să ne saturăm baza de date.

4. Arhitectura pe patru niveluri


Acum folosim un echilibru de încărcare și un memcached, făcând sistemul mai scalabil. Cu acest design, putem adăuga cât mai multe baze de date și servere web, pe cât este necesar, pe lângă faptul că oferim toleranță la erori. Putem împărți încărcarea între bazele de date cu CASSANDRA oferind o implementare multi-nod. Acest design este mult mai complex, dar adaug o toleranță de eroare mult mai mare și capacitatea de a scala toate nivelurile sale.

5. Arhitectura pe cinci niveluri


Conținutul unei pagini web poate fi împărțit în static și dinamic. De exemplu, împărțim stratul web într-un server Apache și altul cu aplicații JAVA care rulează Jetty sau JBoss. Apache oferă conținut static în timp ce serverul de aplicații gestionează conținutul dinamic sau din mers. Un exemplu în acest sens poate fi secțiunea FAQ a unui site web de asistență, deoarece este doar conținut static, poate fi tratat de APACHE / NGINX.

MARI

6. Arhitectura cu șase niveluri


Putem fi puțin mai eleganți și putem adăuga o rețea de livrare a conținutului (CDN), sau ceea ce în AWS este cunoscut sub numele de Amazon CloudFront CDNDe exemplu, avem un site web de învățare electronică și utilizatorii noștri descarcă ghidurile în format PDF sau videoclipuri de pe site-ul nostru. Putem economisi toată lățimea de bandă dedicată descărcărilor, oferindu-l de pe un CDN care se ocupă de el, restul web poate rula pe infrastructura noastră.

MARI

ConcluziiAm văzut arhitecturi cu mai multe niveluri care pot fi aplicate, în funcție de traficul web. Este recomandabil să creați arhitecturi care să se gândească la viitor, care pot scala și menține toleranța la erori, evitând colapsurile de pe web din cauza lipsei de resurse sau a eșecului unui nod indispensabil. Prin crearea unora dintre aceste modele, împreună cu alte recomandări, cum ar fi copiile de rezervă și implementările automate, putem oferi un site web cu 99.9 Uptime tolerant la erori.V-a plăcut și ați ajutat acest tutorial?Puteți recompensa autorul apăsând acest buton pentru a-i oferi un punct pozitiv

Vei ajuta la dezvoltarea site-ului, partajarea pagina cu prietenii

wave wave wave wave wave