Ing internet (bolong layanan), lan iki liyane. Hore! Nanging kenapa? Banjur, aku pengin mratelakake panemume yen bakal luwih apik yen meshes layanan katon 10 taun kepungkur, sadurunge tekane platform wadah kayata Docker lan Kubernetes. Aku ora ujar manawa sudut pandangku luwih apik utawa luwih elek tinimbang liyane, nanging amarga meshes layanan minangka kewan sing cukup rumit, sawetara sudut pandang bakal mbantu luwih ngerti.
Aku bakal ngomong babagan platform dotCloud, sing dibangun ing luwih saka satus microservices lan ndhukung ewu aplikasi containerized. Aku bakal nerangake tantangan sing kita diadhepi nalika ngembangake lan ngluncurake, lan kepiye layanan meshes bisa (utawa ora bisa) mbantu.
Sajarah dotCloud
Aku wis nulis babagan sejarah dotCloud lan pilihan arsitektur kanggo platform iki, nanging aku durung ngomong babagan lapisan jaringan. Yen sampeyan ora pengin nyilem maca babagan dotCloud, iki inti ing ringkesan: iku platform-as-a-layanan PaaS sing ngidini pelanggan mbukak macem-macem aplikasi (Java, PHP, Python ...), kanthi dhukungan kanggo macem-macem data. layanan (MongoDB, MySQL, Redis ...) lan alur kerja kaya Heroku: Sampeyan ngunggah kode menyang platform, iku mbangun gambar wadhah lan nyebarke.
Aku bakal pitutur marang kowe carane lalu lintas diarahake menyang platform dotCloud. Ora amarga iku utamané kelangan (sanajan sistem makarya uga kanggo sawijining wektu!), Nanging utamané amarga karo piranti modern desain kuwi bisa gampang dileksanakake ing wektu cendhak dening tim andhap asor yen padha mbutuhake cara kanggo rute lalu lintas antarane Bunch. saka microservices utawa Bunch saka aplikasi. Kanthi cara iki, sampeyan bisa mbandhingake pilihan: apa sing kedadeyan yen sampeyan ngembangake kabeh dhewe utawa nggunakake bolong layanan sing wis ana. Pilihan standar: nggawe dhewe utawa tuku.
Rute lalu lintas kanggo aplikasi sing di-host
Aplikasi ing dotCloud bisa mbukak titik pungkasan HTTP lan TCP.
HTTP endpoints ditambahake kanthi dinamis menyang konfigurasi kluster load balancer . Iki padha karo apa sumber daya saiki ing Kubernetes lan load balancer kaya .
Klien nyambung menyang titik pungkasan HTTP liwat domain sing cocog, yen jeneng domain kasebut nuduhake dotCloud load balancers. Biasa wae.
TCP endpoints digandhengake karo nomer port, sing banjur diterusake menyang kabeh kontaner ing tumpukan kasebut liwat variabel lingkungan.
Klien bisa nyambung menyang titik pungkasan TCP nggunakake jeneng host sing cocog (kaya gateway-X.dotcloud.com) lan nomer port.
Jeneng host iki mutusake menyang kluster server "nats" (ora ana hubungane karo ), sing bakal nuntun sambungan TCP sing mlebu menyang wadhah sing bener (utawa, ing kasus layanan imbang-muatan, menyang wadhah sing bener).
Yen sampeyan wis kenal karo Kubernetes, iki mbokmenawa bakal ngelingake sampeyan babagan Layanan .
Ora ana layanan sing padha ing platform dotCloud : Kanggo kesederhanaan, layanan diakses kanthi cara sing padha saka njero lan njaba platform.
Kabeh wis diatur cukup prasaja: implementasi awal saka HTTP lan TCP jaringan routing mbokmenawa mung sawetara atus baris Python saben. Algoritma prasaja (Aku bakal ngomong naif) sing ditapis nalika platform saya tambah lan syarat tambahan muncul.
Refactoring ekstensif kode sing wis ana ora dibutuhake. mligine, bisa langsung nggunakake alamat sing dipikolehi liwat variabel lingkungan.
Kepiye bedane karo bolong layanan modern?
Dibatesi visibilitas. Kita ora duwe metrik apa wae kanggo mesh routing TCP. Nalika nerangake rute HTTP, versi sabanjure ngenalake metrik HTTP sing rinci kanthi kode kesalahan lan wektu nanggepi, nanging meshes layanan modern luwih maju, nyedhiyakake integrasi karo sistem koleksi metrik kaya Prometheus, contone.
Visibilitas penting ora mung saka perspektif operasional (kanggo mbantu ngatasi masalah), nanging uga nalika ngeculake fitur anyar. Iku babagan aman и .
Efisiensi rute uga winates. Ing bolong nuntun dotCloud, kabeh lalu lintas kudu ngliwati kluster simpul nuntun khusus. Iki tegese bisa nyabrang sawetara wates AZ (Availability Zone) lan nambah latensi kanthi signifikan. Aku ngelingi kode ngatasi masalah sing nggawe luwih saka satus pitakon SQL saben kaca lan mbukak sambungan anyar menyang server SQL kanggo saben pitakon. Nalika mbukak sacara lokal, kaca kasebut langsung dimuat, nanging ing dotCloud butuh sawetara detik kanggo mbukak amarga saben sambungan TCP (lan pitakon SQL sabanjure) butuh puluhan milidetik. Ing kasus tartamtu, sambungan terus-terusan ngatasi masalah kasebut.
Meshes layanan modern luwih apik kanggo ngatasi masalah kasebut. Kaping pisanan, dheweke mriksa manawa sambungan wis diarahake ing sumber. Aliran logis padha: клиент → меш → сервис, nanging saiki bolong bisa digunakake sacara lokal lan ora ing kelenjar remot, supaya sambungan клиент → меш lokal lan cepet banget (mikrodetik tinimbang milidetik).
Jejaring layanan modern uga ngetrapake algoritma keseimbangan beban sing luwih cerdas. Kanthi ngawasi kesehatan backend, dheweke bisa ngirim luwih akeh lalu lintas menyang backend sing luwih cepet, nyebabake kinerja sakabèhé luwih apik.
Keamanan luwih apik uga. Mesh routing dotCloud mlaku kabeh ing EC2 Classic lan ora ngenkripsi lalu lintas (adhedhasar asumsi yen ana wong sing bisa ngetokake lalu lintas jaringan EC2, sampeyan wis ngalami masalah gedhe). Jejaring layanan modern kanthi transparan nglindhungi kabeh lalu lintas, contone, kanthi otentikasi TLS bebarengan lan enkripsi sabanjure.
Nuntun lalu lintas kanggo layanan platform
Oke, kita wis ngrembug babagan lalu lintas ing antarane aplikasi, nanging kepiye babagan platform dotCloud dhewe?
Platform kasebut kalebu sekitar satus layanan mikro sing tanggung jawab kanggo macem-macem fungsi. Sawetara nampa panjalukan saka wong liya, lan sawetara minangka buruh latar mburi sing nyambung menyang layanan liyane nanging ora nampa sambungan dhewe. Ing kasus apa wae, saben layanan kudu ngerti titik pungkasan alamat sing kudu disambungake.
Akeh layanan tingkat dhuwur bisa nggunakake bolong nuntun sing kasebut ing ndhuwur. Nyatane, akeh dotCloud luwih saka satus microservices wis disebarake minangka aplikasi biasa ing platform dotCloud dhewe. Nanging sawetara layanan tingkat kurang (utamané sing ngleksanakake bolong nuntun iki) perlu soko prasaja, karo dependensi kurang (amarga padha ora bisa gumantung ing karya - pitik lawas lan masalah endhog apik).
Layanan tingkat rendah lan kritis iki disebarake kanthi mbukak wadhah langsung ing sawetara simpul kunci. Ing kasus iki, layanan platform standar ora digunakake: linker, scheduler lan runner. Yen sampeyan pengin mbandhingake karo platform wadhah modern, kaya mlaku pesawat kontrol docker run langsung ing kelenjar, tinimbang delegasi tugas kanggo Kubernetes. Iku cukup padha ing konsep , kang digunakake utawa nalika booting cluster dewekan.
Layanan iki kapapar kanthi prasaja lan kasar: file YAML nyathet jeneng lan alamat; lan saben klien kudu njupuk salinan file YAML iki kanggo penyebaran.
Ing tangan siji, iku arang banget dipercaya amarga ora mbutuhake dhukungan saka kunci external / nyimpen Nilai kayata Zookeeper (eling, etcd utawa Konsul ora ana ing wektu sing). Ing sisih liya, dadi angel kanggo mindhah layanan. Saben pamindhahan ditindakake, kabeh klien bakal nampa file YAML sing dianyari (lan bisa urip maneh). Ora nyaman banget!
Sabanjure, kita wiwit ngleksanakake skema anyar, ing ngendi saben klien disambungake menyang server proxy lokal. Tinimbang alamat lan port, iku mung kudu ngerti nomer port layanan, lan nyambung liwat localhost. Proxy lokal nangani sambungan iki lan nerusake menyang server nyata. Saiki, nalika mindhah backend menyang mesin utawa skala liyane, tinimbang nganyari kabeh klien, sampeyan mung kudu nganyari kabeh proxy lokal iki; lan urip maneh ora dibutuhake maneh.
(Sampeyan uga direncanakake kanggo encapsulate lalu lintas ing sambungan TLS lan sijine server proxy liyane ing sisih panrima, uga verifikasi sertifikat TLS tanpa partisipasi layanan panrima, sing dikonfigurasi kanggo nampa sambungan mung ing localhost. Liyane babagan iki mengko).
Iki meh padha karo saka Airbnb, nanging prabédan pinunjul iku SmartStack wis dipun ginakaken lan disebarake kanggo produksi, nalika sistem nuntun internal dotCloud wis shelved nalika dotCloud dadi Docker.
Aku dhewe nganggep SmartStack minangka salah sawijining pendhudhuk sistem kaya Istio, Linkerd lan Consul Connect amarga kabeh padha ngetutake pola sing padha:
- Jalanake proxy ing saben simpul.
- Klien nyambung menyang proxy.
- Pesawat kontrol nganyari konfigurasi proxy nalika backends diganti.
- ... Bathi!
Implementasi modern saka bolong layanan
Yen kita kudu ngetrapake kothak sing padha saiki, kita bisa nggunakake prinsip sing padha. Contone, atur zona DNS internal kanthi pemetaan jeneng layanan menyang alamat ing papan kasebut 127.0.0.0/8. Banjur mbukak HAProxy ing saben simpul ing kluster, nampa sambungan ing saben alamat layanan (ing subnet 127.0.0.0/8) lan ngarahake / ngimbangi beban menyang backend sing cocog. Konfigurasi HAProxy bisa dikontrol , ngijini sampeyan kanggo nyimpen informasi backend ing etcd utawa Konsul lan push otomatis dianyari konfigurasi kanggo HAProxy yen perlu.
Iki cara kerjane Istio! Nanging kanthi sawetara beda:
- Migunakake tinimbang HAProxy.
- Nyimpen konfigurasi backend liwat Kubernetes API tinimbang etcd utawa Konsul.
- Layanan diparengake alamat ing subnet internal (alamat Kubernetes ClusterIP) tinimbang 127.0.0.0/8.
- Nduwe komponen tambahan (Citadel) kanggo nambah otentikasi TLS bebarengan antarane klien lan server.
- Ndhukung fitur-fitur anyar kayata circuit breaking, tracing sing disebarake, penyebaran kenari, lsp.
Ayo goleki sawetara bedane.
Utusan Proksi
Envoy Proxy ditulis dening Lyft [saingan Uber ing pasar taksi - kira-kira. jalur]. Iku padha ing akeh cara kanggo proxy liyane (eg HAProxy, Nginx, Traefik ...), nanging Lyft wrote duweke amarga padha mbutuhake fitur sing proxy liyane kurang, lan ketoke luwih pinter kanggo nggawe anyar tinimbang ngluwihi sing wis ana.
Utusan bisa digunakake dhewe. Yen aku duwe layanan tartamtu sing kudu nyambung menyang layanan liyane, Aku bisa ngatur kanggo nyambung menyang Utusan, lan banjur mbosenke ngatur lan reconfigure Utusan karo lokasi layanan liyane, nalika entuk akèh fungsi tambahan gedhe, kayata visibilitas. Tinimbang perpustakaan klien khusus utawa nyuntikake jejak telpon menyang kode, kita ngirim lalu lintas menyang Utusan, lan nglumpukake metrik kanggo kita.
Nanging Utusan uga saged makarya minangka pesawat data (bidang data) kanggo bolong layanan. Iki tegese Utusan saiki wis dikonfigurasi kanggo bolong layanan iki pesawat kontrol (kontrol pesawat).
Pesawat kontrol
Kanggo pesawat kontrol, Istio gumantung ing Kubernetes API. Iki ora beda banget karo nggunakake confd, sing gumantung ing etcd utawa Konsul kanggo ndeleng set tombol ing nyimpen data. Istio nggunakake API Kubernetes kanggo ndeleng sakumpulan sumber daya Kubernetes.
Antarane iki lan banjur: Aku pribadi nemokake iki migunani kang maca:
Server API Kubernetes minangka "server bisu" sing nawakake panyimpenan, versi, validasi, nganyari, lan semantik kanggo sumber daya API.
Istio dirancang kanggo nggarap Kubernetes; lan yen sampeyan pengin nggunakake ing njaba Kubernetes, sampeyan kudu mbukak conto saka server API Kubernetes (lan layanan helper etcd).
Alamat layanan
Istio ngandelake alamat ClusterIP sing dialokasikan Kubernetes, mula layanan Istio nampa alamat internal (ora ana ing kisaran 127.0.0.0/8).
Lalu lintas menyang alamat ClusterIP kanggo layanan tartamtu ing kluster Kubernetes tanpa Istio dicegat dening kube-proxy lan dikirim menyang backend proxy kasebut. Yen sampeyan kasengsem ing rincian teknis, kube-proxy nyetel aturan iptables (utawa penyeimbang beban IPVS, gumantung carane dikonfigurasi) kanggo nulis ulang alamat IP tujuan sambungan menyang alamat ClusterIP.
Sawise Istio diinstal ing kluster Kubernetes, ora ana owah-owahan nganti diaktifake kanthi jelas kanggo konsumen tartamtu, utawa malah kabeh ruang jeneng, kanthi ngenalake wadhah. sidecar menyang pods adat. Wadah iki bakal muter conto Utusan lan nyetel set aturan iptables kanggo nyegat lalu lintas menyang layanan liyane lan ngarahake lalu lintas kasebut menyang Utusan.
Yen digabungake karo DNS Kubernetes, iki tegese kode kita bisa nyambung kanthi jeneng layanan lan kabeh "mung bisa digunakake." Ing tembung liyane, kode kita masalah pitakon kaya http://api/v1/users/4242banjur api mutusake masalah panjalukan kanggo 10.97.105.48, aturan iptables bakal nyegat sambungan saka 10.97.105.48 lan nerusake menyang proxy Utusan lokal, lan proxy lokal bakal nerusake panjalukan menyang API backend sing nyata. Phew!
Embel-embel tambahan
Istio uga nyedhiyakake enkripsi end-to-end lan otentikasi liwat mTLS (mutual TLS). Komponen sing diarani Benteng.
Ana uga komponen Mixer, sing bisa dijaluk Utusan saben njaluk nggawe keputusan khusus babagan panyuwunan kasebut gumantung saka macem-macem faktor kayata header, beban backend, lsp... (aja kuwatir: ana akeh cara supaya Mixer tetep mlaku, lan sanajan nabrak, Utusan bakal terus kerja. apik minangka proxy).
Lan, mesthi, kita kasebut visibilitas: Utusan ngumpulake jumlah metrik sing akeh nalika nyedhiyakake tracing sing disebarake. Ing arsitektur microservices, yen panjalukan API siji kudu ngliwati layanan mikro A, B, C, lan D, banjur nalika mlebu, tracing sing disebarake bakal nambah pengenal unik menyang panyuwunan lan nyimpen pengenal kasebut ing subrequests menyang kabeh layanan mikro kasebut, ngidini kabeh telpon sing gegandhengan bakal dijupuk. telat, etc.
Ngembangake utawa tuku
Istio nduweni reputasi minangka kompleks. Ing kontras, mbangun bolong nuntun sing aku diterangake ing awal kirim iki relatif prasaja nggunakake alat sing wis ana. Dadi, apa tegese nggawe bolong layanan sampeyan dhewe?
Yen kita duwe kabutuhan andhap asor (kita ora perlu visibilitas, pemutus sirkuit lan subtleties liyane), banjur pikirane teka kanggo ngembangaken alat kita dhewe. Nanging yen kita nggunakake Kubernetes, bisa uga ora dibutuhake amarga Kubernetes wis nyedhiyakake alat dhasar kanggo nemokake layanan lan imbangan muatan.
Nanging yen kita duwe syarat sing luwih maju, banjur "tuku" bolong layanan misale jek dadi pilihan sing luwih apik. (Iki ora mesthi "tuku" amarga Istio mbukak sumber, nanging kita isih kudu nandur modal wektu teknik kanggo ngerti, nyebarake, lan ngatur.)
Apa aku kudu milih Istio, Linkerd utawa Consul Connect?
Nganti saiki, kita mung ngomong babagan Istio, nanging iki ora mung bolong layanan. Alternatif populer - , lan ana liyane .
Apa milih?
Jujur aku ora ngerti. Ing wayahe aku ora nganggep aku cukup kompeten kanggo njawab pitakonan iki. Ana sawetara kanthi mbandhingake alat kasebut lan malah .
Salah sawijining pendekatan sing njanjeni yaiku nggunakake alat kaya . Iki ngetrapake lapisan abstraksi kanggo nyederhanakake lan nyawijikake API sing kapapar dening meshes layanan. Tinimbang sinau API spesifik (lan, miturut pendapatku, relatif rumit) saka macem-macem layanan, kita bisa nggunakake konstruksi SuperGloo sing luwih gampang - lan gampang ngalih saka siji menyang liyane, kaya-kaya kita duwe format konfigurasi penengah sing njlèntrèhaké antarmuka HTTP lan backends. nggawe konfigurasi nyata kanggo Nginx, HAProxy, Traefik, Apache...
Aku wis dabbled sethitik karo Istio lan SuperGloo, lan ing artikel sabanjuré aku arep kanggo nuduhake carane nambah Istio utawa Linkerd menyang kluster ana nggunakake SuperGloo, lan carane terakhir njaluk proyek rampung, sing ngijini sampeyan kanggo ngalih saka siji bolong layanan menyang liyane tanpa nimpa konfigurasi.
Source: www.habr.com