Cyfieithiad o'r erthygl: Model edafu cennad - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Cefais yr erthygl hon yn eithaf diddorol, a chan fod Envoy yn cael ei ddefnyddio amlaf fel rhan o'r “istio” neu'n syml fel “rheolwr mynediad” kubernetes, nid oes gan y rhan fwyaf o bobl yr un rhyngweithio uniongyrchol ag ef ag, er enghraifft, â nodweddiadol Gosodiadau Nginx neu Haproxy. Fodd bynnag, os bydd rhywbeth yn torri, byddai'n dda deall sut mae'n gweithio o'r tu mewn. Ceisiais gyfieithu cymaint o'r testun â phosibl i Rwsieg, gan gynnwys geiriau arbennig; i'r rhai sy'n ei chael hi'n boenus i edrych ar hyn, gadewais y rhai gwreiddiol mewn cromfachau. Croeso i gath.

Mae dogfennaeth dechnegol lefel isel ar gyfer cronfa godau Envoy yn eithaf prin ar hyn o bryd. I unioni hyn, rwy'n bwriadu gwneud cyfres o bostiadau blog am wahanol is-systemau Envoy. Gan mai hon yw'r erthygl gyntaf, rhowch wybod i mi beth yw eich barn a beth allai fod o ddiddordeb i chi mewn erthyglau yn y dyfodol.

Un o'r cwestiynau technegol mwyaf cyffredin a gaf am Envoy yw gofyn am ddisgrifiad lefel isel o'r model edafu y mae'n ei ddefnyddio. Yn y swydd hon, byddaf yn disgrifio sut mae Envoy yn mapio cysylltiadau ag edafedd, yn ogystal â'r system Storio Lleol Thread y mae'n ei defnyddio'n fewnol i wneud cod yn fwy cyfochrog a pherfformiad uchel.

Trosolwg o edafu

Mae Cennad yn defnyddio tri math gwahanol o ffrydiau:

Prif: Mae'r edefyn hwn yn rheoli cychwyn a therfynu'r broses, yr holl brosesu o'r API XDS (xDiscovery Service), gan gynnwys DNS, gwirio iechyd, clwstwr cyffredinol a rheoli amser rhedeg, ailosod ystadegau, gweinyddu a rheoli prosesau cyffredinol - signalau Linux, ailgychwyn poeth, ac ati Popeth sy'n digwydd yn yr edefyn hwn yn asyncronaidd a "di-blocio". Yn gyffredinol, mae'r prif edefyn yn cydlynu'r holl brosesau ymarferoldeb hanfodol nad oes angen llawer iawn o CPU arnynt i'w rhedeg. Mae hyn yn caniatáu i'r rhan fwyaf o god rheoli gael ei ysgrifennu fel pe bai'n edafedd sengl.
Gweithiwr: Yn ddiofyn, mae Envoy yn creu edefyn gweithiwr ar gyfer pob edefyn caledwedd yn y system, gellir rheoli hyn gan ddefnyddio'r opsiwn --concurrency. Mae pob edefyn gweithiwr yn rhedeg dolen digwyddiad “di-flocio”, sy'n gyfrifol am wrando ar bob gwrandäwr; ar adeg ysgrifennu (Gorffennaf 29, 2017) nid oes unrhyw rwygo'r gwrandäwr, gan dderbyn cysylltiadau newydd, gan gychwyn pentwr hidlo ar gyfer y cysylltiad, a phrosesu'r holl weithrediadau mewnbwn/allbwn (IO) yn ystod oes y cysylltiad. Unwaith eto, mae hyn yn caniatáu i'r rhan fwyaf o god trin cysylltiad gael ei ysgrifennu fel pe bai'n edafedd sengl.
Fflysio ffeil: Ar hyn o bryd mae gan bob ffeil y mae Envoy yn ei hysgrifennu, logiau mynediad yn bennaf, edefyn blocio annibynnol. Mae hyn oherwydd y ffaith bod ysgrifennu at ffeiliau storio gan y system ffeiliau hyd yn oed wrth ddefnyddio O_NONBLOCK weithiau gall gael ei rwystro (ochchneidio). Pan fydd angen i edafedd gweithiwr ysgrifennu i ffeil, mae'r data'n cael ei symud i glustog yn y cof lle caiff ei fflysio trwy'r edefyn yn y pen draw fflysio ffeil. Mae hwn yn un maes o god lle yn dechnegol gall holl edafedd gweithiwr rwystro'r un clo wrth geisio llenwi byffer cof.

Trin cysylltiad

Fel y trafodwyd yn fyr uchod, mae holl edafedd gweithwyr yn gwrando ar bob gwrandäwr heb unrhyw ddarnio. Felly, defnyddir y cnewyllyn i anfon socedi derbyniol i edafedd gweithwyr yn osgeiddig. Yn gyffredinol, mae cnewyllyn modern yn dda iawn am hyn, maent yn defnyddio nodweddion fel hwb blaenoriaeth mewnbwn / allbwn (IO) i geisio llenwi edau â gwaith cyn iddynt ddechrau defnyddio edafedd eraill sydd hefyd yn gwrando ar yr un soced, a hefyd heb ddefnyddio robin crwn cloi (Spinlock) i brosesu pob cais.
Unwaith y bydd cysylltiad yn cael ei dderbyn ar edau gweithiwr, nid yw byth yn gadael yr edefyn hwnnw. Mae holl brosesu pellach y cysylltiad yn cael ei drin yn gyfan gwbl yn yr edefyn gweithiwr, gan gynnwys unrhyw ymddygiad anfon ymlaen.

Mae gan hyn nifer o ganlyniadau pwysig:

Mae pob pwll cysylltiad yn Envoy yn cael ei neilltuo i edefyn gweithiwr. Felly, er mai dim ond un cysylltiad y mae pyllau cysylltiad HTTP/2 yn ei wneud i bob gwesteiwr i fyny'r afon ar y tro, os oes pedwar llinyn gweithiwr, bydd pedwar cysylltiad HTTP/2 fesul gwesteiwr i fyny'r afon mewn cyflwr cyson.
Y rheswm pam mae Cennad yn gweithio fel hyn yw, trwy gadw popeth ar edau un gweithiwr, gellir ysgrifennu bron pob cod heb ei rwystro ac fel pe bai'n edafedd sengl. Mae'r dyluniad hwn yn ei gwneud hi'n hawdd ysgrifennu llawer o god a graddfeydd yn anhygoel o dda i nifer bron yn ddiderfyn o edafedd gweithwyr.
Fodd bynnag, un o'r prif siopau cludfwyd yw ei bod yn bwysig iawn, o safbwynt cronfa cof ac effeithlonrwydd cysylltiad, ffurfweddu'r --concurrency. Bydd cael mwy o edafedd gweithwyr nag sydd angen yn gwastraffu cof, yn creu mwy o gysylltiadau segur, ac yn lleihau cyfradd cronni cysylltiadau. Yn Lyft, mae ein cynwysyddion ceir ochr llysgennad yn rhedeg gyda chyfnewid arian isel iawn fel bod perfformiad yn cyfateb yn fras i'r gwasanaethau y maent yn eistedd wrth eu hymyl. Rydym yn rhedeg Envoy fel dirprwy ymyl yn unig ar yr arian cyfred uchaf.

Beth mae peidio â blocio yn ei olygu?

Mae'r term "di-flocio" wedi cael ei ddefnyddio sawl gwaith hyd yn hyn wrth drafod sut mae'r prif edafedd a'r gweithiwr yn gweithio. Mae'r holl god wedi'i ysgrifennu ar y dybiaeth nad oes dim yn cael ei rwystro erioed. Fodd bynnag, nid yw hyn yn hollol wir (beth sydd ddim yn hollol wir?).

Mae Cennad yn defnyddio sawl clo proses hir:

Fel y trafodwyd, wrth ysgrifennu logiau mynediad, mae pob edafedd gweithiwr yn caffael yr un clo cyn llenwi'r byffer log cof. Dylai'r amser dal clo fod yn isel iawn, ond mae'n bosibl i'r clo gael ei herio ar arian cyfred uchel a thrwybwn uchel.
Mae Cennad yn defnyddio system gymhleth iawn i drin ystadegau sy'n lleol i'r edefyn. Bydd hwn yn destun post ar wahân. Fodd bynnag, soniaf yn fyr, fel rhan o brosesu ystadegau edau yn lleol, weithiau bod angen caffael clo ar "storfa ystadegau" ganolog. Ni ddylai byth fod angen y cloi hwn.
Mae angen i'r prif edefyn o bryd i'w gilydd gydlynu â holl edafedd y gweithiwr. Gwneir hyn trwy "gyhoeddi" o'r prif edefyn i edafedd gweithiwr, ac weithiau o edafedd gweithwyr yn ôl i'r prif edefyn. Mae anfon yn gofyn am glo fel y gellir ciwio'r neges gyhoeddedig i'w hanfon yn ddiweddarach. Ni ddylid byth herio'r cloeon hyn o ddifrif, ond yn dechnegol gellir eu rhwystro o hyd.
Pan fydd Envoy yn ysgrifennu log i ffrwd gwallau'r system (gwall safonol), mae'n cael clo ar y broses gyfan. Yn gyffredinol, mae logio lleol Envoy yn cael ei ystyried yn ofnadwy o safbwynt perfformiad, felly nid oes llawer o sylw wedi'i roi i'w wella.
Mae yna ychydig o gloeon ar hap eraill, ond nid oes yr un ohonynt yn hollbwysig o ran perfformiad ac ni ddylid byth eu herio.

Edau storfa leol

Oherwydd y ffordd y mae Envoy yn gwahanu cyfrifoldebau'r prif edefyn oddi wrth gyfrifoldebau'r edefyn gweithiwr, mae gofyniad y gellir gwneud prosesu cymhleth ar y prif edefyn ac yna ei ddarparu i edau pob gweithiwr mewn modd cydamserol iawn. Mae'r adran hon yn disgrifio Storio Lleol Envoy Thread (TLS) ar lefel uchel. Yn yr adran nesaf byddaf yn disgrifio sut y caiff ei ddefnyddio i reoli clwstwr.

Fel y disgrifiwyd eisoes, mae'r prif edefyn yn ymdrin â bron yr holl swyddogaethau rheoli a rheoli awyrennau yn y broses Cennad. Mae'r awyren reoli wedi'i gorlwytho ychydig yma, ond pan edrychwch arno o fewn y broses Envoy ei hun a'i gymharu â'r anfon ymlaen y mae edafedd y gweithiwr yn ei wneud, mae'n gwneud synnwyr. Y rheol gyffredinol yw bod y brif broses edau yn gwneud rhywfaint o waith, ac yna mae angen iddo ddiweddaru pob llinyn gweithiwr yn ôl canlyniad y gwaith hwnnw. yn yr achos hwn, nid oes angen i'r edefyn gweithiwr gaffael clo ar bob mynediad.

Mae system TLS (Storfa leol Thread) Envoy yn gweithio fel a ganlyn:

Gall cod sy'n rhedeg ar y prif edefyn neilltuo slot TLS ar gyfer y broses gyfan. Er bod hwn yn cael ei dynnu, yn ymarferol mae'n fynegai i fector, sy'n darparu mynediad O(1).
Gall y prif edefyn osod data mympwyol yn ei slot. Pan wneir hyn, cyhoeddir y data i bob llinyn gweithiwr fel digwyddiad dolen digwyddiad arferol.
Gall edafedd gweithwyr ddarllen o'u slot TLS ac adfer unrhyw ddata edau-lleol sydd ar gael yno.

Er ei fod yn batrwm syml a hynod bwerus iawn, mae'n debyg iawn i'r cysyniad o rwystro RCU (Read-Copy-Update). Yn y bôn, nid yw edafedd gweithwyr byth yn gweld unrhyw newidiadau data yn y slotiau TLS tra bod gwaith yn rhedeg. Dim ond yn ystod y cyfnod gorffwys rhwng digwyddiadau gwaith y mae newid yn digwydd.

Mae Cennad yn defnyddio hyn mewn dwy ffordd wahanol:

Trwy storio data gwahanol ar edefyn pob gweithiwr, gellir cyrchu'r data heb unrhyw rwystro.
Trwy gynnal pwyntydd a rennir at ddata byd-eang yn y modd darllen yn unig ar edefyn pob gweithiwr. Felly, mae gan bob edefyn gweithiwr gyfrif cyfeirnod data na ellir ei ostwng tra bod y gwaith yn rhedeg. Dim ond pan fydd yr holl weithwyr yn ymdawelu ac yn uwchlwytho data newydd a rennir y bydd yr hen ddata yn cael ei ddinistrio. Mae hyn yn union yr un fath ag RCU.

Edafu diweddariad clwstwr

Yn yr adran hon, byddaf yn disgrifio sut y defnyddir TLS (Storfa leol Thread) i reoli clwstwr. Mae rheoli clwstwr yn cynnwys API xDS a/neu brosesu DNS, yn ogystal â gwirio iechyd.

Mae rheoli llif clwstwr yn cynnwys y cydrannau a'r camau canlynol:

Mae'r Rheolwr Clwstwr yn gydran o fewn Envoy sy'n rheoli pob clwstwr hysbys i fyny'r afon, y Gwasanaeth Darganfod Clwstwr (CDS) API, y Gwasanaeth Darganfod Cudd (SDS) a Gwasanaeth Darganfod Endpoint (EDS) APIs, DNS, a gwiriadau allanol gweithredol a gwirio iechyd. Mae'n gyfrifol am greu golwg "gyson yn y pen draw" o bob clwstwr i fyny'r afon, sy'n cynnwys gwesteiwyr a ddarganfuwyd yn ogystal â statws iechyd.
Mae’r gwiriwr iechyd yn cynnal gwiriad iechyd gweithredol ac yn adrodd am newidiadau statws iechyd i reolwr y clwstwr.
Perfformir CDS (Gwasanaeth Darganfod Clwstwr) / SDS (Gwasanaeth Darganfod Cyfrinachol) / EDS (Gwasanaeth Darganfod Endpoint) / DNS i bennu aelodaeth clwstwr. Dychwelir y newid cyflwr i'r rheolwr clwstwr.
Mae pob llinyn gweithiwr yn gweithredu dolen digwyddiad yn barhaus.
Pan fydd rheolwr y clwstwr yn penderfynu bod cyflwr clwstwr wedi newid, mae'n creu ciplun darllen yn unig newydd o gyflwr y clwstwr ac yn ei anfon at bob edefyn gweithiwr.
Yn ystod y cyfnod tawel nesaf, bydd yr edefyn gweithiwr yn diweddaru'r ciplun yn y slot TLS a neilltuwyd.
Yn ystod digwyddiad I / O sydd i fod i benderfynu ar y gwesteiwr i lwytho'r cydbwysedd, bydd y cydbwysydd llwyth yn gofyn am slot TLS (Storfa leol Thread) i gael gwybodaeth am y gwesteiwr. Nid oes angen cloeon ar hyn. Sylwch hefyd y gall TLS hefyd sbarduno digwyddiadau diweddaru fel y gall balanswyr llwyth a chydrannau eraill ailgyfrifo caches, strwythurau data, ac ati. Mae hyn y tu hwnt i gwmpas y swydd hon, ond fe'i defnyddir mewn amrywiol leoedd yn y cod.

Gan ddefnyddio'r weithdrefn uchod, gall Cennad brosesu pob cais heb unrhyw rwystro (ac eithrio fel y disgrifiwyd yn flaenorol). Ar wahân i gymhlethdod y cod TLS ei hun, nid oes angen i'r rhan fwyaf o'r cod ddeall sut mae multithreading yn gweithio a gellir ei ysgrifennu ag un edau. Mae hyn yn gwneud y rhan fwyaf o'r cod yn haws i'w ysgrifennu yn ogystal â pherfformiad uwch.

Is-systemau eraill sy'n defnyddio TLS

Defnyddir TLS (Storfa leol Thread) ac RCU (Read Copy Update) yn eang yn Envoy.

Enghreifftiau o ddefnydd:

Mecanwaith ar gyfer newid ymarferoldeb yn ystod gweithredu: Mae'r rhestr gyfredol o swyddogaethau wedi'u galluogi yn cael ei gyfrifo yn y prif edefyn. Yna rhoddir ciplun darllen yn unig i bob edefyn gweithiwr gan ddefnyddio semanteg RCU.
Amnewid tablau llwybr: Ar gyfer tablau llwybr a ddarperir gan RDS (Gwasanaeth Darganfod Llwybr), mae'r tablau llwybr yn cael eu creu ar y prif edefyn. Bydd y ciplun darllen yn unig wedyn yn cael ei ddarparu i bob edefyn gweithiwr gan ddefnyddio semanteg RCU (Read Copy Update). Mae hyn yn gwneud newid tablau llwybr yn atomig effeithlon.
caching pennyn HTTP: Fel mae'n digwydd, mae cyfrifo'r pennawd HTTP ar gyfer pob cais (wrth redeg ~ 25K + RPS fesul craidd) yn eithaf drud. Mae Cennad yn ganolog yn cyfrifo'r pennawd tua bob hanner eiliad ac yn ei roi i bob gweithiwr trwy TLS ac RCU.

Mae achosion eraill, ond dylai'r enghreifftiau blaenorol roi dealltwriaeth dda o'r hyn y defnyddir TLS ar ei gyfer.

Peryglon perfformiad hysbys

Er bod Envoy yn perfformio'n eithaf da ar y cyfan, mae yna rai meysydd nodedig y mae angen rhoi sylw iddynt pan gaiff ei ddefnyddio gyda arian cyfred a mewnbwn uchel iawn:

Fel y disgrifir yn yr erthygl hon, ar hyn o bryd mae pob edafedd gweithiwr yn caffael clo wrth ysgrifennu at y byffer cof log mynediad. Ar arian cyfred uchel a thrwybwn uchel, bydd angen i chi swpio'r logiau mynediad ar gyfer pob llinyn gweithiwr ar draul danfoniad allan-o-archeb wrth ysgrifennu at y ffeil derfynol. Fel arall, gallwch greu log mynediad ar wahân ar gyfer pob edefyn gweithiwr.
Er bod yr ystadegau wedi'u hoptimeiddio'n fawr, ar arian cyfred a thrwybwn uchel iawn mae'n debygol y bydd cynnen atomig ar ystadegau unigol. Yr ateb i'r broblem hon yw cownteri fesul llinyn gweithiwr gydag ailosod cownteri canolog o bryd i'w gilydd. Bydd hyn yn cael ei drafod mewn post dilynol.
Ni fydd y bensaernïaeth bresennol yn gweithio'n dda os caiff Envoy ei ddefnyddio mewn sefyllfa lle nad oes llawer o gysylltiadau sy'n gofyn am adnoddau prosesu sylweddol. Nid oes unrhyw sicrwydd y bydd cysylltiadau yn cael eu dosbarthu'n gyfartal rhwng edafedd gweithwyr. Gellir datrys hyn trwy weithredu cydbwyso cysylltiad gweithwyr, a fydd yn caniatáu cyfnewid cysylltiadau rhwng edafedd gweithwyr.

Casgliad

Mae model edafu Envoy wedi'i gynllunio i ddarparu rhwyddineb rhaglennu a chyfochredd enfawr ar draul cof a chysylltiadau a allai fod yn wastraffus os na chânt eu ffurfweddu'n gywir. Mae'r model hwn yn caniatáu iddo berfformio'n dda iawn ar gyfrif edau uchel iawn a thrwybwn.
Fel y soniais yn fyr ar Twitter, gall y dyluniad hefyd redeg ar ben pentwr rhwydweithio llawn modd defnyddiwr fel DPDK (Pecyn Datblygu Plane Data), a all arwain at weinyddion confensiynol yn trin miliynau o geisiadau yr eiliad gyda phrosesu L7 llawn. Bydd yn ddiddorol iawn gweld beth fydd yn cael ei adeiladu yn y blynyddoedd nesaf.
Un sylw cyflym olaf: Gofynnwyd i mi sawl gwaith pam y gwnaethom ddewis C++ ar gyfer Cennad. Erys y rheswm mai dyma'r unig iaith gradd ddiwydiannol a ddefnyddir yn eang o hyd y gellir adeiladu'r bensaernïaeth a ddisgrifir yn y swydd hon ynddi. Yn bendant nid yw C ++ yn addas ar gyfer pob un neu hyd yn oed lawer o brosiectau, ond ar gyfer rhai achosion defnydd, dyma'r unig offeryn o hyd i gyflawni'r swydd.

Dolenni i'r cod

Dolenni i ffeiliau gyda rhyngwynebau a gweithrediadau pennawd a drafodir yn y swydd hon:

Ffynhonnell: hab.com

[Cyfieithiad] Model edafu Cennad