Hvad er skalerbarhed?
- 6 minutter
I erhvervslivet kan vækst være en fordel. Men når væksten sker for hurtigt, og når du ikke har forberedt dig tilstrækkeligt på det, kan vækst skabe problemer. Et af disse problemer er effekten af vækst på pålideligheden af programmer og tjenester, der ikke var designet til at håndtere en stor stigning i trafikken.
For dine kunder og brugere er en afbrydelse en afbrydelse. De ved ikke eller er ligeglade med, om de ikke kan få adgang til dit websted på grund af fejlkode, eller fordi for mange andre mennesker forsøger at bruge dit perfekt kodede websted på samme tid.
skalerbarhed er muligheden for at tilpasse sig øgede krav eller skiftende behov. Dine programmer og tjenester skal kunne håndtere en større mængde arbejdsbelastning for at imødekomme væksten. Skalerbare programmer kan håndtere et stigende antal anmodninger over tid uden en negativ indvirkning på tilgængeligheden eller ydeevnen.
I dette undermodul lærer du om relationen mellem skalerbarhed og pålidelighed, vigtigheden af kapacitetsplanlægning for at opnå skalerbarhed og gennemgår kort nogle grundlæggende begreber og begreber, der er relateret til skalering.
Skalerbarhed/pålidelighedsrelation
Den gode nyhed er, at hvis du gør din app mere skalerbar, kan det også gøre den mere pålidelig. Hvis systemet f.eks. skalerer automatisk og derefter får en komponentfejl på en enkelt virtuel maskine, klargør tjenesten til automatisk skalering en anden forekomst for at opfylde dine minimumkrav til antal virtuelle maskiner (VM). Dit system bliver mere pålideligt. I et andet eksempel bruger du en højere niveau service som Azure Storage, der er iboende skalerbar. Hvis du har et lagerproblem, er tjenesten bygget til at være pålidelig, så dine data replikeres.
Her er en analogi: Tænk på de tilgængelighedsramper, som du ofte ser uden for bygninger, der oprindeligt var designet til at imødekomme personer i kørestole. De tjener dette formål. Men de bruges også af forældre med babyer i klapvogne eller vogne eller af små børn, for hvem trapperne er for dybe eller høje. Dette forbrug er en sekundær fordel .
Pålidelighed er ofte en sekundær fordel ved skalerbarhed. Hvis du designer dine systemer, så de er skalerbare, er de sandsynligvis også mere pålidelige.
Skalerbarhed og kapacitetsplanlægning
Kapacitetsplanlægning omfatter fastlæggelse af de ressourcer, du skal bruge for at imødekomme både nuværende og fremtidige behov. Du udfører denne planlægning ved at analysere dit aktuelle ressourceforbrug og derefter projektere med henblik på fremtidig vækst.
Hvis du vil anslå kapacitetsbehov i fremtiden, skal du overveje følgende faktorer:
- Forventet forretningsvækst
- Periodiske udsving (sæsonudsving osv.)
- Programbegrænsninger
- Identificering af flaskehalse og begrænsningsfaktorer
Du skal også angive serviceniveaumål, så du kan oprette en kapacitetsstyringsplan, der pålideligt opfylder eller overskrider disse målsætninger, når arbejdsbelastningen og miljøet ændres.
Kapacitetsplanlægning er en iterativ proces. Når vi gennemgår dette modul, lærer du, hvordan du tilknytter ressourcekrav til programkomponenter.
Begreber og terminologi
Før du fuldt ud kan forstå de begreber og strategier, du støder på i dette modul, har du brug for en vis forudsætningsviden om nogle få grundlæggende begreber og grundlæggende begreber relateret til skalering.
- Opskalering: Gør en komponent større, så den kan håndtere en øget arbejdsbelastning. Kaldes også lodret skalering.
- Udskalering: Tilføjelse af flere komponenter eller ressourcer for at fordele belastningen over en distribueret arkitektur. Brug f.eks. en simpel arkitektur, der har flere backends bag et sæt frontends. I takt med at belastningen øges, tilføjer vi flere back end-servere (og frontend)-servere for at håndtere den. Kaldes også vandret skalering.
- Manuel skalering: Menneskelig handling er nødvendig for at øge mængden af ressourcer.
- Automatisk skalering: Systemet justerer automatisk mængden af ressourcer baseret på belastningen. For at være klar justeres mængden både op og ned baseret på enten en øget eller reduceret belastning.
- GØR-det-selv-skalering, hvor du skal konfigurere automatisk skalering.
- Indbygget skalering: Tjenester, der er udviklet til at være skalerbare og håndtere denne skalering for dig i baggrunden, uden at du behøver at foretage dig noget. Fra dit perspektiv ser de næsten uendeligt skalerbare ud, fordi du bare kan forbruge flere ressourcer uden at skulle klargøre dem manuelt.
Tailwind Traders-arkitektur
I dette modul bruger vi et eksempel på arkitektur fra et fiktivt hardwarefirma kaldet Tailwind Traders. Deres e-handelsplatform ser sådan ud:
Dette diagram er ret komplekst ved første øjekast, så lad os gennemgå det. Webstedet har en frontend. Det er det, du taler med, hvis du går til tailwindtraders.com.
Frontend taler til et sæt back end-tjenester. Disse back end-tjenester omfatter almindelige varer som f.eks. en kupontjeneste, en indkøbskurvtjeneste, en lagertjeneste osv. De kører alle i Azure Kubernetes Service. Der er andre dele og teknologier i spil med dette program. Det eneste, du skal fokusere på, er frontend- og back end-tjenesterne, der kører på Kubernetes.
Enkelte fejlpunkter
Nu, hvor du har set hele arkitekturen, lad os tage et øjeblik til at undersøge de enkelte fejlpunkter og de steder, vi måske lægger vores opmærksomhed, når vi tænker på skalering.
Hver af disse tjenester er et enkelt fejlpunkt – de er ikke bygget til robusthed eller skalering. Hvis en af dem bliver overbelastet, er det sandsynligt, at det går ned, og der er ingen nem måde at løse det på i øjeblikket.
Senere i dette modul ser vi på andre måder at designe disse tjenester på, så de er mere skalerbare og pålidelige.
Forudinstalleret kapacitet
Lad os se på et andet problem, der kan vise sig at være besværligt. Her er de tjenester/komponenter, der kræver, at vi klargør kapacitet på forhånd:
Med Cosmos DB klargør vi f.eks. dataoverførselshastigheden på forhånd. Hvis vi overskrider disse grænser, begynder vi at returnere fejlmeddelelser til vores kunder. Med Azure AI services vælger vi niveauet, og det niveau har et maksimalt antal forespørgsler per sekund. Når vi når en af disse grænser, vil kunderne blive begrænset.
Vil en betydelig stigning i trafikken, som lancering af et nyt produkt, få os til at ramme disse grænser? Lige nu ved vi det ikke. Dette er en anden sag, som vi gennemgår senere i dette modul.
Omkostninger
Selv når vi gør tingene rigtigt, skal vi stadig planlægge vækst. Her er betaling pr. gang-tjenesterne:
Her bruger vi Azure Logic Apps og Azure Functions, som begge er eksempler på serverløs teknologi. Disse tjenester skaleres automatisk, og vi betaler pr. anmodning. Din regning vokser, som din kundebase gør. Vi skal i det mindste være opmærksomme på den indvirkning, kommende begivenheder som en produktlancering kan have på vores cloududgifter. Vi arbejder også på at forstå og forudsige vores cloududgifter senere i dette modul.
Tjek din viden
Feedback
Var denne side nyttig?
No
Har du brug for hjælp til dette emne?
Vil du prøve at bruge Ask Learn til at tydeliggøre eller guide dig gennem dette emne?