Nalika urang ngalih tina aplikasi monolitik ka arsitéktur microservices, urang nyanghareupan tantangan anyar.
Dina aplikasi monolithic, biasana rada gampang pikeun nangtukeun mana bagian tina sistem kasalahan lumangsung. Paling dipikaresep, masalahna aya dina kode tina monolith sorangan, atawa dina database. Tapi nalika urang ngamimitian milarian masalah dina arsitéktur microservice, sadayana henteu écés pisan. Urang kedah milarian sadayana jalur anu dipénta ti mimiti dugi ka réngsé sareng pilih tina ratusan jasa mikro. Leuwih ti éta, loba di antarana ogé boga fasilitas gudang sorangan, nu ogé bisa ngabalukarkeun kasalahan logis, kitu ogé masalah kinerja sarta kasabaran sesar.
Kuring parantos lami milarian alat anu bakal ngabantosan masalah sapertos kitu (Kuring nyerat ngeunaan ieu dina Habré: , ), tapi tungtungna kuring ngadamel solusi open source sorangan. Dina tulisan ieu kuring ngobrol ngeunaan mangpaat pendekatan bolong jasa sareng ngabagi alat anyar pikeun palaksanaanna.
Tracing anu disebarkeun mangrupikeun solusi umum pikeun masalah milarian kasalahan dina sistem anu disebarkeun. Tapi kumaha upami pendekatan pikeun ngumpulkeun inpormasi ngeunaan interaksi jaringan henteu acan dilaksanakeun dina sistem, atanapi, parah, dina bagian tina sistem éta parantos jalanna leres, tapi sabagian henteu, sabab éta henteu acan diasupkeun kana jasa anu lami. ? Pikeun nangtukeun cukang lantaran pasti tina masalah, perlu boga gambaran lengkep naon anu lumangsung dina sistem. Utamana penting pikeun ngartos jasa mikro mana anu kalibet dina jalur kritis-bisnis konci.
Di dieu pendekatan bolong jasa tiasa ngabantosan urang, anu bakal ngurus sadaya mesin pikeun ngumpulkeun inpormasi jaringan dina tingkat anu langkung handap tina jasa anu dioperasikeun. Pendekatan ieu ngamungkinkeun urang pikeun ngahalangan sadaya lalu lintas sareng nganalisis éta dina laleur. Leuwih ti éta, aplikasi malah teu kudu nyaho nanaon tentang eta.
Service bolong pendekatan
Gagasan utama pendekatan bolong jasa nyaéta pikeun nambihan lapisan infrastruktur anu sanés dina jaringan, anu bakal ngamungkinkeun urang ngalakukeun naon waé kalayan interaksi antar-jasa. Seuseueurna palaksanaan tiasa didamel sapertos kieu: wadah sidecar tambahan sareng proxy transparan ditambahkeun kana unggal jasa mikro, anu ngalangkungan sadaya lalu lintas asup sareng kaluar jasa. Sareng ieu mangrupikeun tempat dimana urang tiasa ngalakukeun balancing klien, nerapkeun kawijakan kaamanan, maksakeun larangan dina jumlah pamundut sareng ngumpulkeun inpormasi penting dina interaksi jasa dina produksi.
Solusi na
Geus aya sababaraha palaksanaan pendekatan ieu: и . Aranjeunna nyadiakeun loba fitur out of the box. Tapi dina waktos anu sareng, aya asalna hiji overhead badag dina sumberdaya. Sumawona, langkung ageung kluster dimana sistem sapertos kitu beroperasi, langkung seueur sumber daya anu diperyogikeun pikeun ngajaga infrastruktur énggal. Di Avito, urang beroperasi klaster kubernetes nu ngandung rébuan instansi jasa (jeung jumlah maranéhanana terus tumuwuh gancang). Dina palaksanaan ayeuna, Istio meakeun ~ 300Mb RAM per conto jasa. Kusabab sajumlah ageung kamungkinan, balancing transparan ogé mangaruhan waktos réspon sadaya jasa (dugi ka 10ms).
Hasilna, urang ningal persis kamampuan anu urang peryogikeun ayeuna, sareng mutuskeun yén alesan utama naha urang ngamimitian ngalaksanakeun solusi sapertos kitu nyaéta kamampuan pikeun ngalacak inpormasi tina sadaya sistem sacara transparan. Kami ogé hoyong gaduh kontrol kana interaksi jasa sareng ngalakukeun rupa-rupa manipulasi sareng header anu ditransfer antara jasa.
Hasilna, urang sumping ka kaputusan urang: .
Netramesh
mangrupakeun solusi bolong jasa lightweight kalawan kamampuhan pikeun skala infinitely, paduli jumlah jasa dina sistem.
Tujuan utama solusi anyar éta overhead sumberdaya low jeung kinerja tinggi. Diantara fitur utama, urang langsung hayang bisa transparan ngirim tracing bentang ka sistem Jaeger urang.
Kiwari, kalolobaan solusi awan dilaksanakeun di Golang. Sareng, tangtosna, aya alesan pikeun ieu. Nulis aplikasi jaringan dina Golang nu dianggo asynchronously kalawan I / O jeung skala sakuliah cores sakumaha diperlukeun merenah tur cukup basajan. Jeung, naon ogé pohara penting, kinerja cukup pikeun ngajawab masalah ieu. Éta sababna urang ogé milih Golang.
kakuwatan keur ngasilkeun
Kami parantos museurkeun usaha pikeun ngahontal produktivitas maksimal. Pikeun solusi anu disebarkeun sabeulah unggal conto jasa, peryogi pamakean leutik RAM sareng waktos CPU. Na, tangtosna, reureuh respon ogé kudu leutik.
Hayu urang tingali hasilna naon urang meunang.
Ram
Netramesh meakeun ~ 10Mb tanpa lalu lintas sareng maksimal 50Mb kalayan beban dugi ka 10000 RPS per conto.
Istio utusan proxy salawasna meakeun ~ 300Mb dina klaster kami kalawan rébuan instansi. Ieu teu ngidinan pikeun diskalakeun ka sakabéh klaster.
Kalayan Netramesh kami nampi pangurangan ~10x dina konsumsi mémori.
CPU
Pamakéan CPU relatif sarua dina beban. Ieu gumantung kana jumlah requests per unit waktu ka sidecar nu. Nilai dina 3000 requests per detik di puncak:
Aya hiji titik nu leuwih penting: Netramesh - solusi tanpa pesawat kontrol jeung tanpa beban teu meakeun waktu CPU. Kalayan Istio, sidecars salawasna ngamutahirkeun titik jasa. Hasilna, urang tiasa ningali gambar ieu tanpa beban:
Kami nganggo HTTP / 1 pikeun komunikasi antara jasa. Kanaékan waktos réspon pikeun Istio nalika proksi ngalangkungan utusan dugi ka 5-10ms, anu lumayan seueur pikeun jasa anu siap ngabales dina milidetik. Kalayan Netramesh waktos ieu parantos turun ka 0.5-2ms.
Skalabilitas
Jumlah leutik sumber daya anu dikonsumsi ku unggal proxy ngamungkinkeun pikeun nempatkeun éta di gigireun unggal jasa. Netramesh ngahaja dijieun tanpa komponén pesawat kontrol pikeun saukur ngajaga unggal sidecar lightweight. Sering dina solusi bolong jasa, pesawat kontrol nyebarkeun inpormasi penemuan jasa ka unggal sidecar. Marengan éta informasi ngeunaan timeouts na balancing setélan. Sadaya ieu ngidinan Anjeun pikeun ngalakukeun loba hal mangpaat, tapi, hanjakalna, éta bloats sidecars dina ukuran.
Papanggihan jasa
Netramesh henteu nambihan mékanisme tambahan pikeun mendakan jasa. Sadaya lalu lintas diproksi sacara transparan ngaliwatan sidecar netra.
Netramesh ngadukung protokol aplikasi HTTP/1. Pikeun ngartikeun éta, daptar port anu tiasa dikonfigurasi dianggo. Biasana, sistemna ngagaduhan sababaraha palabuhan dimana komunikasi HTTP lumangsung. Salaku conto, kami nganggo 80, 8890, 8080 pikeun interaksi antara jasa sareng pamundut éksternal. Dina hal ieu, aranjeunna tiasa diatur nganggo variabel lingkungan. NETRA_HTTP_PORTS.
Upami anjeun nganggo Kubernetes salaku orkestra sareng mékanisme éntitas Layanan na pikeun komunikasi intra-cluster antara jasa, mékanismena tetep sami. Kahiji, microservice meunang alamat IP layanan maké kube-dns tur muka sambungan anyar pikeun eta. Koneksi ieu mimiti diadegkeun ku netra-sidecar lokal sareng sadaya pakét TCP mimitina dugi ka netra. Salajengna, netra-sidecar ngadegkeun sambungan jeung tujuan aslina. NAT on pod IP dina titik tetep persis sarua jeung tanpa netra.
Disebarkeun tracing jeung konteks diteruskeun
Netramesh nyayogikeun pungsionalitas anu dipikabutuh pikeun ngirim lacak bentang ngeunaan interaksi HTTP. Netra-sidecar parses protokol HTTP, ukuran pamundut reureuh, sarta extracts informasi diperlukeun tina headers HTTP. Pamustunganana, urang meunang sagala ngambah dina sistem Jaeger tunggal. Pikeun konfigurasi rupa-grained, Anjeun oge bisa make variabel lingkungan disadiakeun ku perpustakaan resmi .
Tapi aya masalah. Dugi jasa ngahasilkeun sareng ngirimkeun header uber khusus, kami moal ningali jarak ngalacak anu nyambung dina sistem. Sareng ieu anu urang peryogikeun pikeun gancang mendakan anu nyababkeun masalah. Di dieu deui Netramesh gaduh solusi. Proxies maca header HTTP sareng, upami henteu ngandung id jejak uber, ngahasilkeun hiji. Netramesh ogé nyimpen inpormasi ngeunaan pamundut anu asup sareng kaluar dina sidecar sareng cocog sareng aranjeunna ku cara ngabeungharan aranjeunna kalayan header pamundut kaluar anu diperyogikeun. Sadaya anu anjeun kedah laksanakeun dina jasa nyaéta ngirim ngan hiji lulugu X-Request-Id, anu tiasa dikonpigurasi nganggo variabel lingkungan NETRA_HTTP_REQUEST_ID_HEADER_NAME. Pikeun ngadalikeun ukuran kontéks dina Netramesh, anjeun tiasa nyetél variabel lingkungan ieu: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (waktos keur nu konteks bakal disimpen) jeung NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (frékuénsi cleanup konteks).
Éta ogé mungkin pikeun ngagabungkeun sababaraha jalur dina sistem anjeun ku nyirian aranjeunna ku token sési khusus. Netra ngidinan Anjeun pikeun masang HTTP_HEADER_TAG_MAP pikeun ngahurungkeun header HTTP kana tag bentang tracing saluyu. Ieu bisa jadi mangpaat utamana pikeun nguji. Saatos lulus tés fungsional, anjeun tiasa ningali bagian mana tina sistem anu kapangaruhan ku nyaring ku konci sési anu saluyu.
Nangtukeun Sumber Request
Pikeun nangtukeun ti mana pamenta asalna, anjeun tiasa nganggo pungsionalitasna sacara otomatis nambihan lulugu sareng sumberna. Ngagunakeun variabel lingkungan NETRA_HTTP_X_SOURCE_HEADER_NAME Anjeun tiasa nangtukeun nami lulugu anu bakal otomatis dipasang. Ku ngagunakeun NETRA_HTTP_X_SOURCE_VALUE Anjeun tiasa nyetel nilai nu lulugu X-Source bakal disetel pikeun sakabéh requests kaluar.
Hal ieu ngamungkinkeun sebaran header mangpaat ieu disebarkeun seragam sakuliah jaringan. Teras anjeun tiasa dianggo dina jasa sareng tambahkeun kana log sareng métrik.
Lalu lintas routing sareng internal Netramesh
Netramesh diwangun ku dua komponén utama. Kahiji, netra-init, susunan aturan jaringan pikeun intercept lalulintas. Anjeunna ngagunakeun pikeun nyegat sadayana atanapi bagian tina lalu lintas dina sidecar, anu mangrupikeun komponén utama kadua Netramesh. Anjeun tiasa ngonpigurasikeun palabuhan mana anu kedah dicegat pikeun sési TCP anu asup sareng kaluar: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Alatna ogé ngagaduhan fitur anu pikaresepeun - routing probabilistik. Upami anjeun nganggo Netramesh sacara éksklusif pikeun ngumpulkeun bentang ngalacak, maka dina lingkungan produksi anjeun tiasa ngahémat sumber daya sareng ngaktifkeun rute probabilistik nganggo variabel. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (ti 0 nepi ka 1). Nilai standar nyaéta 1 (sadayana lalu lintas dicegat).
Saatos interception suksés, sidecar netra nampi sambungan sareng panggunaan énggal SO_ORIGINAL_DST pilihan stop kontak pikeun meunangkeun tujuan aslina. Netra lajeng muka sambungan anyar ka alamat IP aslina tur ngadegkeun komunikasi TCP dua arah antara pihak, ngadengekeun sagala lalulintas ngaliwatan. Lamun port diartikeun HTTP, Netra nyoba parse sarta ngalacak eta. Lamun parsing HTTP gagal, Netra ragrag deui ka TCP tur transparan proxies bait.
Ngawangun grafik kagumantungan
Saatos nampi seueur inpormasi ngalacak di Jaeger, kuring hoyong kéngingkeun grafik lengkep ngeunaan interaksi dina sistem. Tapi upami sistem anjeun cukup sarat sareng milyaran ngalacak bentang akumulasi per dinten, ngahijikeun aranjeunna henteu janten tugas anu gampang. Aya cara resmi pikeun ngalakukeun ieu: . Nanging, éta bakal peryogi sababaraha jam pikeun ngawangun grafik lengkep sareng bakal maksa anjeun ngaunduh sadaya set data ti Jaeger salami XNUMX jam katukang.
Upami anjeun nganggo Elasticsearch pikeun nyimpen bentang ngalacak, anjeun tiasa nganggo , anu bakal ngawangun grafik anu sami dina sababaraha menit nganggo fitur sareng kamampuan Elasticsearch.
Kumaha ngagunakeun Netramesh
Netra bisa gampang ditambahkeun kana sagala jasa ngajalankeun sagala orchestrator. Anjeun tiasa ningali conto .
Ayeuna, Netra henteu gaduh kamampuan pikeun otomatis nerapkeun sidecars kana jasa, tapi aya rencana pikeun palaksanaan.
Masa depan Netramesh
tujuan utama nyaéta pikeun ngahontal waragad sumberdaya minimal jeung kinerja tinggi, nyadiakeun kamampuhan dasar pikeun observability jeung kontrol komunikasi antar-layanan.
Ka hareupna, Netramesh bakal ngadukung protokol lapisan aplikasi sanés salian ti HTTP. L7 routing bakal sadia dina mangsa nu bakal datang.
Anggo Netramesh upami anjeun mendakan masalah anu sami sareng nyerat ka kami kalayan patarosan sareng saran.
sumber: www.habr.com