Apoi implementați aplicația, introduceți-o în funcțiune și funcționează bine pentru primele câteva săptămâni, dar cu creșterea numărului de utilizatori crește și numărul de cereri care urmează să fie procesate la server, și dintr-o dată, serverul începe să se înece. La început, acest lucru se poate manifesta într-o creștere a timpului de procesare de interogare, apoi fluxul de lucru începe să se folosească mai multă memorie și de prelucrare a resurselor, și în cele din urmă serverul web pur și simplu încetează să mai fie în măsură să proceseze toate cererile și fișierele jurnal sunt din ce în ce mai multe sanse de a primi un 500 mesaj HTTP ( «Eroare internă server» ).
Ce sa întâmplat? Pot să încep din nou să optimizăm aplicația? Cu toate acestea, cu o creștere a numărului de utilizatori, situația se va repeta. Pot crește cantitatea de memorie sau pot adăuga procesoare? Cu toate acestea, o astfel de extindere a capacităților unui singur computer are limitele sale. Este timpul să recunoaștem faptul că aveți nevoie de servere suplimentare.
Scalingul de aplicații web este un proces natural care începe la un moment dat în viața aplicațiilor web. Un server poate servi simultan zeci, sute sau chiar mii de utilizatori, dar nu este capabil să suporte încărcările de vârf pentru o perioadă lungă de timp. Memoria începe să fie umplută cu informații despre sesiune, cererile noi sunt întrerupte din cauza lipsei firelor de execuție gratuite și comutarea contextului începe prea des, ceea ce duce la o latență crescută și la o lățime de bandă mai mică a serverului.
Scalarea orizontală
Din punct de vedere arhitectural, la scară, nu este greu: este suficient pentru a cumpăra una sau două calculatoare (sau zece), așezați serverele pe computer care realizează echilibrarea încărcării și toate! Dar problema este că, de obicei, totul nu este atât de simplu.
Una dintre principalele probleme ale scalării orizontale cu care se confruntă dezvoltatorii este modul de implementare a legării la server. De exemplu, atunci când rulează un singur server web, informațiile despre starea sesiunilor de utilizatori sunt stocate în memorie. Dacă adăugați un alt server, cum puteți oferi acces la obiectele de sesiune pentru acesta? Cum pot sincroniza sesiunile între servere?
Unii dezvoltatori web rezolvă această problemă prin stocarea informațiilor pe server și asocierea clientului cu un anumit server. Imediat ce clientul se conectează la unul din serverele din spatele balancerului de încărcare, din acel moment toate solicitările clientului vor fi trimise către același server web. Această tehnică este, de asemenea, numită o sesiune obligatorie. Legarea sesiunii este o soluție, dar nu rezolvă problema, deoarece nu permite distribuirea uniformă a sarcinii între servere. Folosind această tehnică, este ușor să intri într-o situație în care un server va servi o mulțime de utilizatori, în timp ce alții vor fi inactivi în acest moment, deoarece clienții lor și-au terminat deja lucrarea și s-au deconectat.
Prin urmare, soluția reală nu este de a folosi memoria computerului pentru a stoca date, cum ar fi informații despre sesiuni de utilizatori sau cache-uri. Dar cum poate stoca cache-ul în memoria unui anumit computer să împiedice scalarea?
Imaginați-vă ce se va întâmpla atunci când un utilizator trimite o solicitare care face cache de actualizare: serverul primește cererea, actualizează memoria cache, dar alte servere nu vor ști că aceasta trebuie să fie făcut, și dacă cache-urile lor stocate copie a aceluiași obiect, acesta va la inconsecvența datelor din întreaga aplicație. O modalitate de a rezolva această problemă - pentru a organiza obiectele în sincronizare cache între servere. Acest lucru este foarte posibil, dar va complica arhitectura generală aplicație web, să nu mai vorbim de modul de a crește cantitatea de trafic între servere.
Scalarea mecanismelor în ASP.NET
Scalarea orizontală necesită stocarea informațiilor de stare în afara proceselor. În ASP.NET există două mecanisme care oferă acest mod de stocare a datelor:
Serviciul de stat
Un serviciu de administrare de stat este un serviciu Windows care acceptă gestionarea de stat pentru mai multe computere. Acest serviciu este instalat automat când instalați .NET Framework, dar este dezactivat în mod implicit. Trebuie doar să alegeți serverul care va rula serviciul de gestionare a statului și să îl configurați pe ceilalți să îl folosească. Deși serviciul de management de stat permite serverelor multiple să utilizeze un magazin comun de informații, acesta nu suportă stocarea pe termen lung. Aceasta înseamnă că, dacă se întâmplă ceva cu serverul în care funcționează acest serviciu, toate informațiile despre sesiunile din ferma web vor fi pierdute.
ASP.NET sprijină capacitatea de a stoca informații despre starea într-o bază de date SQL Server. Acest mecanism sprijină nu numai aceleași caracteristici ca și serviciul de gestionare de stat, dar, de asemenea, oferă spațiu de stocare pe termen lung a datelor, astfel încât, chiar dacă un server de web și serverul cu baza de date SQL Server se întâmplă de urgență, informații cu privire la starea de a continua.
În scopul memorării în cache, în majoritatea cazurilor, puteți utiliza cu succes unul dintre mecanismele de cache distribuite, cum ar fi Microsoft AppFabric Cache. NCache sau Memacached. ultima dintre acestea fiind o implementare deschisă a cache-ului distribuit.
Mecanismul de caching distribuit permite memorie pentru a combina mai multe servere într-un cache distribuit. memorii cache distribuite suporta locații abstractizare, astfel încât să nu trebuie să știe unde fiecare bucată de date, serviciul de notificare pentru a ajuta la a fi la curent - în cazul în care și ce sa schimbat, și de înaltă disponibilitate asigură faptul că, chiar și în cazul datelor privind accidentul nu se vor pierde pe unul dintre serverele.
Unele cache distribuite, cum ar fi AppFabric Cache și Memcached, au, de asemenea, propriile implementări ale serviciului de management de stat și furnizorii de cache pentru ASP.NET.
Horizontale capcane de scalare
Deși acest lucru nu este direct legat de performanță, merită să identificăm unele dintre problemele pe care le puteți întâlni când scalarea aplicațiilor web.
Unele părți ale aplicațiilor Web necesită utilizarea unor chei de securitate speciale pentru a genera identificatori unici pentru a preveni posibilitatea aplicării Web înșelătoare și a intruziunii în ea. De exemplu, o cheie unică este folosită în procedura de autentificare pentru FormsAuthentication și atunci când datele sunt criptate de mecanismul de persistență al stării de vizualizare. În mod implicit, cheile de securitate pentru aplicațiile Web sunt generate de fiecare dată când este pornită grupul de aplicații.
În cazul unui singur server, nu cauzează probleme, dar atunci când aplicația Web rulează pe mai multe servere, acest lucru poate deveni o problemă, din moment ce fiecare server va avea cheia unică proprie. Imaginați-vă această situație: clientul trimite o cerere către serverul A și primește un modul cookie ca răspuns, semnat de o cheie unică a serverului A, atunci clientul trimite o nouă cerere la cookie-ul primit, care ajunge la serverul B. Deoarece serverul B are o cheie unică, conținutul cookie-ul este considerat invalid, iar clientul apare un mesaj de eroare.
Puteți controla generarea acestor chei în ASP.NET prin configurarea setărilor din secțiunea machineKey din fișierul web.config. Când aplicația web rulează pe mai multe servere, trebuie să configurați toate serverele astfel încât acestea să utilizeze aceeași cheie pre-generată.
O altă problemă cu scalarea orizontală și cheile unice este capacitatea de criptare a partițiilor în fișierele web.config. Informațiile închise în fișierele web.config sunt adesea criptate atunci când aplicația este implementată pe servere. De exemplu, secțiunea connectionString poate fi criptată pentru a împiedica scurgerea de nume și parolă de utilizator în baza de date. În loc să criptați fișierul web.config pe fiecare server separat, complicând procesul de implementare, puteți genera un fișier web.config criptat și îl puteți implementa pe toate serverele. Pentru aceasta, creați un container de chei RSA și importați-l pe toate serverele web.
Pentru mai multe informații despre crearea cheilor unice și despre includerea acestora în setările aplicațiilor, consultați Baza de cunoștințe Microsoft. Pentru mai multe informații despre crearea unui container cheie RSA, consultați "Importul și exportul containerelor cheie RSA securizate pentru configurare" pe site-ul MSDN.
Articole similare
Trimiteți-le prietenilor: