Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud
Sveiki, esmu Sergejs Elancevs, es attÄ«stos tÄ«kla slodzes balansētājs vietnē Yandex.Cloud. IepriekÅ” vadÄ«ju L7 balansiera izstrādi portālam Yandex ā€“ kolēģi joko, lai ko es darÄ«tu, izrādās, ka tas ir balansētājs. Es pastāstÄ«Å”u Habr lasÄ«tājiem, kā pārvaldÄ«t slodzi mākoņa platformā, ko mēs uzskatām par ideālu rÄ«ku Ŕī mērÄ·a sasniegÅ”anai un kā mēs virzāmies uz Ŕī rÄ«ka izveidi.

Vispirms ieviesīsim dažus terminus:

  • VIP (Virtual IP) - balansētāja IP adrese
  • Serveris, aizmugursistēma, instance ā€” virtuāla maŔīna, kurā darbojas lietojumprogramma
  • RIP (Real IP) - servera IP adrese
  • Healthcheck - servera gatavÄ«bas pārbaude
  • PieejamÄ«bas zona, AZ - izolēta infrastruktÅ«ra datu centrā
  • ReÄ£ions - dažādu AZ savienÄ«ba

Slodzes balansētāji atrisina trÄ«s galvenos uzdevumus: veic paÅ”u balansÄ“Å”anu, uzlabo pakalpojuma kļūdu toleranci un vienkārÅ”o tā mērogoÅ”anu. Kļūdu tolerance tiek nodroÅ”ināta, izmantojot automātisku trafika pārvaldÄ«bu: balansētājs uzrauga lietojumprogrammas stāvokli un izslēdz no balansÄ“Å”anas gadÄ«jumiem, kas neiztur dzÄ«vÄ«guma pārbaudi. MērogoÅ”ana tiek nodroÅ”ināta, vienmērÄ«gi sadalot slodzi starp gadÄ«jumiem, kā arÄ« lidojuma laikā atjauninot gadÄ«jumu sarakstu. Ja balansÄ“Å”ana nav pietiekami viendabÄ«ga, dažas instances saņems slodzi, kas pārsniedz to jaudas ierobežojumu, un pakalpojums kļūs mazāk uzticams.

Slodzes balansētājs bieži tiek klasificēts pēc protokola slāņa no OSI modeļa, kurā tas darbojas. Cloud Balancer darbojas TCP līmenī, kas atbilst ceturtajam slānim L4.

Pāriesim pie mākoņa balansētāja arhitektÅ«ras pārskata. Mēs pakāpeniski palielināsim detalizācijas lÄ«meni. Mēs sadalām balansētāja sastāvdaļas trÄ«s klasēs. Konfigurācijas plaknes klase ir atbildÄ«ga par lietotāja mijiedarbÄ«bu un saglabā sistēmas mērÄ·a stāvokli. VadÄ«bas plakne saglabā paÅ”reizējo sistēmas stāvokli un pārvalda sistēmas no datu plaknes klases, kas ir tieÅ”i atbildÄ«gas par trafika piegādi no klientiem uz jÅ«su gadÄ«jumiem.

Datu plakne

Satiksme nonāk dārgās ierÄ«cēs, ko sauc par robežmarÅ”rutētājiem. Lai palielinātu kļūdu toleranci, vienā datu centrā vienlaikus darbojas vairākas Ŕādas ierÄ«ces. Pēc tam trafiks tiek novirzÄ«ts uz balansētājiem, kas visiem AZ paziņo jebkuras apraides IP adreses, izmantojot BGP klientiem. 

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Satiksme tiek pārraidÄ«ta pa ECMP - Ŕī ir marÅ”rutÄ“Å”anas stratēģija, saskaņā ar kuru var bÅ«t vairāki vienlÄ«dz labi marÅ”ruti uz mērÄ·i (mÅ«su gadÄ«jumā mērÄ·is bÅ«s galamērÄ·a IP adrese) un paketes var nosÅ«tÄ«t pa jebkuru no tiem. Mēs arÄ« atbalstām darbu vairākās pieejamÄ«bas zonās pēc Ŕādas shēmas: katrā zonā reklamējam adresi, satiksme iet uz tuvāko un nepārsniedz tās robežas. Vēlāk ierakstā sÄ«kāk aplÅ«kosim, kas notiek ar satiksmi.

Konfigurācijas plakne

 
Konfigurācijas plaknes galvenā sastāvdaļa ir API, caur kuru tiek veiktas pamata darbÄ«bas ar balansētājiem: gadÄ«jumu izveidoÅ”ana, dzÄ“Å”ana, sastāva maiņa, veselÄ«bas pārbaužu rezultātu iegÅ«Å”ana utt. No vienas puses, tā ir REST API, un, no otras puses, otrs, mēs mākonÄ« ļoti bieži izmantojam ietvaru gRPC, tāpēc mēs ā€œtulkojamā€ REST uz gRPC un pēc tam izmantojam tikai gRPC. JebkurÅ” pieprasÄ«jums noved pie asinhronu idempotentu uzdevumu sērijas izveidoÅ”anas, kas tiek izpildÄ«ti kopējā Yandex.Cloud darbinieku pÅ«lā. Uzdevumi ir uzrakstÄ«ti tā, lai tos jebkurā laikā varētu apturēt un pēc tam restartēt. Tas nodroÅ”ina darbÄ«bu mērogojamÄ«bu, atkārtojamÄ«bu un reÄ£istrÄ“Å”anu.

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Rezultātā uzdevums no API iesniegs pieprasÄ«jumu balansētāja servisa kontrolierim, kas ir rakstÄ«ts Go. Tas var pievienot un noņemt balansētājus, mainÄ«t aizmugurprogrammu sastāvu un iestatÄ«jumus. 

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Pakalpojums saglabā savu stāvokli Yandex datu bāzē, izplatÄ«tā pārvaldÄ«tā datu bāzē, kuru drÄ«z varēsit izmantot. Vietnē Yandex.Cloud, kā jau mēs stāstÄ«ja, darbojas suņu barÄ«bas koncepcija: ja mēs paÅ”i izmantojam savus pakalpojumus, tad tos labprāt izmantos arÄ« mÅ«su klienti. Šādas koncepcijas ievieÅ”anas piemērs ir Yandex datu bāze. Mēs visus savus datus glabājam YDB, un mums nav jādomā par datu bāzes uzturÄ“Å”anu un mērogoÅ”anu: Ŕīs problēmas tiek atrisinātas mÅ«su vietā, mēs izmantojam datu bāzi kā pakalpojumu.

AtgriezÄ«simies pie balansiera kontroliera. Tās uzdevums ir saglabāt informāciju par balansētāju un nosÅ«tÄ«t uz Healthcheck kontrolleri uzdevumu pārbaudÄ«t virtuālās maŔīnas gatavÄ«bu.

Healthcheck kontrolieris

Tas saņem pieprasÄ«jumus mainÄ«t pārbaudes noteikumus, saglabā tos YDB, sadala uzdevumus starp Healtcheck mezgliem un apkopo rezultātus, kas pēc tam tiek saglabāti datu bāzē un nosÅ«tÄ«ti slodzes lÄ«dzsvara kontrolierim. Tas savukārt nosÅ«ta pieprasÄ«jumu mainÄ«t klastera sastāvu datu plaknē uz loadbalancer-node, par ko es runāŔu tālāk.

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Parunāsim vairāk par veselÄ«bas pārbaudēm. Tos var iedalÄ«t vairākās klasēs. RevÄ«zijām ir dažādi panākumu kritēriji. TCP pārbaudēm ir nepiecieÅ”ams veiksmÄ«gi izveidot savienojumu noteiktā laika periodā. HTTP pārbaudēm ir nepiecieÅ”ams gan veiksmÄ«gs savienojums, gan atbilde ar statusa kodu 200.

ArÄ« čeki atŔķiras pēc darbÄ«bas klases ā€“ tie ir aktÄ«vi un pasÄ«vi. PasÄ«vās pārbaudes vienkārÅ”i pārrauga, kas notiek ar satiksmi, neveicot nekādas Ä«paÅ”as darbÄ«bas. Tas nedarbojas ļoti labi L4, jo tas ir atkarÄ«gs no augstāka lÄ«meņa protokolu loÄ£ikas: L4 nav informācijas par to, cik ilgi darbÄ«ba prasÄ«ja un vai savienojuma pabeigÅ”ana bija laba vai slikta. Lai veiktu aktÄ«vas pārbaudes, lÄ«dzsvarotājam ir jānosÅ«ta pieprasÄ«jumi katrai servera instancei.

Lielākā daļa slodzes balansētāju paÅ”i veic dzÄ«vÄ«bas pārbaudes. Uzņēmumā Cloud mēs nolēmām atdalÄ«t Ŕīs sistēmas daļas, lai palielinātu mērogojamÄ«bu. Å Ä« pieeja ļaus mums palielināt lÄ«dzsvarotāju skaitu, vienlaikus saglabājot pakalpojumam iesniegto veselÄ«bas pārbaudes pieprasÄ«jumu skaitu. Pārbaudes veic atseviŔķi veselÄ«bas pārbaudes mezgli, kuros pārbaudes mērÄ·i tiek sadalÄ«ti un replicēti. JÅ«s nevarat veikt pārbaudes no viena saimniekdatora, jo tas var neizdoties. Tad mēs nesaņemsim viņa pārbaudÄ«to gadÄ«jumu stāvokli. Mēs veicam pārbaudes jebkurā no gadÄ«jumiem no vismaz trim veselÄ«bas pārbaudes mezgliem. Mēs sadalām pārbaužu mērÄ·us starp mezgliem, izmantojot konsekventus jaukÅ”anas algoritmus.

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

LÄ«dzsvaroÅ”anas un veselÄ«bas pārbaudes atdalÄ«Å”ana var radÄ«t problēmas. Ja veselÄ«bas pārbaudes mezgls veic pieprasÄ«jumus instancei, apejot balansētāju (kas Å”obrÄ«d neapkalpo trafiku), tad rodas dÄ«vaina situācija: resurss it kā ir dzÄ«vs, bet satiksme to nesasniegs. Mēs Å”o problēmu atrisinām Ŕādi: mēs garantējam, ka mēs uzsāksim veselÄ«bas pārbaudes satiksmi, izmantojot balansierus. Citiem vārdiem sakot, shēma pakeÅ”u pārvietoÅ”anai ar trafiku no klientiem un no veselÄ«bas pārbaudēm atŔķiras minimāli: abos gadÄ«jumos paketes nonāks lÄ«dzstrādniekiem, kas nogādās tās mērÄ·a resursos.

AtŔķirÄ«ba ir tāda, ka klienti iesniedz pieprasÄ«jumus VIP, bet veselÄ«bas pārbaudes veic pieprasÄ«jumus katram atseviŔķam RIP. Å eit rodas interesanta problēma: mēs saviem lietotājiem dodam iespēju izveidot resursus pelēkajos IP tÄ«klos. Iedomāsimies, ka ir divi dažādi mākoņu Ä«paÅ”nieki, kuri savus pakalpojumus ir slēpuÅ”i aiz balansētājiem. Katram no tiem ir resursi apakÅ”tÄ«klā 10.0.0.1/24 ar vienādām adresēm. Jums ir jāspēj tos kaut kā atŔķirt, un Å”eit jums ir jāiedziļinās Yandex.Cloud virtuālā tÄ«kla struktÅ«rā. Labāk ir uzzināt sÄ«kāku informāciju video no pasākuma about:cloud, mums tagad ir svarÄ«gi, lai tÄ«kls bÅ«tu daudzslāņu un tajā bÅ«tu tuneļi, kurus var atŔķirt pēc apakÅ”tÄ«kla id.

Healthcheck mezgli sazinās ar balansētājiem, izmantojot tā sauktās kvazi-IPv6 adreses. Kvaziadrese ir IPv6 adrese ar tajā iegultu IPv4 adresi un lietotāja apakÅ”tÄ«kla ID. Trafiks sasniedz balansētāju, kas no tā iegÅ«st IPv4 resursa adresi, aizstāj IPv6 ar IPv4 un nosÅ«ta paketi uz lietotāja tÄ«klu.

Apgrieztā trafika notiek tāpat: balansētājs redz, ka galamērÄ·is ir pelēks tÄ«kls no veselÄ«bas pārbaudÄ«tājiem, un pārvērÅ” IPv4 par IPv6.

VPP ā€” datu plaknes sirds

Balansētājs ir ieviests, izmantojot vektora pakeÅ”u apstrādes (VPP) tehnoloÄ£iju, Cisco sistēmu tÄ«kla trafika pakeÅ”apstrādei. MÅ«su gadÄ«jumā ietvars darbojas papildus lietotāja telpas tÄ«kla ierīču pārvaldÄ«bas bibliotēkai - Data Plane Development Kit (DPDK). Tas nodroÅ”ina augstu pakeÅ”u apstrādes veiktspēju: kodolā notiek daudz mazāk pārtraukumu un nav konteksta pārslēgÅ”anās starp kodola vietu un lietotāja vietu. 

VPP iet vēl tālāk un izspiež no sistēmas vēl lielāku veiktspēju, apvienojot paketes partijās. Veiktspējas pieaugumu nodroÅ”ina agresÄ«va keÅ”atmiņas izmantoÅ”ana mÅ«sdienu procesoros. Tiek izmantotas gan datu keÅ”atmiņas (paketes tiek apstrādātas ā€œvektorosā€, dati atrodas tuvu viens otram), gan instrukciju keÅ”atmiņas: VPP pakeÅ”u apstrāde notiek pēc grafika, kuras mezglos ir funkcijas, kas veic vienu un to paÅ”u uzdevumu.

Piemēram, IP pakeÅ”u apstrāde VPP notiek Ŕādā secÄ«bā: vispirms parsÄ“Å”anas mezglā tiek parsētas pakeÅ”u galvenes, un pēc tam tās tiek nosÅ«tÄ«tas uz mezglu, kas tālāk pārsÅ«ta paketes atbilstoÅ”i marÅ”rutÄ“Å”anas tabulām.

Mazliet hardcore. VPP autori nepieļauj kompromisus procesora keÅ”atmiņu izmantoÅ”anā, tāpēc tipisks pakeÅ”u vektora apstrādes kods satur manuālu vektorizāciju: ir apstrādes cilpa, kurā tiek apstrādāta tāda situācija kā ā€œmums ir četras paketes rindāā€, tad tas pats diviem, tad - vienam. IepriekŔējas ielādes instrukcijas bieži tiek izmantotas, lai ielādētu datus keÅ”atmiņā, lai paātrinātu piekļuvi tiem turpmākajās iterācijās.

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)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            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);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        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)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

Tātad Healthchecks, izmantojot IPv6, sarunājas ar VPP, kas tos pārvērÅ” par IPv4. To veic grafa mezgls, ko mēs saucam par algoritmisko NAT. Reversajai trafikai (un pārveidoÅ”anai no IPv6 uz IPv4) ir tas pats algoritmiskais NAT mezgls.

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

TieŔā trafika no balansētāja klientiem iet caur grafika mezgliem, kas paÅ”i veic balansÄ“Å”anu. 

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Pirmais mezgls ir lipÄ«gās sesijas. Tas saglabā jaucējkodu 5-korpuss izveidotajām sesijām. 5-korpuss ietver klienta adresi un portu, no kura tiek pārsÅ«tÄ«ta informācija, trafika saņemÅ”anai pieejamo resursu adresi un portus, kā arÄ« tÄ«kla protokolu. 

5 korpusu jaukÅ”ana palÄ«dz mums veikt mazāk aprēķinu nākamajā konsekventajā jaukÅ”anas mezglā, kā arÄ« labāk apstrādāt resursu saraksta izmaiņas aiz balansētāja. Kad pakete, kurai nav sesijas, nonāk balansētājā, tā tiek nosÅ«tÄ«ta uz konsekvento jaukÅ”anas mezglu. Å eit notiek lÄ«dzsvaroÅ”ana, izmantojot konsekventu jaukÅ”anu: mēs atlasām resursu no pieejamo ā€œdzÄ«voā€ resursu saraksta. Tālāk paketes tiek nosÅ«tÄ«tas uz NAT mezglu, kas faktiski aizstāj galamērÄ·a adresi un pārrēķina kontrolsummas. Kā redzams, mēs ievērojam VPP noteikumus - patÄ«k patÄ«k, grupējot lÄ«dzÄ«gus aprēķinus, lai palielinātu procesora keÅ”atmiņu efektivitāti.

Konsekventa jaukŔana

Kāpēc mēs to izvēlējāmies un kas tas vispār ir? Vispirms apskatÄ«sim iepriekŔējo uzdevumu - resursa atlasi no saraksta. 

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Nekonsekventas jaukÅ”anas gadÄ«jumā tiek aprēķināta ienākoŔās paketes jaucējvērtÄ«ba un resurss tiek atlasÄ«ts no saraksta ar atlikumu, dalot Å”o jaucējfunkciju ar resursu skaitu. Kamēr saraksts paliek nemainÄ«gs, Ŕī shēma darbojas labi: mēs vienmēr nosÅ«tām paketes ar vienu un to paÅ”u 5 korpusu uz vienu un to paÅ”u gadÄ«jumu. Ja, piemēram, kāds resurss pārstāja reaģēt uz veselÄ«bas pārbaudēm, tad lielai daļai jaucēju izvēle mainÄ«sies. Klienta TCP savienojumi tiks pārtraukti: pakete, kas iepriekÅ” sasniegusi gadÄ«jumu A, var sākt sasniegt gadÄ«jumu B, kas nav pazÄ«stama ar Ŕīs paketes sesiju.

Konsekventa jaukÅ”ana atrisina aprakstÄ«to problēmu. VienkārŔākais veids, kā izskaidrot Å”o jēdzienu, ir Ŕāds: iedomājieties, ka jums ir gredzens, uz kuru jÅ«s sadalāt resursus, izmantojot hash (piemēram, pēc IP:porta). Resursa izvēle ir riteņa pagrieÅ”ana par leņķi, ko nosaka paketes hash.

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

Tas samazina trafika pārdali, kad mainās resursu sastāvs. Resursa dzÄ“Å”ana ietekmēs tikai to konsekventā jaukÅ”anas gredzena daļu, kurā atradās resurss. Resursa pievienoÅ”ana maina arÄ« izplatÄ«Å”anu, taču mums ir lipÄ«go sesiju mezgls, kas ļauj nepārslēgt jau izveidotās sesijas uz jauniem resursiem.

Mēs apskatÄ«jām, kas notiek, lai novirzÄ«tu trafiku starp balansētāju un resursiem. Tagad apskatÄ«sim atpakaļgaitas satiksmi. Tas atbilst tādai paÅ”ai shēmai, kā pārbaudÄ«t trafiku ā€” izmantojot algoritmisko NAT, tas ir, izmantojot reverso NAT 44 klientu trafikam un caur NAT 46 veselÄ«bas pārbaužu trafikam. Mēs ievērojam savu shēmu: mēs apvienojam veselÄ«bas pārbaužu trafiku un reālo lietotāju trafiku.

Loadbalancer-mezgls un samontētie komponenti

Par balansētāju un resursu sastāvu VPP ziņo vietējais dienests - loadbalancer-node. Tas abonē notikumu straumi no slodzes lÄ«dzsvara kontroliera un spēj attēlot atŔķirÄ«bu starp paÅ”reizējo VPP stāvokli un mērÄ·a stāvokli, kas saņemts no kontrollera. Mēs iegÅ«stam slēgtu sistēmu: notikumi no API nonāk lÄ«dzsvara kontrolierim, kas veselÄ«bas pārbaudes kontrolierim pieŔķir uzdevumus, lai pārbaudÄ«tu resursu ā€œdzÄ«vuā€. Tas savukārt pieŔķir uzdevumus veselÄ«bas pārbaudes mezglam un apkopo rezultātus, pēc tam tos nosÅ«ta atpakaļ balansētāja kontrollerim. Loadbalancer-node abonē kontroliera notikumus un maina VPP stāvokli. Šādā sistēmā katrs dienests par blakus pakalpojumiem zina tikai nepiecieÅ”amo. Savienojumu skaits ir ierobežots, un mums ir iespēja neatkarÄ«gi darboties un mērogot dažādus segmentus.

Tīkla slodzes balansētāja arhitektūra pakalpojumā Yandex.Cloud

No kādām problēmām izdevās izvairīties?

Visi mÅ«su pakalpojumi vadÄ«bas plaknē ir rakstÄ«ti Go, un tiem ir labas mērogoÅ”anas un uzticamÄ«bas Ä«paŔības. Go ir daudzas atvērtā pirmkoda bibliotēkas sadalÄ«to sistēmu veidoÅ”anai. Mēs aktÄ«vi izmantojam GRPC, visos komponentos ir atvērtā pirmkoda pakalpojumu atklāŔanas ievieÅ”ana - mÅ«su pakalpojumi uzrauga viens otra veiktspēju, var dinamiski mainÄ«t sastāvu, un mēs to saistÄ«jām ar GRPC balansÄ“Å”anu. Metrikas noteikÅ”anai mēs izmantojam arÄ« atvērtā pirmkoda risinājumu. Datu plaknē mēs saņēmām pienācÄ«gu veiktspēju un lielu resursu rezervi: izrādÄ«jās ļoti grÅ«ti salikt stendu, uz kura varētu paļauties uz VPP, nevis dzelzs tÄ«kla kartes veiktspēju.

Problēmas un risinājumi

Kas tik labi nedarbojās? Go ir automātiska atmiņas pārvaldÄ«ba, taču joprojām notiek atmiņas noplÅ«des. VienkārŔākais veids, kā ar tiem tikt galā, ir palaist gorutÄ«nas un atcerēties tās pārtraukt. LÄ«dzņemÅ”anai: skatieties savu Go programmu atmiņas patēriņu. Bieži vien labs rādÄ«tājs ir gorutÄ«nu skaits. Å im stāstam ir pluss: programmā Go ir viegli iegÅ«t izpildlaika datus - atmiņas patēriņu, palaistoÅ”o gorutÄ«nu skaitu un daudzus citus parametrus.

Turklāt Go var nebÅ«t labākā izvēle funkcionālajiem testiem. Tie ir diezgan runÄ«gi, un standarta pieeja ā€œpalaist visu CI pa partijāmā€ viņiem nav Ä«paÅ”i piemērota. Fakts ir tāds, ka funkcionālie testi prasa vairāk resursu un rada reālus taimautu. Å Ä« iemesla dēļ testi var neizdoties, jo CPU ir aizņemts ar vienÄ«bu testiem. Secinājums: ja iespējams, veiciet ā€œsmagosā€ testus atseviŔķi no vienÄ«bas testiem. 

Mikropakalpojumu notikumu arhitektÅ«ra ir sarežģītāka nekā monolÄ«ts: vākt žurnālus desmitiem dažādu iekārtu nav Ä«paÅ”i ērti. Secinājums: ja veicat mikropakalpojumus, nekavējoties padomājiet par izsekoÅ”anu.

Mūsu plāni

Mēs izlaidÄ«sim iekŔējo balansētāju, IPv6 balansētāju, pievienosim atbalstu Kubernetes skriptiem, turpināsim sadalÄ«t savus pakalpojumus (Å”obrÄ«d ir sadalÄ«ti tikai Healthcheck-node un Healthcheck-ctrl), pievienosim jaunas veselÄ«bas pārbaudes, kā arÄ« ieviesÄ«sim viedo pārbaužu apkopoÅ”anu. Apsveram iespēju padarÄ«t savus pakalpojumus vēl neatkarÄ«gākus - lai tie sazinātos nevis tieÅ”i savā starpā, bet izmantojot ziņojumu rindu. MākonÄ« nesen parādÄ«jās ar SQS saderÄ«gs pakalpojums Yandex ziņojumu rinda.

Nesen notika Yandex Load Balancer publiska izlaiÅ”ana. IzpētÄ«t dokumentācija uz servisu, pārvaldiet balansierus sev ērtā veidā un palieliniet savu projektu kļūdu toleranci!

Avots: www.habr.com

Pievieno komentāru