Nejlepší odpověď
Škálovatelnost znamená, že systém lze relativně snadno přizpůsobit širší uživatelské základně, než se původně plánovalo . Mezi faktory, které určují, jak je aplikace škálovatelná, patří:
- dobrá struktura programu (jak snadné je programu porozumět a rozšířit se o podporu nových rolí)
- ustanovení pro více uživatelů a souběžný přístup a úpravy databáze (aby se zabránilo zablokování databáze, zamítnutí přístupu, poškození nebo ztrátě dat)
- bezpečnostní opatření pro přístup uživatelů i integritu databáze
- schopnost fungovat jako distribuovaná aplikace na více serverech a databázích napříč více časovými pásmy
- zálohování, oprava a obnova databáze
- jazykové a kulturní předpisy
- ustanovení pro komunikaci s třetí stranou aplikace buď vystavením dobře spravovaného programového rozhraní nebo přihlášením k průmyslovým standardům
- využití zdrojů a závislosti hardwaru / operačního systému
- výkon v reálném čase
Existují i další faktory, závislé na konkrétních obchodních doménách, ale jsou to faktory, o kterých vidíme, že se běžně stávají i usilovat o to, když se společnost pokusí „škálovat“ nebo „rozšiřovat“ své aplikace.
Škálovatelnost obvykle trpí, když: /
- program je koncipován a napsán někým, kdo není odborník v oboru vývoje aplikací
- odpovědnost za psaní programu je smluvně uzavřena se specifikací, která nezkoumá všechny faktory odpovídající budoucím potřebám zákazníků (slabá specifikace často vede k neškálovatelným řešením )
- Neexistuje dohled nad zkušeným softwarovým inženýrem, který rozumí obchodní doméně.
Jednoduchým příkladem měřítka selhání je program inventáře skladu, na kterém jsem pracoval zpět v roce 1990 (ish).
Původní program byl napsán pro jednoho uživatele, jeden server a noční zálohy (během této doby byl systém nedostupný). V postupném pořadí chtěl zákazník:
- zvýšit počet uživatelů z 1 na 50+ a zavést různé role a přístupová oprávnění pro každého uživatele.
- rozšířit aplikaci o podporu více skladů ve stejné zemi
- rozšířit aplikaci tak, aby zohledňovala nové offshore sklady, z nichž vyplývá podpora více časových pásem, jazyků, právních norem a provozních postupů
Původní program nebyl nikdy strukturován pro tak silný požadavek na změnu měřítka. Databáze trpěla častým blokováním „smrtícího objetí“, ztrátou dat a nepřijatelným výpadkem kvůli postupům zálohování databáze. Aplikace neměla žádné ustanovení pro „offline“ zadávání dat a samozřejmě nebyla napsána tak, aby byla odolná vůči problémům s komunikací. Pokus o aktualizaci programu se také ukázal jako noční můra – v podstatě se celý jejich systém zastavil na několik hodin, které trvalo instalaci globální aktualizace.
Než jsme byli povoláni jako konzultanti, program byl „opraven“ původním kodérem (jednotným číslem), který následně skončil a nepohodlně zmizel.
Oprava zamlžila strukturu a funkčnost kódu – pochybuji však, že program byl někdy správně strukturován nebo zdokumentován – nikdo nevěděl dost na to, aby si uvědomil riziko, které to pro společnost představuje! Tento kód byl napsán v C ++ a používal bajtová pole namísto standardních řetězců vícebajtové znakové sady (MBCS) … získáte obecnou představu!
Byli jsme povoláni, abychom „opravili“ problémy. Pravdou je, že by bylo jednodušší a levnější přepnout zákazníka na produkt správy komerčního inventáře, ale měli do systému hluboce zakomponované finanční modelování a nikdo zcela nerozuměl dost o tom, jak to fungovalo při přenosu těchto funkcí na komerční programu (přinejmenším bez významného rizika).
Nakonec jsme i přes poučení na nákladově efektivnější řešení museli produkt zpětně analyzovat a aplikaci zcela přepsat. Přepsání produktu trvalo 2 systémovým návrhářům, 4 vedoucím technikům, 20 softwarovým technikům, 5 validátorům a 2 technikům / metodikům metodiky – a téměř 2 roky uplynulého času, než se aplikace dostala do obecného vydání.
Takže jak docílíte škálovatelnosti?
- Začněte tím, že jste do specifikace produktu zapsali své požadavky na škálovatelnost. Obecně časová tíseň a nejnižší náklady způsobí oběti v oblastech, které nebyly ve specifikaci správně nařízeny.
- Spolupracujte s odborníky na doménu, kteří vám mohou pomoci vytvořit strukturu, která bude splňovat (pravděpodobné) budoucí potřeby.
- Využijte návrhové vzory, knihovny, aplikace 4GL / AI a architektury, které byly formulovány od základu, aby se předešlo problémům se škálovatelností (mnohé z nich byly vyvinuty z hořkých zkušeností).
- Přečtěte si všechny klíčové oblasti, jako jsou distribuované databáze odolné proti chybám pro vysoce souběžné aplikace, integrované bezpečnostní architektury, replikace databází, cloudové zpracování atd.
- Ujistěte se, že zaměstnáváte ostřílení, zkušení inženýři na klíčových pozicích. Řekl bych, že téměř 50\% záchranných projektů, které jsme podnikli, bylo důsledkem nezkušených vedoucích inženýrů a návrhářů systémů. Zbytek byl způsoben selháním správy nebo nesprávnou komunikací mezi technikem a zákazníkem.
Takže to máte. V dnešní době opravdu neexistuje omluva pro problémy se škálovatelností ve společnostech střední a velké velikosti, nicméně mnoho společností začíná jen s hrstkou lidí, kteří hackují řešení, jak nejlépe umí. Pak společnost roste a škálovatelnost se stává spíše noční můrou než řádným postupem, jaký by měl být!
Odpověď
Škálovatelnost v softwarovém inženýrství se obvykle týká navrhování softwarových systémů takovým způsobem, že s rostoucím počtem uživatelů systému (dokonce i 100krát a více) bude software i nadále fungovat se srovnatelnými dobami odezvy. Další otázkou nyní je, „jak je to možné dosáhnout?“
Samostatný stolní software (např. Hry) je vždy stoprocentně škálovatelný, protože každý uživatel získá celý svůj vlastní počítač. Toto je triviální forma škálovatelnosti.
Klientské servery a webové softwarové systémy však závisí na serverech , což jsou počítače které poskytují služby více uživatelům. Mělo by být zřejmé, že jakýkoli daný server dokáže zpracovat pouze určitý omezený počet současných uživatelů.
Existují dvě obecné techniky, které systému umožňují překračovat rámec toho, co zvládne jediný server. Vysoce škálovatelné systémy budou kombinovat obě techniky.
Prvním je rozdělení funkcí na různé části. Jedním společným rozdělením je mít samostatný server pro hostování databáze, na kterou se systém spoléhá (téměř vždy existuje nějaká databáze, která uchovává trvalé informace). Databázovému serveru je přiděleno velké množství paměti a velmi rychlé disky nebo pole RAID, zatímco druhý typ serveru potřebuje méně paměti a relativně málo místa na disku.
To lze rozšířit na architekturu n-tier, kde je stále více funkcí (a dat pro databáze) rozděleno mezi různé procesy. Když se zatížení zvýší, procesy se migrují na samostatné servery, aby se zachoval výkon. Všimněte si, že všechny tyto servery jsou fyzicky ve stejné serverové farmě a jsou propojeny velmi vysokorychlostními síťovými připojeními.
Další technikou používanou pro škálovatelnost je replikace . To znamená, že se například používá více webových serverů a každý uživatel je připojen pouze k jednomu z nich. K podpoře více uživatelů potřebuje systém jen více hardwaru (v tomto příkladu systémy webových serverů). Databáze jsou také schopné replikace, takže více databázových serverů může podporovat klony databáze (někdy je obtížné udržovat různé kopie databáze aktuální, ale databáze se s tímto problémem zabývají roky). U větších systémů existují databáze, které jsou navrženy tak, aby byly škálovatelné a distribuovaly svá data na více serverů.
A2A: „Co se rozumí„ škálovatelností “v softwarovém inženýrství?“