ProHoster > Blog > Administrim > [Përkthim] Modeli i rrjedhave të Envoy (Envoy threading model)

[Përkthim] Modeli i rrjedhave të Envoy (Envoy threading model)

PĂ«rkthimi i artikullit: Modeli i rrjedhjes sĂ« Envoy — https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Ky artikull më duket mjaft interesant, dhe për shkak se Envoy përdoret më së shpeshti si pjesë e "istio" ose thjesht si "ingress controller" i kubernetes, shumica e njerëzve nuk e kanë një ndërlidhje të drejtpërdrejtë me të siç kanë me instalime tipike si Nginx ose Haproxy. Megjithatë, kur diçka dësht merr, do të ishte mirë të kuptosh se si funksionon nga brenda. Kam përballuar të përkthej sa më shumë tekst në rusisht, duke përfshirë edhe fjalët speciale; për ata që u duket e dhimbshme të shohin, kam lënë origjinalet në kllapa. Mirë se vini nën!

Dokumentacioni teknik i nivelit të ulët për bazën e kodit të Envoy aktualisht është mjaft i varfër. Për ta rregulluar këtë, planifikoj të bëj një seri artikujsh në blog për nën-sistemet e ndryshme të Envoy. Duke qenë se ky është artikulli i parë, ju lutem, më tregoni çfarë mendoni dhe çfarë mund të ishte interesante në artikujt e ardhshëm.

Një nga pyetjet më të zakonshme teknike që marr për Envoy është kërkesa për një përshkrim të nivelit të ulët të modelit të rrjedhjes së përdorur (threading model). Në këtë post, do të përshkruaj se si Envoy lidhet lidhjet me rrjedhat, si dhe përshkrimin e sistemit të ruajtjes lokale të rrjedhave (Thread Local Storage), i cili përdoret brenda për ta bërë kodin më paralel dhe me performancë të lartë.

PĂ«rshkrimi i Rrjedhave (Threading overview)

[Përkthim] Modeli i rrjedhave të Envoy (Envoy threading model)

Envoy përdor tri lloje të ndryshme rrjedhash:

  • Kryesore (Main): Ky rrjedh menaxhon nisjen dhe pĂ«rfundimin e procesit, tĂ« gjitha pĂ«rpunimet e XDS (xDiscovery Service) API, duke pĂ«rfshirĂ« DNS, verifikimin e shĂ«ndetit (health checking), menaxhimin e pĂ«rgjithshĂ«m tĂ« klasterit dhe procesin e funksionimit tĂ« shĂ«rbimit (runtime), ri-nxisjen e statistikave, administrimin dhe menaxhimin e pĂ«rgjithshĂ«m tĂ« proceseve — sinjalet Linux, rinstalimin e nxehtĂ« (hot restart) etj. Çdo gjĂ« qĂ« ndodh nĂ« kĂ«tĂ« rrjedh Ă«shtĂ« asinkrone dhe "jo bllokuese". NĂ« pĂ«rgjithĂ«si, rrjedha kryesore koordinon tĂ« gjithĂ« proceset kritike tĂ« funksionalitetit, pĂ«r kryerjen e tĂ« cilave nuk kĂ«rkohet njĂ« sasi e madhe CPU. Kjo lejon qĂ« njĂ« pjesĂ« e madhe e kodit tĂ« menaxhimit tĂ« shkruhet ashtu siç do tĂ« ishte njĂ« njĂ«-rrjedhĂ«sh.
  • PĂ«rgjegjĂ«s (Worker): Po ashtu, Envoy krijon njĂ« rrjedhĂ« punuese (worker thread) pĂ«r çdo rrjedhĂ« harduerike nĂ« sistem, kjo mund tĂ« kontrollohet me anĂ« tĂ« opsionit --konkurenca. Çdo rrjedhĂ« punuese nis njĂ« cikĂ«l ngjarjesh «jo bllokues» (event loop), i cili Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r pĂ«r tĂ« dĂ«gjuar (listening) çdo dĂ«gjues (listener). NĂ« momentin e shkruarjes sĂ« kĂ«tij artikulli (29 korrik 2017), nuk ka segmentim (sharding) tĂ« dĂ«gjuesit (listener), pranimin e lidhjeve tĂ« reja, krijimin e njĂ« shembulli tĂ« grumbullit tĂ« filtrave pĂ«r lidhjen dhe pĂ«rpunimin e tĂ« gjitha operacioneve tĂ« hyrjes-daljes (IO) gjatĂ« ekzistencĂ«s sĂ« lidhjes. PĂ«rsĂ«ri, kjo lejon qĂ« shumica e kodit pĂ«r pĂ«rpunimin e lidhjeve tĂ« shkruhet ashtu sikur tĂ« ishte njĂ« rrjedhĂ« punuese e vetme.
  • Shkarkimi i skedarĂ«ve (File flusher): Çdo skedar qĂ« shkruan Envoy, kryesisht regjistrat e aksesit (access logs), aktualisht ka njĂ« rrjedhĂ« bllokuese tĂ« pavarur. Kjo Ă«shtĂ« pĂ«r shkak se shkruajtja nĂ« skedarĂ« tĂ« cachuar nga sistemi i skedarĂ«ve, madje edhe nĂ« pĂ«rdorimin e O_NONBLOCK ndonjĂ«herĂ« mund tĂ« bllokohet (suspenso). Kur rrjedhat e punĂ«s duhet tĂ« shkruajnĂ« nĂ« skedar, tĂ« dhĂ«nat nĂ« tĂ« vĂ«rtetĂ« lĂ«vizin nĂ« njĂ« buffer nĂ« memorie, ku ato nĂ« fund shpĂ«rndahen pĂ«rmes rrjedhĂ«s file flush. Kjo Ă«shtĂ« njĂ« nga fushat e kodit, ku teknisht tĂ« gjitha rrjedhat e punĂ«s (worker threads) mund tĂ« bllokojnĂ« (block) tĂ« njĂ«jtin bllokim (lock), duke pĂ«rpiqun tĂ« mbushin buffer-in e memories.

Menaxhimi i lidhjeve (Connection handling)

Siç u diskutua shkurtimisht më sipër, të gjitha rrjedhat e punës dëgjojnë çdo dëgjues (listeners) pa ndonjë segmentim. Kështu, bërthama përdoret për dërgimin e duhur të soketeve të pranuara në rrjedhat e punës. Bërthamqat moderne në përgjithësi janë shumë të mira në këtë, ato përdorin funksione të tilla si rritja e përparësisë së hyrjes-daljes (IO), për të përpiqun të mbushin rrjedhën me punë, para se të fillojnë të përdorin rrjedha të tjera që gjithashtu dëgjojnë të njëjtin soket, si dhe për të mos përdorur bllokimin rrethues (Spinlock) për të trajtuar çdo kërkesë.
Sapo lidhja të pranohet në një rrjedhë pune (worker thread), ajo kurrë nuk largohet nga kjo rrjedhë (thread). Të gjitha përpunimet e mëtejshme të lidhjes trajtohen plotësisht në rrjedhën e punës (worker thread), duke përfshirë çdo sjellje dërguese (forwarding behavior).

Kjo ka disa pasoja të rëndësishme:

  • TĂ« gjitha grupe tĂ« lidhjeve nĂ« Envoy i pĂ«rkasin rrjedhĂ«s sĂ« punĂ«s. Prandaj, megjithĂ«se grupet e lidhjeve HTTP/2 krijojnĂ« vetĂ«m njĂ« lidhje me çdo host tĂ« lartĂ« nĂ« njĂ« kohĂ«, nĂ«se ka katĂ«r rrjedha pune, do tĂ« ketĂ« katĂ«r lidhje HTTP/2 me hostin e lartĂ« nĂ« njĂ« gjendje tĂ« qĂ«ndrueshme.
  • Arsyeja pse Envoy funksionon nĂ« kĂ«tĂ« mĂ«nyrĂ« Ă«shtĂ« se, duke e mbajtur gjithçka nĂ« njĂ« rrjedhĂ« pune, pothuajse e gjithĂ« kodi mund tĂ« shkruhet pa blloqe dhe siç duket se Ă«shtĂ« njĂ« njĂ«si punuese. Ky dizajn e thjeshton shkrimin e njĂ« sasi tĂ« madhe kodi dhe shkallĂ«zohet jashtĂ«zakonisht mirĂ« pĂ«r njĂ« numĂ«r pothuajse tĂ« pakufizuar rrjedhash punuese.
  • MegjithatĂ«, njĂ« nga pĂ«rfundimet kryesore Ă«shtĂ« se, nga pikĂ«pamja e efikasitetit, grupi i memories dhe lidhjeve nĂ« tĂ« vĂ«rtetĂ« Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme tĂ« konfigurohet parametri --konkurenca. TĂ« kesh mĂ« shumĂ« rrjedha pune sesa Ă«shtĂ« e nevojshme do tĂ« çojĂ« nĂ« humbje tĂ« memories, krijimin e mĂ« shumĂ« lidhjeve tĂ« papĂ«rdorura dhe uljen e shpejtĂ«sisĂ« sĂ« hyrjes nĂ« grupin e lidhjeve. NĂ« Lyft, konteinerit tanĂ« tĂ« envoy sidecar punojnĂ« me paralelizĂ«m shumĂ« tĂ« ulĂ«t, kĂ«shtu qĂ« performanca Ă«shtĂ« afĂ«rsisht nĂ« pĂ«rputhje me shĂ«rbimet pranĂ« tĂ« cilave ndodhen. Ne e ekzekutojmĂ« Envoy si njĂ« proxy tĂ« jashtĂ«m (edge) vetĂ«m kur ka maksimum paralelizmi (concurrency).

ÇfarĂ« do tĂ« thotĂ« mĂ«nyra jo bllokues

Termi "jo bllokues" është përdorur disa herë gjatë diskutimeve mbi mënyrën se si funksionojnë rrjedha kryesore dhe rrjedhat punuese. E gjithë kodi është shkruar me kushtin që asgjë kurrë nuk bllokohet. Megjithatë, këtë nuk është plotësisht e saktë (çfarë nuk është plotësisht e saktë?).

Envoy përdor disa bllokime të zgjatura të procesit:

  • Siç u pĂ«rmend mĂ« parĂ«, gjatĂ« regjistrimit tĂ« qasjes, tĂ« gjitha rrjedhat pune marrin tĂ« njĂ«jtin bllokim para se tĂ« mbushin tamponin e regjistrit nĂ« memorje. Koha e mbajtjes sĂ« bllokimit duhet tĂ« jetĂ« shumĂ« e ulĂ«t, por Ă«shtĂ« e mundur qĂ« ky bllokim tĂ« kontestohet me paralelizĂ«m tĂ« lartĂ« dhe kapacitet tĂ« lartĂ«.
  • Envoy pĂ«rdor njĂ« sistem shumĂ« tĂ« komplikuar pĂ«r tĂ« pĂ«rpunuar statistikĂ«n, i cili Ă«shtĂ« lokal pĂ«r rrjedhĂ«n. Kjo do tĂ« jetĂ« njĂ« temĂ« e njĂ« postimi tĂ« veçantĂ«. MegjithatĂ«, do ta pĂ«rmend shkurtimisht se si pjesĂ« e pĂ«rpunimit lokal tĂ« statistikĂ«s sĂ« rrjedhĂ«s, disa herĂ« kĂ«rkohet tĂ« merrni njĂ« bllokim pĂ«r "depon statistikore" qendrore. Ky bllokim nuk duhet kurrĂ« tĂ« kĂ«rkohet.
  • Rrjedha kryesore ka nevojĂ« periodikisht pĂ«r koordinim me tĂ« gjitha rrjedhat e punĂ«s. Kjo bĂ«het pĂ«rmes "publikimit" nga rrjedha kryesore nĂ« rrjedhat e punĂ«s, dhe ndonjĂ«herĂ« nga rrjedhat e punĂ«s prapa nĂ« rrjedhĂ«n kryesore. PĂ«r dĂ«rgimin kĂ«rkohet njĂ« bllokim, nĂ« mĂ«nyrĂ« qĂ« mesazhi i publikuar tĂ« mund tĂ« vihet nĂ« radhĂ« pĂ«r dorĂ«zim tĂ« mĂ«vonshĂ«m. KĂ«to bllokime kurrĂ« nuk duhet tĂ« pĂ«rballen me konkurrencĂ« serioze, por ato prapĂ« mund tĂ« bllokohen teknikisht.
  • Kur Envoy shkruan nĂ« ditarin e rrjedhĂ«s sĂ« gabimeve (standard error), ai merr njĂ« bllokim tĂ« gjithĂ« procesit. PĂ«r pĂ«rgjithĂ«si, regjistrimi lokal i Envoy konsiderohet i tmerrshĂ«m pĂ«r performancĂ«n, prandaj nuk i kushtohet shumĂ« vĂ«mendje pĂ«rmirĂ«simit tĂ« tij.
  • Ka disa bllokime tĂ« tjera rastĂ«sore, por asnjĂ«ra prej tyre nuk Ă«shtĂ« kritike pĂ«r performancĂ«n dhe nuk duhet kurrĂ« tĂ« kontestohet.

Depo lokale e rrjedhave (Thread local storage)

Në shkak të mënyrës se si Envoy ndan detyrat e rrjedhës kryesore nga detyrat e rrjedhës së punës, ekziston një kërkesë që përpunimi i komplikuar mund të bëhet në rrjedhën kryesore dhe pastaj t'i jepet secilës rrjedhë të punës me një shkallë të lartë paralelizmi. Në këtë seksion, përshkruhet sistemi i Envoy Thread Local Storage (TLS) në një nivel të lartë. Në seksionin tjetër, do ta përshkruaj se si përdoret për të menaxhuar klasterin.
[Përkthim] Modeli i rrjedhave të Envoy (Envoy threading model)

Siç është përshkruar më parë, rrjedha kryesore përpunon praktikisht të gjitha funksionet e menaxhimit dhe funksionalitetin e planit të kontrollit në procesin e Envoy. Plani i kontrollit këtu është paksa i ngarkuar, por nëse e shikoni atë brenda vetë procesit të Envoy dhe e krahasoni me përcjelljen që e bëjnë rrjedhat e punës, kjo duket e arsyeshme. Rregulli i përgjithshëm është që procesi i rrjedhës kryesore kryen një punë të caktuar dhe pastaj duhet të azhurnojë çdo rrjedhë pune sipas rezultatit të kësaj pune. në këtë mënyrë, rrjedha e punës nuk ka nevojë të vendosë bllokimin për çdo qasje.

Sistemi TLS (Storage i lokalizuar për thënit) Envoy punon si më poshtë:

  • Kodi qĂ« ekzekutohet nĂ« rrjedhĂ«n kryesore mund tĂ« ndajnĂ« njĂ« slot TLS pĂ«r tĂ« gjithĂ« procesin. Edhe pse kjo Ă«shtĂ« e abstraguar, nĂ« praktikĂ«, kjo Ă«shtĂ« njĂ« indeks nĂ« njĂ« vektor qĂ« siguron qasje O(1).
  • Rrjedha kryesore mund tĂ« vendosĂ« tĂ« dhĂ«na tĂ« arbitrave nĂ« slotin e saj. Kur bĂ«het kjo, tĂ« dhĂ«nat publikohen nĂ« çdo rrjedhĂ« pune si njĂ« ngjarje e zakonshme e ciklit tĂ« ngjarjeve.
  • Rrjedhat e punĂ«s mund tĂ« lexojnĂ« nga sloti i tyre TLS dhe tĂ« nxjerrin çdo tĂ« dhĂ«nĂ« lokale tĂ« rrjedhĂ«s qĂ« Ă«shtĂ« e disponueshme aty.

Edhe pse kjo është një paradigmë shumë e thjeshtë dhe jashtëzakonisht e fuqishme, që është shumë e ngjashme me konceptin e bllokimit RCU (Read-Copy-Update). Në thelb, rrjedhat e punës kurrë nuk shohin ndonjë ndryshim të të dhënave në slotet TLS gjatë ekzekutimit të punës. Ndryshimi ndodh vetëm në periudhën e pushimit midis ngjarjeve të punës.

Envoy e përdor këtë në dy mënyra të ndryshme:

  • Duke ruajtur tĂ« dhĂ«na tĂ« ndryshme nĂ« çdo rrjedhĂ« pune, qasja nĂ« kĂ«to tĂ« dhĂ«na bĂ«het pa asnjĂ« bllokim.
  • Duke ruajtur njĂ« tregues tĂ« pĂ«rbashkĂ«t pĂ«r tĂ« dhĂ«nat globale nĂ« modalitetin "vetĂ«m pĂ«r lexim" nĂ« çdo rrjedhĂ« pune. KĂ«shtu, çdo rrjedhĂ« pune ka njĂ« counter referencash pĂ«r tĂ« dhĂ«nat qĂ« nuk mund tĂ« reduktohet gjatĂ« ekzekutimit tĂ« punĂ«s. VetĂ«m kur tĂ« gjitha punĂ«torĂ«t tĂ« qetĂ«sohen dhe tĂ« ngarkojnĂ« tĂ« dhĂ«na tĂ« reja tĂ« pĂ«rbashkĂ«ta, tĂ« dhĂ«nat e vjetra do tĂ« shkatĂ«rrohen. Kjo Ă«shtĂ« identike me RCU.

Rrjedha e azhurnimit të klasterit (Cluster update threading)

Në këtë seksion, do të përshkruaj se si TLS (Storage i lokalizuar për thënit) përdoret për menaxhimin e klasterit. Menaxhimi i klasterit përfshin trajtimin e API xDS dhe / ose DNS, si dhe kontrollet e shëndetit (health checking).
[Përkthim] Modeli i rrjedhave të Envoy (Envoy threading model)

Menaxhimi i rrjedhave të klasterit përfshin komponentë dhe etapa si më poshtë:

  1. Menaxheri i klasterit është një komponent brenda Envoy, i cili menaxhon të gjitha upstream të njohura të klasterit, API-të CDS (Shërbimi i Zbulimit të Klasterit), API-të SDS (Shërbimi i Zbulimit të Sekreteve) dhe EDS (Shërbimi i Zbulimit të Pikave), DNS dhe kontrollet aktive të jashtme të shëndetit. Ai është përgjegjës për krijimin e një pamjeje "përfundimisht të qëndrueshme" (eventually consistent) për çdo upstream të klasterit, e cila përfshin hostet e zbuluara, si dhe statusin e shëndetit.
  2. Mjeti i kontrollit të gjendjes (health checker) kryen një verifikim aktiv të gjendjes dhe raporton ndryshimet e gjendjes së funksionimit te menaxheri i klasterit.
  3. CDS (Shërbimi i Zbulimit të Klasterit) / SDS (Shërbimi i Zbulimit të Sekreteve) / EDS (Shërbimi i Zbulimit të Pikave të Ndeshjes) / DNS realizohen për të përcaktuar përkatësinë në klaster. Ndryshimi i gjendjes kthehet te menaxheri i klasterit.
  4. Çdo thread pune kryen vazhdimisht njĂ« cikĂ«l tĂ« pĂ«rpunimit tĂ« ngjarjeve.
  5. Kur menaxheri i klasterit përcakton se gjendja për klasterin ka ndryshuar, krijon një imazh të ri të gjendjes së klasterit, të disponueshëm vetëm për lexim, dhe e dërgon atë në çdo thread pune.
  6. Gjatë periudhës së ardhshme të pushimit, thread-i i punës do të përditësojë imazhin në slot-in e dedikuar TLS.
  7. Gjatë një ngjarjeje input-output, e cila duhet të përcaktojë host-in për balancimin e ngarkesës, balancuesi i ngarkesës do të kërkojë slot-in TLS (Storage lokale e thread-it) për të marrë informacionin mbi host-in. Për këtë nuk nevojiten bllokime. Vini re gjithashtu se TLS mund të iniciojë ngjarje gjatë përditësimit, kështu që nën-sistemet e balancimit të ngarkesës dhe komponentët e tjerë mund të ripërkdhejnë cache-t, struktura të dhënash etj. Ky aspekt kalon përtej këtij postimi, por përdoret në vende të ndryshme në kod.

Duke përdorur procedurën e përshkruar më sipër, Envoy mund të përpunojë çdo kërkesë pa asnjë bllokim (përveç atyre të përmendura më parë). Përveç kompleksitetit të kodit TLS, pjesa më e madhe e kodit nuk ka nevojë të kuptojë se si funksionon multithreading dhe mund të shkruhet në një mod që një thread. Kjo lehtëson shkrimin e pjesës më të madhe të kodit përveç performancës së shkëlqyer.

Nën-sistemet e tjera që përdorin TLS

TLS (Storage lokale e thread-it) dhe RCU (Përditësimi i Leximit të Kopjes) përdoren gjerësisht në Envoy.

Shembuj të përdorimeve:

  • Mekanizmi i ndryshimit tĂ« funksionalitetit nĂ« kohĂ«n e ekzekutimit: Lista aktuale e funksionaliteteve tĂ« pĂ«rfshira llogaritet nĂ« thread-in kryesor. Pastaj, çdo thread pune merr njĂ« imazh vetĂ«m pĂ«r lexim duke pĂ«rdorur semantikĂ«n RCU.
  • ZĂ«vendĂ«simi i tabelave tĂ« ruteve: pĂ«r tabelat e rrugĂ«ve, tĂ« ofruara nga RDS (ShĂ«rbimi i Zbulimit tĂ« RrugĂ«ve), tabelat e rrugĂ«ve krijohen nĂ« rrjedhĂ«n kryesore. NjĂ« snapshot qĂ« lexon vetĂ«m do t'i ofrohet mĂ« vonĂ« çdo rrjedhe tĂ« punĂ«s duke pĂ«rdorur semantikĂ«n RCU (Lexo Kopshtin). Kjo e bĂ«n ndryshimin e tabelave tĂ« rrugĂ«ve efektiv nĂ« mĂ«nyrĂ« atomike.
  • Keshimi i titujve HTTP: Siç del, llogaritja e titullit HTTP pĂ«r çdo kĂ«rkesĂ« (me ~25K+ RPS pĂ«r bĂ«rthamĂ«) Ă«shtĂ« mjaft e shtrenjtĂ«. Envoy llogarit nĂ« mĂ«nyrĂ« qendrore titullin çdo gjysmĂ« sekonde dhe e ofron atĂ« pĂ«r çdo punĂ«tor pĂ«rmes TLS dhe RCU.

Ka edhe raste të tjera, por shembujt e mëparshëm duhet të ofrojnë një kuptim të mirë për përdorimin e TLS.

Kapricio të njohura të performancës

Megjithëse në përgjithësi Envoy funksionon mjaft mirë, ka disa zona të njohura që kërkojnë vëmendje kur përdoret me një paralelizmat të shumëfishta dhe kapacitet të lartë:

  • Siç Ă«shtĂ« pĂ«rshkruar nĂ« kĂ«tĂ« artikull, aktualisht tĂ« gjitha rrjedhat e punĂ«s marrin njĂ« bllokim kur shkruajnĂ« nĂ« memorien e caches tĂ« qasjes nĂ« log. Me njĂ« paralelizmat tĂ« lartĂ« dhe kapacitet tĂ« lartĂ«, do tĂ« jetĂ« e nevojshme tĂ« bĂ«het paketimi i logeve tĂ« qasjes pĂ«r secilĂ«n rrjedhĂ« tĂ« punĂ«s nĂ« krah tĂ« dĂ«rgimit tĂ« papĂ«rcaktuar kur shkruani nĂ« skedarin pĂ«rfundimtar. Si njĂ« alternativĂ«, mund tĂ« krijoni njĂ« log qasje pĂ«r secilĂ«n rrjedhĂ« tĂ« punĂ«s.
  • MegjithĂ«se statistikat janĂ« optimizuar shumĂ«, me njĂ« paralelizmat dhe kapacitet tĂ« lartĂ«, Ă«shtĂ« e mundur qĂ« do tĂ« ketĂ« konkurrencĂ« atomike mbi statistikĂ«n individuale. Zgjidhja e kĂ«saj problemi janĂ« numĂ«ruesit pĂ«r njĂ« rrjedhĂ« punĂ« me njĂ« rinisje periodike tĂ« numĂ«ruesve qendrorĂ«. Kjo do tĂ« diskutohet nĂ« postimin e mĂ«pasĂ«m.
  • Arkitektura ekzistuese nuk do tĂ« funksionojĂ« mirĂ« nĂ«se Envoy Ă«shtĂ« vendosur nĂ« njĂ« skenar, nĂ« tĂ« cilin ka shumĂ« pak lidhje, duke kĂ«rkuar tĂ« konsiderueshme pĂ«r burime pĂ«r procesim. Nuk ka garanci qĂ« lidhjet do tĂ« shpĂ«rndahen nĂ« mĂ«nyrĂ« tĂ« barabartĂ« midis rrjedhave tĂ« punĂ«s. Kjo mund tĂ« zgjidhet duke implementuar balancimin e lidhjeve tĂ« punĂ«s, ku do tĂ« implemetohet mundĂ«sia e ndarjes sĂ« lidhjeve midis rrjedhave tĂ« punĂ«s.

PĂ«rfundim

Modeli i horizonteve Envoy është zhvilluar për të siguruar thjeshtësi në programim dhe paralelizëm masiv përmes përdorimit potencialisht të tepruar të memories dhe lidhjeve, nëse ato nuk konfigurohen siç duhet. Ky model i lejon të funksionojë shumë mirë me një numër të lartë lidhjesh dhe gjerësish bandore.
Siç përmenda shkurtimisht në Twitter, dizajni gjithashtu mund të punojë mbi një pil të plotë rrjeti në mënyrën e përdoruesit, si DPDK (Data Plane Development Kit), që mund të rezultojë në servera të zakonshëm që trajtojnë miliona kërkesa në sekondë me përpunim të plotë të L7. Do të jetë shumë interesante të shohim se çfarë do të ndërtohet në vitet e ardhshme.
Një koment i fundit i shpejtë: Më shumë herë më është bërë pyetje përse zgjodhëm C++ për Envoy. Arsyetimi mbetet se është akoma gjuha e vetme e përhapur gjerësisht në nivel industrial, mbi të cilën mund të ngrihet arkitektura e përshkruar në këtë postim. C++ sigurisht që nuk është i përshtatshëm për të gjithë ose madje as për shumë projekte, por për raste të caktuara përdorimi është akoma mjeti i vetëm për të përfunduar punën.

Lidhjet me kodin

Lidhjet me skedarët e ndërfaqeve dhe implementimeve të titujve, të diskutuar në këtë postim:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster