ProHoster > Blogs > Administrācija > [Tulkojums] Sūtņa vītnes modelis

[Tulkojums] Sūtņa vītnes modelis

Raksta tulkojums: Envoy vÄ«tņu modelis ā€” https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Å is raksts man likās diezgan interesants, un tā kā Envoy visbiežāk tiek izmantots kā daļa no ā€œistioā€ vai vienkārÅ”i kā kubernetes ā€œieejas kontrolierisā€, lielākajai daļai cilvēku ar to nav tādas tieÅ”as mijiedarbÄ«bas kā, piemēram, ar tipisku Nginx vai Haproxy instalācijas. Tomēr, ja kaut kas saplÄ«st, bÅ«tu labi saprast, kā tas darbojas no iekÅ”puses. Es centos pēc iespējas vairāk teksta pārtulkot krieviski, arÄ« Ä«paÅ”us vārdus, tiem, kam uz to skatÄ«ties ir sāpÄ«gi, oriÄ£inālus atstāju iekavās. Laipni lÅ«dzam kaÄ·Ä«.

Zema lÄ«meņa tehniskā dokumentācija Envoy kodu bāzei paÅ”laik ir diezgan niecÄ«ga. Lai to novērstu, es plānoju izveidot virkni emuāra ierakstu par dažādām Envoy apakÅ”sistēmām. Tā kā Å”is ir pirmais raksts, lÅ«dzu, dariet man zināmu, ko domājat un kas jÅ«s varētu interesēt nākamajos rakstos.

Viens no visbiežāk uzdotajiem tehniskajiem jautājumiem par Envoy ir lÅ«gt zema lÄ«meņa aprakstu par izmantoto vÄ«tņu modeli. Å ajā ziņojumā es aprakstÄ«Å”u, kā Envoy kartē savienojumus ar pavedieniem, kā arÄ« Thread Local Storage sistēmu, ko tā izmanto iekŔēji, lai padarÄ«tu kodu paralēlāku un augstas veiktspējas.

Vītņu pārskats

[Tulkojums] Sūtņa vītnes modelis

Envoy izmanto trīs dažādu veidu straumes:

  • Galvenais: Å is pavediens kontrolē procesa palaiÅ”anu un izbeigÅ”anu, visu XDS (xDiscovery Service) API apstrādi, tostarp DNS, stāvokļa pārbaudi, vispārējo klasteru un izpildlaika pārvaldÄ«bu, statistikas atiestatÄ«Å”anu, administrÄ“Å”anu un vispārējo procesu pārvaldÄ«bu ā€” Linux signālus. karstā restartÄ“Å”ana utt. kas notiek Å”ajā pavedienā, ir asinhrons un "nebloķējoÅ”s". Kopumā galvenais pavediens koordinē visus kritiskos funkcionalitātes procesus, kuru darbÄ«bai nav nepiecieÅ”ams liels CPU daudzums. Tas ļauj lielāko daļu kontroles koda rakstÄ«t tā, it kā tas bÅ«tu ar vienu pavedienu.
  • Strādnieks: Pēc noklusējuma Envoy izveido darbinieka pavedienu katram sistēmas aparatÅ«ras pavedienam, to var kontrolēt, izmantojot opciju --concurrency. Katrs darbinieka pavediens palaiž ā€œnebloķējoÅ”uā€ notikumu cilpu, kas ir atbildÄ«ga par katra klausÄ«tāja noklausÄ«Å”anos; rakstÄ«Å”anas laikā (29. gada 2017. jÅ«lijā) nav klausÄ«tāja sadalÄ«Å”anas, jaunu savienojumu pieņemÅ”anas, filtru steka instantiances. savienojumu un visu ievades/izvades (IO) darbÄ«bu apstrādi savienojuma darbÄ«bas laikā. Atkal, tas ļauj lielāko daļu savienojuma apstrādes koda rakstÄ«t tā, it kā tas bÅ«tu viens pavediens.
  • Failu skaloÅ”anas lÄ«dzeklis: Katram failam, ko Envoy raksta, galvenokārt piekļuves žurnāliem, paÅ”laik ir neatkarÄ«gs bloÄ·Ä“Å”anas pavediens. Tas ir saistÄ«ts ar faktu, ka ierakstÄ«Å”ana failos, kas saglabāti failu sistēmā, pat tad, ja to lietojat O_NONBLOCK dažreiz var aizsprostot (nopÅ«ta). Kad darbinieka pavedieniem ir jāraksta failā, dati faktiski tiek pārvietoti uz buferi atmiņā, kur tie galu galā tiek izskaloti caur pavedienu. failu flush. Å is ir viens no koda apgabaliem, kurā tehniski visi darbinieku pavedieni var bloķēt vienu un to paÅ”u bloÄ·Ä“Å”anu, mēģinot aizpildÄ«t atmiņas buferi.

Savienojuma apstrāde

Kā Ä«si minēts iepriekÅ”, visi darbinieku pavedieni klausās visus klausÄ«tājus bez jebkādas ŔķelÅ”anās. Tādējādi kodols tiek izmantots, lai graciozi nosÅ«tÄ«tu pieņemtās ligzdas uz darbinieku pavedieniem. MÅ«sdienu kodoli parasti ir ļoti labi Å”ajā ziņā, tie izmanto tādas funkcijas kā ievades/izvades (IO) prioritātes pastiprināŔana, lai mēģinātu aizpildÄ«t pavedienu ar darbu, pirms tie sāk izmantot citus pavedienus, kas arÄ« klausās tajā paŔā ligzdā, kā arÄ« neizmanto round robin. bloÄ·Ä“Å”ana (Spinlock), lai apstrādātu katru pieprasÄ«jumu.
Kad savienojums tiek pieņemts darbinieka pavedienā, tas nekad neatstāj Å”o pavedienu. Visa turpmākā savienojuma apstrāde tiek pilnÄ«bā apstrādāta darbinieka pavedienā, tostarp jebkura pārsÅ«tÄ«Å”anas darbÄ«ba.

Tam ir vairākas svarīgas sekas:

  • Visi savienojumu pÅ«li programmā Envoy ir pieŔķirti darbinieka pavedienam. Tātad, lai gan HTTP/2 savienojumu pÅ«li vienlaikus veido tikai vienu savienojumu ar katru augÅ”upējo resursdatoru, ja ir četri darbinieka pavedieni, stabilā stāvoklÄ« katram augÅ”pus resursdatoram bÅ«s četri HTTP/2 savienojumi.
  • Iemesls, kāpēc Envoy darbojas Ŕādi, ir tas, ka, saglabājot visu vienā darbinieka pavedienā, gandrÄ«z visu kodu var ierakstÄ«t bez bloÄ·Ä“Å”anas un tā, it kā tas bÅ«tu viens pavediens. Å is dizains ļauj viegli uzrakstÄ«t daudz koda un neticami labi mērogot lÄ«dz gandrÄ«z neierobežotam skaitam darbinieku pavedienu.
  • Tomēr viens no galvenajiem aspektiem ir tas, ka no atmiņas baseina un savienojuma efektivitātes viedokļa patiesÄ«bā ir ļoti svarÄ«gi konfigurēt --concurrency. Ja ir vairāk darbinieku pavedienu, nekā nepiecieÅ”ams, tiks iztērēta atmiņa, tiks izveidots vairāk dÄ«kstāves savienojumu un samazināsies savienojumu apkopoÅ”anas ātrums. Uzņēmums Lyft mÅ«su sÅ«tņa blakusvāģu konteineri darbojas ar ļoti zemu vienlaicÄ«gumu, tāpēc veiktspēja aptuveni atbilst pakalpojumiem, kuriem tie atrodas blakus. Mēs palaižam Envoy kā malas starpniekserveri tikai maksimāli vienlaicÄ«gi.

Ko nozÄ«mē nebloÄ·Ä“Å”ana?

Termins "nebloÄ·Ä“Å”ana" lÄ«dz Å”im ir izmantots vairākas reizes, apspriežot galveno un darba pavedienu darbÄ«bu. Viss kods ir rakstÄ«ts, pieņemot, ka nekas nekad nav bloķēts. Tomēr tā nav pilnÄ«ga taisnÄ«ba (kas nav pilnÄ«gi taisnÄ«ba?).

Envoy izmanto vairākas ilgstoÅ”as ā€‹ā€‹ā€‹ā€‹procesa bloÄ·Ä“Å”anas:

  • Kā minēts, rakstot piekļuves žurnālus, visi darbinieka pavedieni iegÅ«st vienu un to paÅ”u bloÄ·Ä“Å”anu, pirms tiek aizpildÄ«ts atmiņā esoŔā žurnāla buferis. Slēdzenes turÄ“Å”anas laikam jābÅ«t ļoti zemam, taču ir iespējams, ka slēdzeni var apstrÄ«dēt ar augstu vienlaicÄ«gumu un lielu caurlaidspēju.
  • Envoy izmanto ļoti sarežģītu sistēmu, lai apstrādātu statistiku, kas ir lokāla pavedienam. Tā bÅ«s atseviŔķa ieraksta tēma. Tomēr es Ä«si pieminÄ“Å”u, ka, apstrādājot pavedienu statistiku lokāli, dažkārt ir jāiegādājas centrālā "statistikas veikala" atslēga. Å o bloÄ·Ä“Å”anu nekad nevajadzētu pieprasÄ«t.
  • Galvenais pavediens periodiski jāsaskaņo ar visiem darbinieka pavedieniem. Tas tiek darÄ«ts, "publicējot" no galvenā pavediena uz darbinieku pavedieniem un dažreiz no darbinieka pavedieniem atpakaļ uz galveno pavedienu. SÅ«tÄ«Å”anai ir nepiecieÅ”ama bloÄ·Ä“Å”ana, lai publicēto ziņojumu varētu ievietot rindā vēlākai piegādei. Å Ä«s slēdzenes nekad nevajadzētu nopietni apstrÄ«dēt, taču tās joprojām var tehniski bloķēt.
  • Kad Envoy ieraksta žurnālu sistēmas kļūdu straumē (standarta kļūda), tas iegÅ«st bloÄ·Ä“Å”anu visam procesam. Kopumā Envoy vietējā mežizstrāde tiek uzskatÄ«ta par briesmÄ«gu no veiktspējas viedokļa, tāpēc tās uzlaboÅ”anai nav pievērsta liela uzmanÄ«ba.
  • Ir dažas citas nejauÅ”as slēdzenes, taču nevienai no tām nav bÅ«tiskas veiktspējas, un tās nekad nevajadzētu apstrÄ«dēt.

Pavedienu lokālā krātuve

Tā kā sÅ«tnis nodala galvenā pavediena pienākumus no darbinieka pavediena pienākumiem, pastāv prasÄ«ba, ka galvenajā pavedienā var veikt sarežģītu apstrādi un pēc tam nodroÅ”ināt to katram darbinieka pavedienam ļoti vienlaicÄ«gi. Å ajā sadaļā ir aprakstÄ«ta sÅ«tņa pavediena vietējā krātuve (TLS) augstā lÄ«menÄ«. Nākamajā sadaļā es aprakstÄ«Å”u, kā tas tiek izmantots klastera pārvaldÄ«Å”anai.
[Tulkojums] Sūtņa vītnes modelis

Kā jau aprakstÄ«ts, galvenais pavediens apstrādā praktiski visas vadÄ«bas un vadÄ«bas plaknes funkcionalitātes sÅ«tņa procesā. Å eit vadÄ«bas plakne ir nedaudz pārslogota, taču, aplÅ«kojot to paŔā sÅ«tņa procesā un salÄ«dzinot to ar pārsÅ«tÄ«Å”anu, ko veic darbinieka pavedieni, tas ir loÄ£iski. Vispārējais noteikums ir tāds, ka galvenā pavediena process veic noteiktu darbu, un pēc tam tam ir jāatjaunina katrs darbinieka pavediens atbilstoÅ”i Ŕī darba rezultātam. Å”ajā gadÄ«jumā darbinieka pavedienam nav jāiegÅ«st bloÄ·Ä“Å”ana katrai piekļuvei.

SÅ«tņa TLS (pavedienu lokālā krātuve) sistēma darbojas Ŕādi:

  • Kods, kas darbojas galvenajā pavedienā, var pieŔķirt TLS slotu visam procesam. Lai gan tas ir abstrahēts, praksē tas ir vektora indekss, kas nodroÅ”ina O(1) piekļuvi.
  • Galvenais pavediens savā slotā var instalēt patvaļīgus datus. Kad tas ir izdarÄ«ts, dati tiek publicēti katrā darbinieka pavedienā kā parasts notikumu cilpas notikums.
  • Darbinieku pavedieni var lasÄ«t no sava TLS slota un izgÅ«t visus tajā pieejamos pavedienu lokālos datus.

Lai gan tā ir ļoti vienkārÅ”a un neticami spēcÄ«ga paradigma, tā ir ļoti lÄ«dzÄ«ga RCU (lasÄ«Å”anas-kopÄ“Å”anas-atjaunināŔanas) bloÄ·Ä“Å”anas koncepcijai. BÅ«tÄ«bā darbinieku pavedieni nekad neredz datu izmaiņas TLS slotos, kamēr darbs darbojas. Izmaiņas notiek tikai atpÅ«tas periodā starp darba notikumiem.

Sūtnis to izmanto divos dažādos veidos:

  • Saglabājot dažādus datus katrā darbinieka pavedienā, datiem var piekļūt bez jebkādas bloÄ·Ä“Å”anas.
  • Uzturot koplietotu rādÄ«tāju uz globālajiem datiem tikai lasÄ«Å”anas režīmā katrā darbinieka pavedienā. Tādējādi katram darbinieka pavedienam ir datu atsauces skaits, ko nevar samazināt, kamēr darbs darbojas. Tikai tad, kad visi darbinieki nomierināsies un augÅ”upielādēs jaunus kopÄ«gotos datus, vecie dati tiks iznÄ«cināti. Tas ir identisks RCU.

Klasteru atjaunināŔanas pavedienu veidoŔana

Šajā sadaļā es aprakstīŔu, kā TLS (pavedienu lokālā krātuve) tiek izmantots klastera pārvaldībai. Klasteru pārvaldība ietver xDS API un/vai DNS apstrādi, kā arī veselības pārbaudi.
[Tulkojums] Sūtņa vītnes modelis

Klasteru plūsmas pārvaldība ietver Ŕādus komponentus un darbības:

  1. Klasteru pārvaldnieks ir sÅ«tņa komponents, kas pārvalda visas zināmās klasteru augÅ”puses, klasteru atklāŔanas pakalpojuma (CDS) API, slepenā atklāŔanas pakalpojuma (SDS) un galapunkta noteikÅ”anas pakalpojuma (EDS) API, DNS un aktÄ«vās ārējās pārbaudes. Tas ir atbildÄ«gs par "galu galā konsekventa" skata izveidi par katru augÅ”upējo klasteru, kas ietver atklātos saimniekdatorus, kā arÄ« veselÄ«bas stāvokli.
  2. Veselības pārbaudītājs veic aktīvo veselības pārbaudi un ziņo par veselības stāvokļa izmaiņām klastera pārvaldniekam.
  3. CDS (klasteru noteikÅ”anas pakalpojums) / SDS (slepenais meklÄ“Å”anas pakalpojums) / EDS (gala punkta noteikÅ”anas pakalpojums) / DNS tiek veikti, lai noteiktu klastera dalÄ«bu. Stāvokļa izmaiņas tiek atgrieztas klastera pārvaldniekam.
  4. Katrs darbinieka pavediens nepārtraukti izpilda notikumu cilpu.
  5. Kad klastera pārvaldnieks nosaka, ka klastera stāvoklis ir mainījies, tas izveido jaunu tikai lasāmu klastera stāvokļa momentuzņēmumu un nosūta to katram darbinieka pavedienam.
  6. Nākamajā klusajā periodā darbinieka pavediens atjauninās momentuzņēmumu pieŔķirtajā TLS slotā.
  7. I/O notikuma laikā, kam ir jānosaka resursdatora slodzes lÄ«dzsvars, slodzes lÄ«dzsvarotājs pieprasÄ«s TLS (pavedienu lokālās atmiņas) slotu, lai iegÅ«tu informāciju par resursdatoru. Tam nav nepiecieÅ”amas slēdzenes. Ņemiet vērā arÄ« to, ka TLS var arÄ« aktivizēt atjaunināŔanas notikumus, lai slodzes balansētāji un citi komponenti varētu pārrēķināt keÅ”atmiņas, datu struktÅ«ras utt. Tas ir ārpus Ŕīs ziņas darbÄ«bas jomas, taču tiek izmantots dažādās koda vietās.

Izmantojot iepriekÅ” minēto procedÅ«ru, sÅ«tnis var apstrādāt katru pieprasÄ«jumu bez jebkādas bloÄ·Ä“Å”anas (izņemot gadÄ«jumus, kas aprakstÄ«ti iepriekÅ”). NeatkarÄ«gi no paÅ”a TLS koda sarežģītÄ«bas, lielākajai daļai koda nav jāsaprot, kā darbojas daudzpavedienu izveide, un to var rakstÄ«t vienā pavedienā. Tas padara lielāko daļu koda vieglāk ierakstāmu, kā arÄ« nodroÅ”ina izcilu veiktspēju.

Citas apakÅ”sistēmas, kas izmanto TLS

TLS (pavedienu lokālā krātuve) un RCU (lasīŔanas kopijas atjauninājums) tiek plaŔi izmantoti programmā Envoy.

LietoÅ”anas piemēri:

  • Mehānisms funkcionalitātes maiņai izpildes laikā: PaÅ”reizējais iespējoto funkcionalitātes saraksts tiek aprēķināts galvenajā pavedienā. Pēc tam katram darbinieka pavedienam tiek pieŔķirts tikai lasāms momentuzņēmums, izmantojot RCU semantiku.
  • MarÅ”ruta tabulu nomaiņa: marÅ”ruta tabulām, ko nodroÅ”ina RDS (marÅ”ruta noteikÅ”anas pakalpojums), marÅ”ruta tabulas tiek izveidotas galvenajā pavedienā. Tikai lasāms momentuzņēmums pēc tam tiks nodroÅ”ināts katram darbinieka pavedienam, izmantojot RCU (lasÄ«Å”anas kopÄ“Å”anas atjauninājuma) semantiku. Tas padara marÅ”ruta tabulu maiņu atomiski efektÄ«vu.
  • HTTP galvenes keÅ”atmiņa: Kā izrādās, HTTP galvenes aprēķināŔana katram pieprasÄ«jumam (palaižot ~25K+ RPS uz kodolu) ir diezgan dārga. Envoy centralizēti aprēķina galveni aptuveni ik pēc pussekundes un nodroÅ”ina to katram darbiniekam, izmantojot TLS un RCU.

Ir arÄ« citi gadÄ«jumi, taču iepriekŔējiem piemēriem vajadzētu sniegt labu izpratni par to, kam tiek izmantots TLS.

Zināmas veiktspējas nepilnības

Lai gan Envoy kopumā darbojas diezgan labi, ir dažas ievērojamas jomas, kurām jāpievērÅ” uzmanÄ«ba, ja to lieto ar ļoti augstu vienlaicÄ«gumu un caurlaidspēju:

  • Kā aprakstÄ«ts Å”ajā rakstā, paÅ”laik visi darbinieka pavedieni iegÅ«st bloÄ·Ä“Å”anu, rakstot piekļuves žurnāla atmiņas buferÄ«. Augstas vienlaicÄ«bas un lielas caurlaidspējas gadÄ«jumā, rakstot galÄ«gajā failā, piekļuves žurnāli bÅ«s jāsagrupē katram darbinieka pavedienam uz ārpuskārtas piegādes rēķina. Varat arÄ« izveidot atseviŔķu piekļuves žurnālu katram darbinieka pavedienam.
  • Lai gan statistika ir ļoti optimizēta, ar ļoti augstu vienlaicÄ«gumu un caurlaidspēju, iespējams, radÄ«sies strÄ«ds par atseviŔķu statistiku. Å Ä«s problēmas risinājums ir skaitÄ«tāji katram darbinieka pavedienam ar periodisku centrālo skaitÄ«tāju atiestatÄ«Å”anu. Tas tiks apspriests nākamajā ierakstā.
  • PaÅ”reizējā arhitektÅ«ra nedarbosies labi, ja Envoy tiks izvietots scenārijā, kurā ir ļoti maz savienojumu, kuriem nepiecieÅ”ami ievērojami apstrādes resursi. Nav garantijas, ka savienojumi tiks vienmērÄ«gi sadalÄ«ti starp darba vÄ«tnēm. To var atrisināt, ievieÅ”ot strādnieku savienojumu balansÄ“Å”anu, kas ļaus apmainÄ«ties ar savienojumiem starp strādnieku pavedieniem.

Secinājums

Envoy vÄ«tņu modelis ir izstrādāts, lai nodroÅ”inātu vieglu programmÄ“Å”anu un masveida paralēlismu uz potenciāli izŔķērdÄ«gas atmiņas un savienojumu rēķina, ja tas nav pareizi konfigurēts. Å is modelis ļauj tam ļoti labi darboties ar ļoti lielu pavedienu skaitu un caurlaidspēju.
Kā jau īsi minēju vietnē Twitter, dizains var darboties arī pilna lietotāja režīma tīkla steksā, piemēram, DPDK (Data Plane Development Kit), kā rezultātā parastie serveri apstrādā miljoniem pieprasījumu sekundē ar pilnu L7 apstrādi. Būs ļoti interesanti redzēt, kas tiks uzbūvēts tuvāko gadu laikā.
Pēdējais Ä«ss komentārs: man daudzas reizes ir jautāts, kāpēc mēs izvēlējāmies C++ priekÅ” Envoy. Iemesls joprojām ir tāds, ka tā joprojām ir vienÄ«gā plaÅ”i izmantotā industriālā lÄ«meņa valoda, kurā var uzbÅ«vēt Å”ajā amatā aprakstÄ«to arhitektÅ«ru. C++ noteikti nav piemērots visiem vai pat daudziem projektiem, taču noteiktiem lietoÅ”anas gadÄ«jumiem tas joprojām ir vienÄ«gais rÄ«ks, lai paveiktu darbu.

Saites uz kodu

Saites uz failiem ar interfeisiem un galveņu ievieÅ”anu, kas apspriesti Å”ajā ziņojumā:

Avots: www.habr.com

Pievieno komentāru