Beste antwoord
Schaalbaar betekent dat het systeem relatief eenvoudig kan worden aangepast aan een breder gebruikersbestand dan aanvankelijk of oorspronkelijk bedoeld was . De factoren die bepalen hoe schaalbaar een applicatie is, zijn:
- goede programmastructuur (hoe gemakkelijk is het programma te begrijpen en uit te breiden om nieuwe rollen te ondersteunen)
- voorzieningen voor meerdere gebruikers en gelijktijdige databasetoegang en -bewerking (om het vastlopen van de database, weigering van toegang, corruptie of gegevensverlies te voorkomen)
- beveiligingsvoorzieningen voor zowel gebruikerstoegang als database-integriteit
- mogelijkheid om als een gedistribueerde applicatie op meerdere servers en databases in meerdere tijdzones
- database back-up, correctie en herstel
- taal- en culturele bepalingen
- voorziening voor intercommunicatie met derde partij toepassingen ofwel door een goed beheerde programma-interface bloot te leggen of door zich te abonneren op industriestandaarden.
- gebruik van bronnen en afhankelijkheden van hardware / besturingssysteem
- real-time prestaties
Er zijn andere factoren, afhankelijk van specifieke bedrijfsdomeinen, maar dit zijn de factoren die we routinematig een i zien worden zien wanneer een bedrijf zijn applicaties probeert te “schalen” of “uit te breiden”.
Schaalbaarheid lijdt gewoonlijk wanneer: / of:
- het programma is bedacht en geschreven door iemand die niet bekwaam in de disciplines van applicatieontwikkeling
- de verantwoordelijkheid voor het schrijven van een programma wordt uitbesteed met een specificatie die niet alle factoren onderzoekt die passen bij de toekomstige behoeften van de klant (een zwakke specificatie leidt vaak tot niet-schaalbare oplossingen )
- er is geen toezicht door bekwame software-ingenieur die het zakelijke domein begrijpt
Een eenvoudig voorbeeld van niet-schaalbaar is een magazijninventarisprogramma waaraan ik heb gewerkt in 1990 (ish).
Het originele programma is geschreven voor één gebruiker, één server en nachtelijke back-ups (gedurende die tijd was het systeem niet beschikbaar). In opeenvolgende volgorde wilde de klant:
- het aantal gebruikers verhogen van 1 tot 50+ en verschillende rollen en toegangsrechten voor elke gebruiker uitoefenen.
- de applicatie uitbreiden om meerdere magazijnen binnen hetzelfde land te ondersteunen
- de applicatie uitbreiden om rekening te houden met nieuwe, offshore magazijnen die ondersteuning impliceerden voor meerdere tijdzones, talen, wettelijke normen en operationele procedures
Het oorspronkelijke programma was nog nooit gestructureerd voor zon sterke schaalvereiste. De database leed aan frequente “dodelijke omhelzing” -blokkades, verlies van gegevens en onaanvaardbare downtime als gevolg van back-upprocedures voor databases. De applicatie had geen voorziening voor “offline” gegevensinvoer en was natuurlijk niet geschreven om fouttolerant te zijn voor communicatieproblemen. Proberen om het programma bij te werken bleek ook een nachtmerrie te zijn – in feite kwam hun hele systeem tot stilstand gedurende de uren die nodig waren om een wereldwijde update te installeren.
Voordat we als consultants werden ingeschakeld, werd het programma werd “gepatcht” door de oorspronkelijke coder (enkelvoud) die vervolgens was gestopt en ongemakkelijk was verdwenen.
Het patchen versluierde de structuur en functionaliteit van de code – hoewel ik betwijfel of het programma ooit goed was gestructureerd of gedocumenteerd – niemand had genoeg geweten om het risico te beseffen dat dit voor het bedrijf inhield! De code is geschreven in C ++ en gebruikte byte-arrays in plaats van in plaats van industriestandaard, multi-byte character set (MBCS) strings … je begrijpt het algemene idee!
We werden opgeroepen om de problemen. De waarheid is dat het eenvoudiger en goedkoper zou zijn geweest om de klant over te schakelen naar een commercieel voorraadbeheerproduct, maar ze hadden diepgaande financiële modellering in het systeem ingebed en niemand begreep voldoende hoe het werkte om deze functies over te dragen naar een reclamespot. programma (in ieder geval zonder significant risico).
Ondanks dat we op meer kosteneffectieve oplossingen wezen, moesten we het product reverse-engineeren en de applicatie volledig herschrijven. Er waren 2 systeemontwerpers, 4 hoofdingenieurs, 20 software-ingenieurs, 5 validatie- en 2 tool / methodologie-ingenieurs nodig om het product te herschrijven – en bijna 2 jaar verstreken tijd om de applicatie algemeen vrij te geven.
Dus hoe bereik je schaalbaarheid?
- Zorg er eerst voor dat je je schaalbaarheidseisen in de productspecificatie hebt geschreven. Over het algemeen zullen tijdsdruk en de laagste kosten leiden tot opofferingen op gebieden die niet op de juiste manier in de specificatie waren voorgeschreven.
- Werk samen met domeinexperts die u kunnen helpen een structuur te ontwikkelen die aan (waarschijnlijke) toekomstige behoeften voldoet.
- Maak gebruik van ontwerppatronen, bibliotheken, 4GL / AI-toepassingen en architecturen die vanaf de basis zijn geformuleerd om problemen met schaalbaarheid te voorkomen (waarvan er vele zijn ontwikkeld op basis van bittere ervaringen).
- Lees alle belangrijke gebieden door, zoals gedistribueerde, fouttolerante databases voor zeer gelijktijdige toepassingen, ingebouwde beveiligingsarchitecturen, databasereplicatie, cloudverwerking enz.
- Zorg ervoor dat u doorgewinterde, ervaren ingenieurs op sleutelposities. Ik zou zeggen dat bijna 50\% van de reddingsprojecten die we ondernamen het gevolg was van onervaren hoofdingenieurs en systeemontwerpers. De rest was te wijten aan managementfouten of onjuiste communicatie tussen engineering en klant.
Dus daar heb je het. Tegenwoordig is er echt geen excuus voor schaalbaarheidsproblemen in middelgrote tot grote bedrijven, maar veel bedrijven beginnen met slechts een handvol mensen die oplossingen zo goed mogelijk hacken. Dan groeit het bedrijf en wordt schaalbaarheid eerder een nachtmerrie dan de ordelijke voortgang die het zou moeten zijn!
Antwoord
Schaalbaarheid in software engineering verwijst normaal gesproken naar het ontwerpen van softwaresystemen op een manier dat , naarmate het aantal gebruikers van het systeem toeneemt (zelfs met factoren van 100x of meer), zal de software blijven functioneren met vergelijkbare responstijden. Nu is de volgende vraag “hoe wordt dit bereikt?”
Standalone desktopsoftware (bijv. Games) is altijd 100\% schaalbaar omdat elke gebruiker een eigen computer krijgt. Dit is een triviale vorm van schaalbaarheid.
Client-server en webgebaseerde softwaresystemen zijn echter afhankelijk van servers , dit zijn computers die diensten verlenen aan meerdere gebruikers. Het zou duidelijk moeten zijn dat een bepaalde server slechts een beperkt aantal gelijktijdige gebruikers aankan.
Er zijn twee algemene technieken waarmee een systeem verder kan schalen dan wat een enkele server aankan. Zeer schaalbare systemen combineren beide technieken.
De eerste is het splitsen van de functionaliteit in verschillende delen. Een veel voorkomende splitsing is om een aparte server te hebben voor het hosten van de database waarop het systeem vertrouwt (er is bijna altijd een soort database om blijvende informatie op te slaan). De databaseserver krijgt een grote hoeveelheid geheugen en zeer snelle schijven of RAID-arrays, terwijl het andere type server minder geheugen en relatief weinig schijfruimte nodig heeft.
Dit kan worden uitgebreid tot een n-tier-architectuur, waar steeds meer functionaliteit (en data, voor databases) wordt opgesplitst over verschillende processen. Wanneer de belasting toeneemt, worden de processen gemigreerd naar afzonderlijke servers om de prestaties te behouden. Houd er rekening mee dat al deze servers zich fysiek in dezelfde serverfarm bevinden en zijn verbonden via zeer snelle netwerkverbindingen.
De andere techniek die wordt gebruikt voor schaalbaarheid is replicatie . Dit betekent dat er bijvoorbeeld meerdere webservers worden gebruikt en dat elke gebruiker slechts met één daarvan is verbonden. Om meer gebruikers te ondersteunen, heeft het systeem alleen meer hardware nodig (webserversystemen in dit voorbeeld). Databases zijn ook geschikt voor replicatie, zodat meerdere databaseservers klonen van de database kunnen ondersteunen (het is soms lastig om de verschillende kopieën van de database up-to-date te houden, maar dbas hebben dit probleem al jaren opgelost). Voor grotere systemen zijn er databases die ontworpen zijn om schaalbaar te zijn en hun gegevens over meerdere servers te verdelen.
A2A: “Wat wordt bedoeld met” schaalbaarheid “in software engineering?”