Ing artikel iki, Aku bakal pirembagan bab carane project aku digunakake ing rubah saka monolit gedhe menyang pesawat saka microservices.
Proyèk iki wiwit sajarahé cukup suwe, ing awal taun 2000. Versi pisanan ditulis ing Visual Basic 6. Swara wektu, dadi cetha yen pembangunan ing basa iki bakal angel kanggo ndhukung ing mangsa, wiwit IDE. lan basane dhewe ya kurang dikembangake. Ing pungkasan taun 2000-an, diputusake kanggo ngalih menyang C # sing luwih janjeni. Versi anyar iki ditulis ing podo karo karo revisi saka lawas, mboko sithik kode liyane lan liyane ditulis ing .NET. Backend ing C # wiwitane fokus ing arsitektur layanan, nanging sajrone pangembangan, perpustakaan umum kanthi logika digunakake, lan layanan diluncurake ing siji proses. Asil kasebut minangka aplikasi sing diarani "monolit layanan."
Salah siji saka sawetara kaluwihan saka kombinasi iki ana kemampuan layanan kanggo nelpon saben liyane liwat API external. Ana prasyarat sing jelas kanggo transisi menyang layanan sing luwih bener, lan ing mangsa ngarep, arsitektur microservice.
Kita miwiti karya babagan dekomposisi sekitar taun 2015. Kita durung tekan negara sing cocog - isih ana bagean saka proyek gedhe sing meh ora bisa diarani monolith, nanging uga ora katon kaya layanan mikro. Nanging, kemajuan penting.
Aku bakal ngomong babagan iki ing artikel kasebut.
Isi
Arsitektur lan masalah solusi sing ana
Kaping pisanan, arsitektur katon kaya iki: UI minangka aplikasi sing kapisah, bagean monolitik ditulis ing Visual Basic 6, aplikasi .NET minangka set layanan sing gegandhengan karo database sing cukup gedhe.
Kerugian saka solusi sadurunge
Titik kegagalan tunggal
Kita duwe titik siji saka Gagal: aplikasi .NET mlaku ing proses siji. Yen modul gagal, kabeh aplikasi gagal lan kudu diwiwiti maneh. Amarga kita ngotomatisasi akeh pangolahan kanggo pangguna sing beda-beda, amarga gagal ing salah sawijining, kabeh wong ora bisa mlaku sawetara wektu. Lan yen ana kesalahan piranti lunak, malah serep ora mbantu.
Antrian dandan
Kelemahan iki rada organisasi. Aplikasi kita duwe akeh pelanggan, lan kabeh padha pengin nambah sanalika bisa. Sadurunge, iku mokal kanggo nindakake iki ing podo karo, lan kabeh pelanggan ngadeg ing baris. Proses iki negatif kanggo bisnis amarga kudu mbuktekake manawa tugase penting. Lan tim pangembangan nglampahi wektu kanggo ngatur antrian iki. Iki njupuk akeh wektu lan gaweyan, lan prodhuk pungkasanipun ora bisa ngganti minangka cepet kaya padha seneng.
Panggunaan sumber daya suboptimal
Nalika hosting layanan ing proses siji, kita tansah rampung disalin konfigurasi saka server kanggo server. Kita pengin nyelehake layanan sing paling akeh dimuat kanthi kapisah supaya ora mbuwang sumber daya lan entuk kontrol sing luwih fleksibel babagan skema penyebaran kita.
Iku angel kanggo ngetrapake teknologi modern
Masalah sing akrab karo kabeh pangembang: ana kepinginan kanggo ngenalake teknologi modern menyang proyek kasebut, nanging ora ana kesempatan. Kanthi solusi monolitik sing gedhe, nganyari perpustakaan saiki, ora kanggo sebutno transisi menyang sing anyar, dadi tugas sing ora pati penting. Butuh wektu dawa kanggo mbuktekaken pimpinan tim sing iki bakal nggawa luwih bonus saka syaraf boroske.
Kesulitan ngetokake owah-owahan
Iki minangka masalah sing paling serius - kita ngeculake rilis saben rong wulan.
Saben release nguripake menyang bilai nyata kanggo bank, senadyan testing lan efforts pangembang. Bisnis mangertos yen ing awal minggu sawetara fungsi ora bakal bisa digunakake. Lan pangembang mangertos yen minggu kedadeyan serius nunggu dheweke.
Saben uwong duwe kepinginan kanggo ngganti kahanan.
Pangarepan saka microservices
Masalah komponen nalika siap. Pangiriman komponen nalika siap kanthi ngurai solusi lan misahake proses sing beda.
Tim produk cilik. Iki penting amarga tim gedhe sing nggarap monolit lawas angel diatur. Tim kasebut dipeksa kerja miturut proses sing ketat, nanging dheweke pengin luwih kreatif lan mandiri. Mung tim cilik sing bisa mbayar iki.
Isolasi layanan ing proses kapisah. Saenipun, kula kepingin ngisolasi ing wadhah, nanging kathah layanan ingkang ditulis ing .NET Framework namung saged dipunlampahi ing WindowsLayanan adhedhasar .NET Core saiki wis muncul, nanging isih ana sawetara.
Fleksibilitas penyebaran. Kita pengin nggabungake layanan kanthi cara sing kita butuhake, lan dudu cara meksa kode kasebut.
Panggunaan teknologi anyar. Iki menarik kanggo programer apa wae.
Masalah transisi
Mesthi wae, yen gampang ngrusak monolit dadi layanan mikro, ora perlu diomongake ing konferensi lan nulis artikel. Ana akeh pitfalls ing proses iki; Aku bakal njlèntrèhaké sing utama sing ngalangi kita.
Masalah pertama khas kanggo paling monoliths: koherensi logika bisnis. Nalika nulis monolit, kita pengin nggunakake maneh kelas supaya ora nulis kode sing ora perlu. Lan nalika pindhah menyang layanan mikro, iki dadi masalah: kabeh kode digandhengake kanthi rapet, lan angel misahake layanan kasebut.
Ing wektu wiwitan karya, gudang duwe luwih saka 500 proyek lan luwih saka 700 ewu baris kode. Iki kaputusan cukup amba lan masalah kapindho. Sampeyan ora bisa mung njupuk lan dibagi dadi microservices.
Masalah katelu - kekurangan infrastruktur sing dibutuhake. Nyatane, kita nyalin kode sumber kanthi manual menyang server.
Carane pindhah saka monolith kanggo microservices
Penyediaan Layanan Mikro
Kaping pisanan, kita langsung nemtokake manawa pemisahan layanan mikro minangka proses iteratif. Kita mesthi dibutuhake kanggo ngembangake masalah bisnis kanthi paralel. Kepiye cara ngetrapake teknis iki wis dadi masalah kita. Mulane, kita nyiapake proses iteratif. Ora bakal bisa digunakake kanthi cara liya yen sampeyan duwe aplikasi gedhe lan durung siap ditulis maneh.
Cara apa sing digunakake kanggo ngisolasi layanan mikro?
Cara pisanan - mindhah modul ana minangka layanan. Ing babagan iki, kita begja: wis ana layanan sing wis kadhaptar sing digunakake nggunakake protokol WCF. Padha dipisahake dadi majelis kapisah. Kita njejeri kanthi kapisah, nambahake peluncur cilik kanggo saben bangunan. Iki ditulis nggunakake perpustakaan Topshelf sing apik, sing ngidini sampeyan mbukak aplikasi kasebut minangka layanan lan minangka konsol. Iki trep kanggo debugging amarga ora ana proyek tambahan sing dibutuhake ing solusi kasebut.
Layanan kasebut disambungake miturut logika bisnis, amarga padha nggunakake rakitan umum lan nggarap database umum. Padha meh ora bisa disebut microservices ing wangun murni. Nanging, kita bisa nyedhiyakake layanan kasebut kanthi kapisah, ing macem-macem proses. Iki mung bisa nyuda pengaruhe ing saben liyane, nyuda masalah karo pangembangan paralel lan siji titik kegagalan.
Majelis karo inang mung siji baris kode ing kelas Program. Kita ndhelikake karya karo Topshelf ing kelas tambahan.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
Cara liya kanggo ngalokasi layanan mikro yaiku: nggawe wong-wong mau kanggo ngatasi masalah anyar. Yen ing wektu sing padha monolith ora tuwuh, iki wis apik banget, sing tegese kita pindhah menyang arah sing bener. Kanggo ngatasi masalah anyar, kita nyoba nggawe layanan sing kapisah. Yen ana kesempatan kasebut, mula kita nggawe layanan "kanonik" luwih akeh sing ngatur model data dhewe, database sing kapisah.
Kita, kaya akeh, miwiti layanan otentikasi lan wewenang. Padha sampurna kanggo iki. Padha mandhiri, minangka aturan, duwe model data sing kapisah. Dheweke dhewe ora sesambungan karo monolith, mung dadi kanggo ngatasi sawetara masalah. Nggunakake layanan kasebut, sampeyan bisa miwiti transisi menyang arsitektur anyar, debug infrastruktur kasebut, nyoba sawetara pendekatan sing ana gandhengane karo perpustakaan jaringan, lsp. Kita ora duwe tim ing organisasi sing ora bisa nggawe layanan otentikasi.
Cara katelu kanggo nyedhiyakake layanan mikroSing kita gunakake rada spesifik kanggo kita. Iki minangka penghapusan logika bisnis saka lapisan UI. Aplikasi UI utama kita yaiku desktop; iku, kaya backend, ditulis ing C #. Pangembang kanthi periodik nggawe kesalahan lan nransfer bagean logika menyang UI sing kudune ana ing backend lan digunakake maneh.
Yen sampeyan ndeleng conto nyata saka kode bagean UI, sampeyan bisa ndeleng manawa sebagian besar solusi iki ngemot logika bisnis nyata sing migunani ing proses liyane, ora mung kanggo mbangun formulir UI.
Logika UI nyata mung ana ing saperangan baris pungkasan. Kita ditransfer menyang server supaya bisa digunakake maneh, saéngga nyuda UI lan entuk arsitektur sing bener.
Cara kaping papat lan paling penting kanggo ngisolasi layanan mikro, kang ndadekake iku bisa kanggo ngurangi monolith ing, punika njabut layanan ana karo Processing. Nalika njupuk modul sing wis ana, asile ora mesthi disenengi para pangembang, lan proses bisnis bisa uga wis ketinggalan jaman wiwit fungsi kasebut digawe. Kanthi refactoring, kita bisa ndhukung proses bisnis anyar amarga syarat bisnis saya ganti. Kita bisa nambah kode sumber, mbusak cacat sing dikenal, lan nggawe model data sing luwih apik. Ana akeh keuntungan sing ditampa.
Misahake layanan saka pangolahan ora bisa dipisahake karo konsep konteks sing diwatesi. Iki minangka konsep saka Domain Driven Design. Iki tegese bagean saka model domain sing kabeh istilah saka basa siji ditetepake kanthi unik. Ayo ndeleng konteks asuransi lan tagihan minangka conto. We duwe aplikasi monolithic, lan kita kudu bisa karo akun ing insurance. Kita ngarepake pangembang nemokake kelas Akun sing ana ing perakitan liyane, ngrujuk saka kelas Asuransi, lan kita bakal duwe kode kerja. Prinsip DRY bakal dihormati, tugas bakal rampung luwih cepet kanthi nggunakake kode sing ana.
Akibaté, ternyata konteks akun lan asuransi disambungake. Nalika syarat anyar muncul, kopling iki bakal ngganggu pembangunan, nambah kerumitan logika bisnis sing wis rumit. Kanggo ngatasi masalah iki, sampeyan kudu nemokake wates antarane konteks ing kode lan mbusak pelanggaran. Contone, ing konteks asuransi, bisa uga nomer akun Bank Sentral 20 digit lan tanggal akun dibukak bakal cukup.
Kanggo misahake konteks sing diwatesi iki lan miwiti proses misahake layanan mikro saka solusi monolitik, kita nggunakake pendekatan kayata nggawe API eksternal ing aplikasi kasebut. Yen kita ngerti manawa sawetara modul kudu dadi layanan mikro, piye wae diowahi sajrone proses kasebut, mula kita langsung nelpon menyang logika sing ana ing konteks winates liyane liwat telpon eksternal. Contone, liwat REST utawa WCF.
Kita mutusake kanthi tegas yen ora bakal ngindhari kode sing mbutuhake transaksi sing disebarake. Ing kasus kita, ternyata cukup gampang kanggo ngetutake aturan iki. Kita durung nemoni kahanan sing mbutuhake transaksi distribusi sing ketat - konsistensi pungkasan antarane modul cukup cukup.
Ayo katon ing conto tartamtu. Kita duwe konsep orkestra - pipa sing ngolah entitas "aplikasi". Dheweke nggawe klien, akun lan kertu bank. Yen klien lan akun digawe kanthi sukses, nanging nggawe kertu gagal, aplikasi kasebut ora pindhah menyang status "sukses" lan tetep ing status "kertu ora digawe". Ing mangsa ngarep, aktivitas latar mburi bakal njupuk lan ngrampungake. Sistem kasebut wis sawetara wektu ora konsisten, nanging umume kita wareg karo iki.
Yen ana kahanan nalika perlu kanggo terus-terusan nyimpen bagean saka data, kita bakal paling kamungkinan pindhah menyang consolidation layanan kanggo proses ing siji proses.
Ayo goleki conto alokasi layanan mikro. Kepiye carane bisa nggawa menyang produksi kanthi aman? Ing conto iki, kita duwe bagean kapisah saka sistem - modul layanan payroll, salah siji saka bagean kode kang kita pengin nggawe microservice.
Kaping pisanan, kita nggawe layanan mikro kanthi nulis ulang kode kasebut. Kita nambah sawetara aspek sing ora seneng. Kita ngetrapake syarat bisnis anyar saka pelanggan. Kita nambah API Gateway kanggo sambungan antarane UI lan backend, kang bakal nyedhiyani telpon nerusake.
Sabanjure, kita ngeculake konfigurasi iki menyang operasi, nanging ing negara pilot. Umume pangguna isih nggarap proses bisnis lawas. Kanggo pangguna anyar, kita ngembangake versi anyar saka aplikasi monolitik sing ora ana maneh proses iki. Ateges, kita duwe kombinasi monolit lan microservice sing digunakake minangka pilot.
Kanthi pilot sukses, kita ngerti yen konfigurasi anyar pancen bisa digunakake, kita bisa mbusak monolith lawas saka persamaan lan ninggalake konfigurasi anyar ing panggonan solusi lawas.
Secara total, kita nggunakake meh kabeh cara sing wis ana kanggo misahake kode sumber monolit. Kabeh mau ngidini kita nyuda ukuran bagean aplikasi lan nerjemahake menyang perpustakaan anyar, nggawe kode sumber sing luwih apik.
Nggarap database
Basis data bisa dipérang luwih elek tinimbang kode sumber, amarga ora mung ngemot skema saiki, nanging uga nglumpukake data sajarah.
Database kita, kaya akeh liyane, duwe kekurangan penting liyane - ukurane gedhe. Database iki dirancang miturut logika bisnis ruwet monolith a, lan hubungan akumulasi antarane tabel macem-macem konteks diwatesi.
Ing kasus kita, kanggo ngatasi kabeh masalah (database gedhe, akeh sambungan, kadhangkala wates sing ora jelas ing antarane tabel), ana masalah sing kedadeyan ing pirang-pirang proyek gedhe: panggunaan template database sing dienggo bareng. Data dijupuk saka tabel liwat tampilan, liwat replikasi, lan dikirim menyang sistem liyane ing ngendi replikasi iki dibutuhake. Akibaté, kita ora bisa mindhah tabel menyang skema kapisah amarga padha aktif digunakake.
Divisi sing padha menyang konteks winates ing kode mbantu kita misahake. Biasane menehi ide sing apik babagan cara ngilangi data ing tingkat database. Kita ngerti tabel sing ana ing konteks sing diwatesi lan sing liyane.
Kita nggunakake rong cara global kanggo pemisahan database: pemisahan tabel sing wis ana lan pemisahan kanthi pangolahan.
Pisah tabel sing wis ana minangka cara sing apik kanggo digunakake yen struktur data apik, nyukupi syarat bisnis, lan kabeh wong seneng. Ing kasus iki, kita bisa misahake tabel sing wis ana dadi skema sing kapisah.
A departemen karo Processing dibutuhake nalika model bisnis wis diganti nemen, lan tabel ora maneh gawe marem kita ing kabeh.
Pisah tabel sing wis ana. Kita kudu nemtokake apa sing bakal dipisahake. Tanpa kawruh iki, ora ana sing bakal bisa, lan ing kene pamisahan konteks sing diwatesi ing kode kasebut bakal mbantu kita. Minangka aturan, yen sampeyan bisa ngerti wates konteks ing kode sumber, dadi cetha kang tabel kudu klebu ing dhaftar departemen.
Ayo mbayangno yen kita duwe solusi ing ngendi rong modul monolith sesambungan karo siji database. Kita kudu nggawe manawa mung siji modul sesambungan karo bagean saka tabel kapisah, lan liyane wiwit sesambungan karo liwat API. Kanggo miwiti, cukup mung rekaman sing ditindakake liwat API. Iki minangka syarat sing perlu kanggo kita ngomong babagan kamardikan layanan mikro. Sambungan maca bisa tetep anggere ora ana masalah gedhe.
Langkah sabanjure yaiku kita bisa misahake bagean kode sing bisa digunakake karo tabel sing dipisahake, nganggo utawa tanpa proses, dadi layanan mikro sing kapisah lan mbukak ing proses sing kapisah, wadhah. Iki bakal dadi layanan sing kapisah kanthi sambungan menyang database monolit lan tabel sing ora ana hubungane langsung. Monolith isih sesambungan kanggo maca karo bagean sing bisa dicopot.
Mengko kita bakal mbusak sambungan iki, yaiku, maca data saka aplikasi monolitik saka tabel sing dipisahake uga bakal ditransfer menyang API.
Sabanjure, kita bakal milih saka database umum tabel sing mung bisa digunakake microservice anyar. Kita bisa mindhah tabel menyang skema sing kapisah utawa malah menyang database fisik sing kapisah. Isih ana sambungan maca antarane microservice lan database monolith, nanging ana apa-apa padha sumelang ing bab, ing konfigurasi iki bisa urip kanggo dangu.
Langkah pungkasan yaiku mbusak kabeh sambungan. Ing kasus iki, kita bisa uga kudu migrasi data saka database utama. Kadhangkala kita pengin nggunakake maneh sawetara data utawa direktori sing ditiru saka sistem eksternal ing sawetara database. Iki kedadeyan kanthi periodik.
departemen pangolahan. Cara iki meh padha karo sing pisanan, mung ing urutan mbalikke. Kita langsung nyedhiyakake database anyar lan layanan mikro anyar sing sesambungan karo monolit liwat API. Nanging ing wektu sing padha, isih ana set tabel database sing pengin dibusak ing mangsa ngarep. Kita ora butuh maneh; kita ngganti model anyar.
Supaya skema iki bisa digunakake, kita bakal mbutuhake wektu transisi.
Banjur ana rong pendekatan sing bisa ditindakake.
Pisanan: kita duplikat kabeh data ing database anyar lan lawas. Ing kasus iki, ana redundansi data lan masalah sinkronisasi bisa uga muncul. Nanging kita bisa njupuk loro klien beda. Siji bakal bisa karo versi anyar, liyane karo sing lawas.
Kapindho: kita dibagi data miturut sawetara kritéria bisnis. Contone, kita duwe 5 produk ing sistem sing disimpen ing database lawas. Kita nyelehake nomer enem ing tugas bisnis anyar ing database anyar. Nanging kita butuh API Gateway sing bakal nyinkronake data iki lan nuduhake klien ing ngendi lan saka apa.
Loro-lorone pendekatan bisa, milih gumantung ing kahanan.
Sawise kita yakin manawa kabeh bisa digunakake, bagean monolit sing bisa digunakake karo struktur database lawas bisa dipateni.
Langkah pungkasan yaiku mbusak struktur data lawas.
Kanggo ngringkes, kita bisa ngomong yen kita duwe masalah karo database: angel digarap dibandhingake karo kode sumber, luwih angel kanggo nuduhake, nanging bisa lan kudu ditindakake. Kita wis nemokake sawetara cara sing ngidini kita nindakake iki kanthi aman, nanging isih luwih gampang nggawe kesalahan karo data tinimbang kode sumber.
Nggarap kode sumber
Iki minangka diagram kode sumber nalika miwiti nganalisa proyek monolitik.
Kira-kira bisa dipérang dadi telung lapisan. Iki minangka lapisan modul sing diluncurake, plugin, layanan lan aktivitas individu. Nyatane, iki minangka titik entri ing solusi monolitik. Kabeh mau ditutup kanthi rapet kanthi lapisan Umum. Nduwe logika bisnis sing dienggo bareng layanan lan akeh sambungan. Saben layanan lan plugin digunakake nganti 10 utawa luwih umum, gumantung saka ukuran lan kalbu pangembang.
Bejo duwe perpustakaan infrastruktur sing bisa digunakake kanthi kapisah.
Kadhangkala ana kahanan nalika sawetara obyek umum ora kalebu ing lapisan iki, nanging minangka perpustakaan infrastruktur. Iki ditanggulangi kanthi ngganti jeneng.
Keprigelan paling gedhe yaiku konteks sing diwatesi. Iku kedaden sing 3-4 konteks dicampur ing siji Déwan umum lan digunakake saben liyane ing fungsi bisnis padha. Sampeyan perlu kanggo ngerti ngendi iki bisa dipérang lan bebarengan apa wates, lan apa sabanjuré karo pemetaan divisi iki menyang kumpulan kode sumber.
Kita wis ngrumusake sawetara aturan kanggo proses pamisah kode.
Pisanan: Kita ora pengin nuduhake logika bisnis ing antarane layanan, aktivitas lan plugin. Kita pengin nggawe logika bisnis mandiri ing layanan mikro. Microservices, ing sisih liya, dianggep minangka layanan sing ana kanthi mandiri. Aku pracaya yen pendekatan iki rada boros, lan angel digayuh, amarga, contone, layanan ing C # bakal disambungake dening perpustakaan standar. Sistem kita ditulis ing C #; kita durung nggunakake teknologi liyane. Mula, kita mutusake manawa bisa nggunakake rakitan teknis umum. Sing utama yaiku ora ngemot fragmen logika bisnis. Yen sampeyan duwe bungkus penak liwat ORM sing sampeyan gunakake, banjur nyalin saka layanan menyang layanan larang banget.
Tim kita minangka penggemar desain sing didhukung domain, mula arsitektur bawang cocog banget kanggo kita. Basis layanan kita dudu lapisan akses data, nanging perakitan kanthi logika domain, sing mung ngemot logika bisnis lan ora ana hubungane karo infrastruktur kasebut. Ing wektu sing padha, kita bisa kanthi mandiri ngowahi rakitan domain kanggo ngatasi masalah sing ana gandhengane karo kerangka kerja.
Ing tahap iki, kita nemoni masalah serius pisanan. Layanan kasebut kudu ngrujuk menyang siji perakitan domain, kita pengin nggawe logika kasebut mandiri, lan prinsip DRY banget ngalangi kita ing kene. Pangembang pengin nggunakake maneh kelas saka majelis tetanggan kanggo ngindhari duplikasi, lan minangka asil, domain wiwit disambungake maneh. Kita nganalisa asil lan mutusake manawa masalah kasebut uga ana ing area piranti panyimpenan kode sumber. Kita duwe gudang gedhe sing ngemot kabeh kode sumber. Solusi kanggo kabeh proyek iki angel banget kanggo ngumpul ing mesin lokal. Mulane, solusi cilik sing kapisah digawe kanggo bagean saka proyek kasebut, lan ora ana sing nglarang nambahake sawetara perakitan umum utawa domain lan digunakake maneh. Siji-sijine alat sing ora ngidini kita nindakake iki yaiku mriksa kode. Nanging kadhangkala uga gagal.
Banjur kita miwiti pindhah menyang model kanthi repositori sing kapisah. Logika bisnis ora mili maneh saka layanan menyang layanan, domain wis dadi independen. Konteks sing diwatesi didhukung kanthi luwih jelas. Kepiye carane nggunakake perpustakaan infrastruktur maneh? Kita misahake menyang gudang sing kapisah, banjur dilebokake ing paket Nuget, sing dilebokake ing Artifactory. Kanthi owah-owahan apa wae, perakitan lan publikasi bakal ditindakake kanthi otomatis.
Layanan kita wiwit ngrujuk paket infrastruktur internal kanthi cara sing padha karo eksternal. Kita ngundhuh perpustakaan eksternal saka Nuget. Kanggo nggarap Artifactory, ing ngendi kita nyelehake paket kasebut, kita nggunakake rong manajer paket. Ing repositori cilik kita uga nggunakake Nuget. Ing repositori kanthi macem-macem layanan, kita nggunakake Paket, sing nyedhiyakake konsistensi versi luwih akeh ing antarane modul.
Mangkono, kanthi nggarap kode sumber, rada ngganti arsitektur lan misahake repositori, kita nggawe layanan luwih mandiri.
Masalah infrastruktur
Umume kekurangan kanggo pindhah menyang layanan mikro ana hubungane karo infrastruktur. Sampeyan mbutuhake panyebaran otomatis, sampeyan butuh perpustakaan anyar kanggo mbukak infrastruktur kasebut.
Instalasi manual ing lingkungan
Kaping pisanan, kita nginstal solusi kanggo lingkungan kanthi manual. Kanggo ngotomatisasi proses iki, kita nggawe pipa CI / CD. Kita milih proses pangiriman sing terus-terusan amarga penyebaran terus-terusan durung bisa ditampa kanggo kita saka sudut pandang proses bisnis. Mulane, ngirim kanggo operasi digawa metu nggunakake tombol, lan kanggo testing - kanthi otomatis.
Kita nggunakake Atlassian, Bitbucket kanggo panyimpenan kode sumber lan Bambu kanggo bangunan. Kita seneng nulis skrip mbangun ing Cake amarga padha karo C #. Paket sing wis siap teka ing Artifactory, lan Ansible kanthi otomatis mlebu menyang server tes, banjur bisa langsung dites.
logging kapisah
Ing sawijining wektu, salah sawijining gagasan monolit yaiku nyedhiyakake logging bareng. Kita uga kudu ngerti apa sing kudu ditindakake karo log individu sing ana ing disk. Log kita ditulis ing file teks. Kita mutusake nggunakake tumpukan ELK standar. Kita ora nulis menyang ELK langsung liwat panyedhiya, nanging mutusake yen kita bakal ngowahi log teks lan nulis ID jejak kasebut minangka pengenal, nambahake jeneng layanan, supaya log kasebut bisa diurai mengko.
Kanthi Filebeat, kita bisa ngumpulake log saka server, banjur transformasikake, gunakake Kibana kanggo mbangun query ing UI, lan deleng kepiye panggilan kasebut diarahake antarane layanan. ID Pelacakan migunani banget kanggo iki.
Layanan sing gegandhengan karo testing lan debugging
Kaping pisanan, kita ora ngerti kanthi lengkap babagan debug layanan sing dikembangake. Kabeh iku prasaja karo monolith; kita mbukak ing mesin lokal. Kaping pisanan, dheweke nyoba nindakake perkara sing padha karo layanan mikro, nanging kadhangkala kanggo mbukak siji layanan mikro sampeyan kudu miwiti sawetara liyane, lan iki ora trep. We temen maujud sing kita kudu pindhah menyang model ngendi kita ninggalake ing mesin lokal mung layanan utawa layanan sing pengin debug. Layanan sing isih digunakake saka server sing cocog karo konfigurasi karo prod. Sawise debugging, sajrone testing, kanggo saben tugas, mung layanan sing diganti sing ditanggepi menyang server test. Mangkono, solusi kasebut diuji ing wangun sing bakal katon ing produksi ing mangsa ngarep.
Ana server sing mung mbukak versi produksi layanan. Server kasebut dibutuhake yen ana kedadeyan, kanggo mriksa pangiriman sadurunge penyebaran lan kanggo latihan internal.
Kita wis nambah proses testing otomatis nggunakake perpustakaan Specflow populer. Tes mlaku kanthi otomatis nggunakake NUnit sanalika sawise penyebaran saka Ansible. Yen jangkoan tugas kanthi otomatis, mula ora perlu tes manual. Sanajan kadhangkala tes manual tambahan isih dibutuhake. Kita nggunakake tag ing Jira kanggo nemtokake tes sing bakal ditindakake kanggo masalah tartamtu.
Kajaba iku, kabutuhan tes beban saya tambah, sadurunge ditindakake mung ing kasus sing jarang. Kita nggunakake JMeter kanggo mbukak tes, InfluxDB kanggo nyimpen, lan Grafana kanggo mbangun grafik proses.
Apa sing wis digayuh?
Kaping pisanan, kita nyingkirake konsep "release". Ical wis rong wulan rilis monstrous nalika colossus iki disebarake ing lingkungan produksi, sementara ngganggu proses bisnis. Saiki kita nyebarake layanan kanthi rata-rata saben 1,5 dina, nglumpukake amarga padha mbukak sawise disetujoni.
Ora ana kegagalan fatal ing sistem kita. Yen kita ngeculake layanan mikro kanthi bug, mula fungsi sing ana gandhengane bakal rusak, lan kabeh fungsi liyane ora bakal kena pengaruh. Iki nemen nambah pengalaman pangguna.
Kita bisa ngontrol pola penyebaran. Sampeyan bisa milih klompok layanan kanthi kapisah saka solusi liyane, yen perlu.
Kajaba iku, kita wis Ngartekno suda masalah karo antrian gedhe dandan. Saiki kita duwe tim produk sing kapisah sing nggarap sawetara layanan kanthi mandiri. Proses Scrum wis apik ing kene. Tim tartamtu bisa uga duwe Pemilik Produk sing kapisah sing menehi tugas.
Ringkesan
- Microservices cocok kanggo decomposing sistem Komplek. Ing proses kasebut, kita wiwit ngerti apa sing ana ing sistem kita, apa konteks sing winates, ing ngendi watese ana. Iki ngidini sampeyan nyebarake perbaikan ing antarane modul lan nyegah kebingungan kode.
- Layanan mikro nyedhiyakake keuntungan organisasi. Dheweke asring diomongake mung minangka arsitektur, nanging arsitektur apa wae dibutuhake kanggo ngrampungake kabutuhan bisnis, lan ora dhewe. Mulane, kita bisa ngomong yen microservices cocok kanggo ngrampungake masalah ing tim cilik, amarga Scrum saiki wis populer banget.
- Pemisahan minangka proses iteratif. Sampeyan ora bisa njupuk aplikasi lan mung dibagi dadi microservices. Produk sing diasilake ora bisa digunakake. Nalika ngaturake layanan mikro, migunani kanggo nulis ulang warisan sing wis ana, yaiku, ngowahi dadi kode sing disenengi lan luwih cocog karo kabutuhan bisnis babagan fungsionalitas lan kacepetan.
Caveat cilik: Biaya pindhah menyang layanan mikro cukup signifikan. Mbutuhake wektu suwe kanggo ngrampungake masalah infrastruktur dhewe. Dadi yen sampeyan duwe aplikasi cilik sing ora mbutuhake skala tartamtu, kajaba sampeyan duwe akeh pelanggan sing saingan kanggo perhatian lan wektu tim, mula layanan mikro bisa uga ora kaya sing sampeyan butuhake saiki. Iku cukup larang. Yen sampeyan miwiti proses kanthi layanan mikro, mula biaya bakal luwih dhuwur tinimbang yen sampeyan miwiti proyek sing padha karo pangembangan monolit.
PS Crita sing luwih emosional (lan kaya kanggo sampeyan dhewe) - miturut .
Punika versi lengkap laporan.
Source: www.habr.com
