Dina internét (bolong jasa), sareng ieu anu sanés. Horeeee! Tapi naha? Teras, abdi hoyong nyatakeun pendapat abdi yén jasa meshes bakal langkung saé 10 taun ka pengker, sateuacan munculna platform wadah sapertos Docker sareng Kubernetes. Abdi teu ngaraos nyebutkeun yen sudut pandang abdi hadé atawa goréng dibandingkeun batur, tapi saprak jasa meshes sato rada kompléks, sababaraha sudut pandang bakal ngabantu pikeun hadé ngartos aranjeunna.
Kuring bakal ngobrol ngeunaan platform dotCloud, anu diwangun dina langkung ti saratus microservices sareng ngadukung rébuan aplikasi dina peti. Kuring bakal ngajelaskeun tangtangan anu kami hadapi dina ngamekarkeun sareng ngaluncurkeunana, sareng kumaha jasa bolong tiasa (atanapi henteu) ngabantosan.
sajarah dotcloud
Kuring parantos nyerat ngeunaan sajarah dotCloud sareng pilihan arsitéktur pikeun platform ieu, tapi henteu acan seueur ngobrol ngeunaan lapisan jaringan. Upami anjeun henteu hoyong maca ngeunaan dotCloud, ieu mangrupikeun inti: éta mangrupikeun platform-as-a-service PaaS anu ngamungkinkeun para klien ngajalankeun rupa-rupa aplikasi (Java, PHP, Python ...), kalayan dukungan pikeun sajumlah jasa data ( MongoDB, MySQL, Redis...) sareng alur kerja sapertos Heroku: anjeun unggah kode anjeun kana platform, éta ngawangun gambar wadahna sareng nyebarkeunana.
Kuring bakal nyaritakeun kumaha lalu lintas dikirim ka platform dotCloud. Henteu kusabab éta saé pisan (sanaos sistemna damel saé pikeun waktosna!), Tapi utamina kusabab ku bantosan alat-alat modéren, desain sapertos kitu tiasa gampang dilaksanakeun dina waktos anu singget ku tim anu sederhana upami aranjeunna peryogi jalan pikeun rute. lalu lintas antara sakumpulan microservices atanapi sakumpulan aplikasi. Janten, anjeun tiasa ngabandingkeun pilihan: naon anu bakal kajadian upami anjeun ngembangkeun sadayana nyalira atanapi nganggo bolong jasa anu tos aya. Pilihan standar: nyieun sorangan atawa meuli.
Lalu lintas routing pikeun aplikasi hosted
Aplikasi dina dotCloud tiasa ngalaan titik tungtung HTTP sareng TCP.
titik tungtung HTTP dinamis ditambahkeun kana konfigurasi beban balancer klaster . Ieu sami sareng naon anu dilakukeun ku sumber ayeuna di Kubernetes sarta load balancer kawas .
Klién nyambung ka titik tungtung HTTP ngaliwatan domain luyu, disadiakeun ngaran domain nunjuk ka dotCloud load balancers. Euweuh nu husus.
titik tungtung TCP pakait sareng nomer port, nu lajeng dibikeun ka sadaya peti dina tumpukan éta via variabel lingkungan.
Klién tiasa nyambung ka titik tungtung TCP nganggo hostname anu cocog (sapertos gateway-X.dotcloud.com) sareng nomer port.
Ngaran host ieu ngarobih kana klaster server "nats" (henteu aya hubunganana sareng ) anu bakal ngajantenkeun sambungan TCP anu asup ka wadah anu leres (atanapi, upami jasa saimbang beban, ka wadah anu leres).
Upami anjeun wawuh sareng Kubernetes, ieu sigana bakal ngingetkeun anjeun ngeunaan jasa .
Henteu aya jasa anu sami dina platform dotCloud : pikeun kesederhanaan, aksés ka jasa lumangsung cara sarua duanana ti jero sarta luar platform nu.
Sagalana diatur cukup basajan: palaksanaan aslina tina HTTP na TCP routing jaringan meureun ukur sababaraha ratus garis Python. Basajan (Kuring bakal nyebutkeun, naif) algoritma nu geus disampurnakeun jeung tumuwuhna platform jeung mecenghulna sarat tambahan.
Refactoring éksténsif kode nu aya teu diperlukeun. Khususna, bisa langsung ngagunakeun alamat diala ngaliwatan variabel lingkungan.
Kumaha ieu béda ti bolong jasa modern?
kawates pisibilitas. Kami henteu ngagaduhan métrik pikeun routing mesh TCP pisan. Lamun datang ka HTTP routing, versi leuwih panganyarna geus lengkep metrics HTTP kalawan Konci kasalahan sarta waktu respon, tapi jasa modern meshes buka malah salajengna, nyadiakeun integrasi jeung sistem kempelan metrics kawas Prometheus, contona.
Visibilitas penting henteu ngan ukur tina sudut pandang operasional (pikeun ngabantosan masalah), tapi ogé nalika fitur anyar dileupaskeun. Ngawangkong ngeunaan aman и .
efisiensi Routing ogé diwatesan. Dina dotCloud routing mesh, sadaya lalu lintas kedah ngalangkungan gugusan titik rute khusus. Ieu hartosna berpotensi nyebrang sababaraha wates AZ (zona kasadiaan) sareng paningkatan latency anu signifikan. Abdi émut kode ngungkulan nu dijieun leuwih saratus queries SQL per kaca sarta dibuka sambungan anyar ka server SQL pikeun tiap query. Nalika dijalankeun sacara lokal, halamanna langsung dimuat, tapi dina dotCloud peryogi sababaraha detik kanggo ngamuat sabab unggal sambungan TCP (sareng pamundut SQL anu salajengna) nyandak puluhan milidetik. Dina hal husus ieu, sambungan pengkuh direngsekeun masalah.
Meshes jasa modern langkung saé pikeun ngatasi masalah sapertos kitu. Anu mimiti, aranjeunna pariksa yén sambungan anu diarahkeun dina sumber. Aliran logisna sami: клиент → меш → сервис, Tapi ayeuna bolong jalan lokal teu on titik jauh, jadi sambungan nu клиент → меш nyaeta lokal sarta pohara gancang (microseconds tinimbang milliseconds).
Meshes jasa modern ogé nerapkeun algoritma balancing beban anu langkung pinter. Ku ngawas kaséhatan backends, aranjeunna bisa ngirim leuwih lalulintas keur backends gancang, hasilna kinerja sakabéh hadé.
kasalametan ogé hadé. The dotCloud routing bolong ieu ngajalankeun sagemblengna dina EC2 Classic sarta henteu encrypt lalulintas (dina asumsi yén lamun batur junun nempatkeun hiji sniffer on lalulintas jaringan EC2, anjeun geus di masalah badag). jasa modern meshes transparan ngajaga sakabéh lalulintas urang, contona, kalawan auténtikasi TLS silih tur enkripsi salajengna.
Lalu lintas routing pikeun jasa platform
Oke, kami parantos ngabahas lalu lintas antara aplikasi, tapi kumaha upami platform dotCloud sorangan?
Platform sorangan diwangun ku ngeunaan saratus microservices jawab sagala rupa fungsi. Sababaraha nampi pamenta ti anu sanés, sareng sababaraha deui pagawé tukang anu nyambung ka jasa sanés tapi henteu nampi sambungan sorangan. Dina dua kasus, unggal jasa kedah terang titik tungtung alamat anu kedah dihubungkeun.
Seueur jasa tingkat luhur tiasa nganggo bolong rute anu dijelaskeun di luhur. Nyatana, seueur langkung ti XNUMX microservices dotCloud parantos dipasang salaku aplikasi biasa dina platform dotCloud sorangan. Tapi sajumlah leutik jasa-tingkat low (hususna, maranéhanana anu nerapkeun bolong routing ieu) diperlukeun hal basajan, kalawan kagumantungan pangsaeutikna (sabab teu bisa gumantung kana diri digawekeun - masalah hayam heubeul jeung endog alus).
Ladenan tingkat rendah sareng penting ieu disebarkeun ku ngajalankeun wadah langsung dina sababaraha titik konci. Dina waktos anu sami, jasa platform standar henteu aub: linker, scheduler, sareng runner. Upami anjeun hoyong ngabandingkeun sareng platform wadah modern, éta sapertos ngaluncurkeun pesawat kontrol docker run langsung dina titik, tinimbang delegating tugas ka Kubernetes. Ieu geulis sarupa dina konsep , anu ngagunakeun atawa nalika booting klaster mandiri.
Ladenan ieu kakeunaan ku cara anu sederhana sareng kasar: file YAML didaptarkeun nami sareng alamatna; sarta unggal klien kedah nyandak salinan file YAML ieu deployment.
Di hiji sisi, ieu pisan dipercaya, sabab teu merlukeun rojongan ti hiji toko konci / nilai éksternal, kayaning Zookeeper (inget, jsb atawa Konsul teu aya dina waktu éta). Di sisi anu sanés, éta hésé pikeun mindahkeun jasa. Unggal waktos gerakan dilakukeun, sadaya klien kedah nampi file YAML anu diropéa (sareng berpotensi ngamuat deui). Teu nyaman pisan!
Salajengna, urang mimitian nerapkeun skéma anyar, dimana unggal klien disambungkeun ka server proxy lokal. Gantina alamat jeung port, eta ngan perlu nyaho jumlah port sahiji layanan, tur sambungkeun via localhost. The proxy lokal handles sambungan ieu sarta diteruskeun ka server sabenerna. Ayeuna nalika mindahkeun backend ka mesin atawa skala sejen, tinimbang ngamutahirkeun sakabeh klien, ngan kabeh proxy lokal ieu perlu diropéa; sareng reboot henteu diperyogikeun deui.
(Ieu ogé direncanakeun pikeun encapsulate lalulintas dina sambungan TLS tur masang server proxy sejen di sisi panarima, kitu ogé pariksa sertipikat TLS tanpa partisipasi dina layanan panarima, nu ngonpigurasi pikeun nampa sambungan ngan dina. localhost. Langkung seueur ngeunaan éta engké).
Ieu pisan sarupa ti Airbnb, tapi béda anu signifikan nyaéta yén SmartStack dilaksanakeun sareng disebarkeun kana produksi, sedengkeun sistem routing internal dotCloud dikotak nalika dotCloud janten Docker.
Kuring pribadi nganggap SmartStack salah sahiji miheulaan sistem sapertos Istio, Linkerd sareng Consul Connect sabab sadayana nuturkeun pola anu sami:
- Jalankeun proxy dina unggal titik.
- Klién nyambung ka proxy.
- Pesawat kontrol ngamutahirkeun konfigurasi proxy nalika backends robah.
- … Untung!
Palaksanaan Bolong Service Modern
Upami urang kedah nerapkeun grid anu sami ayeuna, urang tiasa nganggo prinsip anu sami. Contona, nyetél zona DNS internal ku pemetaan ngaran layanan ka alamat di spasi 127.0.0.0/8. Teras jalankeun HAProxy dina unggal titik kluster, nampi sambungan dina unggal alamat jasa (dina subnet 127.0.0.0/8) jeung alihan / balancing beban ka backends luyu. Konfigurasi HAProxy tiasa diurus , ngamungkinkeun Anjeun pikeun nyimpen informasi backend di etcd atanapi Konsul tur otomatis nyorong konfigurasi diropéa mun HAProxy lamun diperlukeun.
Ieu kumaha Istio jalan! Tapi kalawan sababaraha béda:
- Mangpaat tinimbang HAProxy.
- Ngahemat konfigurasi backend via Kubernetes API tinimbang jsbd atanapi Konsul.
- Jasa dialokasikeun alamat dina subnet internal (alamat Kubernetes ClusterIP) tibatan 127.0.0.0/8.
- Mibanda komponén tambahan (Citadel) pikeun nambahkeun silih auténtikasi TLS antara klien tur server.
- Ngarojong fitur anyar kayaning circuit megatkeun, tracing disebarkeun, deployment kenari, jsb.
Hayu urang tingali sababaraha bédana.
Utusan Proksi
Envoy Proxy ieu ditulis ku Lyft [saingan Uber di pasar taksi - approx. per.]. Éta sami dina sababaraha cara pikeun proksi anu sanés (sapertos HAProxy, Nginx, Traefik ...), tapi Lyft nyerat sorangan sabab peryogi fitur anu henteu gaduh proksi sanés sareng sigana langkung wijaksana pikeun ngadamel anu énggal tinimbang ngalegaan. hiji nu geus aya.
Utusan tiasa dianggo nyalira. Upami kuring ngagaduhan jasa khusus anu kedah nyambung ka jasa anu sanés, kuring tiasa nyetél éta pikeun nyambung ka Utusan teras dinamis ngonpigurasikeun sareng ngonpigurasi ulang Utusan sareng lokasi jasa anu sanés, bari kéngingkeun seueur tambahan sapertos pisibilitas. Gantina perpustakaan klien custom atanapi suntik kana kode tracing panggero, urang ngirim lalulintas keur Utusan, sarta ngumpulkeun metrics pikeun urang.
Tapi Utusan ogé tiasa dianggo salaku pesawat data (pesawat data) pikeun bolong jasa. Ieu ngandung harti yén ayeuna keur bolong jasa ieu, Utusan geus ngonpigurasi pesawat kontrol (pesawat kontrol).
pesawat kontrol
Dina pesawat kontrol, Istio ngandelkeun API Kubernetes. Ieu henteu béda pisan sareng nganggo confd, anu ngandelkeun jsbd atanapi Konsul pikeun milarian set konci dina datastore. Istio ningali sakumpulan sumber daya Kubernetes ngaliwatan API Kubernetes.
Antara ieu jeung saterusna: Kuring pribadi kapanggih ieu mangpaat anu berbunyi:
Server API Kubernetes mangrupikeun "server bodo" anu nawiskeun panyimpenan, versi, validasi, ngamutahirkeun, sareng semantik sumber daya API.
Istio dirancang pikeun gawé bareng Kubernetes; sareng upami anjeun hoyong nganggo éta di luar Kubernetes, anjeun kedah ngamimitian conto server API Kubernetes (sareng jasa pembantu jsb).
Alamat jasa
Istio ngandelkeun alamat ClusterIP anu dialokasikeun Kubernetes, ku kituna jasa Istio nampi alamat internal (henteu dina rentang 127.0.0.0/8).
Lalu lintas ka alamat ClusterIP pikeun layanan husus dina klaster Kubernetes tanpa Istio dicegat ku kube-proxy sarta dikirim ka tungtung tukang proxy. Upami anjeun resep kana detil téknis, kube-proxy nyetél aturan iptables (atanapi pangimbang beban IPVS, gumantung kana kumaha éta dikonpigurasi) pikeun nulis ulang alamat IP tujuan sambungan anu nuju ka alamat ClusterIP.
Sakali Istio dipasang dina klaster Kubernetes, teu aya anu robih dugi ka sacara eksplisit diaktipkeun pikeun konsumen anu dipasihkeun, atanapi bahkan sadayana rohangan nami, ku cara ngenalkeun wadah. sidecar kana pods custom. Wadah ieu bakal ngamimitian conto Utusan sareng nyetél sakumpulan aturan iptables pikeun ngahalangan lalu lintas anu nuju ka jasa sanés sareng alihan lalu lintas éta ka Utusan.
Nalika diintegrasikeun sareng DNS Kubernetes, ieu hartosna kode urang tiasa nyambung ku nami jasa, sareng sadayana "ngan jalanna". Dina basa sejen, kode urang ngaluarkeun queries kawas http://api/v1/users/4242satuluyna api ngabéréskeun paménta pikeun 10.97.105.48, aturan iptables intercept sambungan ti 10.97.105.48 sarta alihan ka proxy Utusan lokal, nu bakal neruskeun pamundut ka backend API sabenerna. Péh!
Embel-embel tambahan
Istio ogé nyadiakeun énkripsi tungtung-to-tungtung sareng auténtikasi via mTLS (silih TLS). Komponén disebut Citadel.
Aya ogé komponén alat keur nyampur, anu Utusan tiasa nyuhunkeun masing-masing nyuhunkeun nyandak kaputusan khusus ngeunaan pamundut éta gumantung kana sababaraha faktor sapertos header, loading backend, jsb ... (tong hariwang: aya seueur alat pikeun ngajaga Mixer tiasa dianggo, sareng upami nabrak, Utusan bakal terus damel. salaku proxy).
Sareng, tangtosna, urang nyebatkeun pisibilitas: Utusan ngumpulkeun jumlah métrik anu ageung bari nyayogikeun lacak anu disebarkeun. Dina arsitéktur microservices, lamun hiji pamundut API kudu ngaliwatan microservices A, B, C, sarta D, lajeng kana login, tracing disebarkeun bakal nambahan hiji identifier unik kana pamundut jeung nyimpen identifier ieu ngaliwatan subrequests ka sadaya microservices ieu, ngamungkinkeun Anjeun tiasa nyandak sadaya telepon anu aya hubunganana, telatna, jsb.
Ngembangkeun atawa meuli
Istio boga reputasi salaku sistem kompléks. Kontras, ngawangun bolong routing anu ku kuring dijelaskeun dina awal tulisan ieu kawilang gampang sareng alat anu tos aya. Janten, naha éta masuk akal pikeun nyiptakeun bolong jasa anjeun nyalira?
Upami urang gaduh pangabutuh anu sederhana (urang henteu peryogi pisibilitas, pemutus sirkuit sareng subtleties sanésna), maka pikiran muncul ngeunaan ngembangkeun alat urang sorangan. Tapi upami urang nganggo Kubernetes, éta ogé henteu diperyogikeun sabab Kubernetes parantos nyayogikeun alat dasar pikeun mendakan jasa sareng kasaimbangan beban.
Tapi upami urang ngagaduhan syarat anu canggih, maka "meuli" bolong jasa sigana pilihan anu langkung saé. (Ieu teu salawasna "meuli" saprak Istio open source, tapi urang masih kudu investasi waktu rékayasa ngartos, nyebarkeun, sarta ngatur eta.)
Naon anu kudu dipilih: Istio, Linkerd atanapi Consul Connect?
Sajauh ieu kami ngan ukur ngobrol ngeunaan Istio, tapi éta sanés ngan ukur bolong jasa. Alternatif populér nyaéta , tapi aya deui .
Naon milih?
Jujur, kuring henteu terang. Di momen kuring teu nganggap sorangan cukup kompeten pikeun ngajawab patarosan ieu. Aya sababaraha kalawan ngabandingkeun tina parabot ieu komo .
Hiji pendekatan ngajangjikeun nyaéta ngagunakeun alat kawas . Éta ngalaksanakeun lapisan abstraksi pikeun nyederhanakeun sareng ngahijikeun API anu disayogikeun ku meshes jasa. Gantina diajar API husus (sareng, dina pamanggih kuring, rélatif kompléks) rupa-rupa meshes jasa, urang tiasa nganggo constructs SuperGloo basajan - sarta gampang pindah ti hiji ka nu sejen, saolah-olah urang boga hiji format konfigurasi panengah ngajéntrékeun interfaces HTTP na backends. sanggup ngahasilkeun konfigurasi saleresna pikeun Nginx, HAProxy, Traefik, Apache…
Kuring maén sabudeureun kalawan Istio na SuperGloo saeutik, sarta dina artikel salajengna Abdi hoyong nunjukkeun kumaha nambahkeun Istio atanapi Linkerd kana klaster aya maké SuperGloo, sarta kumaha dimungkinkeun bakal ngalakukeun pakasaban na, nyaeta, eta ngidinan Anjeun pikeun pindah ti. hiji bolong jasa ka nu sejen tanpa nulis ulang konfigurasi.
sumber: www.habr.com