Cathetan. nerjemahake.: Bolong layanan minangka fenomena sing durung duwe terjemahan sing stabil ing basa Rusia (luwih saka 2 taun kepungkur, kita ngusulake pilihan "bolong kanggo layanan", lan sawetara kolega wiwit aktif promosi kombinasi "sieve layanan"). Dhiskusi sing terus-terusan babagan teknologi iki nyebabake kahanan ing ngendi komponen pemasaran lan teknis banget raket. Materi sing apik banget saka salah sawijining penulis istilah asli iki dimaksudake kanggo menehi kajelasan kanggo insinyur lan liya-liyane.
Komik saka
Pambuka
Yen sampeyan insinyur piranti lunak sing kerja ing papan sistem backend, istilah "bolong layanan" bisa uga wis ana ing pikiran sampeyan sajrone sawetara taun kepungkur. Thanks kanggo ketepakan aneh, tembung iki njupuk liwat industri liyane lan liyane, lan hype lan tawaran promosi sing digandhengake karo iku mundak akeh kaya snowball mabur mudhun lan ora nuduhake pratandha saka kalem mudhun.
Service bolong lair ing murky, banyu bias saka ekosistem native maya. Sayange, iki tegese akeh kontroversi ing saubengé saka "omong kosong kalori" nganti - nggunakake istilah teknis - omong kosong. Nanging yen sampeyan Cut liwat kabeh gangguan, sampeyan bakal nemokake sing bolong layanan wis banget nyata, ditetepake lan fungsi penting.
Ing kirim iki, aku bakal nyoba nindakake mung: nyedhiyakake pandhuan sing jujur, jero, fokus insinyur kanggo layanan bolong. Aku ora mung arep mangsuli pitakonan: "Opo iki?", - nanging uga "Kenapa?"Lan "Ngapa saiki?". Pungkasan, aku bakal nyoba njelasake kenapa (mratelakake panemume) teknologi tartamtu iki nyebabake kerusuhan edan, yaiku crita sing menarik.
Apa sampeyan?
Halo kabeh! jenengku . Aku minangka salah sawijining pangripta - proyek bolong layanan banget pisanan lan proyek sing kudu disalahake kanggo munculé istilah kasebut layanan bolong kaya ngono (ngapunten wong lanang!). (Wigati transl.: Ngomong-ngomong, nalika esuke muncul istilah iki, luwih saka 2,5 taun kepungkur, kita wis nerjemahake materi awal saka penulis sing padha kanthi judhul "".) Aku uga sirah iku wiwitan sing nggawe bolong layanan kelangan iku kaya Linkerd lan .
Sampeyan mbokmenawa bisa guess sing aku duwe pendapat banget bias lan subyektif ing masalah iki. Nanging, aku bakal nyoba supaya bias minimal (kajaba siji bagean: "Kenapa akeh sing ngomong babagan layanan mesh?", - ing ngendi aku isih bakal nuduhake gagasan-gagasanku sing wis ditemtokake). Aku uga bakal nindakake sing paling apik kanggo nggawe pandhuan iki kanthi objektif. Kanggo conto tartamtu, Aku utamané bakal gumantung ing pengalaman Linkerd kang, nalika pointing metu beda (yen ana) aku ngerti ing implementasine saka jinis layanan bolong liyane.
Oke, wektu kanggo pindhah menyang barang.
Apa iku jala layanan?
Senadyan kabeh hype, struktur bolong layanan cukup prasaja. Iki mung sawetara proxy ruang pangguna sing ana ing "sabanjure" layanan (kita bakal ngomong sethithik babagan "sabanjure" mengko), ditambah karo proses kontrol. Proxy diarani bebarengan pesawat data, lan pangolahan kontrol diarani pesawat kontrol. Pesawat data nyegat telpon antarane layanan lan nindakake "kabeh macem-macem iku" karo wong-wong mau; Pesawat kontrol, miturut, koordinat prilaku proxy lan menehi akses kanggo sampeyan, i.e. operator, menyang API, saéngga jaringan bisa diapusi lan diukur minangka kabèh.
Apa jenis proxy iki? Iki minangka proxy TCP Layer 7-aware (yaiku "nyathet" lapisan 7 saka model OSI) kaya HAProxy lan NGINX. Sampeyan bisa milih proxy sing dikarepake; Linkerd nggunakake proxy Rust, mung dijenengi . Kita sijine iku bebarengan khusus kanggo bolong layanan. Meshes liyane seneng proxy liyane (Utusan minangka pilihan umum). Nanging, milih proxy mung masalah implementasine.
Apa sing ditindakake server proxy iki? Temenan, dheweke nelpon proxy menyang lan saka layanan (secara tegas, dheweke tumindak minangka proxy lan proxy mbalikke, nangani telpon mlebu lan metu). Lan padha ngleksanakake set fitur sing fokus ing telpon antarane layanan. Fokus ing lalu lintas antarane layanan iki sing mbedakake proxy bolong layanan saka, umpamane, gateway API utawa proksi ingress (sing terakhir fokus ing telpon sing teka menyang kluster saka donya njaba). (Cathetan. nerjemahake.: Kanggo mbandhingake pengontrol Ingress sing ana kanggo Kubernetes, akeh sing nggunakake Utusan sing wis kasebut, waca. .)
Dadi, kita wis ngurutake bidang data. Bidang kontrol luwih prasaja: yaiku sakumpulan komponen sing nyedhiyakake kabeh mekanika sing kudu dioperasikake pesawat data kanthi cara sing terkoordinasi, kalebu panemuan layanan, nerbitake sertifikat TLS, agregasi metrik, lsp. Pesawat data ngandhani bidang kontrol tindak tanduke; ing siji, pesawat kontrol menehi API sing ngijini sampeyan kanggo ngganti lan ngawasi prilaku pesawat data minangka kabèh.
Ing ngisor iki diagram bidang kontrol lan bidang data ing Linkerd. Kaya sing sampeyan ngerteni, bidang kontrol kalebu sawetara komponen sing beda-beda, kalebu conto Prometheus sing ngumpulake metrik saka server proxy, uga komponen liyane kayata destination (penemuan layanan), identity (panguwasa sertifikat, CA) lan public-api (titik pungkasan kanggo web lan CLI). Ing kontras, bidang data minangka linkerd-proxy sing prasaja ing jejere conto aplikasi. Iki mung diagram logika; Ing panyebaran ing donya nyata, sampeyan bisa uga duwe telung replika saben komponen pesawat kontrol lan atusan utawa ewu proxy ing bidang data.
(Persegi panjang biru ing diagram iki nglambangake wates pods Kubernetes. Sampeyan bisa ndeleng manawa wadhah karo linkerd-proxy ana ing pod sing padha karo wadah aplikasi. Skema iki dikenal minangka wadhah sidecar.)
Arsitektur bolong layanan duwe sawetara implikasi penting. Kaping pisanan, amarga tugas proxy yaiku nyegat telpon ing antarane layanan, bolong layanan mung bisa ditrapake yen aplikasi sampeyan digawe kanggo sawetara layanan tartamtu. bolong bisa nggunakake karo monoliths, nanging iki cetha keluwih kanggo siji proxy siji, lan fungsi iku dipercaya ing dikarepake.
Konsekuensi penting liyane yaiku bolong layanan sing dibutuhake ageng banget nomer proxy. Nyatane, Linkerd masang linkerd-proxy kanggo saben conto saben layanan (implementasine liyane nambah proxy kanggo saben simpul / host / mesin virtual. Sing akeh). Panggunaan proxy sing aktif kasebut dhewe duwe sawetara komplikasi tambahan:
- Proxies ing bidang data kudu cepet, amarga saben telpon ana sawetara panggilan menyang proxy: siji ing sisih klien, siji ing sisih server.
- Uga proxy kudu cilik и entheng. Saben bakal nganggo memori lan sumber daya CPU, lan konsumsi iki bakal tuwuh linearly karo aplikasi.
- Sampeyan mbutuhake mekanisme kanggo nyebarake lan nganyari akeh proxy. Nindakake kanthi manual ora dadi pilihan.
Umumé, bolong layanan katon kaya iki (paling ora saka mripat manuk): sampeyan masang akeh proxy ruang panganggo sing "nindakake" karo lalu lintas internal, antar-layanan, lan nggunakake pesawat kontrol kanggo ngawasi lan ngatur.
Saiki wektu kanggo takon pitakonan "Kenapa?"
Apa gunane mesh layanan?
Wong-wong sing sepisanan nemoni ide bolong layanan bisa diapura amarga rada wedi. Desain bolong layanan tegese ora mung nambah latensi ing aplikasi kasebut, nanging uga nganggo sumber daya lan bakal nambah Bunch saka mekanisme anyar ing infrastruktur. Pisanan sampeyan nyiyapake bolong layanan, banjur dumadakan sampeyan kudu nglayani atusan (yen ora ewonan) proxy. Pitakonan, sapa sing bakal nindakake iki kanthi sukarela?
Jawaban kanggo pitakonan iki ana rong bagéan. Kaping pisanan, biaya transaksi sing ana gandhengane karo panyebaran proxy kasebut bisa dikurangi kanthi signifikan amarga sawetara owah-owahan ing ekosistem (luwih akeh babagan iki mengko).
Kapindho, piranti kaya iki minangka cara sing apik kanggo ngenalake logika tambahan menyang sistem. Ora mung amarga bolong layanan bisa nambah akeh fungsi anyar, nanging uga amarga bisa ditindakake tanpa ngganggu ekosistem. Ing kasunyatan, kabeh model bolong layanan adhedhasar premis iki: ing sistem multiservice, ora ketompo nindakake layanan individu, lalu lintas antarane wong-wong mau iku titik becik kanggo nambah fungsi.
Contone, ing Linkerd (kaya ing pirang-pirang meshes) fungsi kasebut difokusake utamane ing panggilan HTTP, kalebu HTTP/2 lan gRPC*. Fungsionalitas cukup sugih - bisa dipérang dadi telung kelas:
- Fitur related kanggo linuwih. Panjaluk sing bola-bali, wektu entek, pendekatan kenari (pemisahan / pangalihan lalu lintas), lsp.
- Fitur related kanggo ngawasi. Agregasi tingkat sukses, telat lan volume panjalukan kanggo saben layanan utawa pituduh individu; pambangunan peta topologi layanan, lsp.
- Fitur related kanggo keamanan. Mutual TLS, kontrol akses, lsp.
* Saka sudut pandang Linkerd, gRPC praktis ora beda karo HTTP/2: mung nggunakake protobuf ing muatan. Saka sudut pandang pangembang, rong perkara kasebut, mesthi beda.
Akeh mekanisme iki makaryakke ing tingkat request (mula "L7 proxy"). Contone, yen layanan Foo nelpon HTTP kanggo layanan Bar, linkerd-proxy ing sisih Foo bisa nindakake imbangan mbukak cerdas lan rute telpon saka Foo kanggo Bar kedadean adhedhasar latensi diamati; bisa mbaleni panjalukan yen perlu (lan yen idempoten); bisa ngrekam kode respon lan wektu entek, etc. Kajaba iku, linkerd-proxy ing sisih Bar bisa nolak panjalukan yen ora diidini utawa watesan panjalukan ngluwihi; bisa ngrekam wektu tundha, lsp.
Proxies bisa "nindakake soko" ing tingkat sambungan uga. Contone, linkerd-proxy ing sisih Foo bisa miwiti sambungan TLS, lan linkerd-proxy ing sisih Bar bisa mungkasi, lan loro-lorone bisa verifikasi sertifikat TLS saben liyane *. Iki menehi ora mung enkripsi antarane layanan, nanging uga cara cryptographically aman kanggo ngenali layanan: Foo lan Bar bisa "mbuktèkaké" sing padha sing padha ngomong.
* "Mutual of a friend" tegese sertifikat klien uga diverifikasi (mutual TLS). Ing TLS "klasik", contone antarane browser lan server, sertifikat mung siji sisih (server) biasane diverifikasi.
Apa padha operate ing tingkat panjalukan utawa sambungan, iku penting kanggo nandheske sing kabeh fungsi bolong layanan operasional watak. Linkerd ora bisa ngowahi semantik muatan - contone, nambah kolom menyang fragmen JSON utawa nggawe owah-owahan menyang protobuf. Kita bakal ngomong babagan fitur penting iki mengko nalika kita ngomong babagan ESB lan middleware.
Iki minangka set fitur sing ditawakake bolong layanan. Pitakonan muncul: kenapa ora dileksanakake langsung ing aplikasi kasebut? Lan kenapa keganggu karo proxy?
Apa layanan bolong iku apike
Nalika kapabilitas bolong layanan nyenengake, nilai inti kasebut ora ana ing fitur-fitur kasebut. Ing pungkasan kita Bisa ngleksanakake langsung ing aplikasi (kita bakal weruh mengko iki asal saka bolong layanan). Kanggo nyoba lan nyimpulake ing siji ukara, nilai bolong layanan yaiku: menehi fitur kritis kanggo mbukak piranti lunak server modern kanthi konsisten ing kabeh tumpukan lan bebas saka kode aplikasi.
Ayo analisa proposal iki.
«Fitur kritis kanggo mbukak piranti lunak server modern" Yen sampeyan nggawe aplikasi server transaksional sing disambungake menyang Internet umum, nampa panjalukan saka jagad njaba lan nanggapi ing wektu sing cendhak - contone, aplikasi web, server API, lan akeh aplikasi modern liyane. - lan yen sampeyan ngleksanakake minangka sakumpulan layanan sing bebarengan sesambungan karo saben liyane, lan yen sampeyan terus-terusan nganyarke piranti lunak iki, nambah fitur-fitur anyar, lan yen sampeyan dipeksa kanggo njaga sistem iki supaya bisa digunakake sak proses modifikasi - ing iki cilik, Sugeng, sampeyan nggawe piranti lunak server modern. Lan kabeh fitur apik sing kadhaptar ing ndhuwur pancen kritis kanggo sampeyan. Aplikasi kasebut kudu dipercaya, aman, lan sampeyan kudu bisa mirsani apa sing ditindakake. Iki persis pitakonan sing dibantu karo layanan bolong.
(OK, paragraf sadurunge isih kalebu kapercayanku yen pendekatan iki minangka cara modern kanggo nggawe piranti lunak server. Wong liya luwih seneng ngembangake monolit, "layanan mikro reaktif" lan liya-liyane sing ora ana ing definisi kasebut ing ndhuwur. Mratelakake panemume beda karo aku, aku mikir yen dheweke "salah" - sanajan ing kasus apa wae, bolong layanan ora migunani banget kanggo dheweke).
«Seragam kanggo kabeh tumpukan" Fungsi sing diwenehake dening bolong layanan ora mung kritis misi. Padha ditrapake kanggo kabeh layanan ing aplikasi, preduli saka basa apa padha ditulis ing, framework apa padha digunakake, sing wrote wong, carane padha tugasaken, lan subtleties liyane pembangunan lan nggunakake.
«Independen saka kode aplikasi" Pungkasan, bolong layanan ora mung nyedhiyakake fungsi sing konsisten ing kabeh tumpukan, nanging uga kanthi cara sing ora mbutuhake aplikasi kasebut diowahi. Basis dhasar fungsionalitas layanan bolong, kalebu tugas kanggo konfigurasi, nganyari, operasi, pangopènan, lan sapiturute, dumunung ing tingkat platform lan ora gumantung saka aplikasi kasebut. Aplikasi bisa diganti tanpa mengaruhi bolong layanan. Sabanjure, bolong layanan bisa diganti tanpa partisipasi saka aplikasi kasebut.
Singkatipun, bolong layanan ora mung nyedhiyakake fungsi penting, nanging uga nindakake kanthi cara global, seragam, lan bebas aplikasi. Dadi, sanajan fungsi bolong layanan bisa dileksanakake ing kode layanan (contone, minangka perpustakaan sing kalebu ing saben layanan), pendekatan iki ora bakal nyedhiyakake keseragaman lan kamardikan sing penting banget ing kasus bolong layanan.
Lan sampeyan mung kudu nambah akeh proxy! Aku janji bakal nliti biaya operasional sing ana gandhengane karo nambah proxy kasebut kanthi cepet. Nanging pisanan ayo mandheg lan ndeleng ide kamardikan iki saka sudut pandang sing beda. wong.
Sapa sing nulungi layanan bolong?
Sanajan ora trep, supaya teknologi dadi bagean penting ing ekosistem, kudu ditampa dening wong. Dadi sing kasengsem ing layanan bolong? Sapa sing entuk manfaat saka panggunaane?
Yen sampeyan lagi ngembangake piranti lunak server modern, kira-kira sampeyan bisa nganggep tim sampeyan minangka grup nduweni layanansing bebarengan ngembangaken lan ngleksanakake logika bisnis, lan nduweni platform, ngembangake platform internal sing digunakake layanan kasebut. Ing organisasi cilik, iki bisa uga wong sing padha, nanging nalika perusahaan tuwuh, peran kasebut cenderung dadi luwih jelas lan malah dipérang dadi sub-peran ... (Ana akeh sing bisa dicritakake ing kene babagan owah-owahan sifat devops, impact organisasi microservices, etc.) n. Nanging saiki ayo njupuk gambaran iki minangka diwenehi).
Saka sudut pandang iki, para ahli waris sing jelas saka bolong layanan yaiku pamilik platform. Sawise kabeh, pungkasane tujuan tim platform yaiku nggawe platform internal ing ngendi pamilik layanan bisa ngetrapake logika bisnis lan nindakake kanthi cara sing njamin supaya bisa mandiri saka rincian operasine. Ora mung bolong layanan menehi kabisan kritis kanggo nggayuh tujuan iki, nanging uga kanthi cara sing ora nyebabake ketergantungan marang pamilik layanan.
Pamilik layanan uga entuk manfaat, sanajan kanthi cara sing luwih ora langsung. Sasaran saka pemilik layanan yaiku dadi produktif sabisa-bisa kanggo ngetrapake logika proses bisnis, lan kurang kuwatir babagan masalah operasional, luwih apik. Tinimbang kudu ngetrapake, ucapake, nyoba maneh kabijakan utawa TLS, dheweke bisa fokus mung ing tujuan bisnis lan ngarep-arep platform ngurus liyane. Iki minangka kauntungan gedhe kanggo dheweke.
Nilai organisasi saka divisi kasebut antarane pamilik platform lan layanan ora bisa dikira-kira. Aku mikir dheweke nyumbang utama kontribusi kanggo nilai bolong layanan.
Kita sinau pelajaran iki nalika penggemar Linkerd awal ngandhani kenapa dheweke milih bolong layanan: amarga ngidini dheweke "njaga toko ngobrol kanthi minimal." Ing ngisor iki sawetara rincian: wong lanang saka siji perusahaan gedhe migrasi platform menyang Kubernetes. Wiwit aplikasi kasebut nangani informasi sensitif, dheweke pengin ngenkripsi kabeh komunikasi ing kluster kasebut. Nanging, kahanan kasebut rumit amarga ana atusan layanan lan atusan tim pangembangan. Prospek kanggo ngubungi kabeh wong lan ngyakinake supaya kalebu dhukungan TLS ing rencana kasebut ora nggawe dheweke seneng. Sawise nginstal Linkerd, padha ditransfer tanggung jawab saka pangembang (saka sudut pandang sing iki masalah sing ora perlu) menyang platformer, sing dadi prioritas tingkat paling dhuwur. Ing tembung liyane, Linkerd ditanggulangi kanggo wong-wong mau ora dadi luwih masalah teknis minangka organisasi.
Ing cendhak, bolong layanan luwih saka solusi, dudu teknis, nanging sosial-teknis Masalah. (Matur nuwun kanggo ngenalake istilah iki.)
Apa bolong layanan bakal ngrampungake kabeh masalahku?
ya wis. Maksudku, ora!
Yen sampeyan ndeleng telung kelas fitur sing kasebut ing ndhuwur - linuwih, keamanan, lan observasi - dadi cetha yen bolong layanan dudu solusi lengkap kanggo masalah kasebut. Nalika Linkerd bisa nerbitake maneh panjalukan (yen ngerti yen dheweke idempoten), ora bisa nggawe keputusan babagan apa sing bakal bali menyang pangguna yen layanan kasebut gagal permanen-keputusan kasebut kudu ditindakake dening aplikasi kasebut. Linkerd bisa nyimpen statistik panjalukan sing sukses, nanging ora bisa ndeleng layanan kasebut lan nyedhiyakake metrik internal - aplikasi kasebut kudu duwe alat kasebut. Lan sanajan Linkerd bisa ngatur mTLS, solusi keamanan lengkap mbutuhake luwih akeh.
A subset saka fitur ing wilayah iki ditawakake bolong layanan gegandhengan karo fitur platform. Iki tegese fungsi sing:
- Independen saka logika bisnis. Cara kang digawe histograms telpon antarane Foo lan Bar wis rampung independen saka ngapa Foo nelpon Bar.
- Iku angel kanggo ngleksanakake bener. Ing Linkerd, nyoba maneh diparameterake karo macem-macem barang sing apik kaya anggaran nyoba maneh (nyoba maneh anggaran), amarga pendekatan sing ora canggih lan langsung kanggo ngleksanakake perkara kasebut mesthi bakal nyebabake kedadeyan sing disebut "avalanche of requests" (coba maneh badai) lan masalah liyane karakteristik sistem mbagekke.
- Paling efektif nalika ditrapake kanthi seragam. Mekanisme TLS mung bisa ditrapake yen ditrapake ing endi wae.
Wiwit fungsi kasebut dileksanakake ing tingkat proxy (lan ora ing tingkat aplikasi), bolong layanan nyedhiyakake ing platform, dudu aplikasi. Mangkono, ora preduli apa basa layanan kasebut ditulis, kerangka apa sing digunakake, sapa sing nulis lan kenapa. Proxy makaryakke ing njaba kabeh rincian iki, lan basis dhasar saka fungsi iki, kalebu tugas kanggo konfigurasi, nganyari, operasi, pangopènan, etc., dumunung mung ing tingkat platform.
Conto kapabilitas bolong layanan
Kanggo ngringkes, bolong layanan dudu solusi lengkap kanggo linuwih, observasi, utawa keamanan. Ruang lingkup wilayah kasebut mbutuhake partisipasi pamilik layanan, tim Ops/SRE lan entitas perusahaan liyane. Bolong layanan mung nyedhiyakake "irisan" tingkat platform kanggo saben wilayah kasebut.
Napa layanan bolong saiki dadi populer?
Saiki sampeyan bisa uga mikir: ok, yen bolong layanan apik banget, kenapa kita ora miwiti nyebarake mayuta-yuta proxy ing tumpukan sepuluh taun kepungkur?
Ana jawaban banal kanggo pitakonan iki: sepuluh taun kepungkur saben wong mbangun monoliths, lan ora ana sing perlu bolong layanan. Iki bener, nanging ing mratelakake panemume iki jawaban mbleset. Malah sepuluh taun kepungkur, konsep layanan mikro minangka cara sing apik kanggo mbangun sistem skala gedhe wis dibahas lan ditrapake ing perusahaan kayata Twitter, Facebook, Google lan Netflix. Pandangan umum-paling ora ing bagean industri sing aku sesambungan karo-yaiku layanan mikro minangka "cara sing bener" kanggo mbangun sistem gedhe, sanajan angel banget.
Mesthine, sanajan sepuluh taun kepungkur ana perusahaan sing ngoperasikake layanan mikro, dheweke ora nempel proxy ing endi wae sing bisa nggawe bolong layanan. Nanging, yen sampeyan ndeleng kanthi teliti, padha nindakake sing padha: akeh perusahaan kasebut mbutuhake panggunaan perpustakaan internal khusus kanggo komunikasi jaringan (kadhangkala disebut perpustakaan klien sing kandel, perpustakaan klien lemak).
Netflix duwe Hysterix, Google duwe Stubby, Twitter duwe perpustakaan Finagle. Finagle, umpamane, wajib kanggo saben layanan anyar ing Twitter. Iki ditangani loro sambungan klien lan server, ngidini panjaluk bola-bali, nuntun panyuwunan sing didhukung, keseimbangan beban lan pangukuran. Iki nyedhiyakake lapisan linuwih lan observasi sing konsisten ing kabeh tumpukan Twitter, preduli saka apa sing ditindakake layanan kasebut. Mesthine, mung bisa digunakake kanggo basa JVM lan adhedhasar model pemrograman sing kudu digunakake kanggo kabeh aplikasi. Nanging, fungsine meh padha karo bolong layanan. (Nyatane, Linkerd versi pisanan mung Finagle kebungkus ing wangun proxy.)
Mangkono, sepuluh taun kepungkur, ora mung microservices, nanging uga perpustakaan proto-service-mesh khusus sing ngrampungake masalah sing padha karo layanan bolong saiki. Nanging, bolong layanan kasebut dhewe durung ana. Mesthi ana siji shift maneh sadurunge dheweke katon.
Lan ing kene ana jawaban sing luwih jero, sing didhelikake ing owah-owahan liyane sing kedadeyan sajrone 10 taun kepungkur: biaya nyebarake layanan mikro wis mudhun banget. Perusahaan kasebut ing ndhuwur sing nggunakake layanan mikro sepuluh taun kepungkur-Twitter, Netflix, Facebook, Google-yaiku perusahaan kanthi skala gedhe lan sumber daya gedhe banget. Dheweke ora mung butuh, nanging uga duwe kemampuan kanggo mbangun, nyebarake, lan ngoperasikake aplikasi basis microservice sing gedhe. Energi lan upaya sing ditindakake para insinyur Twitter kanggo pindhah saka monolitik menyang pendekatan layanan mikro pancen apik tenan. (Kanggo adil, uga kasunyatan sing sukses.) Manuver infrastruktur kaya iki banjur ora mungkin kanggo perusahaan cilik.
Maju nganti saiki. Ana wiwitan saiki ing ngendi rasio layanan mikro kanggo pangembang yaiku 5: 1 (utawa malah ), lan apa maneh, dheweke bisa ngatasi kanthi sukses! Yen wiwitan 5 wong bisa kanthi gampang ngoperasikake 50 layanan mikro, mula ana sing nyuda biaya implementasine.
1500 microservices ing Monzo; saben baris punika aturan jaringan diwènèhaké sing ngidini lalu lintas
Pangurangan dramatis ing biaya layanan mikro operasi minangka asil saka siji proses: akeh popularitas saka kontaner и orkestra. Iki sabenere jawaban jero kanggo pitakonan apa nyumbang kanggo munculé bolong layanan. Teknologi sing padha nggawe jaringan layanan lan layanan mikro sing menarik: Kubernetes lan Docker.
Kenging punapa? Ya, Docker ngrampungake siji masalah gedhe - masalah kemasan. Kanthi ngemas aplikasi lan dependensi runtime (non-jaringan) menyang wadhah, Docker ngowahi aplikasi kasebut dadi unit sing bisa diganti sing bisa di-host lan mbukak ing ngendi wae. Ing wektu sing padha, iku banget nyederhanakake operasi multibasa Tumpukan: Amarga wadhah minangka unit eksekusi atom, kanggo tujuan penyebaran lan operasional, ora preduli apa sing ana ing njero, dadi aplikasi JVM, Node, Go, Python, utawa Ruby. Sampeyan mung miwiti lan iku.
Kubernetes njupuk kabeh kanggo tingkat sabanjuré. Saiki ana akeh "barang sing kudu ditindakake" lan akeh mesin sing bisa digunakake, mula butuh alat sing bisa nyambungake. Ing pangertèn sing wiyar, sampeyan menehi Kubernetes akeh kontaner lan akeh mesin, lan peta mau marang saben liyane (mesthi, iki proses dinamis lan tansah owah-owahan: kontaner anyar pindhah ing saindhenging sistem, mesin miwiti lan mandheg. , etc. Nanging, Kubernetes njupuk kabeh iki menyang akun).
Sawise Kubernetes dikonfigurasi, biaya wektu kanggo nyebarake lan ngoperasikake siji layanan rada beda karo biaya kanggo nyebarake lan ngoperasikake sepuluh layanan (nyatane, meh padha kanggo 100 layanan). Tambah menyang wadhah iki minangka mekanisme kemasan sing nyengkuyung implementasi multibasa, lan sampeyan duwe akeh aplikasi anyar sing diimplementasikake ing bentuk layanan mikro sing ditulis ing macem-macem basa - persis jenis lingkungan sing cocog karo bolong layanan.
Dadi, kita teka ing jawaban kanggo pitakonan kenapa ide bolong layanan wis populer saiki: homogeneitas sing diwenehake Kubernetes kanggo layanan langsung ditrapake kanggo tantangan operasional sing diadhepi bolong layanan. Sampeyan paket proxy menyang kontaner, menehi Kubernetes tugas nempel ing ngendi wae bisa, lan voila! Akibaté, sampeyan entuk bolong layanan, dene kabeh mekanika panyebarane dikelola dening Kubernetes. (Paling ora saka mripat manuk. Mesthi, ana akeh nuansa kanggo proses iki.)
Kanggo nyimpulake: alasan layanan jejaring wis populer saiki, lan ora sepuluh taun kepungkur, yaiku Kubernetes lan Docker ora mung tambah akeh. butuh ing, wis simplified implementasine saka aplikasi minangka set microservices multibasa, nanging uga Ngartekno suda biaya kanggo operasi, nyediakake mekanisme kanggo nyebarke lan ndhukung armada proxy sidecar.
Yagene akeh sing ngomong babagan layanan bolong?
Nyegah: Ing bagean iki aku nggunakake kabeh jinis asumsi, konjektur, fabrikasi lan informasi njero.
Telusuri "bolong layanan" lan sampeyan bakal nemokake ton isi kalori sing didaur ulang, proyek aneh, lan kaleidoskop distorsi sing cocog karo kamar gema. Sembarang teknologi anyar apik nindakake iki, nanging ing cilik saka bolong layanan masalah utamané akut. Kenging punapa?
Inggih, bagean saka iku salahku. Aku wis makarya hard kanggo ningkataké Linkerd lan layanan bolong saben kesempatan aku njaluk liwat kiriman blog kaetung lan artikel kaya iki. Nanging aku ora kuat. Kanggo njawab pitakonan iki, kita kudu ngomong sethithik babagan kahanan sakabèhé. Lan ora bisa ngomong babagan iki tanpa nyebutake siji proyek: minangka bolong layanan open source sing dikembangake bebarengan dening Google, IBM lan Lyft.
(Telu perusahaan kasebut nduweni peran sing beda banget: Keterlibatan Lyft katon mung ing jeneng; dheweke minangka penulis Utusan, nanging ora nggunakake utawa melu ing pangembangan Istio. IBM melu lan nggunakake pangembangan Istio. Google melu aktif ing Istio. pembangunan , nanging ora bener nggunakake minangka adoh aku bisa ngomong.)
Proyek Istio misuwur amarga rong perkara. Kaping pisanan, ana upaya pemasaran gedhe sing ditindakake Google, utamane, kanggo promosi. Aku bakal ngira manawa umume wong sing ngerti babagan konsep bolong layanan saiki pisanan sinau babagan iki liwat Istio. Ingkang kaping kalih inggih menika kados pundi kirangipun nampi Istio. Ing prakara iki, aku temenan dadi pihak sing kasengsem, nanging nyoba tetep objektif, aku isih ora bisa nulungi , ora banget khas (sanadyan ora unik: systemd teka ing pikiran, ...) kanggo proyek Open Source.
(Ing laku, Istio misale jek duwe masalah ora mung karo kerumitan lan UX, nanging uga karo kinerja. Contone, sak Ing panaliten pihak katelu, peneliti nemokake kahanan sing latensi buntut Istio 100 kaping luwih dhuwur tinimbang Linkerd, uga kahanan sing keluwen sumber daya ing ngendi Linkerd terus sukses nalika Istio mandheg nyambut gawe.)
Ninggalake teori-teori babagan sebabe kedadeyan kasebut, aku percaya manawa kasenengan sing luar biasa babagan bolong layanan kasebut diterangake dening partisipasi Google. Yaiku, kombinasi saka telung faktor ing ngisor iki:
- promosi intrusive Google saka Istio;
- sikap sing ora setuju, kritis marang proyek kasebut;
- munggah meteoric anyar ing popularitas Kubernetes, kenangan kang isih seger.
Bebarengan faktor-faktor iki gabungke kanggo nggawe stupefying, oksigen-free lingkungan kang kapasitas kanggo pertimbangan nyoto wis weakened, lan mung macem-macem aneh tetep. .
Saka perspektif Linkerd, iki ... sing bakal dakgambarake minangka berkah campuran. Maksudku, apik banget yen bolong layanan wis mlebu ing arus utama kanthi cara sing ora ana ing taun 2016 nalika Linkerd pisanan diwiwiti lan pancen angel banget kanggo narik kawigaten wong menyang proyek kasebut. Saiki ora ana masalah kaya ngono! Nanging kabar sing ala yaiku lanskap bolong layanan saiki mbingungake, mula meh ora bisa dingerteni proyek endi sing kalebu ing kategori bolong layanan (apa maneh ngerti endi sing paling cocog kanggo kasus panggunaan tartamtu). Iki mesthine dealbreaker kanggo kabeh wong (lan mesthi ana sawetara kasus ing ngendi Istio utawa proyek liyane luwih cocog tinimbang Linkerd, amarga sing terakhir isih dudu solusi universal).
Ing sisih Linkerd, strategi kita yaiku nglirwakake gangguan, terus fokus kanggo ngrampungake masalah komunitas sing nyata, lan sejatine ngenteni hype mati. Pungkasane, hype bakal suda lan kita bisa terus kerja kanthi tenang.
Ing sawetoro wektu, kita kabeh kudu sabar sethithik.
Apa bolong layanan bakal migunani kanggo aku, insinyur piranti lunak sing andhap asor?
Angket ing ngisor iki bakal mbantu sampeyan njawab pitakonan iki:
Apa sampeyan mung melu ngetrapake logika bisnis? Ing kasus iki, bolong layanan ora bakal migunani kanggo sampeyan. Sing, mesthi, sampeyan bisa uga kasengsem ing, nanging saenipun bolong layanan ngirim ora langsung mengaruhi apa ing lingkungan. Terus nggarap apa sing dibayar.
Apa sampeyan ndhukung platform ing perusahaan sing nggunakake Kubernetes? Ya, ing kasus iki sampeyan kudu bolong layanan (kajaba, mesthi, sampeyan nggunakake K8s mung kanggo mbukak monolith utawa batch Processing - nanging aku kaya kanggo takon apa sampeyan kudu K8s). Sampeyan bisa uga bakal entuk akeh layanan mikro sing ditulis dening wong liya. Kabeh padha sesambungan karo saben liyane lan disambungake menyang tangle saka dependensi runtime, lan sampeyan kudu golek cara kanggo menehi hasil karo kabeh. Nggunakake Kubernetes ngidini sampeyan milih bolong layanan "kanggo sampeyan dhewe." Kanggo nindakake iki, kenal karo kemampuan lan fitur lan jawab pitakonan apa ana proyek sing kasedhiya cocok kanggo sampeyan (Aku nyaranake miwiti riset karo Linkerd).
Apa sampeyan perusahaan platform ing perusahaan sing ora nggunakake Kubernetes nanging nggunakake layanan mikro? Ing kasus iki, bolong layanan bakal migunani kanggo sampeyan, nanging panggunaane ora pati penting. Mesthi sampeyan bisa niru bolong layanan kerja kanthi nyelehake akeh proxy, nanging kauntungan penting saka Kubernetes yaiku model penyebaran: kanthi manual njaga proxy kasebut mbutuhake wektu, gaweyan lan biaya luwih akeh.
Apa sampeyan tanggung jawab kanggo platform ing perusahaan sing nggarap monoliths? Ing kasus iki, sampeyan mbokmenawa ora perlu bolong layanan. Yen sampeyan nggarap monoliths (utawa malah koleksi monoliths) sing wis ditetepake kanthi apik lan arang ngganti pola interaksi, banjur bolong layanan bakal duwe sethitik kanggo kurban sampeyan. Dadi sampeyan mung bisa nglirwakake lan ngarep-arep yen bakal ilang kaya ngimpi sing ala ...
kesimpulan
Mbokmenawa, layanan bolong isih ora kudu disebut "teknologi paling hyped ing donya" - pakurmatan dubious iki mbokmenawa belongs kanggo Bitcoin utawa AI. Dheweke mbokmenawa ana ing limang ndhuwur. Nanging yen sampeyan ngethok lapisan gangguan, dadi cetha yen bolong layanan nggawa keuntungan nyata kanggo wong-wong sing mbangun aplikasi ing Kubernetes.
Aku pengin sampeyan nyoba Linkerd - nginstal ing cluster Kubernetes (utawa malah Minikube ing laptop) , lan sampeyan bisa ndeleng dhewe apa aku ngomong bab.
FAQ
— Yen aku nglirwakake bolong layanan, bakal ilang?
- Aku kudu nguciwani sampeyan: layanan bolong karo kita kanggo dangu.
- Nanging aku ora pengin nggunakake bolong layanan!
- Inggih, iku ora perlu! Waca kuesioner ing ndhuwur kanggo ngerti apa sampeyan kudu ngerti dhasare.
- Apa ora ESB lawas / middleware iki apik karo sauce anyar?
- Layanan bolong ngurusi logika operasional, dudu semantik. bus layanan perusahaan (). Njaga pamisahan iki mbantu bolong layanan supaya ora padha nasib.
— Kepiye bolong layanan beda karo gateway API?
— Ana yuta artikel babagan topik iki. Google wae.
— Utusan iku bolong layanan?
- Ora, Utusan dudu bolong layanan, iku server proxy. Bisa digunakake kanggo ngatur bolong layanan (lan liya-liyane - minangka proxy tujuan umum). Nanging dhewe iku ora bolong layanan.
— Network Service Mesh minangka bolong layanan?
- Ora. Senadyan jeneng, iki dudu bolong layanan (kepiye sampeyan seneng mukjizat marketing?).
— Apa bolong layanan bakal mbantu sistem bedo reaktif adhedhasar antrian pesenku?
- Ora, bolong layanan ora bakal mbantu sampeyan.
— Apa bolong layanan sing kudu digunakake?
- , ora duwe otak.
- Artikel nyedot! / Penulis olèh!
— Mangga nuduhake link menyang kabeh kanca-kanca supaya padha bisa ndeleng!
Matur suwun
Kaya sing bisa ditebak saka judhul, artikel iki diilhami dening risalah fantastis Jay Kreps "" Aku ketemu Jay sepuluh taun kepungkur nalika aku diwawancarai ing Linked In lan wis dadi inspirasi kanggo kula wiwit.
Nalika aku seneng nelpon dhewe "Linkerd pangembang", kasunyatan iku aku luwih saka maintainer file README.md ing project. Linkerd lagi digarap dina iki , , wong, lan project iki ora bakal kelakon tanpa partisipasi masyarakat apik kontributor lan pangguna.
Lan pungkasane, matur nuwun khusus kanggo pencipta Linkerd, (primus inter pares), sing, bebarengan karo aku pirang-pirang taun kepungkur, nyilem menyang kabeh keributan iki kanthi bolong layanan.
PS saka penerjemah
Waca uga ing blog kita:
- «";
- «";
- «";
- «";
- «".
Source: www.habr.com