PĂ«rshĂ«ndetje, unĂ« jam Sergey Ylantsev, po zhvilloj nĂ« Yandex.Cloud. MĂ« parĂ« kam drejtuar zhvillimin e L7-balancuesit tĂ« portalit tĂ« Yandex â kolegĂ«t shaka se çfarĂ«do qĂ« tĂ« bĂ«j, rezulton si njĂ« balancues. Do t'u tregoj lexuesve tĂ« HabrĂ«s si duhet menaxhuar ngarkesa nĂ« platformĂ«n cloud, si e shohim mjetin ideal pĂ«r tĂ« arritur kĂ«tĂ« qĂ«llim dhe si po ecim drejt ndĂ«rtimit tĂ« kĂ«tij mjeti.
Për fillim, le të prezantojmë disa terma:
- VIP (Virtual IP) â adresa IP e balancuesit
- Server, backend, instancĂ« â makinĂ« virtuale me aplikacionin e ndjekur
- RIP (Real IP) â adresa IP e serverit
- Kontrolli i shĂ«ndetit â kontrolli i gatishmĂ«risĂ« sĂ« serverit
- Zona e disponueshmĂ«risĂ«, Availability Zone, AZ â infrastrukturĂ« e izoluar nĂ« qendrĂ«n e tĂ« dhĂ«nave
- Rajoni â kombinim i AZ-ve tĂ« ndryshme
Balancuesit e ngarkesës zgjidhin tri detyra kryesore: kryejnë balancimin vetë, përmirësojnë disponueshmërinë e shërbimit dhe e thjeshtojnë shkallëzimin e tij. Disponueshmëria sigurohet përmes menaxhimit automatik të trafikut: balancuesi ndjek gjendjen e aplikacionit dhe përjashton nga balancimi instancat që nuk kalojnë testin e gjallërisë. Shkallëzimi sigurohet përmes shpërndarjes së barabartë të ngarkesës në instanca, si dhe azhornimit të listës së instancave në fluks. Nëse balancimi nuk është mjaft i barabartë, disa nga instancat do të marrin ngarkesë që tejkalon kufijtë e tyre të funksionimit dhe shërbimi do të bëhet më pak i besueshëm.
Balancuesi i ngarkesës shpesh klasifikohet sipas nivelit të protokollit nga modeli OSI, mbi të cilin funksionon. Balancuesi i Cloud-it punon në nivelin TCP, që korrespondon me nivelin e katërt, L4.
Të kalojmë në një përmbledhje të arkitekturës së balancuesit të Cloud-it. Do të rrisim gradualisht nivelin e detajeve. Ne i ndajmë komponentët e balancuesit në tri klasa. Klasa e config plane kujdeset për ndërveprimin me përdoruesin dhe ruan gjendjen e dëshiruar të sistemit. Control plane ruan gjendjen aktuale të sistemit dhe menaxhon sistemet nga klasa e data plane, që janë përgjegjëse për dërgimin e trafikut nga klientët në instancat tuaja.
Data plane
Trafiku kalon nĂ« pajisje tĂ« shtrenjta tĂ« quajtura routera kufitarĂ«. PĂ«r tĂ« rritur qĂ«ndrueshmĂ«rinĂ«, nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash punojnĂ« njĂ«kohĂ«sisht disa prej kĂ«tyre pajisjeve. MĂ« pas trafiku kalon nĂ« balancuesit, tĂ« cilĂ«t pĂ«r klientĂ«t shpallin njĂ« adresĂ« IP anycast nĂ« tĂ« gjitha AZ pĂ«rmes BGP.Â
Trafiku transmetohet pĂ«rmes ECMP â kjo Ă«shtĂ« njĂ« strategji rrugĂ«zimi, sipas sĂ« cilĂ«s mund tĂ« ketĂ« disa rrugĂ« po aq tĂ« mira pĂ«r nĂ« destinacion (nĂ« kĂ«tĂ« rast destinacioni do tĂ« jetĂ« adresa IP e destinacionit) dhe paketat mund tĂ« dĂ«rgohen nĂ« çdo njĂ«rĂ«n prej tyre. Gjithashtu, ne mbĂ«shtesim punĂ«n nĂ« disa zona tĂ« disponueshme sipas skemĂ«s sĂ« mĂ«poshtme: shpallim adresĂ«n nĂ« secilĂ«n nga zonat, trafiku kalon nĂ« mĂ« tĂ« afĂ«rt dhe mĂ« pas nuk del jashtĂ« saj. MĂ« tutje nĂ« postim do tĂ« shqyrtojmĂ« mĂ« nĂ« detaje se çfarĂ« ndodh me trafik.
Config plane
Â
Komponenti kryesor i config plane Ă«shtĂ« API, pĂ«rmes tĂ« cilit kryhen operacionet kryesore me balancuesit: krijimi, fshirja, ndryshimi i pĂ«rbĂ«rjes sĂ« instancave, marrja e rezultateve tĂ« kontrollit tĂ« shĂ«ndetit etj. Nga njĂ«ra anĂ«, kjo Ă«shtĂ« njĂ« REST API, ndĂ«rsa nga ana tjetĂ«r, ne nĂ« Cloud shpesh pĂ«rdorim kornizĂ«n gRPC, pĂ«r kĂ«tĂ« arsye ne "pĂ«rkthejmĂ«" REST nĂ« gRPC dhe pastaj pĂ«rdorim vetĂ«m gRPC. Ădo kĂ«rkesĂ« çon nĂ« krijimin e njĂ« serie tareas asinkrone idempotente, tĂ« cilat ekzekutohen nĂ« njĂ« pool tĂ« pĂ«rbashkĂ«t punĂ«torĂ«sh tĂ« Yandex.Cloud. TĂ« gjitha detyrat shkruhen nĂ« mĂ«nyrĂ« qĂ« mund tĂ« pezullohen çdoherĂ« dhe pastaj tĂ« rikthehen. Kjo siguron shkallĂ«zueshmĂ«ri, pĂ«rsĂ«ritshmĂ«ri dhe regjistrueshmĂ«ri tĂ« operacioneve.
Si rezultat, njĂ« detyrĂ« nga API do tĂ« bĂ«jĂ« njĂ« kĂ«rkesĂ« nĂ« shĂ«rbimin kontrollues tĂ« balancuesve, i cili Ă«shtĂ« shkruar nĂ« Go. Ai mund tĂ« shtojĂ« dhe fshijĂ« balancuesit, tĂ« ndryshojĂ« pĂ«rbĂ«rjen e backend-Ă«ve dhe parametrat.Â
ShĂ«rbimi ruan gjendjen e tij nĂ« Yandex Database â njĂ« DB tĂ« menaxhuar tĂ« shpĂ«rndarĂ«, qĂ« shumĂ« shpejt do tĂ« mund ta pĂ«rdorni edhe ju. NĂ« Yandex.Cloud, siç e thamĂ« mĂ« parĂ« , vepron koncepti i 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 realizimit tĂ« njĂ« koncepti tĂ« tillĂ«. Ne ruajmĂ« tĂ« dhĂ«nat tona nĂ« YDB, dhe ne nuk e kemi problem me mirĂ«mbajtjen dhe shkallĂ«zimin e bazĂ«s: kĂ«to probleme janĂ« zgjidhur pĂ«r ne, ne pĂ«rdorim bazĂ«n si njĂ« shĂ«rbim.
Kthemi te kontrolluesi i balancuesit. Detyra e tij është të ruajë informacionin mbi balancuesin, të dërgojë detyrën për kontrollimin e gatishmërisë së makinerisë virtuale në kontrolluesin e healthcheck.
Kontrolluesi i healthcheck
Ai merr kërkesa për ndryshimin e rregullave të kontrollit, i ruan ato në YDB, shpërndan detyrat në node-t e healthcheck dhe agregon rezultatet, të cilat më pas ruhen në bazë dhe dërgohen në kontrolluesin e balancuesit. Ky i fundit, 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 të flas më poshtë.
Të flasim më në detaje rreth healthchecks. Ato mund të ndahen në disa klasa. Kontrollimi ka kritere të ndryshme suksesi. Kontrollimet TCP duhet të krijojnë me sukses një lidhje brenda një kohe të caktuar. Kontrollimet HTTP kërkojnë si krijimin e lidhjes, ashtu edhe marrjen e një përgjigje me status-kod 200.
Gjithashtu, kontrollimet dallohen nga klasa e veprimitâato janĂ« aktive dhe pasive. Kontrollimet pasive thjesht monitorojnĂ« atĂ« qĂ« ndodh me trafik, pa bĂ«rĂ« veprime tĂ« veçanta. Kjo nuk funksionon shumĂ« mirĂ« nĂ« L4, pasi varet nga logjika e protokolleve tĂ« nivelit mĂ« tĂ« lartĂ«: nĂ« L4 nuk ka informacion se sa kohĂ« zgjati operacioni, dhe nĂ«se pĂ«rfundimi i lidhjes ishte i mirĂ« apo i keq. Kontrollimet aktive kĂ«rkojnĂ« qĂ« balancuesi tĂ« dĂ«rgojĂ« kĂ«rkesa nĂ« çdo instancĂ« tĂ« serverit.
Shumica e balancuesve të ngarkesës kryejnë vetë kontrollimet e "gjallërisë". Ne në Cloud kemi vendosur të ndajmë këto pjesë të sistemit për të rritur shkallëzueshmërinë. Ky qasje do të na lejojë të rritim numrin e balancuesve, duke mbajtur të pandryshuar numrin e kërkesave të healthcheck për shërbimin. Kontrollimet kryhen nga node të veçanta të healthcheck, të cilat janë të shard-uara dhe replikohen për objektet e kontrollit. Nuk është e mundur të kryhen kontrollime nga një host i vetëm, pasi ai mund të dështojë. Atëherë ne nuk do të marrim gjendjen e instancave të verifikuara prej tij. Ne kryejmë kontrollime të çdo instancë nga të paktën tre node të healthcheck. Objektet e kontrollit ne i shartojmë mes node-ve duke përdorur algoritmet e hashing konsistent.
Shqetësimi i ndarjes së balancimit dhe kontrollit të gjendjes mund të sjellë probleme. Nëse kontrolli i gjendjes bën kërkesa ndaj instancës, duke anashkaluar balancuesin (i cili nuk po shërben trafikun në atë moment), ndodh një situatë e çuditshme: burimi duket se është aktiv, por trafiku nuk arrin deri te ai. Ne e zgjidhim këtë problem kështu: sigurojmë që trafiku i kontrollit të gjendjes kalon përmes balancuesve. Me fjalë të tjera, skema e transferimit të paketave me trafik nga klientët dhe nga kontrollet e gjendjes ndryshon minimalisht: në të dy rastet, paketat do të arrijnë te balancuesit, të cilët do t'i dërgojnë ato te burimet përkatëse.
Dallimi është se klientët bëjnë kërkesa në VIP, ndërsa kontrollet e gjendjes i drejtohen çdo RIP-i të veçantë. Këtu lind një problem interesant: ne u japim përdoruesve tanë mundësinë për të krijuar burime në rrjetet IP të errëta. Imagjinoni se ka dy pronarë të ndryshëm të reve, të cilët fshihen pas balancuesve. Secili prej tyre ka burime në nënrrjetin 10.0.0.1/24, përkatësisht me adresat e njëjta. Duhet të dimë si t'i dallojmë ata, dhe këtu duhet të thellohemi në ndërtimin e rrjetit virtual të Yandex.Cloud. Detajet është më mirë të mësohen në , për ne tani është e rëndësishme se rrjeti është shumëkatësor dhe ka në vetvete tunele, të cilat mund të dallohen nga id e nënrrjetit.
Kontrolluesit e gjendjes i drejtohen balancuesve duke përdorur atë që quhet adresat e kvasit IPv6. Adresa kvas është një adresë IPv6, brenda së cilës është e fshehur një adresë IPv4 dhe id e nënrrjetit të përdoruesit. Trafiku arrin te balancuesi, i cili nxjerr adresën IPv4 të burimit, zëvendëson IPv6 me IPv4 dhe dërgon paketën në rrjetin e përdoruesit.
Trafiku përkatës shkon po ashtu: balancuesi sheh se destinacioni është rrjeti i errët nga kontrolluesit e gjendjes, dhe konverton IPv4 në IPv6.
VPP - zemra e planeve të dhënave
Balancuesi Ă«shtĂ« implementuar mbi teknologjinĂ« Vector Packet Processing (VPP) - njĂ« sistem nga Cisco pĂ«r pĂ«rpunimin e paketave tĂ« trafikut rrjet. NĂ« rastin tonĂ«, struktura punon mbi bibliotekĂ«n e menaxhimit tĂ« pajisjeve rrjet nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit - Data Plane Development Kit (DPDK). Kjo siguron njĂ« performancĂ« tĂ« lartĂ« nĂ« pĂ«rpunimin e pakove: nĂ« bĂ«rthamĂ« ndodhin shumĂ« mĂ« pak ndĂ«rprerje, nuk ka kalime konteksti midis hapĂ«sirĂ«s sĂ« bĂ«rthamĂ«s dhe hapĂ«sirĂ«s sĂ« pĂ«rdoruesit.Â
VPP shkon edhe më tej dhe nxjerr më shumë performancë nga sistemi duke bashkuar paketat në grupe. Rritja e performancës arrihet falë përdorimit agresiv të kesheve të procesorëve modernë. Përdoren si keshet e të dhënave (paketat përpunohen "në vektorë", të dhënat janë afër njëra-tjetrës), ashtu edhe keshet e instrukcioneve: në VPP, përpunimi i paketave ndjek një graf, në nyjat e të cilit ndodhen funksione që kryejnë një detyrë.
Për shembull, përpunimi i paketave IP në VPP ndodh në këtë rend: fillimisht, në nyjën e shqyrtimit, bëhet analiza e kokave të paketave, dhe pastaj ato dërgohen në një nyje që i përcjell paketat më tej sipas tabelave të rrugëve.
Pak hardcore. Autorët e VPP nuk pranojnë kompromise në përdorimin e kesheve të procesorit, prandaj kodi tipik i përpunimit të vektorëve të paketave përmban vektorizim manual: ka një cikël përpunimi, ku trajtohet situata e tipit "ne kemi katër paketa në radhë", më pas - e njëjta gjë për dy, e më pas - për një. Shpesh përdoren instrukcionet prefetch, të cilat ngarkojnë të dhëna në keshe për të nxitur aksesin në to në iteracionet e 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 disa paketeve njëkohësisht
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
\/\/ ...
\/\* Prefetch iteracioni i ardhshëm. *\/\n {
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);
}
\/\/ në të vërtetë përpunoni të dhënat
\/\* verifikoni radhitjet spekulative, ndoshta kaloni në kornizën aktuale tjetër *\/\n 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 drejtohen në IPv6 te VPP, i cili i kthen ato në IPv4. Kjo bëhet nga nyja e grafit, e cila ne e quajmë NAT algoritmik. Për trafikun e kundërt (dhe transformimin nga IPv6 në IPv4) ka një nyje të ngjashme të NAT algoritmik.
Trafiku direkt nga klientĂ«t e balancuesit kalon pĂ«rmes nyjave tĂ« grafit, tĂ« cilat kryejnĂ« balancimin vetĂ«.Â
Nyja e parĂ« â seancat e ngjashme. Ajo ruan njĂ« hash nga pĂ«r seancat e instaluara. 5-tuple pĂ«rfshin adresĂ«n dhe portin e klientit nga i cili dĂ«rgohet informacioni, adresĂ«n dhe portet e burimeve nĂ« dispozicion pĂ«r pranimin e trafikĂ«ve, si dhe protokollin rrjetor.Â
Hash-i i 5-tuple na ndihmon të kryejmë më pak llogaritje në nyjën tjetër të heshit konsistent, si dhe të përpunojmë më mirë ndryshimin e listës së burimeve para balancuesit. Kur një pako mb arrives në balancues, për të cilin nuk ka seancë, ajo dërgohet në nyjën e heshit konsistent. Atje ndodh balancimi përmes heshit konsistent: ne zgjedhim burimin nga lista e burimeve 'të gjalla' të disponueshme. Pastaj paketat dërgohen në nyjën NAT, e cila bën përmbledhjen e adresës së destinacionit dhe rikalibrimin e kontrolleve. Siç e shihni, ne ndjekim rregullat VPP - ngjashmja me ngjashmja, grupojmë llogaritjet e ngjashme për të rritur efikasitetin e caches të procesorëve.
Hesh i konsistent
Pse e zgjodhĂ«m pikĂ«risht kĂ«tĂ« dhe çfarĂ« Ă«shtĂ« kjo nĂ« tĂ« vĂ«rtetĂ«? Fillimisht, le tĂ« shqyrtojmĂ« detyrĂ«n e mĂ«parshme - zgjedhjen e burimit nga lista.Â
Me heshin jo-konsistent, llogaritet hesh-i i paketës hyrëse dhe burimi zgjidhet nga lista nëpërmjet mbetjeve të ndarjes së këtij hesh-i me numrin e burimeve. Deri sa lista të mbetet e pandryshuar, kjo skemë funksionon mirë: gjithmonë dërgojmë paketat me të njëjtin 5-tuple në të njëjtin instancë. Nëse, për shembull, një burim ka ndaluar përgjigjen në kontrollet e shëndetit, atëherë për një pjesë të konsiderueshme të hesh-eve, zgjedhja do të ndryshojë. Klienti do të ndjejë ndërprerje të lidhjeve TCP: ndonjëherë, një paketë që më parë shkonte në instancën A, mund të fillojë të shkojë në instancën B, e cila nuk është e njohur me seancën për këtë paketë.
Heshi konsistent zgjidh këtë problem të përshkruar. Më së lehti, mund ta shpjegoni këtë koncept kështu: imagjinoni se keni një unazë, në të cilën shpërndani burimet sipas hesh-it (për shembull, sipas IP:port). Zgjedhja e burimit është një kthesë e rrotës në një kënd që përcaktohet nga hesh-i i paketës.
Kështu minimalizohet ri-shpërndarja e trafikëve me ndryshimin e përbërjes së burimeve. Eliminimi i një burimi do të ndikohet vetëm në atë pjesë të unazës së heshit konsistent, në të cilën ndodhej ky burim. Shtimi i një burimi gjithashtu ndryshon shpërndarjen, por ne kemi një nyjë sesionesh ngjitëse, e cila lejon që seancat e vendosura të mos kalohen në burime të reja.
Ne kemi shqyrtuar se çfarĂ« ndodh me trafikun direkt midis balancuesit dhe burimeve. Tani le tĂ« kuptojmĂ« trafikun e kthyer. Ai ndjek tĂ« njĂ«jtĂ«n skemĂ« si trafik kontrollesh â pĂ«rmes NAT algoritmik, dmth pĂ«rmes NAT 44 pĂ«r trafik klientĂ«sh dhe pĂ«rmes NAT 46 pĂ«r trafik healthcheck. Ne do tĂ« ndjekim skemĂ«n tonĂ«: unifikojmĂ« trafikun e healthcheck dhe trafikun real tĂ« pĂ«rdoruesve.
Loadbalancer-node dhe komponentët në grumbull
Informacioni mbi pĂ«rbĂ«rjen e balancuesve dhe burimeve nĂ« VPP jepet nga shĂ«rbimi lokal â loadbalancer-node. Ai subscribohet nĂ« fluxin e ngjarjeve nga loadbalancer-controller, ka aftĂ«sinĂ« tĂ« ndĂ«rtojĂ« dallimin midis gjendjes aktuale tĂ« VPP dhe gjendjes sĂ« synuar qĂ« Ă«shtĂ« marrĂ« nga kontrollori. Ne krijojmĂ« njĂ« sistem tĂ« mbyllur: ngjarjet nga API arrijnĂ« te kontrollori i balancuesit, i cili cakton detyra pĂ«r kontrollorin e healthcheck pĂ«r tĂ« kontrolluar 'jetĂ«sinĂ«' e burimeve. Ai, nga ana e tij, cakton detyra nĂ« healthcheck-node dhe agregon rezultatet, e mĂ« pas i kthen ato pĂ«rsĂ«ri te kontrollori i balancuesve. Loadbalancer-node subscribohet nĂ« ngjarjet nga kontrollori dhe ndryshon gjendjen e VPP. NĂ« njĂ« sistem tĂ« tillĂ«, çdo shĂ«rbim di vetĂ«m atĂ« qĂ« i nevojitet pĂ«r shĂ«rbimet fqinjĂ«. Numri i lidhjeve Ă«shtĂ« i kufizuar, dhe ne kemi mundĂ«sinĂ« tĂ« eksplorojmĂ« dhe tĂ« shkallĂ«zojmĂ« nĂ« mĂ«nyrĂ« tĂ« pavarur segmente tĂ« ndryshme.
Cilat pyetje arritëm të shmangim
TĂ« gjitha shĂ«rbimet tona nĂ« plane kontrolli janĂ« shkruar nĂ« Go dhe kanĂ« karakteristika tĂ« mira pĂ«r shkallĂ«zim dhe besueshmĂ«ri. NĂ« Go ka shumĂ« biblioteka opensource pĂ«r ndĂ«rtimin e sistemeve tĂ« shpĂ«rndara. Ne aktivisht pĂ«rdorim GRPC, tĂ« gjitha komponentĂ«t pĂ«rmbajnĂ« njĂ« implementim opensource tĂ« zbulimit tĂ« shĂ«rbimeve â shĂ«rbimet tona monitorojnĂ« funksionimin e njĂ«ra-tjetrĂ«s, mund tĂ« ndryshojnĂ« pĂ«rbĂ«rjen e tyre nĂ« mĂ«nyrĂ« dinamike, dhe ne e kemi lidhur kĂ«tĂ« me balancimin e GRPC. PĂ«r metrikat ne gjithashtu pĂ«rdorim njĂ« zgjidhje opensource. NĂ« plane tĂ« dhĂ«nash, ne arritĂ«m performancĂ« tĂ« denjĂ« dhe njĂ« kapacitet tĂ« madh burimesh: u duk shumĂ« e vĂ«shtirĂ« tĂ« ndĂ«rtojmĂ« njĂ« platformĂ«, nĂ« tĂ« cilĂ«n mund tĂ« pĂ«rballemi me performancĂ«n e VPP, e jo me kartĂ«n rrjetĂ«rore fizike.
Problemet dhe zgjidhjet
Cili ishte ajo që nuk funksionoi shumë mirë? Në Go, menaxhimi i memories është automatik, por humbjet e memories ndodhin ende. Mënyra më e thjeshtë për t'u marrë me to është të nisni gorutina dhe të mos harroni t'i mbyllni ato. Përfundim: mbani nën vëzhgim konsumin e memories së programeve Go. Shpesh një tregues i mirë është numri i gorutinave. Në këtë histori ka dhe një plus: në Go është e lehtë të merrni të dhëna për runtime - për konsumin e memories, për numrin e gorutinave të nisura dhe për shumë parametra të tjerë.
PĂ«rveç kĂ«saj, Go - ndoshta nuk Ă«shtĂ« zgjedhja mĂ« e mirĂ« pĂ«r testet funksionale. Ato janĂ« mjaft voluminoze, dhe qasja standarde "tĂ« nisĂ«sh gjithçka nĂ« CI me grupe" pĂ«r to nuk pĂ«rshtatet shumĂ«. E vĂ«rteta Ă«shtĂ« se testet funksionale kĂ«rkojnĂ« mĂ« shumĂ« burime, ndodhin vĂ«rtet vonesa. Si rezultat, testet mund tĂ« pĂ«rfundojnĂ« pa sukses, pasi CPU Ă«shtĂ« e angazhuar me testet e njĂ«sive. PĂ«rfundim: sa mĂ« shumĂ« qĂ« tĂ« jetĂ« e mundur, ekzekutoni testet "tĂ« rĂ«nda" veçmas nga testet e njĂ«sive.Â
Arkitektura e ngjarjeve mikroshërbore është më e komplikuar se monoliti: të kërkosh logje në dhjetëra makina të ndryshme nuk është shumë e rehatshme. Përfundim: nëse po bëni mikroshërbore, 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ë bëjmë sharding të shërbimeve tona (aktualisht vetëm healthcheck-node dhe healthcheck-ctrl janë të sharduara), do të shtojmë healthchecks të reja dhe do të realizojmë agregimin e zgjuar të kontrolleve. Po shqyrtojmë mundësinë të bëjmë shërbimet tona edhe më të pavarura - që ato të komunikohet jo drejtpërdrejt me njëra-tjetrën, por me anë të një queue mesages. Kohët e fundit është shfaqur një shërbim që është i përputhshëm me SQS në Cloud. .
Së fundmi, ndodhi publikimi i Yandex Load Balancer. Eksploroni shërbimin, menaxhoni balancuesit në mënyrën që ju përshtatet dhe rritni qëndrueshmërinë e projekteve tuaja!
Burimi: habr.com
