Catetan. narjamahkeun.: Service bolong nyaéta fenomena anu teu acan gaduh tarjamahan stabil kana Rusia (leuwih ti 2 sababaraha taun ka pengker kami ngajukeun pilihan "bolong pikeun jasa", sarta saeutik engké sababaraha kolega mimiti aktip ngamajukeun kombinasi "layanan tabung"). Obrolan konstan ngeunaan téknologi ieu nyababkeun kaayaan dimana pamasaran sareng komponén téknis raket pisan. Ieu bahan éndah ti salah sahiji pangarang istilah aslina dimaksudkeun pikeun nyadiakeun kajelasan pikeun insinyur jeung sajabana.
Komik ti
perkenalan
Upami anjeun insinyur parangkat lunak damel dimana waé dina rohangan sistem backend, istilah "jala jasa" sigana parantos aya dina pikiran anjeun dina sababaraha taun ka pengker. Hatur nuhun kana kabeneran aneh, frase ieu nyokot alih industri beuki loba, sarta hype sarta nawaran promosi pakait sareng eta tumuwuh kawas snowball ngalayang Turun gunung tur némbongkeun euweuh tanda slowing handap.
Service bolong lahir di murky, cai bias tina ékosistem pituin awan. Hanjakal, ieu ngandung harti yén loba kontrovérsi sabudeureun eta dibasajankeun "obrolan low-kalori" mun-mun ngagunakeun istilah teknis-outright omong kosong. Tapi lamun motong ngaliwatan sagala noise, anjeun bakal manggihan yén bolong jasa boga fungsi pisan nyata, diartikeun tur penting.
Dina tulisan ieu, kuring bakal nyobian ngalakukeun éta: nyayogikeun pituduh anu jujur, jero, fokus insinyur pikeun ngalayanan bolong. Abdi henteu ngan ukur ngajawab patarosan: "Aya naon?", - tapi ogé "Naha?"jeung "Naha ayeuna?". Tungtungna, kuring bakal nyoba outline naha (dina pendapat abdi) téhnologi husus ieu geus ngabalukarkeun aduk gélo misalna, nu mangrupa carita metot sorangan.
Кто я?
Halo sadayana! Nami abdi . Abdi salah sahiji panyipta - proyék bolong jasa anu munggaran sareng proyék anu disalahkeun pikeun munculna istilah jaring jasa sapertos (punten guys!). (Catetan transl.: Ngomong-ngomong, dina awal munculna istilah ieu, langkung ti 2,5 taun ka pengker, kami parantos narjamahkeun bahan awal pangarang anu sami anu judulna "".) Kuring ogé sirah mangrupakeun ngamimitian nu nyiptakeun hal bolong layanan tiis kawas Linkerd na .
Anjeun meureun bisa nebak yen kuring boga pamadegan pisan bias jeung subjektif dina masalah ieu. Najan kitu, kuring bakal nyobian tetep bias ka minimum (iwal hiji bagian: "Naha aya seueur omongan ngeunaan jasa bolong?", - di mana kuring masih bakal ngabagikeun ideu anu dibayangkeun). Kuring ogé bakal ngalakukeun anu pangsaéna pikeun ngajantenkeun pituduh ieu salaku obyektif sabisa. Pikeun conto husus, kuring utamana bakal ngandelkeun pangalaman Linkerd urang, bari nunjuk kaluar béda (lamun aya) nu kuring terang dina palaksanaan jenis bolong jasa lianna.
Oké, waktos ngaléngkah ka goodies.
Naon ari jasa bolong?
Sanajan sagala hype, struktur bolong jasa cukup basajan. Ieu ngan sakumpulan proxy userspace ayana "gigireun" jasa (urang bakal ngobrol saeutik ngeunaan naon "salajengna" engké), ditambah sakumpulan prosés kontrol. The proxy disebut koléktif pesawat data, jeung prosés kontrol disebut pesawat kontrol. Pesawat data intercepts panggero antara jasa jeung ngalakukeun "sagala sorts hal béda" sareng maranehna; Pesawat kontrol, sasuai, koordinat paripolah proxy jeung nyadiakeun aksés pikeun anjeun, i.e. operator, mun API, sahingga jaringan bisa dimanipulasi sarta diukur sakabéhna.
Jenis proxy ieu? Ieu mangrupikeun proxy TCP Lapisan 7-sadar (nyaéta "nyandak kana akun" lapisan 7 model OSI) sapertos HAProxy sareng NGINX. Anjeun tiasa milih proxy anu anjeun resep; Linkerd ngagunakeun proxy Rust, ngan saukur ngaranna . Urang nunda babarengan husus pikeun bolong jasa. Meshes séjén resep proxy séjén (Utusan mangrupakeun pilihan umum). Nanging, milih proxy ngan ukur palaksanaan.
Naon anu dilakukeun ku server proxy ieu? Jelas, aranjeunna nelepon proxy ka sareng ti jasa (sacara ketat, aranjeunna bertindak salaku proxy sareng proxy sabalikna, nanganan telepon asup sareng telepon kaluar). Sareng aranjeunna ngalaksanakeun set fitur anu museurkeun kana telepon di antara jasa. Fokus kana lalu lintas antara jasa nyaéta anu ngabédakeun proxy bolong jasa tina, sebutkeun, gerbang API atanapi proksi ingress (anu terakhir fokus kana telepon anu asup kana kluster ti dunya luar). (Catetan. narjamahkeun.: Pikeun ngabandingkeun pangendali Ingress anu aya pikeun Kubernetes, seueur anu nganggo Utusan anu parantos disebatkeun, tingali .)
Janten, kami parantos nyortir pesawat data. Pesawat kontrol langkung saderhana: éta mangrupikeun sakumpulan komponén anu nyayogikeun sadaya mékanika anu kedah dioperasikeun ku pesawat data sacara terkoordinasi, kalebet penemuan jasa, ngaluarkeun sertipikat TLS, agrégasi métrik, jsb. Pesawat data nginpokeun ka pesawat kontrol kalakuanana; dina gilirannana, pesawat kontrol nyadiakeun API nu ngidinan Anjeun pikeun ngarobah jeung ngawas kabiasaan pesawat data sakabéhna.
Di handap ieu diagram pesawat kontrol jeung pesawat data dina Linkerd. Sakumaha anjeun tiasa tingali, pesawat kontrol kalebet sababaraha komponén anu béda, kalebet conto Prometheus anu ngumpulkeun métrik tina server proxy, ogé komponén sanés sapertos destination (Papanggihan jasa), identity (otoritas sertipikat, CA) jeung public-api (titik tungtung pikeun wéb sareng CLI). Kontras, pesawat data nyaéta linkerd-proxy basajan gigireun conto aplikasi. Ieu ngan diagram logika; Dina panyebaran dunya nyata, anjeun tiasa gaduh tilu réplika unggal komponén pesawat kontrol sareng ratusan atanapi rébuan proksi dina pesawat data.
(Sagi opat biru dina diagram ieu ngalambangkeun wates pods Kubernetes. Anjeun tiasa ningali yén wadahna sareng linkerd-proxy aya dina pod anu sami sareng wadah aplikasi. Skéma ieu katelah salaku wadah sidecar.)
Arsitéktur bolong jasa ngagaduhan sababaraha implikasi anu penting. Anu mimiti, sabab tugas proksi nyaéta nyegat telepon antara jasa, bolong jasa ngan ukur masuk akal upami aplikasi anjeun diciptakeun pikeun sakumpulan jasa anu tangtu. bolong bisa pamakéan kalawan monoliths, tapi ieu jelas kaleuleuwihan demi hiji proxy tunggal, sarta pungsionalitasna saperti teu mirip jadi di paménta.
konsékuansi penting séjénna nyaéta yén bolong jasa merlukeun badag jumlah proxy. Kanyataanna, Linkerd nempel a linkerd-proxy ka unggal conto tina unggal jasa (implements séjén nambahkeun proxy ka unggal titik / host / mesin virtual. Éta pisan atoh). Pamakéan proksi aktif sapertos kitu nyalira nyababkeun sababaraha komplikasi tambahan:
- Proxies dina pesawat data kudu gancang, sabab pikeun tiap telepon aya sababaraha telepon ka proxy: hiji di sisi klien, hiji di sisi server.
- Ogé proxy kedah leutik и hampang. Masing-masing bakal meakeun memori sareng sumber CPU, sareng konsumsi ieu bakal tumbuh sacara linier sareng aplikasi.
- Anjeun peryogi mékanisme pikeun nyebarkeun sareng ngapdet sajumlah ageung proksi. Ngalakukeunana sacara manual sanés pilihan.
Sacara umum, bolong jasa sapertos kieu (sahenteuna tina pandangan panon manuk): anjeun nyebarkeun sakumpulan proksi ruang pangguna anu "ngalakukeun hiji hal" sareng lalu lintas inter-jasa internal, sareng nganggo pesawat kontrol pikeun ngawas sareng ngatur aranjeunna.
Ayeuna waktuna naroskeun patarosan "Naha?"
Naon ari bolong jasa?
Jalma anu mimiti mendakan ideu bolong jasa tiasa dihampura ku perasaan rada trepidatious. Desain bolong jasa hartosna yén éta henteu ngan ukur ningkatkeun latency dina aplikasi, tapi ogé meakeun sumberdaya jeung bakal nambahan kebat mékanisme anyar dina infrastruktur. Mimiti anjeun nyetél bolong jasa, teras ujug-ujug anjeun mendakan diri anjeun peryogi jasa ratusan (upami sanés rébuan) proksi. Patarosanna, saha anu sacara sukarela ngalakukeun ieu?
Jawaban kana patarosan ieu aya dua bagian. Kahiji, waragad urus pakait sareng deploying proxy ieu bisa nyata ngurangan berkat sababaraha parobahan lumangsung dina ékosistem nu (langkung lengkep ihwal ieu engké).
Kadua, alat sapertos ieu saleresna mangrupikeun cara anu saé pikeun ngenalkeun logika tambahan kana sistem. Henteu ngan kusabab bolong jasa tiasa nambihan seueur fungsionalitas énggal, tapi ogé kusabab éta tiasa dilakukeun tanpa ngaganggu ékosistem. Kanyataanna, sakabéh model bolong jasa dumasar kana premis ieu: dina sistem multiservice, euweuh urusan naon ngalakukeun jasa individu, lalulintas diantarana mangrupa titik idéal pikeun nambahkeun fungsionalitas.
Contona, dina Linkerd (kawas lolobana meshes) pungsionalitasna fokus utamana dina panggero HTTP, kaasup HTTP / 2 na gRPC *. Fungsionalitasna cukup beunghar - éta tiasa dibagi kana tilu kelas:
- Fitur patali jeung reliabiliti. Paménta anu diulang-ulang, waktosna waktos, pendekatan kanaria (pemisahan lalu lintas / alihan), jsb.
- Fitur patali jeung ngawaskeun. Agregasi tingkat kasuksésan, telat sareng volume pamundut pikeun tiap jasa atanapi arah individu; pangwangunan peta topologi jasa, jsb.
- Fitur patali jeung kaamanan. Silih TLS, kontrol aksés, jsb.
* Tina sudut pandang Linkerd, gRPC praktis henteu béda ti HTTP / 2: éta ngan ngagunakeun protobuf dina payload. Tina sudut pandang pamekar, dua hal éta, tangtosna, béda.
Loba mékanisme ieu beroperasi dina tingkat pamundut (ku kituna "L7 proxy"). Contona, upami ladenan Foo nelepon HTTP pikeun layanan Bar, linkerd-proxy di sisi Foo bisa ngalakukeun calakan load balancing sarta nelepon ruteu ti Foo mun Bar instansi dumasar latency observasi; eta bisa ngulang pamundut lamun perlu (jeung lamun idempotent); eta bisa ngarekam kodeu respon na timeout, jsb. Nya kitu, linkerd-proxy dina sisi Bar bisa nolak pamundut lamun teu diwenangkeun atawa wates pamundut ngaleuwihan; bisa ngarekam reureuh dina bagian na, jsb.
Proxies tiasa "ngalakukeun hiji hal" dina tingkat sambungan ogé. Contona, linkerd-proxy di sisi Foo tiasa ngamimitian sambungan TLS, sareng linkerd-proxy di sisi Bar tiasa ngeureunkeunana, sareng dua sisi tiasa pariksa sertipikat TLS masing-masing *. Ieu nyadiakeun teu ngan enkripsi antara jasa, tapi ogé cara cryptographically aman pikeun ngaidentipikasi jasa: Foo na Bar bisa "ngabuktikeun" yen aranjeunna anu aranjeunna nyebutkeun aranjeunna.
* "Silih babaturan" hartosna yén sertipikat klien ogé diverifikasi (silih TLS). Dina TLS "klasik", contona antara browser sareng server, sertipikat ngan ukur hiji sisi (server) biasana diverifikasi.
Henteu paduli naha aranjeunna beroperasi dina tingkat paménta atanapi sambungan, penting pikeun negeskeun yén sadaya fungsi bolong jasa operasional karakter. Linkerd henteu tiasa ngarobih semantik tina payload - contona, nambihan widang kana sempalan JSON atanapi ngadamel parobihan kana protobuf. Urang bakal ngobrol ngeunaan fitur penting ieu engké nalika urang ngobrol ngeunaan ESB na middleware.
Ieu mangrupikeun set fitur anu ditawarkeun ku bolong jasa. Patarosan timbul: naha henteu nerapkeun aranjeunna langsung dina aplikasi? Jeung naha ganggu ku proxy pisan?
Naha bolong jasa mangrupakeun ide nu sae
Sanaos kamampuan bolong jasa anu pikaresepeun, nilai inti na henteu leres-leres aya dina fiturna. Tungtungna urang Tiasa nerapkeun aranjeunna langsung dina aplikasi (urang bakal ningali engké yén ieu asalna tina bolong jasa). Pikeun nyobaan sareng nyimpulkeun dina hiji kalimat, nilai bolong jasa nyaéta: eta nyadiakeun fitur kritis pikeun ngajalankeun software server modern dina ragam konsisten sakuliah sakabéh tumpukan sarta bebas kode aplikasi.
Hayu urang analisa usulan ieu.
«Fitur kritis pikeun ngajalankeun software server modern" Upami anjeun nyiptakeun aplikasi pangladén transaksional anu nyambung ka Internét umum, nampi pamundut ti dunya luar sareng ngarésponana dina waktos anu singget - contona, aplikasi wéb, pangladén API, sareng seuseueurna aplikasi modern anu sanés. - sareng upami anjeun ngalaksanakeunana salaku sakumpulan jasa anu sacara sinkron saling berinteraksi, sareng upami anjeun terus-terusan ningkatkeun parangkat lunak ieu, nambihan fitur-fitur anyar, sareng upami anjeun kapaksa ngajaga sistem ieu dina urutan kerja salami prosés modifikasi - dina ieu bisi, ucapan salamet, anjeun nyieun software server modern. Sareng sadaya fitur hébat ieu anu didaptarkeun di luhur saleresna janten kritis pikeun anjeun. Aplikasina kedah dipercaya, aman, sareng anjeun kedah tiasa niténan naon anu dilakukeunana. Ieu persis patarosan anu bolong jasa ngabantosan ngajawab.
(OKÉ, paragraf saméméhna masih kaasup kapercayaan abdi yen pendekatan ieu cara modern pikeun nyieun software server. Batur resep ngamekarkeun monoliths, "microservices réaktif" jeung hal séjén anu teu digolongkeun dina harti ditétélakeun di luhur. pendapat mah béda ti kuring. Kahareupna kuring nyangka yén aranjeunna "salah" - sanaos dina hal naon waé jasa bolong henteu kapaké pisan pikeun aranjeunna).
«Saragam pikeun sakabéh tumpukan" Fungsionalitas anu disayogikeun ku bolong jasa sanés ngan ukur penting pikeun misi. Éta dilarapkeun ka sadaya jasa dina aplikasi, paduli basa naon maranéhna ditulis dina, naon kerangka aranjeunna ngagunakeun, anu nulis aranjeunna, kumaha aranjeunna deployed, sarta sagala subtleties séjén tina ngembangkeun sarta pamakéan maranéhanana.
«Bebas tina kode aplikasi" Tungtungna, bolong jasa henteu ngan ukur nyayogikeun fungsionalitas anu konsisten dina sadaya tumpukan, tapi ogé ku cara anu henteu ngabutuhkeun aplikasi pikeun diédit. Dasar dasar fungsionalitas jasa bolong, kalebet tugas pikeun konfigurasi, ngamutahirkeun, operasi, pangropéa, sareng sajabana, sadayana aya dina tingkat platform sareng henteu gumantung kana aplikasi. Aplikasina tiasa robih tanpa mangaruhan bolong jasa. Sabalikna, bolong jasa tiasa robih tanpa partisipasi tina aplikasi.
Pondokna, bolong jasa henteu ngan ukur nyayogikeun fungsionalitas anu penting, tapi ogé ngalakukeunana sacara global, seragam, sareng mandiri aplikasi. Janten, sanaos fungsionalitas jasa bolong tiasa dilaksanakeun dina kode jasa (contona, salaku perpustakaan anu kalebet dina unggal jasa), pendekatan ieu moal nyayogikeun kaseragaman sareng kamerdikaan anu berharga pisan dina kasus bolong jasa.
Sareng sadaya anu anjeun kedah laksanakeun nyaéta nambihan sakumpulan proksi! Abdi janji urang bakal ningali biaya operasional anu aya hubunganana sareng nambihan proksi ieu pas. Tapi mimitina hayu urang lirén sareng ningali ide kamerdikaan ieu tina sudut pandang anu béda. jalma.
Saha anu ngabantosan jasa bolong?
Sanaos henteu pikaresepeun, pikeun téknologi janten bagian penting tina ékosistem, éta kedah ditampi ku masarakat. Janten saha anu resep kana jasa bolong? Saha kauntungan tina pamakéanana?
Upami anjeun nuju ngembangkeun parangkat lunak pangladén modern, anjeun tiasa nganggap tim anjeun salaku grup boga jasaanu babarengan ngamekarkeun sarta ngalaksanakeun logika bisnis, jeung boga platform, ngamekarkeun platform internal nu jasa ieu beroperasi. Dina organisasi leutik, ieu bisa jadi jalma anu sarua, tapi salaku parusahaan tumuwuh, kalungguhan ieu condong jadi leuwih dibaca malah dibagi kana sub-peran ... (Aya loba bisa disebutkeun didieu ngeunaan sifat ngarobah devops, dampak organisasi microservices, jsb) n. Tapi pikeun ayeuna hayu urang nyandak déskripsi ieu sakumaha dibikeun).
Tina sudut pandang ieu, ahli waris anu jelas tina bolong jasa nyaéta pamilik platform. Barina ogé, pamustunganana tujuan tim platform nyaéta nyiptakeun platform internal dimana pamilik jasa tiasa nerapkeun logika bisnis sareng ngalakukeunana ku cara anu ngajamin yén aranjeunna bebas sabisa tina detil murky operasina. Henteu ngan ukur bolong jasa nawiskeun kamampuan anu penting pikeun ngahontal tujuan ieu, tapi ogé ku cara anu henteu maksakeun katergantungan ka anu gaduh jasa.
Pamilik jasa ogé nguntungkeun, sanaos ku cara anu henteu langsung. Tujuan tina nu boga jasa nyaéta pikeun jadi produktif sabisa dina ngalaksanakeun logika prosés bisnis, sarta kirang anjeunna boga salempang ngeunaan masalah operasional, anu hadé. Gantina kudu nungkulan palaksanaan, sebutkeun, coba deui kawijakan atawa TLS, aranjeunna bisa museurkeun solely on tujuan bisnis jeung miharep platform ngurus sésana. Ieu mangrupikeun kauntungan anu ageung pikeun aranjeunna.
Nilai organisasi tina pembagian sapertos antara nu gaduh platform sareng jasa henteu tiasa diéstimasikeun. Jigana manehna nyumbang utama kontribusi kana nilai bolong jasa.
Kami diajar palajaran ieu nalika kipas Linkerd awal nyarioskeun ka kami naha aranjeunna milih jasa bolong: sabab ngamungkinkeun aranjeunna "ngajantenkeun toko ngobrol ka minimum." Ieu sababaraha rinci: jalma-jalma ti hiji perusahaan ageung migrasi platformna ka Kubernetes. Kusabab aplikasi éta ngatur inpormasi sénsitip, aranjeunna hoyong énkripsi sadaya komunikasi dina klaster. Tapi, kaayaan éta pajeulit ku ayana ratusan jasa sareng ratusan tim pangembangan. Prospek pikeun ngahubungi sadayana sareng ngayakinkeun aranjeunna ngalebetkeun dukungan TLS dina rencanana henteu ngajantenkeun aranjeunna bagja. Saatos masang Linkerd, aranjeunna mindahkeun tanggung jawab ti pamekar (ti sudut pandang nu ieu masalah teu perlu) ka platformers, pikeun saha ieu prioritas tingkat luhur. Dina basa sejen, Linkerd direngsekeun pikeun aranjeunna teu jadi loba masalah teknis salaku hiji organisasi.
Pondokna, bolong jasa langkung seueur solusi, sanés téknis, tapi sosio-teknis Masalah. (Hatur nuhun pikeun ngawanohkeun istilah ieu.)
Naha bolong jasa bakal ngabéréskeun sadaya masalah kuring?
Sumuhun. Maksad abdi, henteu!
Upami anjeun ningali tilu kelas fitur anu digariskeun di luhur-reliabilitas, kaamanan, sareng observasi-teras jelas yén bolong jasa sanés mangrupikeun solusi anu lengkep pikeun masalah ieu. Nalika Linkerd tiasa ngaluarkeun deui pamundut (upami terang aranjeunna idempoten), éta henteu tiasa nyandak kaputusan ngeunaan naon anu kedah dipulangkeun deui ka pangguna upami palayanan parantos gagal permanén - kaputusan éta kedah dilakukeun ku aplikasi. Linkerd tiasa ngajaga statistik pamundut anu suksés, tapi éta henteu tiasa ningali kana jasa sareng nyayogikeun métrik internalna - aplikasina kedah gaduh alat sapertos kitu. Sareng sanaos Linkerd tiasa ngatur mTLS, solusi kaamanan anu lengkep peryogi langkung seueur.
A sawaréh ti fitur di wewengkon ieu ditawarkeun ku bolong jasa patali jeung fitur platform. Ku ieu maksudna mah fungsi anu:
- Bebas tina logika bisnis. Cara nu nelepon histograms antara Foo na Bar anu diwangun sagemblengna bebas tina naha Foo nelepon Bar.
- Hésé dilaksanakeun kalayan leres. Dina Linkerd, retries anu parameterized kalawan sagala sorts hal fancy kawas retry budgets (Coba deui anggaran), saprak hiji unsophisticated, pendekatan sirah-on pikeun ngalaksanakeun hal saperti pasti bakal ngakibatkeun mecenghulna nu disebut "avalanche of requests" (coba deui badai) sareng masalah-masalah sanés anu ciri tina sistem anu disebarkeun.
- Paling éféktif lamun dilarapkeun seragam. Mékanisme TLS ngan ukur masuk akal upami diterapkeun di mana waé.
Kusabab fungsi ieu dilaksanakeun di tingkat proxy (teu di tingkat aplikasi), bolong jasa nyadiakeun aranjeunna dina platform, sanes aplikasi. Ku kituna, henteu masalah naon basa ladenan ditulis dina, kerangka naon maranéhna ngagunakeun, saha nu nulis aranjeunna sarta naha. Proxies beroperasi di luar sadaya rinci ieu, sarta dasar dasar tina pungsi ieu, kaasup tugas pikeun konfigurasi, ngamutahirkeun, operasi, pangropéa, jeung sajabana, perenahna solely di tingkat platform.
Conto kamampuhan bolong jasa
Pikeun nyimpulkeun, bolong jasa sanes solusi lengkep pikeun reliabilitas, observasi, atanapi kaamanan. Wewengkon wewengkon ieu merlukeun partisipasi nu boga jasa, Ops / tim SRE jeung entitas pausahaan séjén. Bolong jasa ngan ukur nyayogikeun "potongan" tingkat platform pikeun tiap daérah ieu.
Naha jasa bolong janten populer ayeuna?
Ayeuna anjeun panginten panginten: ok, upami bolong jasa saé, naha urang henteu ngamimitian nyebarkeun jutaan proxy dina tumpukan sapuluh taun ka pengker?
Aya jawaban banal pikeun patarosan ieu: sapuluh taun ka pengker sadayana ngawangun monoliths, sareng teu aya anu peryogi jasa bolong. Ieu leres, tapi dina pendapat abdi jawaban ieu misses titik. Malah sapuluh taun ka tukang, konsép microservices salaku cara ngajangjikeun pikeun ngawangun sistem badag skala ieu loba dibahas sarta dilarapkeun di pausahaan kayaning Twitter, Facebook, Google jeung Netflix. Pandangan umum-sahenteuna dina bagian industri anu kuring ngahubungi-nyaéta yén microservices mangrupikeun "jalan anu leres" pikeun ngawangun sistem anu ageung, sanaos éta sesah.
Tangtosna, sanaos sapuluh taun ka pengker aya perusahaan anu ngoperasikeun jasa mikro, aranjeunna henteu nempelkeun proksi dimana waé aranjeunna tiasa ngabentuk bolong jasa. Nanging, upami anjeun ningali taliti, aranjeunna ngalakukeun hal anu sami: seueur perusahaan ieu peryogi panggunaan perpustakaan internal khusus pikeun komunikasi jaringan (kadangkala disebut perpustakaan klien kandel, perpustakaan klien gajih).
Netflix kagungan Hysterix, Google kagungan Stubby, Twitter kagungan perpustakaan Finagle. Finagle, contona, wajib pikeun unggal layanan anyar dina Twitter. Ieu diatur duanana sisi klien tur server tina sambungan, diwenangkeun pikeun requests diulang, dirojong pamundut routing, load balancing sarta pangukuran. Éta nyayogikeun lapisan réliabilitas sareng observasi anu konsisten dina sadaya tumpukan Twitter, henteu paduli naon anu dilakukeun ku jasa éta. Tangtosna, éta ngan ukur dianggo pikeun basa JVM sareng didasarkeun kana modél program anu kedah dianggo pikeun sakabéh aplikasi. Nanging, pungsionalitasna ampir sami sareng bolong jasa. (Padahal, versi munggaran Linkerd ngan saukur Finagle dibungkus dina bentuk proxy.)
Ku kituna, sapuluh taun ka pengker aya teu ngan microservices, tapi ogé perpustakaan proto-jasa-bolong husus anu direngsekeun masalah anu sarua yén layanan bolong solves kiwari. Tapi, bolong jasa sorangan teu aya harita. Kedah aya hiji shift deui sateuacan anjeunna muncul.
Sareng ieu mangrupikeun jawaban anu langkung jero, disumputkeun dina parobihan sanés anu kajantenan salami 10 taun ka pengker: biaya panyebaran microservices parantos turun sacara dramatis. Perusahaan-perusahaan anu disebatkeun di luhur anu nganggo jasa mikro sapuluh taun ka pengker-Twitter, Netflix, Facebook, Google-nyaéta perusahaan skala ageung sareng sumber daya anu ageung. Aranjeunna henteu ngan ukur peryogi, tapi ogé kamampuan pikeun ngawangun, nyebarkeun, sareng ngoperasikeun aplikasi dumasar-microservices ageung. Énergi sareng usaha anu dilakukeun ku insinyur Twitter pikeun ngalih tina monolithic kana pendekatan microservices endah pisan. (Pikeun adil, janten kanyataan yén éta suksés.) Manuver infrastruktur sapertos kitu henteu mungkin pikeun perusahaan anu langkung alit.
Maju gancang ka ayeuna. Aya ngamimitian ayeuna dimana rasio microservices ka pamekar nyaéta 5: 1 (atanapi bahkan ), sarta naon deui, aranjeunna Cope jeung aranjeunna hasil! Upami ngamimitian 5-jalma tiasa gampang ngoperasikeun 50 jasa mikro, maka aya anu jelas ngirangan biaya palaksanaanna.
1500 microservices di Monzo; unggal garis mangrupakeun aturan jaringan prescribed anu ngamungkinkeun lalulintas
Pangurangan dramatis dina biaya operasi microservices mangrupikeun hasil tina hiji prosés: tumuwuh popularitas wadahna и orkestra. Ieu persis jawaban jero kana patarosan naon nyumbang kana mecenghulna bolong jasa. Téknologi anu sami ngajantenkeun jasa bolong sareng jasa mikro pikaresepeun: Kubernetes sareng Docker.
Naha? Nya, Docker ngarengsekeun hiji masalah gedé - masalah bungkusan. Ku ngabungkus aplikasi sareng katergantungan runtime (non-jaringan) kana wadahna, Docker ngajantenkeun aplikasi janten unit anu tiasa ditukeurkeun anu tiasa di-host sareng dijalankeun dimana waé. Dina waktu nu sarua, eta greatly simplifies operasi multibasa Tumpukan: Kusabab wadahna mangrupikeun unit palaksanaan atom, pikeun panyebaran sareng tujuan operasional, henteu masalah naon anu aya di jero, janten aplikasi JVM, Node, Go, Python, atanapi Ruby. Anjeun ngan ngaluncurkeun éta sareng éta.
Kubernetes nyandak sagalana ka tingkat salajengna. Ayeuna yén aya seueur "hal anu kedah dijalankeun" sareng seueur mesin pikeun ngajalankeunana, peryogi alat anu tiasa ngahubungkeun aranjeunna. Dina rasa anu lega, anjeun masihan Kubernetes seueur wadah sareng seueur mesin, sareng peta aranjeunna ngalawan silih (tangtosna, ieu mangrupikeun prosés anu dinamis sareng kantos robih: wadah énggal ngalih kana sistem, mesin ngamimitian sareng ngeureunkeun. , jsb. Tapi, Kubernetes merhatikeun sadayana ieu).
Sakali Kubernetes dikonpigurasikeun, biaya waktos pikeun nyebarkeun sareng ngoperasikeun hiji layanan sakedik béda ti biaya pikeun nyebarkeun sareng ngoperasikeun sapuluh jasa (saleresna, ampir sami pikeun 100 jasa). Tambihkeun kana wadah ieu salaku mékanisme bungkusan anu nyorong palaksanaan multibasa, sareng anjeun gaduh seueur aplikasi anyar anu dilaksanakeun dina bentuk microservices anu ditulis dina basa anu béda - persis jinis lingkungan anu cocog pisan pikeun bolong jasa.
Janten, urang dugi ka jawaban kana patarosan naha ideu bolong jasa parantos populer ayeuna: homogénitas anu disayogikeun ku Kubernetes pikeun jasa langsung manglaku ka tantangan operasional anu nyanghareupan bolong jasa. Anjeun ngarangkep proxies kana peti, masihan Kubernetes tugas nempel aranjeunna dimana wae eta bisa, sarta voila! Hasilna, anjeun nampi bolong jasa, sedengkeun sadaya mékanika panyebaranna diurus ku Kubernetes. (Sahenteuna ti tempoan panon manuk urang. Tangtu, aya loba nuances kana prosés ieu.)
Pikeun nyimpulkeun éta: alesan jasa meshes parantos populer ayeuna, sareng sanés sapuluh taun ka pengker, nyaéta Kubernetes sareng Docker henteu ngan ukur ningkat sacara signifikan. peryogi di dinya, sanggeus disederhanakeun palaksanaan aplikasi salaku susunan microservices multibasa, tapi ogé nyata ngurangan harga pikeun operasi na, nyadiakeun mékanisme pikeun deploying tur ngarojong armada proxy sidecar.
Naha aya seueur omongan ngeunaan jasa bolong?
pangeling-eling: Dina bagian ieu kuring ngagunakeun sagala rupa asumsi, conjectures, fabrikasi jeung informasi jero.
Milarian "jala jasa" sareng anjeun bakal mendakan ton eusi kalori-rendah daur ulang, proyék-proyék aneh, sareng kaleidoskop distorsi anu pantes pikeun kamar gema. Sakur téknologi anyar anu énggal ngalakukeun ieu, tapi dina kasus bolong jasa masalahna khususna akut. Naha?
Muhun, bagian tina éta lepat abdi. Kuring parantos kerja keras pikeun ngamajukeun Linkerd sareng jasa bolong unggal kasempetan kuring ngalangkungan tulisan blog sareng tulisan sapertos kieu. Tapi kuring henteu kuat. Pikeun leres-leres ngajawab patarosan ieu, urang kedah ngobrol sakedik ngeunaan kaayaan umum. Sareng mustahil pikeun ngobrol ngeunaan éta tanpa nyebatkeun hiji proyék: nyaéta bolong jasa open source anu dikembangkeun babarengan ku Google, IBM sareng Lyft.
(Tilu pausahaan boga kalungguhan pisan béda: involvement Lyft urang mucunghul ngan dina ngaran; aranjeunna panulis Utusan, tapi teu make atawa ilubiung dina ngembangkeun Istio urang. IBM aub dina sarta ngagunakeun ngembangkeun Istio urang. Google aktip aub dina Istio urang pamekaran, tapi henteu leres-leres ngagunakeunana sajauh anu kuring tiasa nyarios.)
Proyék Istio kasohor ku dua hal. Anu mimiti, aya usaha pamasaran anu ageung anu Google, khususna, nempatkeun kana promosi éta. Kuring bakal ngira-ngira yén kalolobaan jalma sadar kana konsép bolong jasa ayeuna mimiti diajar ngeunaan éta ngaliwatan Istio. Hal kadua kumaha kirang nampi Istio éta. Dina urusan ieu, Kami écés mangrupa pihak kabetot, tapi nyobian tetep jadi obyektif sabisa, kuring masih teu bisa mantuan , teu pisan has (sanajan teu unik: systemd datang ka pikiran, ...) pikeun proyék Open Source.
(Dina prakna, Istio sigana boga masalah teu ukur ku pajeulitna sarta UX, tapi ogé kalawan kinerja. Contona, salila Dina panilitian pihak katilu, panalungtik mendakan kaayaan dimana latensi buntut Istio 100 kali langkung luhur tibatan Linkerd, kitu ogé kaayaan kalaparan sumber daya dimana Linkerd terus tiasa dianggo nalika Istio lirén damel lengkep.)
Ninggalkeun téori kuring ngeunaan naha ieu kajantenan, kuring yakin yén pikagumbiraeun anu luar biasa dina bolong jasa dijelaskeun ku partisipasi Google. Nyaéta, kombinasi tilu faktor ieu:
- promosi intrusive Google ngeunaan Istio;
- a saluyu disapproving, sikep kritis kana proyék;
- kebangkitan meteoric panganyarna dina popularitas Kubernetes, kenangan nu masih seger.
Kalawan babarengan faktor ieu digabungkeun pikeun nyieun hiji stupefying, lingkungan bébas oksigén nu kapasitas pikeun judgment rasional lemah, sarta ngan rupa-rupa aneh tetep. .
Tina sudut pandang Linkerd, ieu ... naon anu kuring ngajelaskeun salaku berkah anu dicampur. Maksad abdi, saé pisan yén jasa bolong parantos lebet kana arus utama dina cara anu henteu di 2016 nalika Linkerd mimiti ngamimitian sareng éta hésé pisan pikeun narik jalma pikeun nengetan proyék éta. Ayeuna teu aya masalah sapertos kitu! Tapi wartos anu goréng nyaéta yén bentang jasa bolong matak ngabingungkeun ayeuna dugi ka ampir teu mungkin ngartos proyék mana anu saleresna kalebet dina kategori bolong jasa (sumawonten ngartos mana anu paling cocog pikeun pamakean khusus). Ieu pasti dealbreaker for everyone (jeung pasti aya sababaraha kasus dimana Istio atawa proyék séjén leuwih hade tinimbang Linkerd, saprak kiwari dimungkinkeun masih teu solusi universal).
Di sisi Linkerd, strategi kami nyaéta pikeun teu malire sora, terus fokus dina ngarengsekeun masalah komunitas nyata, sareng dasarna ngantosan hype maot. Pamustunganana, hype bakal suda sareng urang tiasa teras damel kalayan tenang.
Samentawis waktos, urang sadayana kedah sabar sakedik.
Naha bolong jasa bakal mangpaat pikeun kuring, insinyur software anu hina?
Angkét di handap ieu bakal ngabantosan anjeun ngajawab patarosan ieu:
Naha anjeun ngan ukur aub dina ngalaksanakeun logika bisnis? Dina hal ieu, bolong jasa moal aya gunana pikeun anjeun. Nyaéta, tangtosna, anjeun tiasa resep kana éta, tapi idéalna bolong jasa henteu langsung mangaruhan naon waé di lingkungan anjeun. Terus ngerjakeun naon anu anjeun dibayar.
Naha anjeun ngadukung platform di perusahaan anu nganggo Kubernetes? Sumuhun, dina hal ieu anjeun perlu bolong jasa (iwal, tangtosna, anjeun ngagunakeun K8s ngan pikeun ngajalankeun hiji monolith atanapi bets processing - tapi lajeng Abdi hoyong nanya naha anjeun peryogi K8s). Anjeun kamungkinan bakal mungkas nepi ka loba microservices ditulis ku jalma béda. Éta sadayana saling berinteraksi sareng dihijikeun kana kusut gumantungna runtime, sareng anjeun kedah milarian cara pikeun ngatasi éta sadayana. Nganggo Kubernetes ngamungkinkeun anjeun milih bolong jasa "kanggo diri anjeun." Jang ngalampahkeun ieu, familiarize diri kalawan kamampuhan sarta fitur maranéhanana sarta ngajawab patarosan naha salah sahiji proyék sadia cocog pikeun anjeun (Kuring nyarankeun ngamimitian panalungtikan anjeun kalawan Linkerd).
Naha anjeun perusahaan platform di perusahaan anu henteu nganggo Kubernetes tapi nganggo jasa mikro? Dina hal ieu, bolong jasa bakal mangpaat ka anjeun, tapi pamakéan na bakal non-trivial. Tangtu bisa niru-niru jasa gawé bolong ku nempatkeun kebat proxy, tapi hiji kaunggulan penting Kubernetes nyaeta model deployment: sacara manual ngajaga proxy ieu bakal merlukeun leuwih waktos, usaha jeung expense.
Naha anjeun tanggung jawab platform dina perusahaan anu damel sareng monolith? Dina hal ieu, anjeun panginten henteu peryogi bolong jasa. Upami anjeun damel sareng monoliths (atanapi koleksi monoliths) anu gaduh pola interaksi anu jelas sareng jarang robih, maka bolong jasa bakal sakedik nawiskeun anjeun. Janten anjeun ngan saukur tiasa teu malire sareng ngarepkeun éta bakal ngaleungit sapertos impian anu goréng ...
kacindekan
Panginten, jasa bolong tetep henteu kedah disebat "téknologi anu paling hyped di dunya" - kahormatan anu diragukeun ieu sigana milik Bitcoin atanapi AI. Manehna meureun dina lima luhur. Tapi lamun motong ngaliwatan lapisan noise, janten jelas yén bolong jasa mawa kauntungan nyata pikeun jalma anu ngawangun aplikasi dina Kubernetes.
Abdi hoyong anjeun nyobian Linkerd - masang éta dina klaster Kubernetes (atanapi Minikube dina laptop) , tur anjeun tiasa ningali keur diri naon Kuring ngawangkong ngeunaan.
FAQ
- Upami kuring teu malire bolong jasa, bakal ngaleungit?
- Abdi kedah nguciwakeun anjeun: jasa bolong aya sareng kami kanggo lami.
- Tapi kuring TEU HAYANG ngagunakeun jasa bolong!
- Muhun, teu perlu! Ngan maca kuesioner kuring di luhur pikeun ngarti naha anjeun sahenteuna kedah familiarize diri sareng dasarna.
- Teu ieu ESB heubeul alus / middleware kalawan saos anyar?
- Service bolong ngurus logika operasional, sanes semantik. bus jasa perusahaan (). Ngajaga pamisahan ieu ngabantosan bolong jasa ngahindarkeun nasib anu sami.
— Kumaha bolong jasa béda sareng gerbang API?
- Aya sajuta artikel ngeunaan topik ieu. Ngan Google eta.
— Utusan téh bolong jasa?
- Henteu, Utusan sanés bolong jasa, éta mangrupikeun server proxy. Éta tiasa dianggo pikeun ngatur bolong jasa (sareng seueur deui - éta mangrupikeun proxy tujuan umum). Tapi dina diri éta sanés bolong jasa.
- Network Service Mesh mangrupikeun jasa bolong?
- Henteu. Sanajan ngaranna, ieu lain bolong jasa (kumaha anjeun resep miracles pamasaran?).
— Naha bolong jasa bakal ngabantosan sareng sistem Asynchronous réaktif dumasar antrian pesen kuring?
- Henteu, bolong jasa moal ngabantosan anjeun.
— Bolong jasa mana anu kuring kedah dianggo?
- , euweuh brainer.
- Tulisan éta ngabeledug! / Panulis wilujeng sumping!
— Punten bagikeun tautan ka sadaya réréncangan anjeun supados aranjeunna tiasa ningali éta!
Ngahaturkeun
Sakumaha anjeun tiasa duga tina judulna, tulisan ieu diideuan ku risalah hebat Jay Kreps "" Kuring tepang sareng Jay sapuluh taun ka pengker nalika kuring diwawancara dina Linked In sareng anjeunna parantos janten inspirasi pikeun kuring ti saprak éta.
Bari kuring resep nelepon sorangan "Linkerd pamekar", kanyataanana yen Abdi langkung ti hiji maintainer file README.md on proyék a. Linkerd keur digarap kiwari , , jalma, sarta proyék ieu moal lumangsung tanpa partisipasi komunitas éndah kontributor sarta pamaké.
Tungtungna, hatur nuhun khusus ka pencipta Linkerd, (primus inter pares), anu, babarengan jeung kuring sababaraha taun ka pengker, dived headlong kana sagala fuss ieu kalawan bolong jasa.
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «";
- «";
- «".
sumber: www.habr.com