[Translation] Model threading utusan

Terjemahan artikel: Model threading utusan - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

Aku nemokake artikel iki cukup menarik, lan wiwit Utusan paling asring digunakake minangka bagéan saka "istio" utawa mung minangka "ingress controller" saka kubernetes, paling wong ora duwe interaksi langsung padha karo, contone, karo instalasi Nginx utawa Haproxy khas. Nanging, yen ana sing rusak, luwih becik sampeyan ngerti carane disusun saka njero. Aku nyoba kanggo nerjemahake minangka akeh teks sabisa menyang Rusian, kalebu tembung khusus, kanggo wong-wong sing nemokake iku nglarani kanggo ndeleng iki, aku ninggalake asli ing kurung. Sugeng rawuh ing ngisor potong.

Dokumentasi teknis tingkat rendah kanggo basis kode Utusan saiki cukup jarang. Kanggo ngatasi masalah iki, aku arep nggawe serangkaian postingan blog babagan macem-macem subsistem Utusan. Amarga iki minangka kiriman pisanan, muga-muga aku ngerti apa sing sampeyan pikirake lan apa sing sampeyan minati ing kiriman sabanjure.

Salah sawijining pitakonan teknis sing paling umum sing daktampa babagan Utusan yaiku panjaluk katrangan tingkat rendah babagan model threading sing digunakake. Ing kirim iki, aku bakal njlèntrèhaké carane Utusan peta sambungan kanggo Utas, uga gambaran saka sistem Panyimpenan Lokal Utas digunakake internal kanggo nggawe kode luwih podo lan performant.

Ringkesan threading

[Translation] Model threading utusan

Utusan nggunakake telung jinis aliran:

  • Utama: Utas iki ngatur wiwitan lan pambusakan proses, kabeh pamrosesan API XDS (xDiscovery Service), kalebu DNS, pamriksan kesehatan, manajemen kluster lan runtime umum, reset statistik, administrasi, lan manajemen proses umum. Linux Sinyal, restart panas, lan liya-liyane. Kabeh sing kedadeyan ing thread iki asinkron lan ora ngalangi. Sakabèhé, thread utama ngkoordinasi kabeh proses penting sing ora mbutuhake CPU gedhe. Iki ngidini umume kode kontrol ditulis kaya-kaya single-threaded.
  • buruh: Kanthi gawan, Utusan nggawe thread buruh kanggo saben thread hardware ing sistem, iki bisa kontrol karo pilihan --concurrencySaben thread buruh mbukak loop acara "non-blocking" sing tanggung jawab kanggo ngrungokake saben pamireng (ora ana sharding pamireng nalika nulis (29 Juli 2017)), nampa sambungan anyar, instantiating tumpukan filter kanggo sambungan, lan nangani kabeh IO kanggo umur sambungan. Maneh, iki ngidini paling kode nangani sambungan bisa ditulis minangka yen padha siji-Utas.
  • File flusher: Saben file sing ditulis Utusan, utamane ngakses log, saiki duwe benang ngunci independen. Iki amarga nulis menyang file sing di-cache dening sistem file, sanajan nggunakake O_NONBLOCK sok bisa ngalang-alangi (ngiyup). Nalika thread buruh kudu nulis menyang file, data kasebut bener-bener dipindhah menyang buffer ing memori, sing pungkasane dibuang liwat benang. file flush. Iki minangka salah sawijining area kode sing sacara teknis kabeh benang pekerja bisa mblokir kunci sing padha nalika nyoba ngisi buffer memori.

Penanganan sambungan

Kaya sing wis dibahas ing ndhuwur, kabeh thread buruh ngrungokake kabeh pamireng tanpa segmentasi. Kernel digunakake kanggo ngirim soket sing ditampa kanthi apik menyang benang pekerja. Kernel modern umume apik banget, nggunakake fitur kayata IO boosting kanggo nyoba ngisi benang kanthi karya sadurunge benang liyane sing uga ngrungokake soket sing padha wiwit nggunakake, lan ora nggunakake spinlock kanggo nangani saben panjaluk.
Sawise sambungan ditampa ing benang buruh, ora bakal ninggalake benang kasebut. Kabeh pangolahan luwih saka sambungan ditangani kabeh ing thread buruh, kalebu prilaku nerusake.

Iki duwe sawetara akibat penting:

  • Kabeh blumbang sambungan ing Utusan saben thread buruh. Dadi, nalika blumbang sambungan HTTP / 2 mung nggawe siji sambungan menyang saben host hulu sekaligus, yen ana papat benang pekerja, bakal ana papat sambungan HTTP / 2 saben host hulu ing kahanan ajeg.
  • Alesane Utusan dianggo kanthi cara iki yaiku kanthi nyimpen kabeh ing benang buruh siji, meh kabeh kode bisa ditulis tanpa kunci lan kaya benang tunggal. Desain iki nggampangake nulis akeh kode lan timbangan kanthi apik kanggo benang buruh sing meh ora ana watesan.
  • Nanging, salah siji saka takeaways utama yaiku saka blumbang memori lan perspektif efisiensi sambungan, iku penting banget kanggo nyetel parameter. --concurrencyNduwe benang pekerja sing luwih akeh tinimbang sing dibutuhake bakal mbuang memori, nggawe sambungan sing ora aktif, lan nyuda tingkat sambungan ing kolam sambungan. Ing Lyft, wadhah sidecar utusan kita mlaku kanthi konkurensi sing sithik banget, saengga kinerja kira-kira cocog karo layanan sing ana ing jejere. Kita mung mbukak Utusan minangka proksi pinggiran kanthi konkurensi maksimal.

Apa tegese non-blocking

Istilah "non-blocking" wis digunakake kaping pirang-pirang nganti saiki nalika ngrembug babagan cara kerja utas utama lan buruh. Kabeh kode ditulis kanthi asumsi yen ora ana sing ngalangi. Nanging, iki ora bener (apa sing ora bener?).

Utusan nggunakake sawetara kunci proses dawa:

  • Kaya sing kasebut, nalika nulis log akses, kabeh benang pekerja entuk kunci sing padha sadurunge ngisi buffer log ing memori. Wektu penylametan kunci kudu sithik banget, nanging bisa uga kunci iki bakal dilawan miturut konkurensi sing dhuwur lan throughput sing dhuwur.
  • Utusan nggunakake sistem banget canggih kanggo nangani statistik sing lokal kanggo thread. Iki bakal dadi topik kiriman sing kapisah. Nanging, aku bakal sebutno sedhela sing minangka bagéan saka nangani statistik thread-lokal, iku kadhangkala perlu kanggo ndarbeni kunci ing tengah "toko stats". Kunci iki ora bakal dibutuhake.
  • Utas utama sacara periodik kudu koordinasi karo kabeh benang pekerja. Iki ditindakake kanthi "nerbitake" saka utas utama menyang utas buruh, lan kadhangkala saka utas buruh bali menyang utas utama. Ngirim mbutuhake kunci supaya pesen sing diterbitake bisa antri kanggo pangiriman mengko. Kunci kasebut ora bakal kena pengaruh serius, nanging isih bisa diblokir kanthi teknis.
  • Nalika Envoy nulis log menyang stream kesalahan sistem (kesalahan standar), entuk kunci proses. Umumé, logging lokal Utusan dianggep nggegirisi saka sudut pandang kinerja, mula ora ana perhatian sing dibayar kanggo nambah.
  • Ana sawetara kunci acak liyane, nanging ora ana sing kritis kinerja lan ora kudu ditantang.

Utas panyimpenan lokal

Amarga cara Utusan misahake tanggung jawab utas utama saka tanggung jawab utas buruh, ana syarat supaya pangolahan kompleks bisa ditindakake ing utas utama banjur dikirim menyang saben benang buruh kanthi tingkat paralelisme sing dhuwur. Bagean iki nggambarake sistem Panyimpenan Lokal Utas (TLS) Utusan ing tingkat dhuwur. Ing bagean sabanjure, aku nerangake carane digunakake kanggo ngatur cluster.
[Translation] Model threading utusan

Kaya sing kasebut ing ndhuwur, benang utama nangani meh kabeh fungsi manajemen lan kontrol pesawat ing proses Utusan. Pesawat kontrol rada nduwur sirah ing kene, nanging yen dideleng ing proses Utusan kasebut dhewe lan dibandhingake karo penerusan sing ditindakake dening benang pekerja, mula ana akal. Aturan umum yaiku proses utas utama nindakake sawetara pakaryan, banjur kudu nganyari saben utas buruh kanthi asil karya kasebut, cara iki thread buruh ora perlu nyetel kunci ing saben akses.

Sistem TLS (Thread local storage) Envoy dianggo kaya ing ngisor iki:

  • Kode sing mlaku ing utas utama bisa nyedhiyakake slot TLS kanggo kabeh proses. Senajan iki abstrak, ing laku iku indeks menyang vektor, menehi akses O (1).
  • Utas utama bisa nyetel data kasepakatan menyang slot. Yen wis rampung, data diterbitake kanggo saben thread buruh minangka acara daur ulang normal.
  • Utas pekerja bisa maca saka slot TLS lan njupuk data lokal benang sing kasedhiya ing kana.

Sanajan paradigma sing gampang banget lan luar biasa kuat, meh padha karo konsep kunci RCU (Read-Copy-Update). Ateges, benang pekerja ora nate ndeleng owah-owahan ing data ing slot TLS nalika lagi nindakake pakaryan. Owah-owahan mung kedadeyan sajrone wektu sepi ing antarane acara kerja.

Utusan nggunakake iki kanthi rong cara:

  • Kanthi nyimpen data sing beda ing saben thread buruh, data iki bisa diakses tanpa ngunci.
  • Kanthi tetep pointer sing dienggo bareng menyang data global ing mode mung diwaca ing saben thread buruh. Kanthi cara iki, saben thread pegawe duwe nomer referensi kanggo data sing ora bisa suda nalika karya lagi mlaku. Mung nalika kabeh buruh wis calmed mudhun lan dimuat data sambungan anyar, data lawas numpes. Iki padha karo RCU.

Cluster nganyari threading

Ing bagean iki aku bakal njlèntrèhaké carane TLS (Thread panyimpenan lokal) digunakake kanggo Manajemen kluster. Manajemen kluster kalebu nangani xDS lan/utawa API DNS, uga mriksa kesehatan.
[Translation] Model threading utusan

Manajemen aliran cluster kalebu komponen lan tahapan ing ngisor iki:

  1. Manajer kluster minangka komponen ing Envoy sing ngatur kabeh hulu kluster sing dikenal, API Layanan Penemuan Kluster (CDS), API Layanan Penemuan Rahasia (SDS) lan Layanan Penemuan Titik Akhir (EDS), DNS, lan pamriksa kesehatan eksternal sing aktif. Tanggung jawab kanggo nggawe tampilan "pungkasane konsisten" saben klompok hulu, sing kalebu host sing ditemokake uga status kesehatan.
  2. Pemeriksa kesehatan nindakake pemeriksaan kesehatan aktif lan nglaporake owah-owahan status kesehatan menyang manajer kluster.
  3. CDS (Layanan Penemuan Kluster) / SDS (Layanan Penemuan Rahasia) / EDS (Layanan Penemuan Titik Akhir) / DNS ditindakake kanggo nemtokake anggota kluster. Owah-owahan negara bali menyang manajer kluster.
  4. Saben thread buruh terus-terusan mbukak loop pangolahan acara.
  5. Nalika manajer kluster nemtokake negara kanggo kluster wis diganti, nggawe snapshot mung diwaca saka negara kluster lan dikirim menyang saben thread buruh.
  6. Sajrone periode sepi sabanjuré, thread buruh bakal nganyari snapshot ing slot TLS diparengake.
  7. Sajrone acara I/O sing kudu nemtokake host sing bakal mbukak imbangan, load balancer bakal takon slot TLS (Thread local storage) kanggo entuk informasi babagan host. Iki ora mbutuhake kunci. Elinga uga TLS uga bisa micu acara refresh, supaya load balancers lan komponen liyane bisa recalculate caches, struktur data, etc.. Iki njaba orane katrangan saka kirim iki, nanging digunakake ing macem-macem panggonan ing kode.

Nggunakake prosedur ing ndhuwur, Utusan bisa nangani saben panjalukan tanpa pamblokiran (liyane saka sing wis diterangake sadurunge). Saliyane kerumitan kode TLS dhewe, umume kode kasebut ora perlu ngerti cara kerja multithreading lan bisa ditulis ing mode single-threaded. Iki nggawe paling kode luwih gampang kanggo nulis saliyane kinerja banget.

Subsistem liyane sing nggunakake TLS

TLS (Thread local storage) lan RCU (Read Copy Update) digunakake sacara ekstensif ing Utusan.

Tuladhane nggunakake:

  • Mekanisme kanggo ngganti fungsi sajrone eksekusi: Dhaptar fungsi aktif saiki diwilang ing utas utama. Saben utas buruh banjur diwenehake snapshot mung diwaca nggunakake semantik RCU.
  • Ngganti tabel rute: Kanggo tabel rute sing diwenehake dening RDS (Route Discovery Service), tabel rute digawe ing utas utama. A snapshot mung diwaca banjur diwenehake kanggo saben thread buruh nggunakake semantik RCU (Read Copy Update). Iki ndadekake modifikasi kanggo rute tabel kanthi efisien atom.
  • Caching Header HTTP: Ternyata, ngitung header HTTP kanggo saben panyuwunan (mlaku ~ 25K + RPS saben inti) cukup larang. Utusan tengah ngitung header kira-kira saben setengah detik lan nyedhiyakake kanggo saben buruh liwat TLS lan RCU.

Ana kasus liyane, nanging conto sadurunge kudu menehi pangerten sing apik babagan apa sing digunakake TLS.

pitfalls kinerja dikenal

Nalika Utusan umume nindakake kanthi apik, ana sawetara wilayah sing dikenal sing mbutuhake perhatian nalika digunakake kanthi konkurensi lan throughput sing dhuwur banget:

  • Kaya sing diterangake ing artikel iki, saiki kabeh benang pekerja entuk kunci nalika nulis menyang buffer memori log akses. Ing concurrency dhuwur lan skenario throughput dhuwur, iku bakal perlu kanggo kumpulan log akses kanggo saben thread buruh ing beyo saka pangiriman out-of-order nalika nulis menyang file final. Utawa, log akses sing kapisah bisa digawe kanggo saben thread buruh.
  • Sanajan statistik kasebut dioptimalake banget, kanthi konkurensi lan throughput sing dhuwur banget, bakal ana kontroversi atom ing statistik individu. Solusi kanggo masalah iki counters saben thread buruh karo periodik ngreset counters tengah. Iki bakal dibahas ing kirim sabanjure.
  • Arsitektur saiki ora bakal bisa digunakake kanthi apik yen Utusan disebarake ing skenario sing ana sawetara sambungan sing mbutuhake sumber daya sing penting kanggo diproses. Ora ana jaminan manawa sambungan bakal disebarake kanthi rata ing antarane benang pekerja. Iki bisa ditanggulangi kanthi ngleksanakake keseimbangan sambungan pekerja, sing bakal ngidini sambungan bisa diganti ing antarane benang pekerja.

Kesimpulan

Model threading utusan dirancang kanggo nyedhiyakake pemrograman lan paralelisme massive kanthi biaya memori lan sambungan sing bisa boros yen ora dikonfigurasi kanthi bener. Model iki ngidini kanggo nindakake banget ing counts thread dhuwur lan throughput.
Kaya sing dakcritakake ing Twitter, desain kasebut uga bisa mlaku ing ndhuwur tumpukan jaringan mode pangguna lengkap kaya DPDK (Data Plane Development Kit), sing bisa nyebabake server komoditas nangani mayuta-yuta panjalukan per detik kanthi proses L7 lengkap. Bakal menarik banget kanggo ndeleng apa sing dibangun ing sawetara taun sabanjure.
Siji komentar cepet pungkasan: Aku wis takon kaping pirang-pirang kok kita milih C ++ kanggo Utusan. Alesane tetep dadi siji-sijine basa kelas produksi sing bisa digunakake kanggo mbangun arsitektur sing diterangake ing kirim iki. C ++ temtunipun ora nengen kanggo kabeh utawa malah akeh proyèk, nanging kanggo kasus panggunaan tartamtu iku isih mung alat kanggo njaluk proyek rampung.

Pranala menyang kode

Link menyang file kanthi antarmuka lan implementasi header sing dibahas ing kirim iki:

Source: www.habr.com

Tuku hosting sing dipercaya kanggo situs kanthi proteksi DDoS, server VPS VDS 🔥 Tuku hosting situs web sing bisa dipercaya nganggo proteksi DDoS, server VPS VDS | ProHoster