19 September ing Moskow patemon tematik pisanan HUG (Highload ++ User Group), kang darmabakti kanggo microservices. Ana presentasi "Operating Microservices: Size Matters, Even If You Have Kubernetes," ing ngendi kita nuduhake pengalaman ekstensif Flant ing proyek operasi kanthi arsitektur microservice. Kaping pisanan, bakal migunani kanggo kabeh pangembang sing mikir babagan nggunakake pendekatan iki ing proyek saiki utawa mbesuk.
nepangaken (50 menit, luwih informatif tinimbang artikel), uga ekstrak utama ing wangun teks.
NB: Video lan presentasi uga kasedhiya ing pungkasan kiriman iki.
Pambuka
Biasane crita sing apik nduweni wiwitan, plot utama lan resolusi. Laporan iki luwih kaya prelude, lan minangka tragis. Sampeyan uga penting kanggo dicathet yen menehi tampilan layanan mikro saka wong njaba. eksploitasi.
Aku bakal miwiti karo grafik iki, penulis kang (ing 2015) Martin Fowler:
Iki nuduhake carane, ing kasus aplikasi monolitik sing tekan nilai tartamtu, produktivitas wiwit mudhun. Layanan mikro beda-beda amarga produktivitas awal luwih murah, nanging nalika kerumitan mundhak, degradasi efisiensi ora katon kanggo dheweke.
Aku bakal nambah grafik iki kanggo kasus nggunakake Kubernetes:
Napa aplikasi karo layanan mikro luwih apik? Amarga arsitektur kuwi nempatno syarat serius kanggo arsitektur, kang siji sampurna dijamin dening Kapabilitas Kubernetes. Ing tangan liyane, sawetara fungsi iki bakal migunani kanggo monolith a, utamané amarga monolith khas dina iki ora persis monolith a (rincian bakal mengko ing laporan).
Kaya sing sampeyan ngerteni, grafik pungkasan (nalika aplikasi monolitik lan microservice ana ing infrastruktur karo Kubernetes) ora beda banget karo sing asli. Sabanjure kita bakal ngomong babagan aplikasi sing dioperasikake nggunakake Kubernetes.
Layanan mikro sing migunani lan mbebayani
Lan iki gagasan utama:
Opo iku normal arsitektur microservice? Sampeyan kudu menehi keuntungan nyata, nambah efisiensi kerja. Yen kita bali menyang grafik, iki:
Yen sampeyan nelpon dheweke migunani, banjur ing sisih liya saka grafik bakal ana mbebayani microservices (ngganggu karya):
Bali menyang "gagasan utama": apa aku kudu percaya karo pengalamanku? Wiwit awal taun iki aku wis katon 85 proyek. Ora kabeh padha microservices (kira-kira katelu kanggo setengah saka padha duwe arsitektur kuwi), nanging iki isih akeh. Kita (perusahaan Flant) minangka outsourcing bisa ndeleng macem-macem aplikasi sing dikembangake ing perusahaan cilik (karo 5 pangembang) lan ing gedhe (~ 500 pangembang). Keuntungan tambahan yaiku kita ndeleng aplikasi kasebut urip lan berkembang sajrone pirang-pirang taun.
Kenapa layanan mikro?
Kanggo pitakonan babagan keuntungan microservices ana saka Martin Fowler sing wis kasebut:
- wates sing jelas saka modularitas;
- penyebaran mandiri;
- kebebasan kanggo milih teknologi.
Aku wis ngomong akeh karo arsitek lan pangembang piranti lunak lan takon kenapa dheweke butuh layanan mikro. Lan aku nggawe dhaptar pangarepan. Mangkene kedadeyane:
Yen kita njlèntrèhaké sawetara titik "ing sensasi," banjur:
- wates modul sing jelas: ing kene kita duwe monolit sing nggegirisi, lan saiki kabeh bakal disusun kanthi rapi ing repositori Git, sing kabeh ana "ing rak", sing anget lan alus ora dicampur;
- kamardikan penyebaran: kita bakal bisa kanggo muter metu layanan independen supaya pembangunan dadi luwih cepet (nerbitaké fitur anyar ing podo karo);
- kamardikan pembangunan: kita bisa menehi microservice iki kanggo siji tim / pangembang, lan sing siji kanggo liyane, thanks kanggo kang kita bisa berkembang luwih cepet;
- боlinuwih luwih: yen degradasi sebagean ana (siji microservice saka 20 tumiba), banjur mung siji tombol bakal mandheg apa, lan sistem minangka kabèh bakal terus kanggo fungsi.
Arsitektur microservice khas (mbebayani).
Kanggo nerangake kenapa kasunyatan ora kaya sing dikarepake, aku bakal menehi kolektif gambar arsitektur microservice adhedhasar pengalaman saka akeh proyek beda.
Conto bakal dadi toko online abstrak sing bakal saingan karo Amazon utawa paling ora OZON. Arsitektur microservice katon kaya iki:
Kanggo kombinasi alasan, layanan mikro iki ditulis ing macem-macem platform:
Amarga saben layanan mikro kudu duwe otonomi, akeh sing butuh database lan cache dhewe. Arsitektur pungkasan kaya ing ngisor iki:
Apa akibate?
Fowler uga duwe iki - babagan "pembayaran" kanggo nggunakake layanan mikro:
Lan kita bakal weruh yen pangarepan kita wis ketemu.
Mbusak wates modul ...
Nanging carane akeh microservices kita bener kudu ndandani?kanggo muter metu owah-owahan? Apa kita bisa ngerti carane kabeh bisa tanpa tracer sing disebarake (sawise kabeh, panjaluk apa wae diproses dening setengah saka microservices)?
Ana pola"", lan ing kene ternyata dadi bongkahan rereget sing disebarake. Kanggo konfirmasi iki, iki minangka gambaran kira-kira babagan carane panjalukan:
Kemandirian penyebaran...
Secara teknis, wis digayuh: kita bisa muter saben layanan mikro kanthi kapisah. Nanging ing laku sampeyan kudu njupuk menyang akun sing tansah muter metu akeh microservices, lan kita kudu njupuk menyang akun urutan rollout sing. Kanthi cara sing apik, umume kita kudu nyoba ing sirkuit sing kapisah manawa kita ngeculake rilis kanthi urutan sing bener.
Kebebasan milih teknologi...
Dheweke. Elinga yen kamardikan asring wewatesan karo pelanggaran hukum. Penting banget ing kene ora milih teknologi mung kanggo "muter" karo wong-wong mau.
Kemandirian pembangunan...
Kepiye carane nggawe loop test kanggo kabeh aplikasi (kanthi akeh komponen)? Nanging sampeyan isih kudu tetep nganyari. Kabeh iki ndadékaké kanggo kasunyatan sing nomer nyata saka sirkuit test, sing kita bisa ngemot prinsip, pranyata minimal.
Kepiye carane nyebarake kabeh iki sacara lokal?
Skala kapisah...
Ya, nanging diwatesi ing area DBMS sing digunakake. Ing conto arsitektur sing diwenehake, Cassandra ora bakal duwe masalah, nanging MySQL lan PostgreSQL bakal.
Боluwih linuwih...
Ora mung kegagalan siji layanan mikro ing kasunyatan asring ngrusak fungsi sing bener saka kabeh sistem, nanging uga ana masalah anyar: nggawe saben microservice fault-tolerant banget angel. Amarga microservices nggunakake teknologi beda (memcache, Redis, etc.), Kanggo saben sampeyan kudu mikir liwat kabeh lan ngleksanakake, kang, mesthi, bisa, nanging mbutuhake sumber daya ageng.
Pengukuran beban...
Iki apik tenan.
"Keringanan" layanan mikro ...
Kita ora mung duwe ageng overhead jaringan (panyuwunan kanggo DNS wis multiplying, etc.), nanging uga amarga akeh subqueries kita miwiti replika data (nyimpen caches), kang mimpin kanggo jumlah pinunjul saka panyimpenan.
Lan iki minangka asil saka nyukupi pangarepan kita:
Nanging ora mung kuwi!
Amarga:
- Paling kamungkinan kita bakal mbutuhake bis pesen.
- Kepiye carane nggawe serep sing konsisten ing wektu sing tepat? mung siji nyata pilihan kanggo mateni lalu lintas kanggo iki. Nanging carane nindakake iki ing produksi?
- Yen kita ngomong babagan ndhukung sawetara wilayah, mula ngatur kelestarian ing saben wilayah kasebut minangka tugas sing akeh banget.
- Masalah nggawe owah-owahan terpusat muncul. Contone, yen kita kudu nganyari versi PHP, kita kudu komitmen kanggo saben repositori (lan ana puluhan).
- Wutah ing kerumitan operasional, langsung, eksponensial.
Apa sing kudu dilakoni karo kabeh iki?
Mulai nganggo aplikasi monolitik. pengalaman Fowler kang sing meh kabeh aplikasi microservice sukses diwiwiti minangka monolit sing dadi gedhe banget lan banjur rusak. Ing wektu sing padha, meh kabeh sistem sing dibangun minangka layanan mikro saka wiwitan cepet utawa mengko ngalami masalah serius.
Pikiran liyane sing penting yaiku supaya proyek kanthi arsitektur microservice bisa sukses, sampeyan kudu ngerti banget lan subyek, lan carane nggawe microservices. Lan cara paling apik kanggo sinau babagan subyek yaiku nggawe monolit.
Nanging kepiye yen kita wis ana ing kahanan iki?
Langkah pisanan kanggo ngrampungake masalah apa wae yaiku setuju lan ngerti yen iki masalah, mula kita ora pengin nandhang sangsara maneh.
Yen, ing kasus monolith overgrown (nalika kita wis kehabisan kesempatan kanggo tuku sumber daya tambahan kanggo iku), kita Cut, banjur ing kasus iki crita ngelawan dadi metu: nalika microservices gedhe banget ora bantuan maneh, nanging ngalangi - Cut keluwihan lan nggedhekake!
Contone, kanggo gambar kolektif sing dibahas ing ndhuwur ...
Mbusak layanan mikro sing paling diragukan:
Gabungke kabeh layanan mikro sing tanggung jawab kanggo generasi ngarep:
... dadi siji layanan mikro, ditulis ing siji (modern lan normal, kaya sing sampeyan pikirake) basa / kerangka:
Bakal duwe siji ORM (siji DBMS) lan pisanan sawetara aplikasi:
... nanging umume sampeyan bisa nransfer luwih akeh ing kana, entuk asil ing ngisor iki:
Kajaba iku, ing Kubernetes, kabeh iki ditindakake kanthi kapisah, tegese kita isih bisa ngukur beban lan ngukur kanthi kapisah.
Kanggo ngringkes
Deleng gambar sing luwih gedhe. Kerep banget, kabeh masalah karo microservices muncul amarga ana sing njupuk tugas, nanging pengin "main karo microservices".
Ing tembung "layanan mikro" bagean "mikro" keluwih.. Padha "mikro" mung amarga padha luwih cilik tinimbang monolit ageng. Nanging aja nganggep minangka barang cilik.
Lan kanggo pamikiran pungkasan, ayo bali menyang grafik asli:
A cathetan ditulis ing (ndhuwur tengen) boils mudhun kanggo kasunyatan sing katrampilan tim sing nggawe proyek sampeyan tansah utami - padha bakal muter peran tombol ing pilihan antarane microservices lan monolith a. Yen tim ora duwe katrampilan sing cukup, nanging wiwit nggawe layanan mikro, critane mesthi bakal fatal.
Video lan minger
Video saka pidato kasebut (~ 50 menit; sayangé, ora nuduhake akeh emosi para pengunjung, sing umume nemtokake swasana ati laporan kasebut, nanging kaya ngono):
Presentasi laporan:
PS
Laporan liyane ing blog kita:
- «» (Dmitry Stolyarov; 28 Mei 2018 ing RootConf);
- «» (Dmitry Stolyarov; 7 November 2017 ing HighLoad++);
- «» (Dmitry Stolyarov; 6 Juni 2017 ing RootConf);
- «» (Dmitry Stolyarov; 8 November 2016 ing HighLoad++);
- «» (Dmitry Stolyarov; 31 Mei 2016 ing RootConf).
Sampeyan bisa uga kasengsem ing publikasi ing ngisor iki:
- «";
- «";
- «".
Source: www.habr.com