Die beskikbaarheid van toepassings is nog nooit so ernstig opgeneem soos vandag wanneer ons toepassings vir meer as net kommunikasie gebruik nie, hetsy persoonlik of professioneel en wanneer toepassings die besigheid is.
Toepassings wat nie voortdurend aanlyn is nie, of onstabiel is, verloor hul gebruikers en relevansie, en raak uiteindelik uitgedien. Dit het blitsvinnig gebeur. Omdat die internet nooit slaap nie en 24 uur per dag, 7 dae per week werk, moet dieselfde idee vir toepassings geld.
Skaalbaarheid is van kritieke belang om dit te doen en die beskikbaarheid van toepassings te verseker. Lasbalansering is een van die belangrikste komponente om beskikbaarheid te verseker. Baie mense glo steeds dat lasbalansering met 'n eenvoudige skrif bewerkstellig kan word.
Dit is egter nie die geval nie. Dit alleen bied toegang tot programme regoor die wêreld - te eniger tyd en vanaf enige toestel.
In hierdie plasing gaan ons onder meer diep kyk na lasbalansering, die algoritmes daarvan en hoe dit met mikrodienste verband hou. Laat ons begin!
Wat is lasbalansering?
Soos die vraag na 'n webwerf of besigheidstoepassing toeneem, sal 'n enkele bediener binnekort nie die hele vrag kan hanteer nie. Organisasies versprei die werklading oor talle bedieners om die vraag te bevredig. Hierdie metode, bekend as “vragbalansering”, keer dat 'n enkele bediener oorlaai word, wat kan veroorsaak dat dit stadiger word, versoeke laat val of selfs ineenstort.
Lasbalansering versprei netwerkverkeer eweredig om mislukking as gevolg van hulpbronoorlading te voorkom. Toepassings, webwerwe, databasisse en ander rekenaarhulpbronne presteer beter en is meer beskikbaar deur hierdie metode te gebruik. Dit help ook met die behoorlike en tydige verwerking van gebruikersversoeke.
Uit die perspektief van die gebruiker dien lasbalansering as 'n ongesiene tussenganger tussen 'n kliënt en 'n versameling bedieners, om te verseker dat verbindingsversoeke nie laat vaar word nie. Toepassings, webwerwe, databasisse en aanlyndienste sal heel waarskynlik in duie stort as die vraag te groot word sonder vragbalansering.
Honderde duisende gebruikersversoeke kan op dieselfde tyd na 'n enkele hoë-verkeer webwerf gestuur word. Veelvuldige bedieners word vereis om webbladsye korrek te vul met die gevraagde inhoud, soos teks, beelde, video en oudiostroming. Lasbalansering word algemeen gebruik in hoë-verkeer webwerf-bedienerplase, sowel as DNS-bedieners, databasisse en File Transfer Protocol (FTP)-werwe.
As 'n enkele bediener oorlaai is, kan dit swak funksioneer of selfs ineenstort. Lasbalanseerders verminder die kans op stilstand deur gebruikersversoeke eweredig tussen 'n versameling bedieners te versprei. As een van die bedieners in die groep misluk, word verkeer na ander bedieners in die groep herlei. 'n Lasbalanseerder voeg outomaties nuwe bedieners by in die verkeersverspreidingsproses wanneer hulle by die bedienerpoel gevoeg word.
Hoe werk lasbalansering?
Dit werk soos volg:
- Wanneer 'n kliënt 'n versoek ontvang, soos via 'n blaaier of 'n toepassing, probeer dit om met die bediener te koppel.
- Wanneer 'n lasbalanseerder 'n versoek ontvang, stuur dit dit na een van die bedieners in 'n bedienergroep gebaseer op gevestigde patrone deur die algoritme (of plaas).
- Die bediener ontvang die verbindingsversoek en antwoord die kliënt deur die lasbalanseerder.
- Wanneer die lasbalanseerder die antwoord ontvang, pas dit die IP-adres van die kliënt by die IP-adres van die geselekteerde bediener. Daarna word die antwoord saam met die pakkie versend.
- SSL-aflaai is die proses om data te dekripteer deur die Security Socket Layer-enkripsieprotokol te gebruik sodat bedieners dit nie hoef te doen nie.
- Die proses word herhaal totdat die sessie verby is.
Lasbalansering metodes
Om te kies watter van die bedieners in 'n bedienerplaas die volgende versoek ontvang, gebruik elke lasbalanseringstegniek 'n stel kriteria. Daar is vyf tipiese benaderings vir lasbalansering:
- Rondomtalie: Dit is die verstekbenadering, en dit werk net soos dit klink. Die lasbalanseerder versprei versoeke in 'n roterende patroon, begin met die eerste bediener in die groep en gaan af na onder, waar dit wag om weer opgeroep te word. Hierdie metode verseker dat elke bediener min of meer dieselfde aantal verbindings hanteer.
- Geweegde Round Robin: Hierdie benadering ken aan elke bediener 'n gewig (of voorkeur) toe wat oor die algemeen eweredig is aan sy kapasiteit. Hoe meer versoeke 'n bediener ontvang, hoe hoër is die gewig. Byvoorbeeld, 'n bediener met 'n gewigwaarde van twee ontvang twee keer soveel versoeke as 'n bediener met 'n gewigwaarde van een.
- Klewerige sessie: Hierdie benadering, ook bekend as sessie volharding, verbind sekere kliënte en bedieners vir die duur van 'n sessie. Om die skakel te vestig, gebruik die lasbalanseerder 'n koekie of die gebruiker se IP-adres om 'n gebruikerkenmerk te identifiseer. Sodra die verbinding tot stand gebring is, word die gebruiker se versoeke na dieselfde bediener gerig totdat die sessie eindig. Dit optimaliseer netwerkhulpbronne terwyl dit ook die gebruikerservaring verbeter.
- Minste verbindings: Hierdie strategie veronderstel dat alle versoeke 'n gelyke bedienerlas tot gevolg het. Gevolglik ontvang die bediener met die kleinste aantal versoeke die volgende versoek.
- IP Hash: Hierdie algoritme genereer 'n unieke hash-sleutel gebaseer op die kliënt en bediener se bron- en bestemmings-IP-adresse. Die sleutel word gebruik om die versoek te stuur en laat 'n verlore verbinding met dieselfde bediener toe om te hervat.
Hardeware vs. Sagteware Load Balancers
Hardeware Load Balancer
Fisiese hardeware, soos 'n toestel, maak hardeware lasbalanseerders uit. Hierdie stuur verkeer na bedieners na gelang van faktore soos die aantal bestaande verbindings, verwerkergebruik en bedienerwerkverrigting. Hardeware-lasbalanseerders het eie fermware wat in stand gehou en bygewerk moet word wanneer nuwe weergawes en sekuriteitsoplossings beskikbaar word.
Hardeware-lasbalanseerders bied dikwels hoër werkverrigting en beheer, sowel as 'n wyer reeks vermoëns soos Kerberos-verifikasie en SSL-hardewareversnelling, maar dit vereis 'n mate van bestuur- en instandhoudingskundigheid. Omdat hardeware-lasbalanseerders minder buigsaam en skaalbaar is as sagteware-lasbalanseerders, is daar 'n geneigdheid om hardeware-lasbalanseerders te oorvoorsien.
Sagteware Load Balancer
Sagteware-lasbalanseerders is gewoonlik makliker om op te stel as hul hardeware-eweknieë. Hulle is ook meer koste-effektief en aanpasbaar, en hulle werk goed saam met sagteware-ontwikkelingsomgewings. Die sagtewaremetode laat jou toe om die lasbalanseerder aan te pas by jou omgewing se presiese vereistes. Die verhoogde buigsaamheid kan ten koste gaan van bykomende tyd wat spandeer word om die lasbalanseerder op te stel.
Sagteware-balanseerders bied jou groter buigsaamheid om wysigings en opdaterings aan te bring as hardeware, wat 'n meer geslote boks-benadering het. Voorafverpakte virtuele masjiene kan as sagteware load balancers (VM's) gebruik word. Virtuele masjiene sal jou 'n bietjie tyd spaar, maar hulle het dalk nie al die funksies wat in hul hardeware-eweknieë beskikbaar is nie.
Eenvoudige Load Balancing Implementering
Ons sal die Spring Cloud-biblioteek gebruik om programme te bou wat op 'n lasgebalanseerde wyse aan ander toepassings koppel. Terwyl ons afgeleë diensversoeke verwerk, kan ons maklik vragbalansering opstel deur gebruik te maak van watter tegniek ons ook al wil. Beskou die volgende kode as 'n voorbeeld. Ons begin met 'n basiese bedienertoepassing.
Die bediener sal slegs een HTTP-eindpunt hê en sal in verskeie gevalle bedryf word. Dan sal ons 'n kliënt-toepassing bou wat Load Balancer gebruik om versoeke oor verskeie bedienergevalle te versprei.
bediener
Ons begin met 'n basiese Springstewel toepassing vir ons voorbeeldbediener:
Om te begin, spuit ons 'n aanpasbare veranderlike genaamd instance_ID in. Dit help ons om te onderskei tussen talle gevalle wat werk. Daarna skep ons 'n enkele HTTP GET-eindpunt wat 'n boodskap en instansie-ID terugstuur.
Die verstekinstansie met ID 1 sal op poort 8080 werk. Ons hoef net 'n paar programparameters by te voeg om 'n tweede instansie te begin:
Kliënt
Kom ons kyk nou na die kliëntkode. Dit is waar Load Balancer inkom, so kom ons begin deur dit in ons toepassing in te sluit:
Daarna ontwikkel ons 'n implementering van ServiceInstanceListSupplier. Dit is een van die belangrikste koppelvlakke in Load Balancer. Dit spesifiseer hoe ons toeganklike diensgevalle opspoor.
Ons sal twee afsonderlike gevalle van ons voorbeeldbediener hardkodeer in ons voorbeeldtoepassing. Hulle loop op dieselfde stelsel, maar gebruik aparte poorte:
Skep nou 'n LoadBalancerConfiguration-klas:
Hierdie klas het net een doel: dit skep 'n lasgebalanseerde WebClient-bouer vir die maak van afgeleë versoeke. Ons aantekening gebruik 'n fiktiewe naam vir die diens.
Dit is te wyte aan die feit dat ons heel waarskynlik nie die presiese gasheername en poorte sal ken vir die loop van gevalle voor die tyd nie. Gevolglik gebruik ons 'n fiktiewe naam as 'n plekhouer, en die raamwerk sal werklike inligting vervang wanneer dit 'n lopende instansie kies.
Kom ons maak dan 'n konfigurasieklas wat gebruik sal word om ons diensinstansieverskaffing te instansieer. Neem kennis dat ons dieselfde alias gebruik as voorheen:
Ons kan nou die regte kliënttoepassing bou. Kom ons stuur 10 navrae na die voorbeeldbediener met die WebClient-boon van vroeër:
Ons kan uit die uitset sien dat ons lasbalansering tussen twee afsonderlike gevalle:
Lasbalansering in mikrodienste
Mikrodiensargitektuur word deur verskeie maatskappye, soos Netflix en Amazon, gebruik om besigheidstoepassings te ontwikkel as 'n stel losweg gekoppelde dienste. Hiperskaal en deurlopende aflewering vir ingewikkelde toepassings is slegs twee van die redes om na hierdie verspreide, losweg gekoppelde argitektuur te beweeg.
Hierdie ondernemings se spanne het Agile- en DevOps-strategieë geïmplementeer om toepassings vinniger en met 'n laer mislukkingsyfer as tradisionele metodes te produseer. U moet egter 'n balans vind tussen die verspreide argitektuur se kompleksiteit en die toepassing se eise, skaalvereistes en tyd-tot-mark-beperkings.
Vir soveel jare was toepassingafleweringsbeheerders (ADC's) van kritieke belang om te voldoen aan diensvlakvereistes vir korporatiewe toepassings wat op die perseel of in die wolk aangebied word. 'n Kliënt wat betrokke is by 'n mikrodiens-gebaseerde toepassing hoef nie te weet van die gevalle wat dit verskaf om die kliënt en mikrodienste onafhanklik te laat groei nie.
Dit is presies die ontkoppeling wat deur 'n omgekeerde instaanbediener of 'n lasbalanseerder verskaf word. Weereens, vragbalansering is die oplossing om te verseker dat mikrodienste vraag, sekuriteit en beskikbaarheid kan hanteer.
Wanneer jy tradisionele Noord-Suid-lasbalansering tussen kliënt- en mikrodiensgebaseerde toepassings kombineer met Oos-Wes-ontplooiing vir horisontale skaalbaarheid, kry jy 'n aansienlike hupstoot. Die doelwit is om die veilige en gereguleerde omgewing wat deur IT vereis word te handhaaf sonder om ontwikkelingsbehendigheid of DevOps -outomatisering vereistes.
Voordele
Lasbalansering bied verskeie voordele deur hulpbronbenutting, datalewering en reaksietyd te verbeter vir webwerwe en toepassings wat baie verkeer, sowel as databasisse wat 'n groot aantal navrae kry. Lasbalansering verseker dat gebruikersversoeke vinnig en korrek in hoë-verkeer scenario's vervul word.
Hulle spaar gebruikers die verergering van die hantering van trae programme en hulpbronne. Lasbalansering help ook om stilstand te vermy en sekuriteit te vereenvoudig, wat die risiko van verlore produktiwiteit en verdienste vir jou maatskappy verlaag.
- Lasbalansering bied die buigsaamheid om bedieners by te voeg en te verwyder soos die vraag dit vereis, benewens die bestuur van verkeer tot optimale doeltreffendheid. Omdat verkeer tydens onderhoud na ander bedieners herlei word, is dit ook haalbaar om bedieneronderhoud te onderneem sonder om gebruikers te ontwrig.
- Lasbalansering bied ingeboude oortolligheid deur verkeer tussen 'n stel bedieners te verdeel. U kan die vrag onmiddellik na ander bedieners herlei as een misluk, wat die impak op gebruikers verminder.
- As 'n toepassing of webwerf se gebruik groei, kan die verhoogde verkeer sy werkverrigting verswak as dit nie doeltreffend hanteer word nie. Met lasbalansering kan u 'n regte of virtuele bediener byvoeg om aan die vraag te voldoen sonder om diens te ontwrig. Die lasbalanseerder identifiseer nuwe bedieners soos hulle aanlyn kom en inkorporeer hulle moeiteloos in die operasie. Hierdie metode is verkieslik bo die migreer van 'n webwerf van 'n oorlaaide bediener na 'n nuwe een, wat gereeld 'n mate van stilstand behels.
Gevolgtrekking
Lasbalansering is 'n kritieke komponent van kontemporêre, foutverdraagsame stelsels. Ons kan eenvoudig toepassings bou wat versoeke na veelvuldige diensgevalle versprei deur verskillende lasbalanseringsbenaderings te gebruik. Besighede moet ingewikkelde IT-stelsels ondersteun om toepassings veilig te verskaf.
Kruisdomein-mikrodienste-konfigurasie, -ontplooiing en -onderhoud kan foutgevoelig, duur en tydrowend wees. IT moet outomatisering, sigbaarheid, analise en orkestrasie beste praktyke en tegnologieë gebruik wat versoenbaar is met hul ratse en DevOps-prosesse om die opstel en instandhouding van hierdie mikrodienste makliker te maak.
Lewer Kommentaar