Nalika kita pindhah saka aplikasi monolitik menyang arsitektur microservices, kita ngadhepi tantangan anyar.
Ing aplikasi monolitik, biasane cukup gampang kanggo nemtokake bagean sistem sing ana kesalahan. Paling kamungkinan, masalah ana ing kode saka monolith dhewe, utawa ing database. Nanging nalika kita miwiti nggoleki masalah ing arsitektur microservice, kabeh ora ketok. Kita kudu nemokake kabeh path sing dijaluk saka wiwitan nganti rampung lan pilih saka atusan microservices. Kajaba iku, akeh uga duwe fasilitas panyimpenan dhewe, sing uga bisa nyebabake kesalahan logis, uga masalah kinerja lan toleransi kesalahan.
Aku wis suwe nggoleki alat sing bakal mbantu ngatasi masalah kasebut (Aku nulis babagan iki ing Habré: , ), nanging ing pungkasan aku nggawe solusi open source dhewe. Ing artikel iki aku ngomong babagan keuntungan saka pendekatan bolong layanan lan nuduhake alat anyar kanggo implementasine.
Tilak sing disebarake minangka solusi umum kanggo masalah nemokake kesalahan ing sistem sing disebarake. Nanging apa yen pendekatan iki kanggo ngumpulake informasi babagan interaksi jaringan durung dileksanakake ing sistem, utawa, luwih elek, ing bagean saka sistem wis bisa mlaku kanthi bener, nanging sawetara ora, amarga durung ditambahake menyang layanan lawas. ? Kanggo nemtokake panyebab sing bener saka masalah, perlu duwe gambaran lengkap babagan apa sing kedadeyan ing sistem kasebut. Penting banget kanggo ngerti layanan mikro sing melu ing jalur kritis bisnis utama.
Ing kene pendekatan bolong layanan bisa mbantu kita, sing bakal ngatasi kabeh mesin kanggo ngumpulake informasi jaringan ing tingkat sing luwih murah tinimbang layanan sing ditindakake. Pendekatan iki ngidini kita nyegat kabeh lalu lintas lan nganalisa kanthi cepet. Kajaba iku, aplikasi ora kudu ngerti apa-apa.
Pendekatan mesh layanan
Gagasan utama pendekatan bolong layanan yaiku nambah lapisan infrastruktur liyane ing jaringan, sing bakal ngidini kita nindakake apa wae kanthi interaksi antar layanan. Umume implementasine kaya ing ngisor iki: wadhah sidecar tambahan kanthi proxy transparan ditambahake ing saben layanan mikro, sing liwati kabeh lalu lintas mlebu lan metu saka layanan kasebut. Lan iki minangka papan sing bisa nggawe keseimbangan klien, ngetrapake kabijakan keamanan, ngetrapake watesan babagan jumlah panjaluk lan ngumpulake informasi penting babagan interaksi layanan ing produksi.
Solusi
Ana sawetara implementasine saka pendekatan iki: и . Dheweke nyedhiyakake akeh fitur sing metu saka kothak. Nanging ing wektu sing padha, ana overhead gedhe ing sumber daya. Kajaba iku, luwih gedhe kluster ing ngendi sistem kasebut beroperasi, luwih akeh sumber daya sing dibutuhake kanggo njaga infrastruktur anyar. Ing Avito, kita ngoperasikake kluster kubernetes sing ngemot ewonan instansi layanan (lan jumlahe terus berkembang kanthi cepet). Ing implementasine saiki, Istio nganggo ~300Mb RAM saben conto layanan. Amarga akeh kemungkinan, imbangan transparan uga mengaruhi wektu respon sakabèhé layanan (nganti 10ms).
Akibaté, kita ndeleng persis apa kapabilitas sing kita butuhake saiki, lan mutusake manawa alasan utama kenapa kita miwiti ngetrapake solusi kasebut yaiku kemampuan kanggo ngumpulake informasi nelusuri saka kabeh sistem kanthi transparan. Kita uga pengin ngontrol interaksi layanan lan nindakake macem-macem manipulasi karo header sing ditransfer ing antarane layanan.
Akibaté, kita njupuk keputusan: .
Netramesh
iku solusi bolong layanan entheng karo kemampuan kanggo ukuran tanpa wates, preduli saka nomer layanan ing sistem.
Tujuan utama solusi anyar yaiku overhead sumber daya sing kurang lan kinerja dhuwur. Antarane fitur utama, kita langsung pengin bisa ngirim tracing kanthi transparan menyang sistem Jaeger kita.
Saiki, umume solusi awan dileksanakake ing Golang. Lan, mesthi, ana alasan kanggo iki. Nulis aplikasi jaringan ing Golang sing makarya kanthi asynchronously karo I/O lan skala antarane intine sing dibutuhake trep lan cukup prasaja. Lan, sing penting banget, kinerja cukup kanggo ngatasi masalah iki. Mula uga milih Golang.
Produktivitas
Kita wis fokus usaha kanggo nggayuh produktivitas maksimal. Kanggo solusi sing disebarake ing jejere saben conto layanan kasebut, konsumsi RAM lan wektu CPU sing cilik dibutuhake. Lan, mesthi, wektu tundha respon uga kudu cilik.
Ayo ndeleng apa asil sing dipikolehi.
Ram
Netramesh nganggo ~10Mb tanpa lalu lintas lan maksimal 50Mb kanthi muatan nganti 10000 RPS saben conto.
Proksi utusan Istio tansah nganggo ~300Mb ing kluster kita kanthi ewonan instan. Iki ora ngidini kanggo skala kanggo kabeh kluster.
Kanthi Netramesh kita entuk ~ 10x pangurangan ing konsumsi memori.
CPU
Panggunaan CPU relatif padha ing beban. Iku gumantung ing nomer panjalukan saben unit wektu kanggo sidecar. Nilai ing 3000 panjalukan saben detik ing puncak:
Ana siji titik sing luwih penting: Netramesh - solusi tanpa bidang kontrol lan tanpa beban ora nganggo wektu CPU. Kanthi Istio, sidecars tansah nganyari titik pungkasan layanan. Akibaté, kita bisa ndeleng gambar iki tanpa mbukak:
Kita nggunakake HTTP / 1 kanggo komunikasi antarane layanan. Tambah wektu nanggepi kanggo Istio nalika proxying liwat utusan nganti 5-10ms, sing cukup akeh kanggo layanan sing siap nanggapi ing milidetik. Kanthi Netramesh wektu iki wis suda dadi 0.5-2ms.
Skalabilitas
Jumlah cilik saka sumber daya sing digunakake dening saben proxy ndadekake iku bisa kanggo diselehake ing jejere saben layanan. Netramesh sengaja digawe tanpa komponen bidang kontrol supaya saben sidecar tetep entheng. Asring ing solusi bolong layanan, pesawat kontrol nyebarake informasi panemuan layanan menyang saben sidecar. Bebarengan karo informasi babagan wektu entek lan setelan imbangan. Kabeh iki ngidini sampeyan nindakake akeh perkara sing migunani, nanging, sayangé, ukuran sidecars kembung.
Panemuan layanan
Netramesh ora nambah mekanisme tambahan kanggo panemuan layanan. Kabeh lalu lintas diproksi kanthi transparan liwat sidecar netra.
Netramesh ndhukung protokol aplikasi HTTP/1. Kanggo nemtokake, dhaptar port sing bisa dikonfigurasi digunakake. Biasane, sistem kasebut duwe sawetara port kanggo komunikasi HTTP. Contone, kita nggunakake 80, 8890, 8080 kanggo interaksi antarane layanan lan panjalukan eksternal. Ing kasus iki, padha bisa disetel nggunakake variabel lingkungan NETRA_HTTP_PORTS.
Yen sampeyan nggunakake Kubernetes minangka orkestra lan mekanisme entitas Layanan kanggo komunikasi intra-kluster antarane layanan, mekanisme kasebut tetep padha. Kaping pisanan, layanan mikro entuk alamat IP layanan nggunakake kube-dns lan mbukak sambungan anyar. Sambungan iki pisanan digawe karo netra-sidecar lokal lan kabeh paket TCP wiwitane teka ing netra. Sabanjure, netra-sidecar nggawe sambungan karo tujuan asli. NAT ing pod IP ing simpul tetep persis padha tanpa netra.
Nelusuri sing disebarake lan nerusake konteks
Netramesh nyedhiyakake fungsi sing dibutuhake kanggo ngirim tracing span babagan interaksi HTTP. Netra-sidecar ngurai protokol HTTP, ngukur tundha panyuwunan, lan njupuk informasi sing dibutuhake saka header HTTP. Pungkasane, kita entuk kabeh jejak ing sistem Jaeger siji. Kanggo konfigurasi sing apik, sampeyan uga bisa nggunakake variabel lingkungan sing diwenehake dening perpustakaan resmi .
Nanging ana masalah. Nganti layanan ngasilake lan ngirim header uber khusus, kita ora bakal weruh span tracing sing disambungake ing sistem kasebut. Lan iki kita kudu cepet nemokake sabab saka masalah. Ing kene maneh Netramesh duwe solusi. Proksi maca header HTTP lan, yen ora ngemot id jejak uber, ngasilake siji. Netramesh uga nyimpen informasi babagan panjalukan mlebu lan metu ing sidecar lan cocog karo dheweke kanthi nambahi header panjaluk metu sing dibutuhake. Kabeh sing perlu dilakoni ing layanan mung ngirim siji header X-Request-Id, sing bisa dikonfigurasi nggunakake variabel lingkungan NETRA_HTTP_REQUEST_ID_HEADER_NAME. Kanggo ngontrol ukuran konteks ing Netramesh, sampeyan bisa nyetel variabel lingkungan ing ngisor iki: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (wektu sing konteks bakal disimpen) lan NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (frekuensi ngresiki konteks).
Sampeyan uga bisa nggabungake pirang-pirang jalur ing sistem sampeyan kanthi menehi tandha karo token sesi khusus. Netra ngijini sampeyan kanggo nginstal HTTP_HEADER_TAG_MAP kanggo ngowahi header HTTP dadi tag span tracing sing cocog. Iki bisa migunani utamane kanggo tes. Sawise ngliwati tes fungsional, sampeyan bisa ndeleng bagean sistem sing kena pengaruh kanthi nyaring nganggo tombol sesi sing cocog.
Nemtokake Sumber Panyuwunan
Kanggo nemtokake saka ngendi panyuwunan kasebut, sampeyan bisa nggunakake fungsi kanthi otomatis nambah header kanthi sumber. Nggunakake variabel lingkungan NETRA_HTTP_X_SOURCE_HEADER_NAME Sampeyan bisa nemtokake jeneng header sing bakal diinstal kanthi otomatis. Kanthi nggunakake NETRA_HTTP_X_SOURCE_VALUE sampeyan bisa nyetel nilai kanggo header X-Source bakal disetel kanggo kabeh panjalukan metu.
Iki ngidini distribusi header sing migunani iki bisa disebarake kanthi seragam ing saindhenging jaringan. Banjur sampeyan bisa nggunakake ing layanan lan nambah menyang log lan metrik.
Rute lalu lintas lan internal Netramesh
Netramesh kasusun saka rong komponen utama. Pisanan, netra-init, nyetel aturan jaringan kanggo nyegat lalu lintas. Dheweke nggunakake kanggo nyegat kabeh utawa bagéan saka lalu lintas ing sidecar, kang komponen utama kapindho Netramesh. Sampeyan bisa ngatur port endi sing kudu dicegat kanggo sesi TCP mlebu lan metu: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Alat kasebut uga nduweni fitur sing menarik - rute probabilistik. Yen sampeyan nggunakake Netramesh khusus kanggo ngumpulake span tracing, mula ing lingkungan produksi sampeyan bisa ngirit sumber daya lan ngaktifake rute probabilistik nggunakake variabel. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (saka 0 nganti 1). Nilai standar yaiku 1 (kabeh lalu lintas dicegat).
Sawise interception sukses, sidecar netra nampa sambungan anyar lan nggunakake SO_ORIGINAL_DST pilihan soket kanggo entuk tujuan asli. Netra banjur mbukak sambungan anyar menyang alamat IP asli lan netepake komunikasi TCP rong arah antarane pihak, ngrungokake kabeh lalu lintas liwat. Yen port ditetepake minangka HTTP, Netra nyoba ngurai lan nglacak. Yen parsing HTTP gagal, Netra bali menyang TCP lan transparan proksi bait.
Nggawe grafik ketergantungan
Sawise nampa akeh informasi nelusuri ing Jaeger, aku pengin njaluk grafik lengkap interaksi ing sistem. Nanging yen sistem sampeyan cukup dimuat lan milyaran tracing nglumpukake saben dina, nglumpukake ora dadi tugas sing gampang. Ana cara resmi kanggo nindakake iki: . Nanging, butuh jam kanggo nggawe grafik lengkap lan bakal meksa sampeyan ndownload kabeh set data saka Jaeger sajrone XNUMX jam kepungkur.
Yen sampeyan nggunakake Elasticsearch kanggo nyimpen tracing span, sampeyan bisa nggunakake , sing bakal nggawe grafik sing padha ing sawetara menit kanthi nggunakake fitur lan kemampuan Elasticsearch.
Cara nggunakake Netramesh
Netra bisa gampang ditambahake menyang layanan apa wae sing nganggo orkestra. Sampeyan bisa ndeleng conto .
Saiki, Netra ora duwe kemampuan kanggo ngleksanakake sidecars kanthi otomatis menyang layanan, nanging ana rencana kanggo implementasine.
Masa depan Netramesh
gol utama yaiku kanggo entuk biaya sumber daya minimal lan kinerja dhuwur, nyedhiyakake kemampuan dhasar kanggo observasi lan kontrol komunikasi antar-layanan.
Ing mangsa ngarep, Netramesh bakal ndhukung protokol lapisan aplikasi liyane kajaba HTTP. L7 nuntun bakal kasedhiya ing mangsa cedhak.
Gunakake Netramesh yen sampeyan nemoni masalah sing padha lan nulis pitakon lan saran marang kita.
Source: www.habr.com