Tafsiri ya makala: Muundo wa kuunganisha mjumbe - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Nilipata nakala hii ya kufurahisha sana, na kwa kuwa Mjumbe mara nyingi hutumiwa kama sehemu ya "istio" au kama "kidhibiti cha ingress" cha kubernetes, watu wengi hawana mwingiliano sawa wa moja kwa moja nayo kama, kwa mfano, na kawaida. Usakinishaji wa Nginx au Haproxy. Hata hivyo, ikiwa kitu kinavunjika, itakuwa nzuri kuelewa jinsi inavyofanya kazi kutoka ndani. Nilijaribu kutafsiri maandishi mengi kwa Kirusi iwezekanavyo, kutia ndani maneno maalum; kwa wale ambao wanaona kuwa ni chungu kutazama hili, niliacha asili kwenye mabano. Karibu paka.

Nyaraka za kiufundi za kiwango cha chini kwa msingi wa nambari ya Mjumbe kwa sasa ni chache sana. Ili kurekebisha hili, ninapanga kufanya safu ya machapisho ya blogi kuhusu mifumo ndogo ya Mjumbe. Kwa kuwa hii ndiyo makala ya kwanza, tafadhali nijulishe unachofikiri na kile ambacho unaweza kupendezwa nacho katika makala zijazo.

Mojawapo ya maswali ya kawaida ya kiufundi ninayopokea kuhusu Mjumbe ni kuuliza maelezo ya kiwango cha chini ya muundo wa nyuzi unaotumia. Katika chapisho hili, nitaelezea jinsi Mjumbe anavyoweka miunganisho kwenye nyuzi, na vile vile mfumo wa Hifadhi ya Ndani ya Thread unaotumia ndani kufanya msimbo ufanane zaidi na utendakazi wa hali ya juu.

Muhtasari wa thread

Mjumbe hutumia aina tatu tofauti za mitiririko:

Kuu: Mazungumzo haya hudhibiti uanzishaji na usitishaji wa mchakato, uchakataji wote wa API ya XDS (xDiscovery Service) ikijumuisha DNS, ukaguzi wa afya, usimamizi wa nguzo ya jumla na wakati wa utekelezaji, kuweka upya takwimu, usimamizi na usimamizi wa mchakato wa jumla - mawimbi ya Linux. anzisha upya motomoto, n.k. Kila kitu kinachotokea kwenye uzi huu ni asynchronous na "non-blocking". Kwa ujumla, thread kuu inaratibu michakato yote muhimu ya utendaji ambayo haihitaji kiasi kikubwa cha CPU kuendesha. Hii inaruhusu nambari nyingi za udhibiti kuandikwa kana kwamba zimeunganishwa moja.
Mfanyakazi: Kwa chaguo-msingi, Mjumbe huunda uzi wa mfanyakazi kwa kila uzi wa vifaa kwenye mfumo, hii inaweza kudhibitiwa kwa kutumia chaguo --concurrency. Kila uzi wa mfanyikazi huendesha kitanzi cha tukio "kisicho kuzuia", ambacho kina jukumu la kusikiliza kila msikilizaji; wakati wa kuandika (Julai 29, 2017) hakuna mgawanyiko wa msikilizaji, kukubali miunganisho mipya, kuanzisha rundo la chujio kwa muunganisho, na kuchakata shughuli zote za pembejeo/pato (IO) wakati wa uhai wa muunganisho. Tena, hii inaruhusu nambari nyingi za kushughulikia muunganisho kuandikwa kana kwamba zimeunganishwa moja.
Kisafishaji faili: Kila faili ambayo Mjumbe anaandika, haswa fikia kumbukumbu, kwa sasa ina uzi huru wa kuzuia. Hii ni kutokana na ukweli kwamba kuandika kwa faili zilizohifadhiwa na mfumo wa faili hata wakati wa kutumia O_NONBLOCK wakati mwingine inaweza kuzuiwa (kuugua). Wakati nyuzi za mfanyikazi zinahitaji kuandikia faili, data hiyo huhamishwa hadi kwenye buffer kwenye kumbukumbu ambapo mwishowe husafishwa kupitia uzi. safisha faili. Hili ni eneo moja la msimbo ambapo kitaalam nyuzi zote za wafanyikazi zinaweza kuzuia kufuli sawa wakati wa kujaribu kujaza akiba ya kumbukumbu.

Ushughulikiaji wa uunganisho

Kama ilivyojadiliwa kwa ufupi hapo juu, nyuzi zote za wafanyikazi husikiliza wasikilizaji wote bila kugawanyika. Kwa hivyo, kernel hutumiwa kutuma kwa neema soketi zilizokubaliwa kwa nyuzi za wafanyikazi. Kernels za kisasa kwa ujumla ni nzuri sana kwa hili, hutumia vipengee kama uongezaji wa kipaumbele wa pembejeo/pato (IO) kujaribu kujaza uzi na kazi kabla ya kuanza kutumia nyuzi zingine ambazo pia zinasikiza kwenye tundu moja, na pia kutotumia robin ya pande zote. kufunga (Spinlock) ili kuchakata kila ombi.
Mara tu muunganisho unapokubaliwa kwenye uzi wa mfanyakazi, hauachi kamwe uzi huo. Usindikaji wote zaidi wa muunganisho unashughulikiwa kabisa katika uzi wa mfanyakazi, ikiwa ni pamoja na tabia yoyote ya usambazaji.

Hii ina matokeo kadhaa muhimu:

Mabwawa yote ya uunganisho katika Mjumbe yamepewa uzi wa mfanyakazi. Kwa hivyo, ingawa vidimbwi vya muunganisho wa HTTP/2 hufanya muunganisho mmoja tu kwa kila mwenyeji wa mkondo wa juu kwa wakati mmoja, ikiwa kuna nyuzi nne za wafanyikazi, kutakuwa na miunganisho minne ya HTTP/2 kwa kila seva pangishi ya juu katika hali thabiti.
Sababu ya Mjumbe kufanya kazi kwa njia hii ni kwamba kwa kuweka kila kitu kwenye uzi mmoja wa mfanyakazi, karibu msimbo wote unaweza kuandikwa bila kuzuia na kana kwamba ni thread moja. Muundo huu hurahisisha kuandika nambari nyingi na mizani vizuri sana hadi idadi isiyo na kikomo ya nyuzi za wafanyikazi.
Walakini, moja ya njia kuu za kuchukua ni kwamba kutoka kwa bwawa la kumbukumbu na mtazamo wa ufanisi wa unganisho, kwa kweli ni muhimu sana kusanidi --concurrency. Kuwa na nyuzi nyingi zaidi za wafanyikazi kuliko inavyohitajika kutapoteza kumbukumbu, kuunda miunganisho isiyo na kazi zaidi, na kupunguza kasi ya uunganishaji wa miunganisho. Huko Lyft, makontena yetu ya kando ya wajumbe huendeshwa kwa sarafu ya chini sana ili utendakazi ulingane na huduma wanazokaa karibu nazo. Tunaendesha Mjumbe kama wakala wa ukingo tu kwa upatanifu wa juu zaidi.

Nini maana ya kutozuia?

Neno "kutokuzuia" limetumika mara kadhaa hadi sasa wakati wa kujadili jinsi nyuzi kuu na za wafanyikazi zinavyofanya kazi. Nambari zote zimeandikwa kwa kudhani kuwa hakuna kitu ambacho kimezuiwa. Hata hivyo, hii si kweli kabisa (nini si kweli kabisa?).

Mjumbe hutumia kufuli kadhaa ndefu za mchakato:

Kama ilivyojadiliwa, wakati wa kuandika kumbukumbu za ufikiaji, nyuzi zote za wafanyikazi hupata kufuli sawa kabla ya bafa ya kumbukumbu ya kumbukumbu kujazwa. Muda wa kushikilia kufuli unapaswa kuwa mdogo sana, lakini inawezekana kwa kufuli kupingwa kwa upatanifu wa juu na upitishaji wa juu.
Mjumbe hutumia mfumo changamano kushughulikia takwimu ambazo ni za ndani kwenye uzi. Hii itakuwa mada ya chapisho tofauti. Walakini, nitataja kwa ufupi kuwa kama sehemu ya usindikaji wa takwimu za nyuzi ndani ya nchi, wakati mwingine ni muhimu kupata kufuli kwenye "duka la takwimu". Ufungaji huu haupaswi kuhitajika kamwe.
Uzi kuu mara kwa mara unahitaji kuratibu na nyuzi zote za wafanyikazi. Hii inafanywa kwa "kuchapisha" kutoka kwa nyuzi kuu hadi nyuzi za mfanyakazi, na wakati mwingine kutoka kwa nyuzi za mfanyakazi kurudi kwenye thread kuu. Kutuma kunahitaji kufuli ili ujumbe uliochapishwa uweze kuwekwa kwenye foleni ili uwasilishwe baadaye. Kufuli hizi hazipaswi kupingwa vikali, lakini bado zinaweza kuzuiwa kiufundi.
Wakati Mjumbe anaandika logi kwenye mkondo wa makosa ya mfumo (kosa la kawaida), hupata kufuli kwenye mchakato mzima. Kwa ujumla, ukataji miti wa ndani wa Mjumbe unachukuliwa kuwa mbaya kutoka kwa mtazamo wa utendakazi, kwa hivyo haujazingatiwa sana kuiboresha.
Kuna kufuli zingine chache za nasibu, lakini hakuna kati ya hizo ambazo ni muhimu kwa utendaji na hazipaswi kupingwa kamwe.

Hifadhi ya ndani ya uzi

Kwa sababu ya jinsi Mjumbe anavyotenganisha majukumu ya thread kuu kutoka kwa majukumu ya thread ya mfanyakazi, kuna mahitaji kwamba usindikaji tata unaweza kufanywa kwenye thread kuu na kisha kutolewa kwa kila thread ya mfanyakazi kwa namna ya juu sana. Sehemu hii inaelezea Hifadhi ya Ndani ya Mjumbe (TLS) kwa kiwango cha juu. Katika sehemu inayofuata nitaelezea jinsi inavyotumika kusimamia nguzo.

Kama ilivyoelezwa tayari, uzi kuu hushughulikia karibu utendaji wote wa usimamizi na udhibiti wa ndege katika mchakato wa Mjumbe. Ndege ya udhibiti imejaa zaidi hapa, lakini unapoitazama ndani ya mchakato wa Mjumbe yenyewe na kuilinganisha na usambazaji ambao nyuzi za mfanyakazi hufanya, inaeleweka. Kanuni ya jumla ni kwamba mchakato kuu wa thread hufanya kazi fulani, na kisha inahitaji kusasisha kila thread ya mfanyakazi kulingana na matokeo ya kazi hiyo. katika kesi hii, thread ya mfanyakazi haina haja ya kupata lock kwenye kila upatikanaji.

Mfumo wa TLS wa Mjumbe (Uhifadhi wa ndani wa Thread) hufanya kazi kama ifuatavyo:

Msimbo unaoendeshwa kwenye uzi kuu unaweza kutenga nafasi ya TLS kwa mchakato mzima. Ingawa hii imetolewa, kwa mazoezi ni faharisi ndani ya vekta, kutoa ufikiaji wa O (1).
Thread kuu inaweza kusakinisha data kiholela kwenye yanayopangwa yake. Hili linapofanywa, data huchapishwa kwa kila uzi wa mfanyakazi kama tukio la kawaida la kitanzi.
Mazungumzo ya wafanyikazi yanaweza kusoma kutoka kwa nafasi yao ya TLS na kupata data yoyote ya ndani inayopatikana hapo.

Ingawa ni dhana rahisi sana na yenye nguvu sana, inafanana sana na dhana ya kuzuia RCU(Soma-Copy-Sasisho). Kimsingi, nyuzi za wafanyikazi haziwahi kuona mabadiliko yoyote ya data katika nafasi za TLS wakati kazi inaendelea. Mabadiliko hutokea tu wakati wa mapumziko kati ya matukio ya kazi.

Mjumbe hutumia hii kwa njia mbili tofauti:

Kwa kuhifadhi data tofauti kwenye kila uzi wa mfanyakazi, data inaweza kupatikana bila kuzuia yoyote.
Kwa kudumisha kielekezi kilichoshirikiwa kwa data ya kimataifa katika hali ya kusoma tu kwenye kila uzi wa mfanyakazi. Kwa hivyo, kila uzi wa mfanyakazi una hesabu ya kumbukumbu ya data ambayo haiwezi kupunguzwa wakati kazi inaendelea. Ni wakati tu wafanyikazi wote watakapotulia na kupakia data mpya iliyoshirikiwa ndipo data ya zamani itaharibiwa. Hii ni sawa na RCU.

Usasishaji wa nguzo

Katika sehemu hii, nitaelezea jinsi TLS (Uhifadhi wa ndani wa Thread) hutumiwa kudhibiti nguzo. Usimamizi wa nguzo hujumuisha API ya xDS na/au usindikaji wa DNS, pamoja na ukaguzi wa afya.

Usimamizi wa mtiririko wa nguzo unajumuisha vipengele na hatua zifuatazo:

Kidhibiti cha Nguzo ni kipengele ndani ya Mjumbe ambacho kinasimamia mikondo yote ya juu ya nguzo, API ya Huduma ya Ugunduzi wa Cluster (CDS), Huduma ya Siri ya Ugunduzi (SDS) na API za Endpoint Discovery Service (EDS), DNS, na ukaguzi wa nje unaoendelea. ukaguzi wa afya. Ina jukumu la kuunda mwonekano "hatimaye thabiti" wa kila nguzo ya mto, ambayo inajumuisha wapangishi waliogunduliwa na hali ya afya.
Mkaguzi wa afya hufanya ukaguzi wa afya na kuripoti mabadiliko ya hali ya afya kwa msimamizi wa nguzo.
CDS (Huduma ya Ugunduzi wa Nguzo) / SDS (Huduma ya Ugunduzi wa Siri) / EDS (Huduma ya Ugunduzi wa Sehemu ya Mwisho) / DNS hufanywa ili kubaini uanachama wa nguzo. Mabadiliko ya hali yanarejeshwa kwa msimamizi wa nguzo.
Kila uzi wa mfanyakazi huendelea kutekeleza kitanzi cha tukio.
Wakati msimamizi wa nguzo anaamua kuwa hali ya nguzo imebadilika, huunda picha mpya ya kusoma tu ya hali ya nguzo na kuituma kwa kila uzi wa mfanyakazi.
Katika kipindi kijacho tulivu, uzi wa mfanyakazi utasasisha muhtasari katika nafasi ya TLS iliyotengwa.
Wakati wa tukio la I/O ambalo linafaa kubainisha seva pangishi ili kupakia salio, kisawazisha kipakiaji kitaomba nafasi ya TLS (Uhifadhi wa ndani wa Thread) ili kupata maelezo kuhusu seva pangishi. Hii haihitaji kufuli. Kumbuka pia kuwa TLS inaweza pia kuanzisha matukio ya kusasisha ili visawazishaji vya upakiaji na vipengele vingine viweze kukokotoa upya akiba, miundo ya data, n.k. Hii ni zaidi ya upeo wa chapisho hili, lakini inatumika katika maeneo mbalimbali kwenye msimbo.

Kwa kutumia utaratibu ulio hapo juu, Mjumbe anaweza kushughulikia kila ombi bila kizuizi chochote (isipokuwa kama ilivyoelezwa hapo awali). Kando na utata wa msimbo wa TLS yenyewe, nambari nyingi za msimbo hazihitaji kuelewa jinsi usomaji mwingi unavyofanya kazi na unaweza kuandikwa kwa uzi mmoja. Hii hurahisisha zaidi kuandika msimbo pamoja na utendakazi bora.

Mifumo mingine midogo inayotumia TLS

TLS (Uhifadhi wa ndani wa Thread) na RCU (Soma Sasisho la Nakala) hutumiwa sana katika Mjumbe.

Mfano wa kutumia:

Utaratibu wa kubadilisha utendakazi wakati wa utekelezaji: Orodha ya sasa ya utendakazi uliowezeshwa inakokotolewa katika mnyororo mkuu. Kila uzi wa mfanyakazi hupewa muhtasari wa kusoma tu kwa kutumia semantiki za RCU.
Kubadilisha meza za njia: Kwa meza za njia zinazotolewa na RDS (Huduma ya Ugunduzi wa Njia), meza za njia zinaundwa kwenye thread kuu. Muhtasari wa kusoma tu baadaye utatolewa kwa kila mazungumzo ya mfanyakazi kwa kutumia semantiki za RCU (Soma Nakili Sasisho). Hii inafanya kubadilisha jedwali za njia kuwa na ufanisi wa atomiki.
Uakibishaji wa vichwa vya HTTP: Inavyobadilika, kuhesabu kichwa cha HTTP kwa kila ombi (huku inaendesha ~ 25K+ RPS kwa kila msingi) ni ghali kabisa. Mjumbe hukokotoa kichwa takriban kila nusu sekunde na humpa kila mfanyakazi kupitia TLS na RCU.

Kuna visa vingine, lakini mifano iliyotangulia inapaswa kutoa uelewa mzuri wa nini TLS inatumika.

Mitego ya utendaji inayojulikana

Ingawa Mjumbe anafanya kazi vizuri kwa ujumla, kuna maeneo machache mashuhuri ambayo yanahitaji kuzingatiwa inapotumiwa kwa upatanifu wa juu sana na matokeo:

Kama ilivyoelezewa katika nakala hii, kwa sasa nyuzi zote za wafanyikazi hupata kufuli wakati wa kuandika kwa bafa ya kumbukumbu ya ufikiaji. Kwa ulinganifu wa juu na upitishaji wa juu, utahitaji kuweka kumbukumbu za ufikiaji kwa kila uzi wa mfanyakazi kwa gharama ya uwasilishaji wa nje ya agizo wakati wa kuandika faili ya mwisho. Vinginevyo, unaweza kuunda logi tofauti ya ufikiaji kwa kila uzi wa mfanyakazi.
Ingawa takwimu zimeboreshwa sana, kwa upatanifu wa juu sana na upitishaji kunaweza kuwa na mzozo wa atomiki kwenye takwimu za mtu binafsi. Suluhisho la tatizo hili ni vihesabio kwa kila uzi wa mfanyakazi na kuweka upya mara kwa mara kaunta kuu. Hii itajadiliwa katika chapisho linalofuata.
Usanifu wa sasa hautafanya kazi vizuri ikiwa Mjumbe atatumwa katika hali ambapo kuna viunganisho vichache sana vinavyohitaji rasilimali muhimu za usindikaji. Hakuna hakikisho kwamba miunganisho itasambazwa sawasawa kati ya nyuzi za wafanyikazi. Hii inaweza kutatuliwa kwa kutekeleza kusawazisha kwa uunganisho wa mfanyakazi, ambayo itawawezesha kubadilishana uhusiano kati ya nyuzi za mfanyakazi.

Hitimisho

Muundo wa kuunganisha wa Mjumbe umeundwa ili kutoa urahisi wa upangaji na usawazishaji mkubwa kwa gharama ya kumbukumbu na miunganisho inayoweza kuharibu ikiwa haijasanidiwa ipasavyo. Mtindo huu unairuhusu kufanya vizuri sana kwa hesabu za juu sana za nyuzi na upitishaji.
Kama nilivyotaja kwa ufupi kwenye Twitter, muundo huo unaweza pia kukimbia juu ya safu kamili ya mtandao wa hali ya watumiaji kama vile DPDK (Kifaa cha Kukuza Data ya Ndege), ambayo inaweza kusababisha seva za kawaida kushughulikia mamilioni ya maombi kwa sekunde na usindikaji kamili wa L7. Itakuwa ya kuvutia sana kuona nini kinajengwa katika miaka michache ijayo.
Maoni moja ya mwisho haraka: Nimeulizwa mara nyingi kwa nini tulichagua C++ kwa Mjumbe. Sababu inabakia kuwa bado ni lugha pekee ya daraja la viwanda inayotumika sana ambayo usanifu ulioelezewa katika chapisho hili unaweza kujengwa. C++ hakika haifai kwa miradi yote au hata mingi, lakini kwa hali fulani za utumiaji bado ndio zana pekee ya kukamilisha kazi.

Viungo kwa msimbo

Viungo vya faili zilizo na miingiliano na utekelezaji wa vichwa vilivyojadiliwa katika chapisho hili:

Chanzo: mapenzi.com

[Tafsiri] Muundo wa kuunganisha mjumbe