Indholdsfortegnelse
Hvad er skalerbarhed?Skalerbarhed er den ønskelige egenskab ved et system, netværk eller proces, som angiver dets evne til at reagere og tilpasse sig uden at miste kvalitet eller til at håndtere kontinuerlig jobvækst på en flydende måde, at være forberedt på at vokse sig større uden at miste kvalitet i de tilbudte tjenester .
Du kan sige, hvad er vores systems evne til at understøtte en større arbejdsbyrde med ændringer eller udvidelser, der er rimelige med hensyn til omkostninger, tid, tid og kompleksitet.
Typer af skalerbarhed
Generelt kan vi tale om lodret og vandret skalering eller en kombination af begge.
Lodret skalering
Det består dybest set i at øge kapaciteten for et eller flere specifikke elementer i vores arkitektur, for eksempel at udvide hukommelsen på vores centrale server eller udskifte CPU'erne med andre højere hastigheder. Sammenfattende skal du øge serverens kapacitet, noget meget almindeligt, når vi bruger virtualisering, og vi siger, at serveren på dette tidspunkt vil have 30% RAM tilgængeligt.
Horisontal skalering
Det er den, vi vil beskrive detaljeret i vejledningen, er baseret på at øge antallet af noder, der udfører den samme opgave, ved hjælp af forskellige planlægningstyper, for eksempel hvis vi har en mættet webserver, tilføjer vi en anden for at afbalancere belastningen.
Typer af webarkitektur baseret på niveauer.
Vi vil tale om arkitekturer, der kan anvendes med linux-systemer, ved hjælp af open source-værktøjer vil vi gå fra de mest basale til nogle ganske avancerede, der tilbyder vandret skalerbarhed og modstandsdygtighed over for fejl, alle disse arkitekturer kan anvendes i enhver PaaS eller med egen infrastruktur.
1. Arkitektur på ét niveau
Det er det mest basale af alt, hvor der kun er en server med Apache og MySQL, som kan fås eksternt. Det er meget almindeligt på sider med lille besøgsmargin eller testmiljøer, det giver ikke tolerance over for fejl, og det er svært at bruge det til at vokse vandret.
2. To-lags arkitektur
Denne gang adskilte vi databasen fra webserveren med en smule fejltolerance. På denne måde, hvis databasen mislykkes, kan webserveren tilbyde indhold på en statisk måde, der ikke afhænger af databasen. Og hvis webserveren svigter, kan vi stadig få adgang til oplysningerne ved at rejse en ny webserver igen.Designet byder på flere fejl, da det ikke er et meget skalerbart design.
3. Tre-lags arkitektur
Denne gang begynder vi at bruge en load balancer, der modtager alle anmodninger fra brugere. Denne gang tilbyder vi et mere skalerbart design, så hvis vores belastning stiger, kan vi tilføje flere webservere og skalere. Vi kan endda anvende autoskaling, så webservere tilføjes automatisk ved et bestemt belastningsniveau eller i en spidsbelastningstid. Problemet med dette design er, at vi kan mætte vores database.
4. Fire-lags arkitektur
Nu gør vi brug af en load balancer og en memcached, hvilket gør systemet mere skalerbart. Med dette design kan vi tilføje så mange databaser og webservere som nødvendigt ud over at tilbyde fejltolerance. Vi kan opdele belastningen mellem databaserne med CASSANDRA tilbyder en multi-node implementering. Dette design er meget mere komplekst, men jeg tilføjer meget større fejltolerance og evnen til at skalere alle dets niveauer.
5. Fem-lags arkitektur
Indholdet på en webside kan opdeles i statisk og dynamisk. For eksempel opdeler vi weblaget i en Apache -server og en anden med JAVA -applikationer, der kører Jetty eller JBoss. Apache leverer det statiske indhold, mens applikationsserveren håndterer det dynamiske eller on-the-fly-indhold. Et eksempel på dette kan være FAQ -sektionen på et supportwebsted, da det blot er statisk indhold, kan det håndteres af APACHE / NGINX.
FORSTØRRE
6. Seks-lags arkitektur
Vi kan være lidt mere elegante og tilføje et indholdsleveringsnetværk (CDN), eller hvad i AWS er kendt som Amazon CloudFront CDNFor eksempel har vi et E-learning-websted, og vores brugere downloader vejledninger i PDF eller videoer fra vores websted. Vi kan gemme al den båndbredde, der er dedikeret til downloads, Ved at tilbyde det fra et CDN, der tager sig af det, kan resten af nettet køre på vores infrastruktur.
FORSTØRRE
KonklusionerVi har set arkitekturer på flere niveauer, der kan anvendes, afhængigt af webtrafikken. Det er tilrådeligt at oprette arkitekturer, der tænker på fremtiden, der kan skalere og opretholde fejltolerance og undgå sammenbrud på nettet på grund af mangel på ressourcer eller fejl i en uundværlig knude. Ved at oprette nogle af disse designs sammen med andre anbefalinger såsom sikkerhedskopier og automatisk implementering kan vi tilbyde et websted med 99,9 fejltolerant oppetid.Kan du lide og hjælpe denne vejledning?Du kan belønne forfatteren ved at trykke på denne knap for at give ham et positivt punkt