Legjobb válasz
A méretezhetőség azt jelenti, hogy a rendszer viszonylag könnyedén alkalmazható a kezdeti vagy eredetileg tervezett szélesebb felhasználói bázisra . Azok a tényezők, amelyek meghatározzák az alkalmazás méretezhetőségét, a következőket tartalmazzák:
- jó programstruktúra (mennyire könnyű megérteni és kibővíteni a programot új szerepkörök támogatására)
- több felhasználó és egyidejű hozzáférés és szerkesztés az adatbázisokhoz (az adatbázis zárolásának, a hozzáférés megtagadásának, a korrupció vagy az adatvesztés elkerülése érdekében)
- biztonsági rendelkezések mind a felhasználói hozzáférés, mind az adatbázis integritása érdekében
- az a képesség, hogy egy elosztott alkalmazás több szerveren és adatbázisban, több időzónában
- adatbázis biztonsági mentése, javítása és helyreállítása
- nyelvi és kulturális rendelkezések
- harmadik féllel való kommunikációra vonatkozó rendelkezés alkalmazásokat vagy jól kezelt programfelület bemutatásával, vagy az ipari szabványoknak való megfeleléssel
- erőforrás-felhasználás és hardver / operációs rendszer függőségek
- valós idejű teljesítmény
Vannak más tényezők, amelyek függenek az adott üzleti területtől, de ezek azok a tényezők, amelyeket rutinszerűen i-vé válunk akkor folytassa, amikor egy vállalat megpróbálja “méretezni” vagy “kibővíteni” alkalmazásait.
A méretezhetőség általában akkor szenved, ha vagy: vagy:
- a programot valaki más nem készítette és írta az alkalmazásfejlesztés szakterületein jártas
- a programírás felelősségét olyan specifikációval kötik le, amely nem tárja fel az ügyfelek jövőbeli igényeinek megfelelő összes tényezőt (a gyenge specifikáció gyakran nem skálázható megoldásokhoz vezet )
- nincs felügyelet az üzleti területet értő képzett szoftvermérnök részéről.
A méretarányos kudarc egyszerű példája egy raktári készletprogram, amelyen dolgoztam 1990-ben (ish).
Az eredeti programot egy felhasználó, egy szerver és éjszakai biztonsági másolatok írták (ezalatt a rendszer nem volt elérhető). Az ügyfél egymást követő sorrendben a következőket kívánta elérni:
- a felhasználók számának növelése 1-ről 50+ -ra, valamint az egyes felhasználók számára különféle szerepek és hozzáférési jogosultságok bevezetése.
- bővítse az alkalmazást több raktár támogatására ugyanazon az országon belül
- az alkalmazás kibővítése az új, offshore raktárak figyelembevételével, amelyek több időzóna, nyelv, jogi szabványok és működési eljárások támogatását jelentették
Az eredeti program még soha nem volt felépítve ilyen szigorú méretezési követelményekre. Az adatbázis gyakori „halálos átfogó” zárolások, adatvesztés és az adatbázis-mentési eljárások miatt elfogadhatatlan leállás miatt szenvedett. Az alkalmazás nem rendelkezett „offline” adatbevitelre, és természetesen nem írták úgy, hogy hibatűrő legyen a kommunikációs problémákkal szemben. A program frissítésének próbálkozása is rémálomnak bizonyult – alapvetően az egész rendszerük leállt a globális frissítés telepítéséhez szükséges néhány óráig.
Mielőtt tanácsadónak hívtak minket, a program „javította” az eredeti kódoló (egyes szám), aki később kilépett és kényelmetlenül eltűnt. senki sem tudta eléggé, hogy felismerje a vállalat számára jelentett kockázatot! A kódot C ++ nyelven írták, és bájtos tömböket használtak az iparági szabványos, többbájtos karakterkészlet (MBCS) karakterláncok helyett … megkapja az általános elképzelést!
Felhívtak minket a problémák. Az igazság az, hogy egyszerűbb és olcsóbb lett volna az ügyfelet kereskedelmi készletgazdálkodási termékre váltani, azonban mélyen beágyazta a pénzügyi modellezést, és senki sem értette eléggé, hogyan működött ezeknek a funkcióknak a kereskedelmi célokra történő átadása program (legalábbis jelentős kockázat nélkül).
Végül annak ellenére, hogy költséghatékonyabb megoldásokat emeltünk ki, át kellett terveznünk a terméket, és teljesen át kellett írnunk az alkalmazást. 2 rendszertervezőre, 4 vezető mérnökre, 20 szoftvermérnökre, 5 validálásra és 2 eszköz / módszertani mérnökre volt szükség a termék átírásához – és majdnem 2 év telt el az alkalmazás általános kiadásáig.
Tehát hogyan érheti el a méretezhetőséget?
- Kezdje azzal, hogy meggyőződött arról, hogy beírta-e a méretezhetőségi követelményeket a termék specifikációjába. Általában az időigény és a legalacsonyabb költség áldozatokat okoz azokon a területeken, amelyeket nem írtak elő megfelelően a specifikációban.
- Dolgozzon olyan szakterületi szakértőkkel, akik segíthetnek olyan struktúra kialakításában, amely kielégíti a (valószínű) jövőbeni igényeket.
- Használja ki azokat a tervezési mintákat, könyvtárakat, 4GL / AI alkalmazásokat és architektúrákat, amelyeket az alapoktól fogva fogalmaztak meg, hogy elkerüljék a méretezhetőség kérdéseit (amelyek közül sokakat keserű tapasztalatokból fejlesztettek ki).
- Olvassa el az összes kulcsfontosságú területet, például elosztott, hibatűrő adatbázisokat a nagyon egyidejű alkalmazásokhoz, beágyazott biztonsági architektúrákat, adatbázis-replikációt, felhőfeldolgozást stb.
- Győződjön meg róla, hogy alkalmaz tapasztalt, tapasztalt mérnökök kulcspozíciókban. Azt mondanám, hogy az általunk vállalt mentési projektek majdnem 50\% -a tapasztalatlan vezető mérnökök és rendszertervezők következménye volt. A többi a menedzsment kudarcaiból vagy a mérnökök és az ügyfelek közötti helytelen kommunikációból származott.
Tehát itt van. Manapság valóban nincs mentség a közepesen nagy méretű vállalatok méretezhetőségi problémáira, azonban sok vállalat csak néhány emberrel indul, akik a lehető legjobban feltörik a megoldásokat. Aztán a vállalat növekszik, és a méretezhetőség rémálommá válik, nem pedig annak a rendezett előrelépésnek, amelynek lennie kellene!
Válasz
A szoftvertervezés skálázhatósága általában a szoftverrendszerek tervezésére utal, hogy , amint a rendszer felhasználói száma növekszik (akár 100-szoros vagy annál nagyobb tényezőkkel is), a szoftver továbbra is hasonló válaszidőkkel fog működni. Most a következő kérdés az, hogy “hogyan érhető el ez?”
Az önálló asztali szoftver (pl. Játékok) mindig 100\% -ban méretezhető, mert minden felhasználó egy teljes számítógépet kap. Ez a méretezhetőség triviális formája.
Az ügyfél-kiszolgáló és a web-alapú szoftver rendszerek azonban a kiszolgálóktól függenek, amelyek számítógépek amelyek több felhasználónak nyújtanak szolgáltatásokat. Nyilvánvalónak kell lennie, hogy bármelyik szerver csak korlátozott számú egyidejű felhasználót képes kezelni.
Két olyan általános technika létezik, amelyek lehetővé teszik a rendszer méretezését túl azon, amit egyetlen szerver képes kezelni. A jól skálázható rendszerek mindkét technikát egyesítik.
Az első a funkcionalitás különböző részekre bontása. Az egyik általános felosztás az, hogy külön kiszolgálóval kell ellátni azt az adatbázist, amelyre a rendszer támaszkodik (szinte mindig van valamilyen adatbázis a tartós információk tárolására). Az adatbázis-kiszolgáló nagy memóriát és nagyon gyors lemezeket vagy RAID tömböket kap, míg a másik típusú kiszolgálóknak kevesebb memóriára és viszonylag kevés lemezterületre van szükségük.
Ez kiterjeszthető egy n-szintű architektúrára, ahol egyre több funkcionalitás (és adat, adatbázisokhoz) oszlik meg a különböző folyamatok között. A terhelés növekedésével a folyamatok külön szerverekre kerülnek a teljesítmény fenntartása érdekében. Ne feledje, hogy ezek a kiszolgálók fizikailag ugyanabban a szerverfarmban vannak, és nagyon nagy sebességű hálózati kapcsolatokkal vannak összekapcsolva.
A méretezhetőség másik technikája a replikáció . Ez azt jelenti, hogy például több webszervert használnak, és mindegyik felhasználó csak az egyikhez csatlakozik. Több felhasználó támogatásához a rendszernek csak több hardverre van szüksége (ebben a példában webkiszolgáló rendszerek). Az adatbázisok képesek replikálódásra is, így több adatbázis-kiszolgáló is képes támogatni az adatbázis klónjait (néha bonyolult az adatbázis különböző példányait naprakészen tartani, de a dba évek óta kezeli ezt a problémát). Nagyobb rendszerek esetében vannak olyan skálázható adatbázisok, amelyek adataikat több szerveren osztják szét.
A2A: “Mit jelent a” skálázhatóság “a szoftverfejlesztésben?”