Mērogojama tīmekļa arhitektūra

Kas ir mērogojamība?
Mērogojamība ir vēlama sistēmas, tīkla vai procesa īpašība, kas norāda uz tās spēju reaģēt un pielāgoties, nezaudējot kvalitāti, vai vienmērīgi risināt nepārtrauktu darba vietu pieaugumu, lai būtu gatava palielināties, nezaudējot piedāvāto pakalpojumu kvalitāti. .
Jūs varētu teikt, kāda ir mūsu sistēmas spēja atbalstīt lielāku darba slodzi ar izmaiņām vai paplašinājumiem, kas ir saprātīgi izmaksu, laika, laika un sarežģītības ziņā.
Mērogojamības veidi
Kopumā mēs varam runāt par vertikālu un horizontālu mērogošanu vai abu kombināciju.

Vertikālā mērogošana


Tas būtībā sastāv no viena vai vairāku mūsu arhitektūras elementu jaudas palielināšanas, piemēram, mūsu centrālā servera atmiņas paplašināšanas vai centrālo procesoru nomaiņas ar citiem ātrākajiem. Rezumējot, palieliniet servera jaudu, kas ir ļoti bieži, kad mēs izmantojam virtualizāciju un sakām, ka tajā laikā serverim būs pieejami 30% RAM.

Horizontālā mērogošana


Tas ir tas, kuru mēs detalizēti aprakstīsim apmācībā, ir balstīta uz to mezglu skaita palielināšanu, kas veic vienu un to pašu uzdevumu, izmantojot dažāda veida plānošanu, piemēram, ja mums ir piesātināts tīmekļa serveris, mēs pievienojam citu, lai līdzsvarotu slodzi.
Tīmekļa arhitektūras veidi, pamatojoties uz līmeņiem.
Mēs runāsim par arhitektūrām, kuras var izmantot ar Linux sistēmām, izmantojot atvērtā pirmkoda rīkus, mēs pāriesim no visvienkāršākā uz diezgan progresīvu, piedāvājot horizontālu mērogojamību un izturību pret neveiksmēm, visas šīs arhitektūras var izmantot jebkurā PaaS vai ar savu infrastruktūru.

1. Viena līmeņa arhitektūra


Tas ir visvienkāršākais no visiem, kur ir tikai viens serveris ar Apache un MySQL, kuram var piekļūt attālināti. Tas ir ļoti izplatīts lapās, kurās ir neliela apmeklējumu rezerve vai testa vide, tas nepiedāvā pielaidi neveiksmēm, un to ir grūti izmantot, lai augtu horizontāli.

2. Divu līmeņu arhitektūra


Šoreiz mēs atdalījām datu bāzi no tīmekļa servera, piedāvājot nelielu kļūdu toleranci. Tādā veidā, ja datu bāze neizdodas, tīmekļa serveris var piedāvāt saturu statiskā veidā, kas nav atkarīgs no datu bāzes. Un gadījumā, ja tīmekļa serveris neizdodas, mēs joprojām varam piekļūt informācijai, vēlreiz izveidojot jaunu tīmekļa serveri.Dizains piedāvā vairākus trūkumus, jo tas nav ļoti pielāgojams dizains.

3. Trīspakāpju arhitektūra


Šoreiz mēs sākam izmantot slodzes līdzsvarotāju, kas saņems visus lietotāju pieprasījumus. Šoreiz mēs piedāvājam pielāgojamāku dizainu, lai, palielinoties slodzei, mēs varētu pievienot vairāk tīmekļa serveru un mērogu. Mēs pat varam piemērot automātisko mērogošanu, lai tīmekļa serveri tiktu pievienoti automātiski noteiktā slodzes līmenī vai maksimālās stundas laikā. Šī dizaina problēma ir tā, ka mēs varam piesātināt mūsu datu bāzi.

4. Četru līmeņu arhitektūra


Tagad mēs izmantojam slodzes līdzsvarotāju un atmiņu, padarot sistēmu mērogojamāku. Izmantojot šo dizainu, mēs varam pievienot tik daudz datu bāzu un tīmekļa serveru, cik nepieciešams, papildus kļūdu tolerances nodrošināšanai. Mēs varam sadalīt slodzi starp datu bāzēm ar KASANDRA piedāvā vairāku mezglu ieviešanu. Šis dizains ir daudz sarežģītāks, taču es pievienoju daudz lielāku kļūdu toleranci un spēju mērogot visus tā līmeņus.

5. Piecu līmeņu arhitektūra


Tīmekļa lapas saturu var iedalīt statiskā un dinamiskā. Piemēram, mēs sadalām tīmekļa slāni Apache serverī un citā, izmantojot JAVA lietojumprogrammas, kurās darbojas Jetty vai JBoss. Apache nodrošina statisku saturu, kamēr lietojumprogrammu serveris apstrādā dinamisko vai lidojuma saturu. Piemērs tam var būt atbalsta vietnes FAQ sadaļa, jo tas ir tikai statisks saturs, to var apstrādāt APACHE / NGINX.

PALIELINĀT

6. Sešu līmeņu arhitektūra


Mēs varam būt nedaudz elegantāki un pievienot satura piegādes tīklu (CDN), jeb to, kas AWS ir pazīstams kā Amazon CloudFront CDNPiemēram, mums ir e-apmācības vietne, un mūsu lietotāji no mūsu vietnes lejupielādē ceļvežus PDF formātā vai videoklipos. Mēs varam ietaupīt visu joslas platumu, kas veltīts lejupielādēm, piedāvājot to no CDN, kas par to rūpējas. Pārējais tīmeklis var darboties mūsu infrastruktūrā.

PALIELINĀT

SecinājumiMēs esam redzējuši daudzlīmeņu arhitektūras, kuras var piemērot atkarībā no tīmekļa trafika. Ieteicams veidot arhitektūru, domājot par nākotni, kas var palielināt un saglabāt kļūdu toleranci, izvairoties no sabrukšanas tīmeklī resursu trūkuma vai neaizstājama mezgla kļūmes dēļ. Izveidojot dažus no šiem dizainparaugiem kopā ar citiem ieteikumiem, piemēram, dublējumiem un automātisku izvietošanu, mēs varam piedāvāt vietni ar 99,9 kļūdu izturīgu darbības laiku.Vai jums patika šī apmācība un palīdzējāt tai?Jūs varat apbalvot autoru, nospiežot šo pogu, lai sniegtu viņam pozitīvu punktu
wave wave wave wave wave