Ce se înțelege prin sistem scalabil? Ce tehnici pot fi folosite pentru a atinge scalabilitatea?

Cel mai bun răspuns

Scalabil înseamnă că sistemul poate, cu relativă ușurință, să fie adaptat la o bază de utilizatori mai largă decât inițial sau inițial intenționat . Factorii care determină cât de scalabilă este o aplicație, ar include:

• o structură bună a programului (cât de ușor este programul de înțeles și extins pentru a susține noi roluri)
• prevedere pentru mai mulți utilizatori și acces și editare simultană la baze de date (pentru a evita blocarea bazei de date, refuzarea accesului, corupția sau pierderea datelor)
• prevederi de securitate atât pentru accesul utilizatorului, cât și pentru integritatea bazei de date
• capacitatea de a rula ca o aplicație distribuită pe mai multe servere și baze de date pe mai multe fusuri orare
• copiere de rezervă, corectare și restaurare a bazei de date
• prevederi lingvistice și culturale
• furnizare pentru inter-comunicare cu terți aplicații fie prin expunerea unei interfețe de program bine gestionate, fie prin abonarea la standardele din industrie
• utilizarea resurselor și dependențe de hardware / sistem de operare
• performanță în timp real

Există alți factori, dependenți de anumite domenii de afaceri, dar aceștia sunt factorii pe care îi vedem de obicei devenind un i urmează atunci când o companie încearcă să „scaleze” sau „să extindă” aplicațiile lor.

Scalabilitatea suferă de obicei atunci când / sau:

• programul este conceput și scris de cineva calificat în disciplinele dezvoltării aplicațiilor
• responsabilitatea pentru scrierea unui program este contractată cu o specificație care nu explorează toți factorii corespunzători nevoilor viitoare ale clienților (o specificație slabă duce adesea la soluții non-scalabile) )
• nu există nicio supraveghere de către un inginer software calificat care înțelege domeniul afacerii

Un exemplu simplu de eșec la scară este un program de inventar de depozit la care am lucrat înapoi în 1990 (ish).

Programul original a fost scris pentru un utilizator, un server și copii de siguranță nocturne (timp în care sistemul nu a fost disponibil). În ordine succesivă, clientul a dorit să:

• crește numărul de utilizatori de la 1 la 50+ și să adopte diverse roluri și privilegii de acces pentru fiecare utilizator.
• extindeți aplicația pentru a susține mai multe depozite din aceeași țară
• extindeți aplicația pentru a ține cont de depozite noi, offshore, care implicau suport pentru mai multe fusuri orare, limbi, standarde legale și proceduri de operare

Programul original nu a fost niciodată structurat pentru o cerință de scalare atât de puternică. Baza de date a suferit de blocări frecvente de „îmbrățișare mortală”, pierderi de date și perioade de nefuncționare inacceptabile din cauza procedurilor de rezervă a bazei de date. Aplicația nu a prevăzut introducerea de date „offline” și, bineînțeles, nu a fost scrisă pentru a fi tolerantă la erori la problemele de comunicare. Încercarea de a actualiza programul s-a dovedit, de asemenea, a fi un coșmar – practic întregul lor sistem s-a oprit pentru câteva ore necesare instalării unei actualizări globale.

Înainte de a fi solicitați, în calitate de consultanți, programul a fost „corecționat” de codificatorul original (singular) care a renunțat ulterior și a dispărut inconvenient.

Corecția a ofuscat structura și funcționalitatea codului – totuși mă îndoiesc că programul a fost vreodată structurat sau documentat corect – nimeni nu știa suficient pentru a-și da seama de riscul pe care îl reprezenta aceasta pentru companie! Codul a fost scris în C ++ și a folosit matrici de octeți în loc de șiruri de seturi de caractere multi-octet (MBCS) standard din industrie … veți obține ideea generală!

Am fost chemați să „reparăm” Probleme. Adevărul este că ar fi fost mai simplu și mai ieftin să treceți clientul la un produs comercial de gestionare a inventarului, totuși aceștia aveau modele financiare adânc încorporate în sistem și nimeni nu înțelegea suficient despre modul în care a funcționat pentru a transfera aceste caracteristici într-o reclamă comercială. program (cel puțin fără riscuri semnificative).

La final, în ciuda faptului că am subliniat soluții mai eficiente din punct de vedere al costurilor, a trebuit să proiectăm produsul invers și să rescriem complet aplicația. Au fost necesari 2 designeri de sisteme, 4 ingineri principali, 20 de ingineri software, 5 validatori și 2 ingineri de instrumente / metodologie pentru a rescrie produsul – și aproape 2 ani de timp scurs pentru ca aplicația să fie lansată în general.

cum realizați scalabilitatea?

1. Începeți prin a vă asigura că ați scris cerințele de scalabilitate în specificațiile produsului. În general, presiunea timpului și cel mai mic cost vor cauza sacrificii în domenii care nu au fost mandatate corespunzător în caietul de sarcini.
2. Colaborați cu experți din domeniu care vă pot ajuta să dezvoltați o structură care să răspundă nevoilor viitoare (probabile).
3. Profitați de modele de proiectare, biblioteci, aplicații 4GL / AI și arhitecturi care au fost formulate de la bază pentru a evita problemele de scalabilitate (dintre care multe au fost dezvoltate din experiențe amare).
4. Citiți toate domeniile cheie, cum ar fi baze de date distribuite, tolerante la erori, pentru aplicații extrem de concurente, arhitecturi de securitate încorporate, replicarea bazei de date, procesare în cloud etc.
5. Asigurați-vă că utilizați ingineri experimentați, cu experiență, în poziții cheie. Aș spune că aproape 50\% din proiectele de salvare pe care le-am întreprins au fost consecința inginerilor neexperimentați și a proiectanților de sistem. Restul s-au datorat eșecurilor de gestionare sau comunicărilor necorespunzătoare între inginerie și client.

Deci, acolo aveți. În zilele noastre, nu există nicio scuză pentru probleme de scalabilitate în companiile de dimensiuni medii până la mari, cu toate acestea, multe companii încep doar cu o mână de oameni care piratează soluții cât de bine pot. Apoi, compania crește și scalabilitatea devine un coșmar mai degrabă decât progresia ordonată pe care ar trebui să o aibă! , pe măsură ce numărul utilizatorilor sistemului crește (chiar și cu factori de 100x sau mai mulți), software-ul va continua să funcționeze cu timpi de răspuns comparabili. Acum, următoarea întrebare este „cum se realizează acest lucru?”

Software-ul desktop independent (de exemplu, jocuri) este întotdeauna 100\% scalabil, deoarece fiecare utilizator primește un computer întreg. Aceasta este o formă banală de scalabilitate.

Client-server și sistemele software bazate pe web, totuși, depind de servere , care sunt computere care furnizează servicii mai multor utilizatori. Ar trebui să fie evident că orice server dat poate gestiona doar un număr limitat de utilizatori simultani.

Există două tehnici generale care permit unui sistem să se extindă dincolo de ceea ce poate gestiona un singur server. Sistemele foarte scalabile vor combina ambele tehnici.

Primul este împărțirea funcționalității în diferite părți. O împărțire obișnuită este de a avea un server separat pentru a găzdui baza de date pe care se bazează sistemul (există aproape întotdeauna un fel de bază de date pentru a deține informații persistente). Serverului bazei de date i se oferă o cantitate mare de memorie și discuri foarte rapide sau matrice RAID, în timp ce celălalt tip de server are nevoie de mai puțină memorie și spațiu relativ redus pe disc.

Acest lucru poate fi extins la o arhitectură de nivel n, unde tot mai multe funcționalități (și date, pentru baze de date) sunt împărțite între diferite procese. Când încărcarea crește, procesele sunt migrate pe servere separate pentru a menține performanța. Rețineți că toate aceste servere sunt fizic în aceeași fermă de servere și sunt conectate prin conexiuni de rețea de mare viteză.

Cealaltă tehnică utilizată pentru scalabilitate este replicare . Aceasta înseamnă că, de exemplu, sunt utilizate mai multe servere web și fiecare utilizator este conectat la unul singur. Pentru a sprijini mai mulți utilizatori, sistemul are nevoie doar de mai mult hardware (sisteme de server web în acest exemplu). Bazele de date sunt, de asemenea, capabile de replicare, astfel încât mai multe servere de baze de date pot suporta clone ale bazei de date (uneori este dificil să mențineți actualizate diferitele copii ale bazei de date, dar dba’s gestionează această problemă de ani de zile). Pentru sistemele mai mari, există baze de date concepute pentru a fi scalabile, distribuindu-și datele pe mai multe servere.

A2A: „Ce se înțelege prin„ scalabilitate ”în ingineria software?”