PĂ«rshĂ«ndetje, unĂ« jam Sergey Ylantsev, po zhvilloj nĂ« Yandex.Cloud. MĂ« parĂ« udhĂ«hoqa zhvillimin e njĂ« balansuesi L7 pĂ«r portalin e Yandex â kolegĂ«t shakahtin se çfarĂ«do qĂ« tĂ« bĂ«j, del si njĂ« balansues. Do t'u tregoj lexuesve tĂ« HabrĂ«s se si duhet menaxhuar ngarkesa nĂ« platformĂ«n e reve, si e shohim ne mjetin ideal pĂ«r tĂ« arritur kĂ«tĂ« qĂ«llim dhe si po ecim drejt ndĂ«rtimit tĂ« kĂ«tij mjeti.
Fillimisht le të prezantojmë disa terma:
- VIP (Virtual IP) â adresa IP e balansuesit
- Server, backend, instancĂ« â makinĂ« virtuale me program tĂ« ngarkuar
- RIP (Real IP) â adresa IP e serverit
- Healthcheck â kontrolli i gatishmĂ«risĂ« sĂ« serverit
- Zona e disponueshmĂ«risĂ«, Availability Zone, AZ â InfrastrukturĂ« e izoluar nĂ« qendrĂ«n e tĂ« dhĂ«nave
- Rajoni â Bashkimi i AZ-ve tĂ« ndryshme
Balancuesit e ngarkesës zgjidhin tre detyra kryesore: realizojnë vetë balancimin, përmirësojnë qëndrueshmërinë kundrejt dështimit të shërbimit dhe lehtësojnë shkallëzimin e tij. Qëndrueshmëria ndihmohet përmes menaxhimit automatik të trafikëve: balansuesi monitoron gjendjen e aplikacionit dhe përjashton nga balancimi instancat që nuk kalojnë kontrollin e jetëgjatësisë. Shkallëzimi sigurohet përmes shpërndarjes së barabartë të ngarkesës mbi instanca, si dhe përditësimit së listës së instancave në fluks. Nëse balancimi nuk është mjaft i barabartë, disa nga instancat do të marrin një ngarkesë që tejkalon kufijtë e tyre të operimit dhe shërbimi do të bëhet më pak të besueshëm.
Balancuesit e ngarkesës shpesh klasifikohen sipas nivelit të protokollit nga modeli OSI, në të cilin ata punojnë. Balancuesi i Cloud-ëve punon në nivelin TCP, që korrespondon me nivelin e katërt, L4.
Le të kalojmë në një përmbledhje të arkitekturës së balansuesit të Cloud-it. Do të rritim gradualisht nivelin e detajeve. Ne i ndajmë komponentët e balansuesit në tri klasa. Klasa e planit config është përgjegjëse për ndërveprimin me përdoruesin dhe ruan gjendjen e synuar të sistemit. Klasa e planit të kontrollit ruan gjendjen aktuale të sistemit dhe menaxhon sistemet nga klasa e planit të të dhënave, të cilat janë përgjegjëse direkt për dërgimin e trafikëve nga klientët në instancat tuaja.
Plani i të dhënave
Trafiku arrin nĂ« pajisjet e shtrenjta tĂ« quajtura router-at kufitarĂ«. PĂ«r tĂ« rritur qĂ«ndrueshmĂ«rinĂ«, nĂ« njĂ« qendĂ«r tĂ« tĂ« dhĂ«nave punojnĂ« njĂ«kohĂ«sisht disa nga kĂ«to pajisje. MĂ« pas, trafiku arrin nĂ« balancuesit, tĂ« cilĂ«t pĂ«r klientĂ«t shpallin adresĂ«n anycast IP nĂ« tĂ« gjitha AZ-tĂ« pĂ«rmes BGP.Â
Trafiku transmetohet pĂ«rmes ECMP â kjo Ă«shtĂ« njĂ« strategji rruge, sipas sĂ« cilĂ«s mund tĂ« ekzistojnĂ« disa rruge njĂ«soj tĂ« mira drejt qĂ«llimit (nĂ« rastin tonĂ«, qĂ«llimi do tĂ« jetĂ« adresa IP e destinacionit) dhe paketat mund tĂ« dĂ«rgohen pĂ«rmes cilĂ«sdo prej tyre. Po ashtu, ne mbĂ«shtesim punĂ«n nĂ« zona tĂ« ndryshme tĂ« disponueshmĂ«risĂ« sipas skemĂ«s sĂ« mĂ«poshtme: shpallim adresĂ«n nĂ« çdo zonĂ«, trafik arrin nĂ« atĂ« mĂ« tĂ« afertĂ«n dhe nuk del mĂ« tej. MĂ« tej nĂ« post do tĂ« shqyrtojmĂ« mĂ« nĂ« detaje se çfarĂ« ndodh me trafikun.
Plani i konfigurimit
Â
Komponenti kyç i planit tĂ« konfigurimit Ă«shtĂ« API, pĂ«rmes tĂ« cilit realizohen operacionet kryesore me balancuesit: krijimi, fshirja, ndryshimi i pĂ«rmbajtjes sĂ« instancave, marrja e rezultateve tĂ« kontrollave tĂ« gatishmĂ«risĂ« etj. Nga njĂ«ra anĂ«, Ă«shtĂ« njĂ« REST API, dhe nga ana tjetĂ«r, ne nĂ« Cloud pĂ«rdorim shpesh kornizĂ«n gRPC, prandaj ne "pĂ«rkthejmĂ«" REST nĂ« gRPC dhe mĂ« pas pĂ«rdorim vetĂ«m gRPC. Ădo kĂ«rkesĂ« krijon njĂ« seri detyrash asinkrone idempotente, tĂ« cilat ekzekutohen nĂ« njĂ« grup punĂ«torĂ«sh tĂ« pĂ«rbashkĂ«t tĂ« Yandex.Cloud. Detyrat shkruhen nĂ« njĂ« mĂ«nyrĂ« qĂ« ato mund tĂ« ndĂ«rpriten nĂ« çdo moment dhe pastaj tĂ« rinisin. Kjo siguron shkallĂ«zim, ripĂ«rsĂ«ritshmĂ«ri dhe regjistrueshmĂ«ri tĂ« operacioneve.
Si rezultat, detyra nga API do tĂ« bĂ«jĂ« njĂ« kĂ«rkesĂ« nĂ« shĂ«rbimin e kontrollorit tĂ« balancuesve, i shkruar nĂ« Go. Ai mund tĂ« shtojĂ« dhe fshijĂ« balancuesit, tĂ« ndryshojĂ« pĂ«rbĂ«rjen e backend-eve dhe konfigurimet.Â
ShĂ«rbimi ruan gjendjen e tij nĂ« Yandex Database â njĂ« databazĂ« tĂ« shpĂ«rndarĂ« tĂ« menaxhuar, qĂ« shumĂ« shpejt do ta pĂ«rdorni edhe ju. NĂ« Yandex.Cloud, siç e kemi thĂ«nĂ« mĂ« parĂ«, veprojmĂ« sipas konceptit dog food: nĂ«se ne vetĂ« pĂ«rdorim shĂ«rbimet tona, atĂ«herĂ« edhe klientĂ«t tanĂ« do tĂ« gĂ«zojnĂ« t'i pĂ«rdorin ato. Yandex Database Ă«shtĂ« njĂ« shembull i implementimit tĂ« njĂ« koncepti tĂ« tillĂ«. Ne ruajmĂ« tĂ« dhĂ«nat tona nĂ« YDB dhe nuk kemi nevojĂ« tĂ« mendojmĂ« pĂ«r mirĂ«mbajtjen dhe shkallĂ«zimin e databazĂ«s: kĂ«to probleme janĂ« zgjidhur pĂ«r ne, ne e pĂ«rdorim databazĂ«n si njĂ« shĂ«rbim. Kthehemi te kontrollori i balancuesit. Detyra e tij Ă«shtĂ« tĂ« ruajĂ« informacionin rreth balancuesit, tĂ« dĂ«rgojĂ« detyrĂ«n e kontrollit tĂ« gatishmĂ«risĂ« sĂ« makinĂ« virtuale nĂ« kontrollorin e healthcheck.
Kontrollori i healthcheck
Healthcheck controller
Ai merr kërkesa për të ndryshuar rregullat e kontrollit, i ruan ato në YDB, shpërndan detyrat në nodet e kontrollit të shëndetit dhe agregon rezultatet, të cilat më pas ruhen në bazë dhe dërgohen në controller-in e balancuesit të ngarkesës. Ai, nga ana e tij, dërgon një kërkesë për të ndryshuar përbërjen e klasterit në data plane te loadbalancer-node, për të cilin do flas më poshtë.
Le të flasim më në detaje për kontrollin e shëndetit. Ato mund të ndahen në disa klasa. Kontrolloret kanë kritere të ndryshme suksesi. Kontrolloret TCP kërkojnë që të vendoset me sukses një lidhje brenda një periudhe të caktuar.
Kontrolloret ndryshojnĂ« gjithashtu sipas klasĂ«s sĂ« veprimit â ato mund tĂ« jenĂ« aktive ose pasive. Kontrolloret pasive thjesht ndjekin atĂ« qĂ« ndodh me trafikun, pa bĂ«rĂ« ndonjĂ« veprim tĂ« veçantĂ«. Ky funksionim nuk funksionon shumĂ« mirĂ« mbi L4, pasi varet nga logjika e protokolleve tĂ« niveleve mĂ« tĂ« larta: mbi L4 nuk ka informacion nĂ«se operacioni ka zgjatur shumĂ« ose nĂ«se pĂ«rfundimi i lidhjes ka qenĂ« i mirĂ« apo i keq. Kontrolloret aktive kĂ«rkojnĂ« qĂ« balancuesi tĂ« dĂ«rgojĂ« kĂ«rkesa te çdo instancĂ« serveri.
Shumica e balancuesve të ngarkesës kryejnë kontrolle të 'jetësisë' vetë. Ne në Cloud kemi vendosur të ndajmë këto pjesë të sistemit për të përmirësuar shkallëzueshmërinë. Ky qasje do të na mundësojë të rrisim numrin e balancuesve, duke mbajtur numrin e kërkesave për kontroll të shëndetit të shërbimeve. Kontrolloret kryhen nga nodet e veçanta të kontrollit të shëndetit, të cilat janë të ndara dhe të replikueshme për qëllimet e kontrollit. Nuk duhet të bëhen kontrolle nga një host, pasi ai mund të dështojë. Në këtë rast, nuk do të marrim statusin e instancave që ai ka kontrolluar. Ne kryejmë kontrolle të çdo instancave me të paktën tre nodet të kontrollit të shëndetit. Qëllimet e kontrolleve shpërndahen midis nodave nëpërmjet algoritmeve të hash-it konsistent.
Ndara balancimi dhe kontrolli i shëndetit mund të çojë në probleme. Nëse nodet e kontrollit të shëndetit bëjnë kërkesa te një instancë, duke kaluar balancuesin (i cili në atë moment nuk është duke shërbyer trafikun), ndodh një situatë e çuditshme: burimi duket i gjallë, por trafiku nuk do të arrijë te ai. Ne e zgjidhim këtë problem kështu: garantimisht e dërgojmë trafikun e kontrollit të shëndetit përmes balancuesve. Me fjalë të tjera, skema e ndihmës së paketave me trafikun nga klientët dhe nga kontrolli i shëndetit ndryshon minimalisht: në të dy rastet, paketat do të arrijnë te balancuesit, të cilët do t'i dërgojnë ato te burimet e synuara.
Dallimi është se klientët bëjnë kërkesa në VIP, ndërsa kontrolloret e shëndetit i drejtohen çdo RIP-i të veçantë. Keto krijon një problem interesant: ne ofrojmë mundësi përdoruesve tanë për të krijuar burime në rrjeta IP të errëta. Imagjinoni se ka dy pronarë të ndryshëm të reve, të cilët kanë fshehur shërbimet e tyre pas balancuesve. Secili prej tyre ka burime në nënrrjetin 10.0.0.1/24, me adresa të njëjta. Duhet të jemi në gjendje t'i dallojmë ato ndryshe, dhe këtu duhet të thellojmë në strukturën e rrjetit virtual të Yandex.Cloud. Detajet më të mira do të mësosh në , që tani është e rëndësishme për ne që rrjeti është me shumë nivele dhe ka në të tunel që mund të dallohet sipas identifikuesit të nënrrjetit.
Nodet e kontrollit të shëndetit i drejtohen balancuesve me një lloj adrese quasi-IPv6. Adresa quasi-IPv6 është një adresë IPv6, e cila ka inkuadruar një adresë IPv4 dhe identifikuesin e nënrrjetit të përdoruesit. Trafiku arrin te balancuesi, ai e nxjerr adresën IPv4 të burimit, zëvendëson IPv6 me IPv4 dhe dërgon paketën në rrjetin e përdoruesit.
Trafiku i kundërt shkon po ashtu: balancuesi sheh se destinacioni është një rrjet i errët nga kontrollet e shëndetit, dhe e konverton IPv4 në IPv6.
VPP â zemra e data plane
Balancuesi realizohet nĂ« teknologjinĂ« Vector Packet Processing (VPP) â njĂ« kornizĂ« nga Cisco pĂ«r pĂ«rpunimin e paketave tĂ« trafikut rrjetit. NĂ« rastin tonĂ«, korniza punon mbi bibliotekĂ«n e menaxhimit tĂ« pajisjeve rrjetĂ«rore nĂ« hapĂ«sirĂ« pĂ«rdoruese â Data Plane Development Kit (DPDK). Kjo siguron performancĂ« tĂ« lartĂ« tĂ« pĂ«rpunimit tĂ« paketave: nĂ« kernel ndodhin shumĂ« mĂ« pak ndĂ«rprerje, nuk ka kalime konteksti midis hapĂ«sirĂ«s sĂ« kernelit dhe hapĂ«sirĂ«s pĂ«rdoruese.Â
VPP shkon edhe më larg dhe nxjerr më shumë performancë nga sistemi duke bashkuar paketat në bache. Rritja e performancës ndodh falë përdorimit agresiv të cache-ve të procesorëve modernë. Përdoren si cache-t e të dhënave (paketat përpunohen 'në vektora', të dhënat qëndrojnë afër njëra-tjetrës), ashtu edhe cache-t e instruksioneve: në VPP, përpunimi i paketave ndjek një graf, në nyjet e të cilit ndodhen funksionet që zbatojnë një qëllim të vetëm.
Për shembull, përpunimi i paketave IP në VPP ndodh në këtë rend: së pari, në nyjën e analit, kryhet analiza e titujve të paketave, pastaj ato dërgohen në nyjën që i përcjell paketat më tej sipas tabelave të routing-ut.
Pak hardkor. AutorĂ«t e VPP-eve nuk pranojnĂ« kompromis nĂ« pĂ«rdorimin e cache-ve tĂ« procesorit, prandaj kodi tipik pĂ«r pĂ«rpunimin e vektorĂ«ve tĂ« paketave pĂ«rmban vektorizim manual: ka njĂ« cikĂ«l pĂ«rpunimi, ku trajtohet situata tipike "kemi katĂ«r paketa nĂ« radhĂ«", pastaj â e njĂ«jta gjĂ« pĂ«r dy, pastaj â pĂ«r njĂ«. Shpesh pĂ«rdoren udhĂ«zime prefetch qĂ« ngarkojnĂ« tĂ« dhĂ«nat nĂ« cache pĂ«r tĂ« pĂ«rshpejtuar qasjen nĂ« to gjatĂ« iterares sĂ« ardhshme.
n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// ...
while (n_left_from >= 4 && n_left_to_next >= 2)
{
// përpunimi i paketave të shumta njëherësh
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
// ...
/* Prefetch iteracioni i ardhshëm. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
// praktikisht përpunoni të dhënat
/* verifikoni enqueue-imet spekulative, ndoshta ndërro situatën aktuale të kuadrit të ardhshëm */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
while (n_left_from > 0 && n_left_to_next > 0)
{
// përpunimi i paketave një nga një
}
// grumbulli i përpunuar
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}Pra, Healthchecks i drejtohen VPP-së përmes IPv6, e cila i konverton në IPv4. Kjo realizohet nga nyja e grafit, të cilën e quajmë NAT algoritmik. Për trafikun e kthyer (dhe konvertimin nga IPv6 në IPv4) ka një nyjë të ngjashme NAT algoritmik.
Trafiku direkt nga klientĂ«t e balancuesit kalon pĂ«rmes nyjave tĂ« grafit, tĂ« cilat kryejnĂ« balancimin vetĂ«.Â
Nyja e parĂ« â sesionet e ngjashme. Ajo ruan njĂ« hash nga pĂ«r sesionet e vendosura. 5-tuple pĂ«rfshin adresĂ«n dhe portin e klientit, nga i cili dĂ«rgohet informacioni, adresĂ«n dhe portin e burimeve tĂ« disponueshme pĂ«r tĂ« pranuar trafikun, si dhe protokollin rrjetor.Â
Hashi nga 5-tuple na ndihmon tĂ« kryejmĂ« mĂ« pak llogaritje nĂ« nyjĂ«n e ardhshme tĂ« heshit tĂ« qĂ«ndrueshĂ«m, si dhe tĂ« pĂ«rballojmĂ« mĂ« mirĂ« ndryshimin e listĂ«s sĂ« burimeve pas balancuesit. Kur njĂ« paketĂ« vjen nĂ« balancues pĂ«r tĂ« cilĂ«n nuk ka sesion, ajo dĂ«rgohet nĂ« nyjĂ«n e heshit tĂ« qĂ«ndrueshĂ«m. Atje ndodh balancimi pĂ«rmes heshit tĂ« qĂ«ndrueshĂ«m: ne zgjedhim njĂ« burim nga lista e burimeve "aktive". MĂ« pas paketat dĂ«rgohen nĂ« nyjĂ«n NAT, e cila realizon zĂ«vendĂ«simin e adresĂ«s sĂ« destinacionit dhe ribĂ«rjen e kontrolleve tĂ« shumave. Siç shihni, ne ndjekim rregullat e VPP-sĂ« â ngjashmĂ«ria me ngjashmĂ«rinĂ«, grumbullojmĂ« llogaritje tĂ« ngjashme pĂ«r tĂ« rritur efikasitetin e cache-ve tĂ« procesorit.
Hesh i qëndrueshëm
Pse e zgjodhĂ«m atĂ« dhe çfarĂ« Ă«shtĂ« nĂ« tĂ« vĂ«rtetĂ«? PĂ«r tĂ« filluar, le tĂ« shqyrtojmĂ« problemin e mĂ«parshĂ«m â zgjedhjen e burimit nga lista.Â
Me heshin e pasigurt, llogaritet heshi nga paketa hyrëse, dhe burimi zgjidhet nga lista sipas mbetjeve nga ndarja e këtij heshit me numrin e burimeve. Sa kohë që lista mbetet e pandryshuar, një skemë e tillë funksionon mirë: ne gjithmonë dërgojmë paketat me të njëjtin 5-tuple në të njëjtin instancë. Nëse, për shembull, ndonjë burim ndalon së përgjigjuri ndaj healthchecks, atëherë për një pjesë të madhe të heshit, zgjedhja do të ndryshojë. Klienti do të ketë TCP-ngërç: paketa e cila më parë shkonte në instancën A, mund të fillojë të shkojë në instancën B, e cila nuk e njeh sesionin për këtë paketë.
Heshi i qëndrueshëm zgjidh problemin e përshkruar. Më lehtë është të shpjegohet kjo koncept në këtë mënyrë: imagjinoni se keni një brez, mbi të cilin shpërndani burimet sipas heshit (për shembull, sipas IP:port). Zgjedhja e burimit është një kthesë e rrotës në një kënd që përcaktohet nga hesh nga paketa.
Kështu, minimizohet rinovimi i trafikut gjatë ndryshimeve në përbërjen e burimeve. Fshirja e një burimi do të ndikojë vetëm në atë pjesë të brezit të heshit të qëndrueshëm, ku ndodhej ky burim. Shtimi i një burimi gjithashtu ndryshon shpërndarjen, por ne kemi një nyjë për sesionet e ngjashme, e cila lejon të mos kalojmë sesionet e vendosura në burime të reja.
Ne shqyrtuam se çfarĂ« ndodh me trafikun direkt midis balancuesit dhe burimeve. Tani le tĂ« shqyrtojmĂ« trafikun e kthyer. Ai ndiqet sipas tĂ« njĂ«jtĂ«s skemĂ« si trafiku i healthchecks â pĂ«rmes NAT algoritmik, dmth pĂ«rmes NAT 44 pĂ«r trafikun e klientĂ«ve dhe pĂ«rmes NAT 46 pĂ«r trafikun e healthchecks. Ne ndjekim skemĂ«n tonĂ«: unifikojmĂ« trafikun e healthchecks dhe trafikun real tĂ« pĂ«rdoruesve.
Loadbalancer-node dhe komponentët në mbledhje
Informacioni pĂ«r arkitekturat e ekuilibrit dhe burimeve nĂ« VPP jep shĂ«rbimi lokal â loadbalancer-node. Ai subscribohet nĂ« rrjedhĂ«n e ngjarjeve nga loadbalancer-controller, Ă«shtĂ« i aftĂ« tĂ« ndihmojĂ« nĂ« ndĂ«rtimin e diferencĂ«s midis gjendjes aktuale tĂ« VPP dhe gjendjes targete tĂ« marrĂ« nga kontrolluesi. Ne kemi njĂ« sistem tĂ« mbyllur: ngjarjet nga API vijnĂ« te kontrolluesi i balancuesve, i cili i jep detyra kontrolluesit tĂ« healthcheck pĂ«r tĂ« verifikuar 'jetĂ«sinĂ«' e burimeve. Ky, nga ana e tij, vendos detyra nĂ« healthcheck-node dhe aggregon rezultatet, tĂ« cilat pastaj i kthen pĂ«rsĂ«ri te kontrolluesi i balancuesve. Loadbalancer-node subscribohet nĂ« ngjarjet nga kontrolluesi dhe ndryshon gjendjen e VPP. NĂ« njĂ« sistem tĂ« tillĂ«, çdo shĂ«rbim di vetĂ«m atĂ« qĂ« i nevojitet pĂ«r shĂ«rbimet e afĂ«rta. Numri i lidhjeve Ă«shtĂ« i kufizuar, dhe kemi mundĂ«sinĂ« tĂ« operojmĂ« dhe tĂ« shkallĂ«zojmĂ« lehtĂ«sisht segmente tĂ« ndryshme.
Cilat pyetje arritëm t'i shmangim
TĂ« gjitha shĂ«rbimet tona nĂ« control plane janĂ« shkruar nĂ« Go dhe karakterizohen nga performancĂ« e lartĂ« pĂ«r shkallĂ«zim dhe besueshmĂ«ri. NĂ« Go ka shumĂ« biblioteka tĂ« hapura pĂ«r ndĂ«rtimin e sistemeve tĂ« shpĂ«rndara. Ne aktivisht pĂ«rdorim GRPC, tĂ« gjitha komponentĂ«t pĂ«rmbajnĂ« njĂ« implementim tĂ« hapur tĂ« zbulimit tĂ« shĂ«rbimeve â shĂ«rbimet tona ndjekin funksionimin e njĂ«ra-tjetrĂ«s, mund tĂ« ndryshojnĂ« pĂ«rbĂ«rjen e tyre nĂ« mĂ«nyrĂ« dinamike, dhe e kemi lidhur kĂ«tĂ« me balancimin GRPC. Po ashtu pĂ«r metrikat pĂ«rdorim njĂ« zgjidhje tĂ« hapur. NĂ« data plane arritĂ«m njĂ« performancĂ« tĂ« shkĂ«lqyer dhe njĂ« rezervĂ« tĂ« madhe burimesh: doli shumĂ« e vĂ«shtirĂ« tĂ« ndĂ«rtojmĂ« njĂ« ambjent ku tĂ« arrijmĂ« performancĂ«n e VPP, e jo tĂ« kartĂ«s rrjetĂ«s.
Problemet dhe zgjidhjet
ĂfarĂ« nuk funksionoi shumĂ« mirĂ«? NĂ« Go menaxhimi i memories Ă«shtĂ« automatik, por ende ndodhin rrjedhje memoriesh. MĂ«nyra mĂ« e thjeshtĂ« pĂ«r t'i pĂ«rballuar ato Ă«shtĂ« tĂ« nisni goroutines dhe tĂ« mos harroni tâi pĂ«rfundoni ato. PĂ«rfundimi: mbani nĂ«n kontroll pĂ«rdorimin e memories nĂ« programet Go. Shpesh, njĂ« indikator i mirĂ« Ă«shtĂ« numri i goroutines. NĂ« kĂ«tĂ« histori ka edhe njĂ« pĂ«rfitim: nĂ« Go Ă«shtĂ« e lehtĂ« tĂ« merrni tĂ« dhĂ«nat pĂ«r runtime â pĂ«r pĂ«rdorimin e memories, pĂ«r numrin e goroutines tĂ« nisura dhe pĂ«r shumĂ« parametra tĂ« tjerĂ«.
PĂ«r mĂ« tepĂ«r, Go mund tĂ« mos jetĂ« zgjedhja mĂ« e mirĂ« pĂ«r testet funksionale. Ato janĂ« mjaft tĂ« zĂ«na, dhe qasja standarte âtĂ« nisĂ«sh gjithçka nĂ« CI nĂ« grupeâ nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme pĂ«r to. Problemi Ă«shtĂ« se testet funksionale kĂ«rkojnĂ« mĂ« shumĂ« burime, dhe pĂ«r to ndodhin vĂ«rtet momente skadimi. KĂ«shtu, testet mund tĂ« pĂ«rfundojnĂ« me dĂ«shtim, pasi CPU Ă«shtĂ« e angazhuar me testet e njĂ«sive. PĂ«rfundimi: pĂ«r sa mundeni, kryeni testet âe rĂ«ndaâ veçmas nga testet e njĂ«sive.Â
Arkitektura e ngjarjeve të mikrosherbimeve është më e komplikuar se ajo e monolitit: kërkimi i log-eve në dhjetëra makina të ndryshme nuk është shumë i rehatshëm. Përfundimi: nëse do të ndërtoni mikrosherbime, mendoni menjëherë për gjurmimin.
Planet tona
Ne do tĂ« lançojmĂ« njĂ« balancues tĂ« brendshĂ«m, njĂ« balancues IPv6, do tĂ« shtojmĂ« mbĂ«shtetje pĂ«r skenarĂ«t Kubernetes, do tĂ« vazhdojmĂ« tĂ« sharmojmĂ« shĂ«rbimet tona (aktualisht janĂ« tĂ« sharmuar vetĂ«m healthcheck-node dhe healthcheck-ctrl), do tĂ« shtojmĂ« healthchecks tĂ« rinj, si dhe do tĂ« zbatojmĂ« njĂ« agregim tĂ« mençur tĂ« kontrollimeve. Po ashtu, presim tĂ« bĂ«jmĂ« shĂ«rbimet tona edhe mĂ« tĂ« pavarura â pĂ«r tâu komunikuar jo drejtpĂ«rdrejt me njĂ«ri-tjetrin, por nĂ«pĂ«rmjet njĂ« radhĂ« mesazhesh. NĂ« Cloud sapo ka dalĂ« njĂ« shĂ«rbim SQS-kompatibil .
Kohët e fundit ndodhi lançimi publik i Yandex Load Balancer. Eksploroni shërbimin, menaxhoni balancuesit në mënyrën që preferoni dhe rrisni disponueshmërinë e projekteve tuaja!
Burimi: habr.com
