Bästa svaret
Skalbart betyder att systemet relativt enkelt kan anpassas till en bredare användarbas än ursprungligen eller ursprungligen avsedd . De faktorer som avgör hur skalbar en applikation är, skulle inkludera:
- bra programstruktur (hur lätt är programmet att förstå och utöka för att stödja nya roller)
- avsättning för flera användare och samtidig databasåtkomst och redigering (för att undvika databaslåsning, åtkomstavslag, korruption eller dataförlust)
- säkerhetsbestämmelser för både användaråtkomst och databasintegritet
- förmåga att köras som distribuerad applikation på flera servrar och databaser över flera tidszoner
- säkerhetskopiering av databaser, korrigering och återställning
- språk- och kulturbestämmelser
- tillhandahållande för interkommunikation med tredje part applikationer antingen genom att exponera ett välskött programgränssnitt eller prenumerera på branschstandarder
- resursanvändning och maskinvaru- / operativsystemberoende
- realtidsprestanda
Det finns andra faktorer, beroende på specifika affärsområden, men det är de faktorer som vi rutinmässigt blir ett i se när ett företag försöker ”skala” eller ”utvidga” sina applikationer.
Skalbarhet lider vanligtvis när antingen / eller:
- programmet är tänkt och skrivet av någon som inte är skicklig inom disciplinerna för applikationsutveckling
- ansvaret för att skriva ett program är utdraget med en specifikation som inte undersöker alla faktorer som är lämpliga för kundens framtida behov (en svag specifikation leder ofta till icke-skalbara lösningar )
- det finns ingen övervakning av skicklig programvarutekniker som förstår affärsdomänen
Ett enkelt exempel på att inte kunna skalas är ett lagerinventeringsprogram som jag arbetat med tillbaka 1990 (ish).
Det ursprungliga programmet skrevs för en användare, en server och säkerhetskopior varje natt (under vilken tid systemet inte var tillgängligt). I på varandra följande ordning ville kunden:
- öka antalet användare från 1 till 50+ och att anta olika roller och åtkomstbehörigheter för varje användare.
- expandera applikationen för att stödja flera lager inom samma land
- expandera applikationen för att ta hänsyn till nya offshore-lager som innebar stöd för flera tidszoner, språk, juridiska standarder och driftsförfaranden
Det ursprungliga programmet hade aldrig strukturerats för ett så starkt skalningskrav. Databasen led av frekventa ”dödliga omfamning” -låsningar, förlust av data och oacceptabel driftstopp på grund av databasbackupförfaranden. Applikationen hade ingen bestämmelse för ”offline” datainmatning och var naturligtvis inte skriven för att vara fel-tolerant för kommunikationsproblem. Att försöka uppdatera programmet visade sig också vara en mardröm – i grund och botten stannade hela systemet under de flera timmar det tog att installera en global uppdatering.
Innan vi kallades in, som konsulter, programmet ”lappades” av den ursprungliga kodaren (singular) som därefter hade slutat och obekvämt försvunnit.
Korrigeringen fördunklade kodens struktur och funktionalitet – men jag tvivlar på att programmet någonsin hade varit ordentligt strukturerat eller dokumenterat – ingen hade känt tillräckligt för att inse den risk som företaget representerade! Koden skrevs i C ++ och användes byte-matriser istället för istället för branschstandard, MBCS-strängar (multi-byte) … du får den allmänna idén!
Vi kallades in för att ”fixa” problem. Sanningen är att det skulle ha varit enklare och billigare att byta kunden till en kommersiell lagerhanteringsprodukt, men de hade djupt inbäddad ekonomisk modellering i systemet och ingen förstod tillräckligt om hur det fungerade för att överföra dessa funktioner till en kommersiell (åtminstone utan betydande risk).
Till slut, trots att vi påpekat mer kostnadseffektiva lösningar, var vi tvungna att omarbeta produkten och skriva om applikationen helt. Det tog två systemdesigners, 4 ledande ingenjörer, 20 mjukvaruutvecklare, 5 validerings- och 2 verktygs- / metodtekniker att skriva om produkten – och nästan två års förfluten tid för att få applikationen till allmän version.
Så hur uppnår du skalbarhet?
- Börja med att se till att du har skrivit in dina skalbarhetskrav i produktspecifikationen. I allmänhet kommer tidspress och lägsta kostnad att ge uppoffringar i områden som inte var korrekt föreskrivna i specifikationen.
- Arbeta med domenexperter som kan hjälpa dig att utveckla en struktur som uppfyller (troliga) framtida behov.
- Använd designmönster, bibliotek, 4GL / AI-applikationer och arkitekturer som formulerats från grunden för att undvika problem med skalbarhet (varav många utvecklats från bittra erfarenheter).
- Läs upp alla nyckelområden som distribuerade, feltoleranta databaser för applikationer med hög grad samtidigt, inbäddade säkerhetsarkitekturer, databasreplikering, molnbehandling osv.
- Se till att du använder erfarna, erfarna ingenjörer i nyckelpositioner. Jag skulle säga att nästan 50\% av de räddningsprojekt vi genomförde var en följd av oerfarna leadingenjörer och systemdesigners. Resten berodde på ledningsfel eller felaktig kommunikation mellan teknik och kund.
Så där har du det. Dessa dagar finns det verkligen ingen ursäkt för skalbarhetsproblem i medelstora företag, men många företag börjar med bara en handfull människor som hackar lösningar så bra de kan. Då växer företaget och skalbarheten blir en mardröm snarare än den ordnade utvecklingen den borde vara!
Svar
Skalbarhet inom mjukvaruteknik hänvisar normalt till att utforma programvarusystem på ett sådant sätt att , eftersom antalet användare av systemet ökar (även med faktorer som är 100 gånger eller mer) kommer programvaran att fortsätta att fungera med jämförbara svarstider. Nu är nästa fråga ”hur uppnås detta?”
Fristående skrivbordsprogramvara (t.ex. spel) är alltid 100\% skalbar eftersom varje användare får en helt egen dator. Detta är en trivial form av skalbarhet.
Klientserver och webbaserade programvarusystem beror dock på servrar , vilket är datorer som tillhandahåller tjänster till flera användare. Det bör vara uppenbart att en viss server bara kan hantera ett begränsat antal samtidiga användare.
Det finns två allmänna tekniker som gör att ett system kan skala utöver vad en enskild server kan hantera. Mycket skalbara system kommer att kombinera båda teknikerna.
Den första är att dela upp funktionaliteten i olika delar. En vanlig uppdelning är att ha en separat server för att vara värd för databasen som systemet är beroende av (det finns nästan alltid någon form av databas för att hålla ihållande information). Databasservern ges mycket minne och mycket snabba skivor eller RAID-matriser medan den andra typen av server behöver mindre minne och relativt lite diskutrymme.
Detta kan utökas till en n-nivåarkitektur, där mer och mer funktionalitet (och data, för databaser) delas mellan olika processer. När belastningen ökar migreras processerna till separata servrar för att upprätthålla prestanda. Observera att alla dessa servrar är fysiskt i samma serverfarm och är anslutna med mycket snabba nätverksanslutningar.
Den andra tekniken som används för skalbarhet är replikering . Detta innebär att t.ex. flera webbservrar används och att varje användare bara är ansluten till en av dem. För att stödja fler användare behöver systemet bara mer hårdvara (webbserversystem i det här exemplet). Databaser kan också replikeras, så att flera databasservrar kan stödja kloner av databasen (det är ibland svårt att hålla de olika kopiorna av databasen uppdaterade men dba har hanterat detta problem i flera år). För större system finns det databaser som är utformade för att vara skalbara och distribuerar deras data över flera servrar.
A2A: “Vad menas med” skalbarhet ”i programvaruteknik?”