Semasa kami beralih daripada aplikasi monolitik kepada seni bina perkhidmatan mikro, kami menghadapi cabaran baharu.
Dalam aplikasi monolitik, biasanya agak mudah untuk menentukan bahagian sistem mana ralat berlaku. Kemungkinan besar, masalahnya adalah dalam kod monolit itu sendiri, atau dalam pangkalan data. Tetapi apabila kita mula mencari masalah dalam seni bina perkhidmatan mikro, semuanya tidak lagi begitu jelas. Kami perlu mencari keseluruhan laluan yang diambil oleh permintaan dari awal hingga akhir dan pilihnya daripada ratusan perkhidmatan mikro. Selain itu, banyak daripada mereka juga mempunyai kemudahan penyimpanan mereka sendiri, yang juga boleh menyebabkan ralat logik, serta masalah dengan prestasi dan toleransi kesalahan.
Saya telah lama mencari alat yang akan membantu mengatasi masalah sedemikian (saya menulis tentang ini di HabrΓ©: , ), tetapi pada akhirnya saya membuat penyelesaian sumber terbuka saya sendiri. Dalam artikel ini saya bercakap tentang faedah pendekatan mesh perkhidmatan dan berkongsi alat baharu untuk pelaksanaannya.
Pengesanan teragih adalah penyelesaian biasa kepada masalah mencari ralat dalam sistem teragih. Tetapi bagaimana jika pendekatan untuk mengumpul maklumat tentang interaksi rangkaian ini belum lagi dilaksanakan dalam sistem, atau, lebih teruk, di sebahagian daripada sistem ia sudah berfungsi dengan baik, tetapi sebahagiannya tidak, kerana ia belum ditambahkan pada perkhidmatan lama ? Untuk menentukan punca sebenar masalah, adalah perlu untuk mempunyai gambaran lengkap tentang apa yang berlaku dalam sistem. Adalah amat penting untuk memahami perkhidmatan mikro yang terlibat dalam laluan kritikal perniagaan utama.
Di sini pendekatan mesh perkhidmatan boleh membantu kami, yang akan menangani semua jentera untuk mengumpul maklumat rangkaian pada tahap yang lebih rendah daripada perkhidmatan itu sendiri beroperasi. Pendekatan ini membolehkan kami memintas semua lalu lintas dan menganalisisnya dengan cepat. Selain itu, aplikasi tidak perlu mengetahui apa-apa tentangnya.
Pendekatan mesh perkhidmatan
Idea utama pendekatan mesh perkhidmatan adalah untuk menambah satu lagi lapisan infrastruktur ke atas rangkaian, yang akan membolehkan kami melakukan apa-apa perkara dengan interaksi antara perkhidmatan. Kebanyakan pelaksanaan berfungsi seperti berikut: bekas kereta sampingan tambahan dengan proksi telus ditambahkan pada setiap perkhidmatan mikro, yang melaluinya semua trafik masuk dan keluar perkhidmatan itu diluluskan. Dan di sinilah tempat kami boleh melakukan pengimbangan pelanggan, menggunakan dasar keselamatan, mengenakan sekatan ke atas bilangan permintaan dan mengumpul maklumat penting tentang interaksi perkhidmatan dalam pengeluaran.
Penyelesaian
Terdapat beberapa pelaksanaan pendekatan ini: ΠΈ . Mereka menyediakan banyak ciri di luar kotak. Tetapi pada masa yang sama, terdapat overhed yang besar pada sumber. Selain itu, lebih besar kluster di mana sistem sedemikian beroperasi, lebih banyak sumber akan diperlukan untuk mengekalkan infrastruktur baharu. Di Avito, kami mengendalikan kluster kubernetes yang mengandungi ribuan contoh perkhidmatan (dan bilangannya terus berkembang dengan pesat). Dalam pelaksanaan semasanya, Istio menggunakan ~300Mb RAM bagi setiap contoh perkhidmatan. Disebabkan bilangan kemungkinan yang besar, pengimbangan telus juga mempengaruhi masa tindak balas keseluruhan perkhidmatan (sehingga 10ms).
Hasilnya, kami melihat dengan tepat keupayaan yang kami perlukan sekarang, dan memutuskan bahawa sebab utama kami mula melaksanakan penyelesaian sedemikian ialah keupayaan untuk mengumpul maklumat pengesanan daripada keseluruhan sistem secara telus. Kami juga ingin mengawal interaksi perkhidmatan dan melakukan pelbagai manipulasi dengan pengepala yang dipindahkan antara perkhidmatan.
Akibatnya, kami membuat keputusan:β .
Netramesh
ialah penyelesaian mesh perkhidmatan ringan dengan keupayaan untuk menskala tanpa mengira, tanpa mengira bilangan perkhidmatan dalam sistem.
Matlamat utama penyelesaian baharu adalah overhed sumber yang rendah dan prestasi tinggi. Antara ciri utama, kami dengan serta-merta mahu dapat menghantar rentang pengesanan secara telus ke sistem Jaeger kami.
Hari ini, kebanyakan penyelesaian awan dilaksanakan di Golang. Dan, tentu saja, ada sebab untuk ini. Menulis aplikasi rangkaian dalam Golang yang berfungsi secara tak segerak dengan I/O dan skala merentas teras mengikut keperluan adalah mudah dan agak mudah. Dan, apa yang juga sangat penting, prestasinya mencukupi untuk menyelesaikan masalah ini. Sebab itu kami juga memilih Golang.
Produktiviti
Kami telah menumpukan usaha kami untuk mencapai produktiviti maksimum. Untuk penyelesaian yang digunakan di sebelah setiap contoh perkhidmatan, penggunaan kecil RAM dan masa CPU diperlukan. Dan, sudah tentu, kelewatan tindak balas juga harus kecil.
Mari lihat apa keputusan yang kami dapat.
RAM
Netramesh menggunakan ~10Mb tanpa trafik dan maksimum 50Mb dengan muatan sehingga 10000 RPS setiap kejadian.
Proksi utusan Istio sentiasa menggunakan ~300Mb dalam kelompok kami dengan beribu-ribu kejadian. Ini tidak membenarkan ia diskalakan kepada keseluruhan kluster.
Dengan Netramesh kami mendapat ~10x pengurangan dalam penggunaan ingatan.
CPU
Penggunaan CPU secara relatifnya sama di bawah beban. Ia bergantung kepada bilangan permintaan setiap unit masa kepada kereta sampingan. Nilai pada 3000 permintaan sesaat pada puncak:
Terdapat satu lagi perkara penting: Netramesh - penyelesaian tanpa satah kawalan dan tanpa beban tidak memakan masa CPU. Dengan Istio, sidecars sentiasa mengemas kini titik akhir perkhidmatan. Akibatnya, kita boleh melihat gambar ini tanpa beban:
Kami menggunakan HTTP/1 untuk komunikasi antara perkhidmatan. Peningkatan masa tindak balas untuk Istio semasa membuat proksi melalui utusan adalah sehingga 5-10ms, yang agak banyak untuk perkhidmatan yang sedia bertindak balas dalam milisaat. Dengan Netramesh kali ini telah menurun kepada 0.5-2ms.
Kebolehskalaan
Jumlah kecil sumber yang digunakan oleh setiap proksi memungkinkan untuk meletakkannya di sebelah setiap perkhidmatan. Netramesh sengaja dicipta tanpa komponen pesawat kawalan untuk memastikan setiap kereta sampingan ringan. Selalunya dalam penyelesaian mesh servis, pesawat kawalan mengedarkan maklumat penemuan perkhidmatan kepada setiap kereta sampingan. Bersama-sama dengannya disertakan maklumat tentang tamat masa dan tetapan pengimbangan. Semua ini membolehkan anda melakukan banyak perkara yang berguna, tetapi, malangnya, ia mengembang saiz sidecars.
Penemuan perkhidmatan
Netramesh tidak menambah sebarang mekanisme tambahan untuk penemuan perkhidmatan. Semua trafik diproksi secara telus melalui sidecar netra.
Netramesh menyokong protokol aplikasi HTTP/1. Untuk mentakrifkannya, senarai port yang boleh dikonfigurasikan digunakan. Biasanya, sistem mempunyai beberapa port yang melaluinya komunikasi HTTP berlaku. Sebagai contoh, kami menggunakan 80, 8890, 8080 untuk interaksi antara perkhidmatan dan permintaan luaran. Dalam kes ini, ia boleh ditetapkan menggunakan pembolehubah persekitaran NETRA_HTTP_PORTS.
Jika anda menggunakan Kubernetes sebagai orkestra dan mekanisme entiti Perkhidmatannya untuk komunikasi intra-kluster antara perkhidmatan, maka mekanismenya tetap sama. Pertama, perkhidmatan mikro mendapatkan alamat IP perkhidmatan menggunakan kube-dns dan membuka sambungan baharu kepadanya. Sambungan ini mula-mula diwujudkan dengan kereta sisi netra tempatan dan semua paket TCP pada mulanya tiba di netra. Seterusnya, netra-sidecar mewujudkan sambungan dengan destinasi asal. NAT pada IP pod pada nod kekal sama seperti tanpa netra.
Pengesanan dan penghantaran konteks yang diedarkan
Netramesh menyediakan fungsi yang diperlukan untuk menghantar rentang pengesanan tentang interaksi HTTP. Netra-sidecar menghuraikan protokol HTTP, mengukur kelewatan permintaan dan mengekstrak maklumat yang diperlukan daripada pengepala HTTP. Akhirnya, kami mendapat semua jejak dalam satu sistem Jaeger. Untuk konfigurasi terperinci, anda juga boleh menggunakan pembolehubah persekitaran yang disediakan oleh perpustakaan rasmi .
Tetapi ada masalah. Sehingga perkhidmatan menjana dan menghantar pengepala uber khas, kami tidak akan melihat rentang jejak bersambung dalam sistem. Dan inilah yang kita perlukan untuk mencari punca masalah dengan cepat. Di sini sekali lagi Netramesh mempunyai penyelesaian. Proksi membaca pengepala HTTP dan, jika ia tidak mengandungi id jejak uber, hasilkan satu. Netramesh juga menyimpan maklumat tentang permintaan masuk dan keluar dalam kereta sampingan dan memadankannya dengan memperkayakannya dengan pengepala permintaan keluar yang diperlukan. Apa yang anda perlu lakukan dalam perkhidmatan adalah menghantar hanya satu pengepala X-Request-Id, yang boleh dikonfigurasikan menggunakan pembolehubah persekitaran NETRA_HTTP_REQUEST_ID_HEADER_NAME. Untuk mengawal saiz konteks dalam Netramesh, anda boleh menetapkan pembolehubah persekitaran berikut: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (masa yang konteks akan disimpan) dan NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (kekerapan pembersihan konteks).
Ia juga mungkin untuk menggabungkan berbilang laluan pada sistem anda dengan menandakannya dengan token sesi khas. Netra membolehkan anda memasang HTTP_HEADER_TAG_MAP untuk menukar pengepala HTTP menjadi teg rentang pengesanan yang sepadan. Ini boleh berguna terutamanya untuk ujian. Selepas lulus ujian kefungsian, anda boleh melihat bahagian sistem mana yang terjejas oleh penapisan oleh kunci sesi yang sepadan.
Menentukan Sumber Permintaan
Untuk menentukan dari mana permintaan itu datang, anda boleh menggunakan fungsi menambah pengepala dengan sumber secara automatik. Menggunakan pembolehubah persekitaran NETRA_HTTP_X_SOURCE_HEADER_NAME Anda boleh menentukan nama pengepala yang akan dipasang secara automatik. Dengan menggunakan NETRA_HTTP_X_SOURCE_VALUE anda boleh menetapkan nilai yang mana pengepala X-Source akan ditetapkan untuk semua permintaan keluar.
Ini membolehkan pengedaran pengepala berguna ini diedarkan secara seragam ke seluruh rangkaian. Kemudian anda boleh menggunakannya dalam perkhidmatan dan menambahkannya pada log dan metrik.
Penghalaan trafik dan dalaman Netramesh
Netramesh terdiri daripada dua komponen utama. Yang pertama, netra-init, menetapkan peraturan rangkaian untuk memintas trafik. Dia menggunakan untuk memintas semua atau sebahagian trafik pada kereta sampingan, yang merupakan komponen utama kedua Netramesh. Anda boleh mengkonfigurasi port mana yang perlu dipintas untuk sesi TCP masuk dan keluar: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Alat ini juga mempunyai ciri yang menarik - penghalaan kebarangkalian. Jika anda menggunakan Netramesh secara eksklusif untuk mengumpul rentang pengesanan, maka dalam persekitaran pengeluaran anda boleh menjimatkan sumber dan mendayakan penghalaan kebarangkalian menggunakan pembolehubah NETRA_INBOUND_PROBABILITY ΠΈ NETRA_OUTBOUND_PROBABILITY (dari 0 hingga 1). Nilai lalai ialah 1 (semua trafik dipintas).
Selepas pemintasan berjaya, sidecar netra menerima sambungan dan kegunaan baharu SO_ORIGINAL_DST pilihan soket untuk mendapatkan destinasi asal. Netra kemudian membuka sambungan baharu ke alamat IP asal dan mewujudkan komunikasi TCP dua hala antara pihak, mendengar semua lalu lintas yang melaluinya. Jika port ditakrifkan sebagai HTTP, Netra cuba menghuraikan dan mengesannya. Jika penghuraian HTTP gagal, Netra akan kembali kepada TCP dan proksi bait secara telus.
Membina graf pergantungan
Selepas menerima sejumlah besar maklumat pengesanan dalam Jaeger, saya ingin mendapatkan graf lengkap interaksi dalam sistem. Tetapi jika sistem anda agak dimuatkan dan berbilion-bilion rentang pengesanan terkumpul setiap hari, mengagregatkannya bukanlah satu tugas yang mudah. Terdapat cara rasmi untuk melakukan ini: . Walau bagaimanapun, ia akan mengambil masa beberapa jam untuk membina graf yang lengkap dan akan memaksa anda memuat turun keseluruhan set data daripada Jaeger selama XNUMX jam yang lalu.
Jika anda menggunakan Elasticsearch untuk menyimpan rentang jejak, anda boleh gunakan , yang akan membina graf yang sama dalam beberapa minit menggunakan ciri dan keupayaan Elasticsearch.
Cara menggunakan Netramesh
Netra boleh ditambah dengan mudah pada mana-mana perkhidmatan yang menjalankan mana-mana orkestra. Anda boleh lihat contoh .
Pada masa ini, Netra tidak mempunyai keupayaan untuk melaksanakan sidecar secara automatik kepada perkhidmatan, tetapi terdapat rancangan untuk pelaksanaan.
Masa depan Netramesh
matlamat utama adalah untuk mencapai kos sumber yang minimum dan prestasi tinggi, menyediakan keupayaan asas untuk pemerhatian dan kawalan komunikasi antara perkhidmatan.
Pada masa hadapan, Netramesh akan menyokong protokol lapisan aplikasi lain selain HTTP. Penghalaan L7 akan tersedia dalam masa terdekat.
Gunakan Netramesh jika anda menghadapi masalah yang sama dan tulis kepada kami dengan soalan dan cadangan.
Sumber: www.habr.com