Ce face o aplicație scalabilă?

Continuă să văd în ofertele de locuri de muncă că solicitantul trebuie să aibă experiență în scrierea aplicațiilor „scalabile”. Ce face o aplicație scalabilă și de unde știu că codul meu poate ajunge la milioane de utilizatori?


Cred că un mod mai bun de formulare a acestei întrebări este: Cum îmi pot scrie codul cu scalabilitate in minte? Astfel încât codul să fie scalabil din start, spre deosebire de un gând ulterior. Există anumite metodologii de proiectare? Sau este pur și simplu o chestiune de a alege algoritmii corecți pentru job?

Răspuns

Există două direcții de scalabilitate:

  • vertical (aka scaling up): procesor mai rapid, mai mult RAM, mai mult spațiu pe disc;
  • orizontal (aka scaling out): mai multe nuclee în CPU, mai multe CPU, mai multe servere ;

Pentru prima, trebuie doar să aveți grijă să nu aveți limitări arbitrare. Acestea fie din cauza dimensiunilor întregi prea mici, fie a structurilor de lungime fixă / limitată. Aceste structuri ar putea fi legate de sistemul de operare subiacent. De exemplu, dacă încercați să vă extindeți cu mai multe fire sau procese, la un moment dat veți atinge limitele sistemului de operare. De aceea, în prezent, serverele construite pentru scalabilitate ridicată fac concurență pe baza evenimentelor asincrone. Această problemă este descrisă în celebrul C10K document .

Al doilea este mai dificil. Este nevoie de programare având în vedere două lucruri: datele vor fi procesate în paralel, iar datele ar putea fi să fie distribuită fizic. Comunicarea dintre noduri ar trebui să fie limitată. În practică, acest lucru înseamnă, de obicei, sacrificarea unor părți din ACID (este dovedit că nu puteți avea ACID complet și capacitatea de a extinde în același timp). Cea mai cunoscută soluție pentru date stocarea în acea paradigmă sunt soluții NoSQL . Acestea variază de la depozite de valori-cheie foarte simple, până la sisteme asemănătoare RDBMS, care nu au capacitatea de a face îmbinări. div id = „73fab16cf2”>

magazinele cheie-valoare sunt ultra-scalabile, dar asta vine ca un preț. Puteți interoga practic numai pe cheia principală. Există totuși soluție pentru că, „s reduce hartă . S-ar putea să pară foarte suboptim dacă vă uitați la punctul de vedere al complexității cumulative, dar trebuie să aveți în vedere că funcționează masiv paralel.

Dacă doriți să citiți mai multe despre scalabilitate cu exemple din viața reală , consultați HighScalability.com blog .

Comentarii

  • +1 pentru menționarea extinderii. Adăugarea mai multor resurse este foarte rapidă și atractivă pentru factorii de decizie (cumpărați câteva nuclee hexagonale și dublați memoria! ). Dar dacă aplicația ‘ nu poate pune presiune asupra lor, aveți o problemă mai mare.

Răspundeți

Scalabilitatea se măsoară în termeni de transfer pe baza unei variabile. De exemplu, numărul de solicitări / secundă cu utilizatorii X . Cel mai simplu mod de a descrie scalabilitatea este:

O măsură a eficienței pe măsură ce crește sarcina.

Primul lucru pe care trebuie să îl înțelegeți în proiectarea scalabilității este ce măsurare este cea mai importantă pentru aplicația dvs.? Există mai multe moduri de măsurare a eficienței care este o componentă cheie a scalabilității:

  • Cereri simultane pe secundă
  • Timpul mediu de răspuns pe cerere
  • Numărul de înregistrări procesate pe secundă / minut

Există mai multe măsurători de eficiență care pot fi utilizate, dar acestea sunt comune pentru sistemele bazate pe web sau sistemele de procesare în serie.

Următorul aspect al scalabilității este măsurarea a ceea ce se întâmplă cu eficiența dvs. pe măsură ce sarcina crește. Modalități obișnuite de creștere a încărcării sunt:

  • Mai mulți utilizatori care lovesc serverul (adică mai mult trafic web)
  • Mai multe date în baza de date (adică interogările durează mai mult sau prelucrarea durează mai lung)
  • Eroarea hard diskului într-un RAID (performanța / fiabilitatea stocării este afectată)
  • Saturația rețelei

Obiectivul unei aplicații scalabile este fie să menținem, fie să îmbunătățim eficiența pe măsură ce ne ocupăm de problema încărcării. Pe scurt, dacă timpul de răspuns durează prea mult, putem adăuga un alt server pentru a distribui încărcarea în mod egal? Această abordare reduce cantitatea de muncă pe care o poate face un server și păstrează serverele care funcționează în acel „punct dulce” pentru eficiență.

Aplicația dvs. va trebui să fie concepută special pentru a se scala. trebuie să aveți grijă cu datele de sesiune, solicitările de rutare către serverul potrivit, reducând blocajele care limitează capacitatea de scalare a aplicației.

Răspuns

Practic doriți să evitați blocajele de performanță atunci când creșteți numărul de utilizatori și / sau procesați un set de date mai mare și / sau oferiți interfața dvs. în mai multe limbi etc.

Priviți practic schema bazei de date, algoritmii și procesul de dezvoltare software și încercați să preziceți problemele viitoare. De asemenea, doriți să configurați monitorizarea performanței pentru a identifica problemele atunci când încep să se acumuleze.

Am luat aceste sfaturi când am citit Construirea de site-uri web scalabile (link către Amazon).

Sper că acest lucru vă va ajuta!

Răspundeți

Singurul mod în care aplicațiile poate fi cu adevărat scalabil, este prin faptul că nu aveți restricții care nu pot fi trecute (sau doar foarte scumpe).

Un exemplu tipic este ce se întâmplă atunci când rămâneți fără ciclurile cpu disponibile? Dacă programul dvs. este cu mai multe pași, puteți rula pe o cutie cu mai multe nuclee, dar ce se întâmplă când nu mai puteți cumpăra o cutie mai mare? Aplicația dvs. pur și simplu nu mai poate crește și, prin urmare, nu este scalabilă.

Orice aplicație cu adevărat scalabilă trebuie să fie capabilă să se răspândească pe mai multe computere într-o manieră transparentă și să o facă fără nicio deficiență vizibilă. Acest lucru nu este ușor și este unul dintre motivele pentru care Google a avut atât de mult succes.

Răspuns

Există probleme unice care vin cu suport pentru aplicații mari la scară. Afișarea locului de muncă caută solicitanți care au lucrat în acel mediu și au trebuit să rezolve astfel de probleme.

Dintr-o aplicație de nivel înalt, aplicațiile sunt scalabile punând permanent întrebarea ce s-ar întâmpla dacă această bucată de cod ar fi rulată de mii de ori într-o perioadă foarte mică. Aceasta înseamnă gestionarea amprentelor de memorie , folosind stocarea în cache a totalelor și a datelor, folosind surse de date care sunt ele însele scalabile etc.

Răspuns

Dacă ați fi crearea unei funcții de căutare care a avut rezultate bune atunci când are 100 de rânduri în DB pentru a căuta și 10 utilizatori care o folosesc odată. Cât de bine ar funcționa atunci când 100 de utilizatori l-ar folosi în același timp și există 100K rânduri pentru a căuta în sus.

Dacă funcționează la fel indiferent de ceea ce este, atunci este foarte bun. Dacă funcționează proporțional cu cantitatea de utilizatori / date (adică 10 ori mai multe date == 10 ori mai mult de procesat) este bine. În cazul în care performează mult micșorați cu cât aveți mai multe date (date mod 10x == 10x ^ 10 mai lung de procesat), apoi nu scară bine.

Exemplele mele ar trebui să fie afișate într-adevăr în notația Big O, dar eu cu deocamdată nu o știu suficient de bine pentru a scrie exemplele din Big O.

Puteți simula mai multe date, aruncând date false în DB și există instrumente pentru a simula mai mulți utilizatori, cum ar fi Apache AB.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *