Beste svaret
Skalerbart betyr at systemet med relativt letthet kan tilpasses en bredere brukerbase enn opprinnelig eller opprinnelig ment . Faktorene som avgjør hvor skalerbar en applikasjon er, vil omfatte:
- god programstruktur (hvor lett er programmet å forstå og utvide for å støtte nye roller)
- flere brukere og samtidig databasetilgang og redigering (for å unngå databaselåsing, tilgangsnektelse, korrupsjon eller datatap)
- sikkerhetsbestemmelser for både brukertilgang og databaseintegritet
- muligheten til å kjøre som en distribuert applikasjon på flere servere og databaser på tvers av flere tidssoner
- backup av databaser, korreksjon og gjenoppretting
- språk- og kulturbestemmelser
- bestemmelse for interkommunikasjon med tredjepart applikasjoner enten ved å utsette et godt administrert programgrensesnitt eller abonnere på industristandarder
- ressursbruk og avhengighet av maskinvare / operativsystem
- ytelse i sanntid
Det er andre faktorer, avhengig av spesifikke forretningsdomener, men dette er faktorene vi rutinemessig blir et i se når et selskap prøver å «skalere» eller «utvide» applikasjonene.
Skalerbarhet lider vanligvis når enten / eller:
- programmet er unnfanget og skrevet av noen som ikke er dyktig innen fagområdene applikasjonsutvikling
- ansvaret for å skrive et program er kontrakt med en spesifikasjon som ikke utforsker alle faktorene som er passende for kundenes fremtidige behov (en svak spesifikasjon fører ofte til ikke-skalerbare løsninger )
- det er ingen tilsyn av dyktig programvareingeniør som forstår virksomhetsdomenet
Et enkelt eksempel på manglende skalering er et lagerbeholdningsprogram jeg jobbet med tilbake i 1990 (ish).
Det opprinnelige programmet ble skrevet for én bruker, én server og nattlige sikkerhetskopier (i løpet av hvilken tid systemet ikke var tilgjengelig). I påfølgende rekkefølge ønsket kunden å:
- øke antall brukere fra 1 til 50+ og å vedta forskjellige roller og tilgangsrettigheter for hver bruker.
- utvide applikasjonen for å støtte flere lagre i samme land
- utvide applikasjonen for å ta hensyn til nye offshore-lagre som antydet støtte for flere tidssoner, språk, juridiske standarder og driftsprosedyrer
Det opprinnelige programmet hadde aldri vært strukturert for et så sterkt skaleringskrav. Databasen led av hyppige «dødelige omfavnelse» -låsinger, tap av data og uakseptabel nedetid på grunn av sikkerhetskopieringsprosedyrer for databaser. Søknaden hadde ingen bestemmelser om «offline» datainnføring og ble selvfølgelig ikke skrevet for å være feiltolerant for kommunikasjonsproblemer. Å prøve å oppdatere programmet viste seg også å være et mareritt – i utgangspunktet ble hele systemet stanset i flere timer det tok å installere en global oppdatering.
Før vi ble kalt inn, som konsulenter, programmet ble «lappet» av den opprinnelige koderen (entall) som senere hadde sluttet og uheldigvis forsvant. ingen hadde kjent nok til å innse risikoen dette representerte for selskapet! Koden ble skrevet i C ++ og brukt byte-matriser i stedet for i stedet for industristandard, multi-byte tegnsett (MBCS) strenger … du får den generelle ideen!
Vi ble kalt inn for å «fikse» problemer. Sannheten er at det ville vært enklere og billigere å bytte kunden til et kommersielt lagerstyringsprodukt, men de hadde dypt innebygd økonomisk modellering i systemet, og ingen forstod nok om hvordan det fungerte for å overføre disse funksjonene til en kommersiell program (i det minste uten betydelig risiko).
Til slutt, til tross for å påpeke mer kostnadseffektive løsninger, måtte vi omforme produktet og omskrive applikasjonen fullstendig. Det tok to systemdesignere, 4 ledende ingeniører, 20 programvareingeniører, 5 validering og 2 verktøy / metodikkingeniører å omskrive produktet – og nesten 2 års forløpt tid for å få applikasjonen til generell utgivelse.
Så hvordan oppnår du skalerbarhet?
- Start med å sørge for at du har skrevet skalerbarhetskravene dine i produktspesifikasjonen. Generelt vil tidspress og laveste kostnad føre til ofre i områder som ikke var riktig påbudt i spesifikasjonen.
- Arbeid med domeneksperter som kan hjelpe deg med å utvikle en struktur som vil møte (sannsynlige) fremtidige behov.
- Benytt deg av designmønstre, biblioteker, 4GL / AI-applikasjoner og arkitekturer som ble formulert fra grunnen av for å unngå problemer med skalerbarhet (hvorav mange ble utviklet fra bitre opplevelser).
- Les opp alle nøkkelområdene, for eksempel distribuerte, feiltolerante databaser for svært samtidige applikasjoner, innebygde sikkerhetsarkitekturer, replikering av databaser, skybehandling osv.
- Sørg for at du bruker erfarne, erfarne ingeniører i nøkkelstillinger. Jeg vil si at nesten 50\% av redningsprosjektene vi gjennomførte var en konsekvens av uerfarne blyingeniører og systemdesignere. Resten skyldtes ledelsesfeil eller feil kommunikasjon mellom prosjektering og kunde.
Så der har du det. I disse dager er det virkelig ingen unnskyldning for skalerbarhetsproblemer i mellomstore til store selskaper, men mange selskaper starter med bare en håndfull mennesker som hacker løsninger så godt de kan. Da vokser selskapet og skalerbarhet blir et mareritt i stedet for den ordnede progresjonen den burde være!
Svar
Skalerbarhet innen programvareteknikk refererer normalt til å utforme programvaresystemer på en slik måte at , ettersom antall brukere av systemet øker (selv med faktorer på 100 ganger eller mer), vil programvaren fortsette å fungere med sammenlignbare responstider. Nå er det neste spørsmålet “hvordan oppnås dette?”
Frittstående desktop-programvare (for eksempel spill) er alltid 100\% skalerbar fordi hver bruker får en hel datamaskin for seg selv. Dette er en triviell form for skalerbarhet.
Klient-server og nettbaserte programvaresystemer er imidlertid avhengig av servere , som er datamaskiner som tilbyr tjenester til flere brukere. Det bør være åpenbart at en gitt server bare kan håndtere et begrenset antall samtidige brukere.
Det er to generelle teknikker som lar et system skalere utover det en enkelt server kan håndtere. Svært skalerbare systemer vil kombinere begge teknikkene.
Den første er å dele funksjonaliteten i forskjellige deler. En vanlig splitting er å ha en egen server for å være vert for databasen som systemet er avhengig av (det er nesten alltid en slags database som inneholder vedvarende informasjon). Databaseserveren får mye minne og veldig raske disker eller RAID-arrays, mens den andre typen server trenger mindre minne og relativt lite diskplass.
Dette kan utvides til en n-lags arkitektur, hvor mer og mer funksjonalitet (og data, for databaser) er delt mellom forskjellige prosesser. Når belastningen øker, overføres prosessene til separate servere for å opprettholde ytelsen. Vær oppmerksom på at alle disse serverne er fysisk i samme serverfarm og er forbundet med nettverkstilkoblinger med høy hastighet.
Den andre teknikken som brukes for skalerbarhet er replikering . Dette betyr at f.eks. Flere webservere brukes, og hver bruker er koblet til bare en av dem. For å støtte flere brukere trenger systemet bare mer maskinvare (webserver-systemer i dette eksemplet). Databaser kan også replikeres, slik at flere databaseservere kan støtte kloner av databasen (det er noen ganger vanskelig å holde de forskjellige kopiene av databasen oppdatert, men dba har håndtert dette problemet i årevis). For større systemer er det databaser som er utformet for å være skalerbare, og distribuerer dataene deres på flere servere.
A2A: “Hva menes med» skalerbarhet «i programvareteknikk?”