Bedste svar
Skalerbart betyder, at systemet med relativ lethed kan tilpasses til en bredere brugerbase end oprindeligt eller oprindeligt beregnet . De faktorer, der bestemmer, hvor skalerbar en applikation er, vil omfatte:
- god programstruktur (hvor let er programmet at forstå og udvide for at understøtte nye roller)
- flere brugere og samtidig databaseadgang og redigering (for at undgå databaselåsning, adgangsafvisning, korruption eller datatab)
- sikkerhedsbestemmelser for både brugeradgang og databaseintegritet
- evne til at køre som distribueret applikation på flere servere og databaser på tværs af flere tidszoner
- sikkerhedskopiering af database, korrektion og gendannelse
- sproglige og kulturelle bestemmelser
- bestemmelse til interkommunikation med tredjepart applikationer enten ved at udsætte en veladministreret programgrænseflade eller abonnere på industristandarder
- ressourceforbrug og hardware / operativsystemafhængigheder
- realtidsydelse
Der er andre faktorer, der afhænger af specifikke forretningsdomæner, men det er de faktorer, vi rutinemæssigt bliver et i ssue når et firma forsøger at “skalere” eller “udvide” deres applikationer.
Skalerbarhed lider normalt, når enten / eller:
- programmet er udtænkt og skrevet af nogen, der ikke er dygtige inden for disciplinerne applikationsudvikling
- ansvaret for at skrive et program er udkontrakteret med en specifikation, der ikke udforsker alle de faktorer, der passer til kundernes fremtidige behov (en svag specifikation fører ofte til ikke-skalerbare løsninger )
- der er ikke tilsyn med en dygtig softwareingeniør, der forstår forretningsdomænet
Et simpelt eksempel på manglende skalering er et lagerbeholdningsprogram, jeg har arbejdet med tilbage i 1990 (ish).
Det originale program blev skrevet til en bruger, en server og natlige sikkerhedskopier (i hvilket tidsrum systemet ikke var tilgængeligt). I rækkefølge efter hinanden ønskede kunden at:
- øge antallet af brugere fra 1 op til 50+ og at vedtage forskellige roller og adgangsrettigheder for hver bruger.
- udvid applikationen til at understøtte flere lagre inden for samme land
- udvid applikationen for at tage højde for nye offshore-lagre, der indebar støtte til flere tidszoner, sprog, juridiske standarder og driftsprocedurer
Det oprindelige program var aldrig struktureret til et så stærkt skaleringskrav. Databasen led af hyppige “dødbringende omfavnelse” -låsning, tab af data og uacceptabel nedetid på grund af sikkerhedskopieringsprocedurer til databaser. Ansøgningen havde ingen bestemmelse om “offline” dataindtastning og var naturligvis ikke skrevet for at være fejletolerant over for kommunikationsproblemer. Forsøg på at opdatere programmet viste sig også at være et mareridt – grundlæggende stoppede hele deres system i de flere timer, det tog at installere en global opdatering.
Før vi blev kaldt ind som konsulenter, var programmet blev “patched” af den originale koder (ental), som efterfølgende var stoppet og ubesværet forsvandt. ingen havde kendt nok til at indse den risiko, dette repræsenterede for virksomheden! Koden blev skrevet i C ++ og anvendt byte-arrays i stedet for i stedet for industristandard, multi-byte-tegnsæt (MBCS) -strenge … du får den generelle idé!
Vi blev kaldt til for at “rette” problemer. Sandheden er, det ville have været enklere og billigere at skifte kunden til et kommercielt lagerstyringsprodukt, men de havde dybt integreret økonomisk modellering i systemet, og ingen forstod helt nok om, hvordan det fungerede til at overføre disse funktioner til en kommerciel program (i det mindste uden væsentlig risiko).
Til sidst, på trods af at vi påpegede mere omkostningseffektive løsninger, var vi nødt til at reverse-engineering af produktet og omskrive applikationen fuldstændigt. Det tog 2 systemdesignere, 4 ledende ingeniører, 20 softwareingeniører, 5 validering og 2 værktøjs- / metodologingeniører at omskrive produktet – og næsten 2 års forløbet tid for at få applikationen til generel frigivelse.
Så hvordan opnår du skalerbarhed?
- Start med at sikre, at du har skrevet dine skalerbarhedskrav i produktspecifikationen. Generelt vil tidspres og laveste omkostninger medføre ofre i områder, der ikke var ordentligt påbudt i specifikationen.
- Arbejd med domæneeksperter, der kan hjælpe dig med at udvikle en struktur, der imødekommer (sandsynlige) fremtidige behov.
- Benyt dig af designmønstre, biblioteker, 4GL / AI-applikationer og arkitekturer, der blev formuleret fra grunden for at undgå problemer med skalerbarhed (hvoraf mange blev udviklet fra bitre oplevelser).
- Læs alle nøgleområder som distribuerede, fejltolerante databaser til meget samtidige applikationer, indlejrede sikkerhedsarkitekturer, databasereplikering, cloudbehandling osv.
- Sørg for, at du anvender erfarne, erfarne ingeniører i nøglepositioner. Jeg vil sige, at næsten 50\% af de redningsprojekter, vi foretog, var en konsekvens af uerfarne blyingeniører og systemdesignere. Resten skyldtes ledelsesfejl eller forkert kommunikation mellem teknik og kunde.
Så der har du det. I disse dage er der virkelig ingen undskyldning for problemer med skalerbarhed i mellemstore virksomheder, men mange virksomheder starter med kun en håndfuld mennesker, der hacker løsninger så godt de kan. Derefter vokser virksomheden, og skalerbarhed bliver et mareridt snarere end den ordnede progression, den burde være! , da antallet af brugere af systemet stiger (selv med faktorer på 100 gange eller mere), vil softwaren fortsat fungere med sammenlignelige svartider. Nu er det næste spørgsmål “hvordan opnås dette?”
Standalone desktop-software (f.eks. Spil) er altid 100\% skalerbart, fordi hver bruger får en helt egen computer. Dette er en triviel form for skalerbarhed.
Client-server og webbaserede softwaresystemer afhænger dog af servere , som er computere som leverer tjenester til flere brugere. Det skal være indlysende, at en given server kun kan håndtere et begrænset antal samtidige brugere.
Der er to generelle teknikker, der gør det muligt for et system at skalere ud over, hvad en enkelt server kan håndtere. Systemer, der er meget skalerbare, kombinerer begge teknikker.
Den første er at opdele funktionaliteten i forskellige dele. En fælles opdeling er at have en separat server til at være vært for den database, som systemet er afhængig af (der er næsten altid en slags database, der indeholder vedvarende information). Databaseserveren får en stor mængde hukommelse og meget hurtige diske eller RAID-arrays, mens den anden type server har brug for mindre hukommelse og relativt lidt diskplads.
Dette kan udvides til en n-lags arkitektur, hvor mere og mere funktionalitet (og data til databaser) er opdelt mellem forskellige processer. Når belastningen øges, migreres processerne til separate servere for at opretholde ydeevnen. Bemærk, at alle disse servere er fysisk i samme serverfarm og er forbundet med netværksforbindelser med meget høj hastighed.
Den anden teknik, der bruges til skalerbarhed, er replikering . Dette betyder, at der f.eks. Bruges flere webservere, og at hver bruger kun er forbundet til en af dem. For at understøtte flere brugere har systemet bare brug for mere hardware (webserver-systemer i dette eksempel). Databaser er også i stand til replikering, så flere databaseservere kan understøtte kloner af databasen (det er undertiden vanskeligt at holde de forskellige kopier af databasen opdateret, men dba har håndteret dette problem i årevis). For større systemer er der databaser, der er designet til at være skalerbare og distribuerer deres data på flere servere.
A2A: “Hvad menes der med” skalerbarhed “i softwareteknik?”