Dina artikel ieu, kuring bakal ngobrol ngeunaan kumaha proyék Kuring keur dipake dina robah tina monolith badag kana susunan microservices.
Proyék mimiti sajarahna geus lila pisan, dina awal 2000. Versi munggaran ditulis dina Visual Basic 6. Kana waktu, éta janten jelas yén ngembangkeun dina basa ieu bakal hésé ngarojong dina mangsa nu bakal datang, saprak IDE. jeung basa sorangan kurang dimekarkeun. Dina ahir taun 2000-an, éta mutuskeun pikeun ngalih ka C # anu langkung ngajangjikeun. Versi anyar ieu ditulis dina paralel jeung révisi nu heubeul, laun beuki loba kode ieu ditulis dina .NET. Backend dina C # mimitina fokus kana arsitéktur jasa, tapi dina mangsa pangwangunan, perpustakaan umum kalawan logika dipaké, sarta jasa anu dibuka dina prosés tunggal. Hasilna mangrupikeun aplikasi anu kami sebut "monolith jasa".
Salah sahiji ti saeutik kaunggulan tina kombinasi ieu nya éta kamampuh jasa pikeun nelepon silih ngaliwatan hiji API éksternal. Aya prasyarat anu jelas pikeun transisi ka layanan anu langkung leres, sareng ka hareupna, arsitéktur microservice.
Kami ngamimitian padamelan ngeunaan dékomposisi sakitar 2015. Kami henteu acan ngahontal kaayaan anu idéal - masih aya bagian tina proyék ageung anu boro tiasa disebat monoliths, tapi aranjeunna henteu ogé sapertos microservices. Sanajan kitu, kamajuan signifikan.
Kuring bakal ngobrol ngeunaan eta dina artikel.
eusi
Arsitéktur jeung masalah tina solusi aya
Dina awalna, arsitéktur katingali sapertos kieu: UI mangrupikeun aplikasi anu misah, bagian monolithic ditulis dina Visual Basic 6, aplikasi .NET mangrupikeun set jasa anu aya hubunganana sareng database anu lumayan ageung.
Kakurangan leyuran saméméhna
Hiji titik gagal
Urang kungsi titik tunggal gagal: aplikasi .NET lumpat dina prosés tunggal. Upami aya modul anu gagal, sadaya aplikasi gagal sareng kedah dibalikan deui. Kusabab urang ngajadikeun otomatis sajumlah ageung prosés pikeun pangguna anu béda-béda, kusabab gagalna salah sahijina, sadayana henteu tiasa dianggo pikeun sababaraha waktos. Sareng upami aya kasalahan parangkat lunak, bahkan cadangan henteu ngabantosan.
Antrian perbaikan
Kelemahan ieu rada organisasi. Aplikasi kami ngagaduhan seueur palanggan, sareng aranjeunna sadayana hoyong ningkatkeun éta pas mungkin. Saméméhna, mustahil pikeun ngalakukeun ieu paralel, sarta sakabeh nasabah nangtung dina garis. Proses ieu négatip pikeun usaha sabab kedah ngabuktikeun yén tugasna berharga. Sareng tim pamekaran nyéépkeun waktos pikeun ngatur antrian ieu. Ieu nyandak loba waktu jeung usaha, sarta produk pamustunganana teu bisa ngarobah gancang-gancang sakumaha maranéhna bakal resep.
pamakéan sumberdaya suboptimal
Nalika jasa hosting dina prosés tunggal, kami salawasna nyalin lengkep konfigurasi tina server ka server. Kami hoyong nempatkeun jasa anu paling beurat dimuat sacara misah supados henteu miceunan sumber daya sareng kéngingkeun kontrol anu langkung fleksibel dina skéma panyebaran kami.
Hésé pikeun nerapkeun téknologi modern
Hiji masalah wawuh ka sadaya pamekar: aya kahayang pikeun ngawanohkeun téknologi modern kana proyék, tapi euweuh kasempetan. Kalawan leyuran monolithic badag, sagala update tina perpustakaan ayeuna, teu nyebut transisi ka nu anyar, robah jadi tugas rada non-trivial. Butuh waktu lila pikeun ngabuktikeun ka pamimpin tim nu ieu bakal mawa leuwih bonus ti saraf wasted.
Kasesahan ngaluarkeun parobahan
Ieu mangrupikeun masalah anu paling serius - kami ngaluarkeun sékrési unggal dua bulan.
Unggal release robah jadi musibah nyata pikeun bank, sanajan nguji sarta usaha pamekar. Usaha ngartos yén dina awal minggu sababaraha pungsionalitasna moal jalan. Sareng pamekar ngartos yén saminggu kajadian anu serius ngantosan aranjeunna.
Sarerea boga kahayang pikeun ngarobah kaayaan.
Ekspektasi ti microservices
Ngaluarkeun komponén nalika siap. Pangiriman komponén lamun siap ku decomposing solusi na misahkeun prosés béda.
Tim produk leutik. Ieu penting sabab tim badag gawe dina monolith heubeul éta hésé ngatur. Tim sapertos ieu kapaksa dianggo dina prosés ketat, tapi maranéhna hayang leuwih kreativitas sarta kamerdikaan. Ngan tim leutik anu mampuh ieu.
Isolasi jasa dina prosés anu misah. Sacara idéal, kuring hoyong ngasingkeun éta dina wadah, tapi seueur jasa anu ditulis dina .NET Framework ngan ukur dijalankeun dina WindowsLayanan anu dumasar kana .NET Core ayeuna parantos muncul, tapi masih aya sababaraha.
fleksibilitas deployment. Kami hoyong ngagabungkeun jasa sakumaha anu urang peryogikeun, sareng sanés cara kodeu maksakeunana.
Pamakéan téknologi anyar. Ieu metot pikeun programer wae.
Masalah transisi
Tangtosna, upami éta gampang pikeun ngarobih monolith kana microservices, teu aya anu peryogi pikeun ngobrol ngeunaan éta dina konperénsi sareng nyerat tulisan. Aya seueur pitfalls dina prosés ieu; Kuring bakal ngajelaskeun anu utama anu ngahalangan kami.
Masalah kahiji has pikeun kalolobaan monoliths: kohérénsi logika bisnis. Nalika urang nyerat monolith, urang hoyong nganggo deui kelas urang supados henteu nyerat kode anu teu perlu. Sareng nalika ngalih ka microservices, ieu janten masalah: sadaya kodena caket pisan, sareng sesah pikeun misahkeun jasa.
Dina waktos mimiti damel, gudang ngagaduhan langkung ti 500 proyék sareng langkung ti 700 rébu garis kode. Ieu rada kaputusan badag tur masalah kadua. Teu mungkin ngan saukur nyandak sareng ngabagi kana jasa mikro.
Masalah katilu - kurangna infrastruktur diperlukeun. Kanyataanna, kami sacara manual nyalin kodeu sumber ka server.
Kumaha carana mindahkeun tina monolith ka microservices
Provisioning microservices
Anu mimiti, urang langsung mutuskeun pikeun diri urang yén pamisahan jasa mikro mangrupikeun prosés iteratif. Kami salawasna diperlukeun pikeun ngembangkeun masalah bisnis dina paralel. Kumaha urang bakal nerapkeun ieu téhnisna geus masalah urang. Ku alatan éta, urang nyiapkeun hiji prosés iterative. Éta moal tiasa dianggo ku cara anu sanés upami anjeun gaduh aplikasi anu ageung sareng éta henteu acan siap ditulis deui.
Métode naon anu kami anggo pikeun ngasingkeun jasa mikro?
Metodeu munggaran - mindahkeun modul aya salaku jasa. Dina hal ieu, kami untung: parantos didaptarkeun jasa anu dianggo nganggo protokol WCF. Aranjeunna dipisahkeun kana majelis anu misah. Urang porting aranjeunna nyalira, nambahkeun launcher leutik ka unggal wangunan. Ieu ditulis ngagunakeun perpustakaan Topshelf éndah, nu ngidinan Anjeun pikeun ngajalankeun aplikasi duanana salaku layanan sarta salaku konsol a. Ieu merenah pikeun debugging saprak euweuh proyék tambahan diperlukeun dina solusi.
Ladenan dihubungkeun dumasar kana logika bisnis, sabab ngagunakeun rakitan umum sareng damel sareng database umum. Aranjeunna boro bisa disebut microservices dina formulir murni maranéhanana. Nanging, urang tiasa nyayogikeun jasa ieu nyalira, dina prosés anu béda. Ieu nyalira ngamungkinkeun pikeun ngurangan pangaruh maranéhanana dina silih, ngurangan masalah kalayan ngembangkeun paralel sarta titik tunggal gagal.
Majelis sareng host ngan ukur hiji garis kode dina kelas Program. Urang nyumput karya kalawan Topshelf dina kelas bantu.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
Cara kadua pikeun alokasi microservices nyaéta: nyieun aranjeunna pikeun ngajawab masalah anyar. Upami dina waktos anu sami monolith henteu tumbuh, ieu parantos saé, anu hartosna urang nuju ka arah anu leres. Pikeun ngabéréskeun masalah anyar, kami nyobian nyiptakeun jasa anu misah. Upami aya kasempetan sapertos kitu, kami nyiptakeun langkung seueur jasa "canonical" anu lengkep ngatur modél data sorangan, database anu misah.
Kami, sapertos seueur, dimimitian ku jasa auténtikasi sareng otorisasi. Aranjeunna sampurna pikeun ieu. Aranjeunna bebas, sakumaha aturan, maranéhna boga model data misah. Aranjeunna sorangan teu berinteraksi sareng monolith nu, ngan kabukti aranjeunna pikeun ngajawab sababaraha masalah. Nganggo jasa ieu, anjeun tiasa ngamimitian transisi ka arsitéktur énggal, debug infrastrukturna, cobian sababaraha pendekatan anu aya hubunganana sareng perpustakaan jaringan, jsb. Kami henteu ngagaduhan tim dina organisasi kami anu henteu tiasa nyiptakeun jasa auténtikasi.
Cara katilu pikeun allocate microservicesAnu kami anggo sakedik khusus pikeun kami. Ieu mangrupikeun ngaleungitkeun logika bisnis tina lapisan UI. Aplikasi UI utama kami nyaéta desktop; éta, sapertos backend, ditulis dina C #. Pamekar périodik nyieun kasalahan sareng nransferkeun bagian logika ka UI anu kedahna aya dina tonggong sareng dianggo deui.
Upami anjeun ningali conto nyata tina kode bagian UI, anjeun tiasa ningali yén kalolobaan solusi ieu ngandung logika bisnis nyata anu mangpaat dina prosés anu sanés, sanés ngan ukur pikeun ngawangun bentuk UI.
Logika UI nyata ngan ukur aya dina sababaraha garis terakhir. Kami mindahkeun éta ka server supados tiasa dianggo deui, ku kituna ngirangan UI sareng ngahontal arsitéktur anu leres.
Cara kaopat sareng pangpentingna pikeun ngasingkeun jasa mikro, nu ngamungkinkeun pikeun ngurangan monolith nu, nyaeta ngaleupaskeun jasa aya kalawan processing. Nalika urang nyandak modul anu aya sapertos kitu, hasilna henteu salawasna dipikaresep ku pamekar, sareng prosés bisnis tiasa janten luntur saprak fungsionalitasna diciptakeun. Kalayan refactoring, urang tiasa ngadukung prosés bisnis énggal sabab syarat bisnis terus robih. Urang tiasa ningkatkeun kodeu sumber, ngaleungitkeun cacad anu dipikanyaho, sareng nyiptakeun modél data anu langkung saé. Aya loba mangpaat accruing.
Misahkeun jasa tina ngolah ieu inextricably numbu ka konsép konteks bounded. Ieu mangrupikeun konsép tina Desain Didorong Domain. Éta hartosna bagian tina modél domain dimana sadaya istilah tina hiji basa diartikeun sacara unik. Hayu urang nempo konteks asuransi na tagihan salaku conto. Simkuring boga aplikasi monolithic, sarta kami kudu digawekeun ku akun di asuransi. Kami ngarepkeun pamekar mendakan kelas Akun anu aya dina rakitan anu sanés, ngarujuk ti kelas Asuransi, sareng kami bakal ngagaduhan kode kerja. Prinsip DRY bakal dimangfaatkeun, tugas bakal dilakukeun langkung gancang ku ngagunakeun kode anu aya.
Hasilna, tétéla yén kontéks akun sareng asuransi disambungkeun. Nalika syarat anyar muncul, gandeng ieu bakal ngaganggu pangwangunan, ningkatkeun pajeulitna logika bisnis anu parantos rumit. Pikeun ngajawab masalah ieu, anjeun kudu neangan wates antara konteks dina kode jeung cabut palanggaran maranéhanana. Salaku conto, dina kontéks asuransi, kamungkinan yén jumlah akun Bank Séntral 20-angka sareng tanggal akun dibuka bakal cekap.
Pikeun misahkeun ieu konteks bounded ti silih tur mimitian prosés misahkeun microservices tina solusi monolithic, kami ngagunakeun pendekatan kayaning nyieun API éksternal dina aplikasi. Upami urang terang yén sababaraha modul kedah janten jasa mikro, kumaha waé dirobih dina prosésna, teras urang langsung nelepon kana logika anu aya dina kontéks kawates anu sanés ngalangkungan telepon éksternal. Contona, via REST atanapi WCF.
Urang pageuh mutuskeun yén urang moal bakal nyingkahan kode nu bakal merlukeun transaksi disebarkeun. Dina kasus urang, tétéla rada gampang nuturkeun aturan ieu. Kami henteu acan mendakan kaayaan dimana transaksi anu disebarkeun ketat leres-leres diperyogikeun - konsistensi akhir antara modul cukup cekap.
Hayu urang nempo conto husus. Kami ngagaduhan konsép orkestra - saluran pipa anu ngolah éntitas "aplikasi". Anjeunna nyiptakeun klien, rekening sareng kartu bank giliran. Upami klien sareng akun suksés didamel, tapi kreasi kartu gagal, aplikasina henteu ngalih ka status "suksés" sareng tetep dina status "kartu henteu diciptakeun". Dina mangsa nu bakal datang, kagiatan latar bakal nyokot eta jeung rengse eta. Sistim nu geus dina kaayaan inconsistency pikeun sawatara waktu, tapi urang umumna wareg jeung ieu.
Upami aya kaayaan nalika perlu konsistén ngahemat bagian tina data, urang paling dipikaresep bakal ngiringan konsolidasi jasa pikeun ngolahna dina hiji prosés.
Hayu urang tingali conto alokasi microservice. Kumaha anjeun tiasa mawa ka produksi rélatif aman? Dina conto ieu, urang gaduh bagian anu misah tina sistem - modul jasa gaji, salah sahiji bagian kode anu urang hoyong ngadamel microservice.
Anu mimiti, urang nyieun microservice ku nulis ulang kode. Kami ningkatkeun sababaraha aspék anu kami henteu resep. Urang nerapkeun syarat bisnis anyar ti nasabah. Urang nambahkeun hiji gateway API kana sambungan antara UI na backend nu, nu bakal nyadiakeun diteruskeun panggero.
Salajengna, urang ngaleupaskeun konfigurasi ieu kana operasi, tapi dina kaayaan pilot. Seuseueurna pangguna urang masih tiasa dianggo sareng prosés bisnis anu lami. Pikeun pamaké anyar, urang ngamekarkeun versi anyar tina aplikasi monolithic nu euweuh ngandung prosés ieu. Intina, urang gaduh kombinasi monolith sareng microservice anu damel salaku pilot.
Ku pilot suksés, urang ngarti yén konfigurasi anyar memang bisa dipake, urang bisa nyabut monolith heubeul tina persamaan jeung ninggalkeun konfigurasi anyar dina tempat solusi heubeul.
Dina total, kami nganggo ampir kabéh métode aya pikeun ngabagi kodeu sumber monolith a. Sadayana ngamungkinkeun urang ngirangan ukuran bagian tina aplikasi sareng narjamahkeun kana perpustakaan énggal, ngajantenkeun kode sumber anu langkung saé.
Gawe sareng database
database bisa dibagi leuwih goreng ti kode sumber, sabab ngandung teu ukur schema ayeuna, tapi ogé akumulasi data sajarah.
Database kami, sapertos seueur anu sanés, ngagaduhan kalemahan anu penting - ukuranana ageung. database ieu dirancang nurutkeun logika bisnis intricate of monolith a, sarta hubungan akumulasi antara tabel rupa konteks bounded.
Dina kasus urang, ka luhur sagala troubles (database badag, loba sambungan, kadang wates jelas antara tabel), timbul masalah anu lumangsung dina loba proyék badag: pamakéan template database dibagikeun. Data dicokot tina tabel ngaliwatan view, ngaliwatan réplikasi, sarta shipped ka sistem séjén dimana réplikasi ieu diperlukeun. Hasilna, urang teu bisa mindahkeun tabel kana skéma misah sabab aktip dipaké.
Divisi sarua kana konteks kawates dina kode mantuan kami di separation. Biasana masihan kami ide anu saé ngeunaan kumaha urang ngarecah data dina tingkat pangkalan data. Urang ngarti mana tabel milik hiji konteks wates jeung nu sejen.
Kami nganggo dua metode global pikeun ngabagi database: ngabagi tabel anu tos aya sareng ngabagi sareng ngolah.
Ngabagi tabel anu tos aya mangrupikeun metode anu saé pikeun dianggo upami struktur datana saé, nyumponan sarat bisnis, sareng sadayana senang. Dina hal ieu, urang tiasa misahkeun tabel anu aya kana skéma anu misah.
A departemén kalawan processing diperlukeun nalika modél bisnis geus robah greatly, sarta tabel euweuh nyugemakeun urang pisan.
Ngabagi tabel anu aya. Urang kudu nangtukeun naon urang bakal misahkeun. Tanpa pangaweruh ieu, nanaon bakal jalan, sarta di dieu separation of konteks bounded dina kode bakal nulungan urang. Sakumaha aturan, lamun bisa ngarti wates of konteks dina kode sumber, janten jelas nu tabel kudu kaasup dina daptar pikeun departemen.
Hayu urang ngabayangkeun yén urang boga solusi nu dua modul monolith berinteraksi sareng hiji database. Urang kudu mastikeun yén ngan hiji modul interaksi jeung bagian tina tabel dipisahkeun, sarta séjén mimiti berinteraksi sareng eta via API. Pikeun mimitian, cukup ngan ukur ngarékam anu dilakukeun ku API. Ieu kaayaan dipikabutuh pikeun urang ngobrol ngeunaan kamerdikaan microservices. Sambungan bacaan tiasa tetep salami teu aya masalah anu ageung.
Lengkah saterusna nyaeta urang bisa misahkeun bagian kode anu hade jeung tabel dipisahkeun, nganggo atawa henteu sareng processing, kana microservice misah tur ngajalankeun eta dina prosés misah, wadahna. Ieu bakal janten jasa anu misah sareng sambungan kana database monolith sareng tabel anu henteu aya hubunganana langsung sareng éta. Monolith masih berinteraksi pikeun maca sareng bagian anu tiasa dicabut.
Engké urang bakal nyabut sambungan ieu, nyaeta, maca data tina aplikasi monolithic tina tabel dipisahkeun ogé bakal dibikeun ka API.
Salajengna, urang bakal milih tina database umum tabel nu ukur gawéna microservice anyar. Urang bisa mindahkeun tabel ka schema misah atawa malah ka database fisik misah. Aya kénéh sambungan bacaan antara microservice na database monolith, tapi aya nanaon salempang ngeunaan, dina konfigurasi ieu bisa hirup keur lila.
Léngkah terakhir nyaéta ngahapus sadayana sambungan. Dina hal ieu, urang bisa jadi kudu migrasi data tina database utama. Kadang urang hoyong nganggo deui sababaraha data atanapi diréktori anu ditiru tina sistem éksternal dina sababaraha pangkalan data. Ieu kajadian ka urang périodik.
departemén ngolah. Metoda ieu sarupa pisan jeung nu kahiji, ngan dina urutan sabalikna. Urang langsung allocate database anyar jeung microservice anyar nu berinteraksi sareng monolith via API. Tapi dina waktos anu sami, tetep aya sakumpulan tabel database anu badé dipupus di hareup. Kami henteu peryogi deui; kami ngagentos éta dina modél énggal.
Pikeun skéma ieu jalan, urang sigana bakal butuh periode transisi.
Lajeng aya dua pendekatan mungkin.
kahiji: urang duplikat sakabeh data dina database anyar jeung heubeul. Dina hal ieu, urang gaduh redundansi data sareng masalah sinkronisasi tiasa timbul. Tapi urang tiasa nyandak dua klien béda. Hiji bakal tiasa dianggo sareng versi énggal, anu sanésna sareng anu lami.
kadua: urang ngabagi data nurutkeun sababaraha kriteria bisnis. Contona, urang tadi 5 produk dina sistem nu disimpen dina database heubeul. Urang nempatkeun hiji kagenep dina tugas bisnis anyar dina database anyar. Tapi urang peryogi API Gateway anu bakal nyingkronkeun data ieu sareng nunjukkeun ka klien dimana sareng naon anu kedah dicandak.
Duanana pendekatan dianggo, milih gumantung kana kaayaan.
Saatos kami yakin yén sagalana jalan, bagian tina monolith nu gawéna kalayan struktur database heubeul bisa ditumpurkeun.
Léngkah terakhir nyaéta ngahapus struktur data anu lami.
Pikeun nyimpulkeun, urang tiasa nyebatkeun yén urang gaduh masalah sareng pangkalan data: sesah damel sareng éta dibandingkeun sareng kode sumber, langkung hese dibagikeun, tapi éta tiasa sareng kedah dilakukeun. Kami geus kapanggih sababaraha cara nu ngidinan urang ngalakukeun ieu rada aman, tapi masih gampang nyieun kasalahan jeung data ti kalayan kode sumber.
Gawe sareng kode sumber
Ieu mangrupikeun diagram kode sumber nalika urang mimiti nganalisa proyék monolitik.
Ieu kasarna bisa dibagi kana tilu lapisan. Ieu mangrupikeun lapisan modul anu diluncurkeun, plugins, jasa sareng kagiatan individu. Nyatana, ieu mangrupikeun titik éntri dina solusi monolitik. Sadayana disegel pageuh ku lapisan Umum. Éta ngagaduhan logika bisnis yén jasa dibagikeun sareng seueur sambungan. Tiap jasa jeung plugin dipaké nepi ka 10 atawa leuwih umum rakitan, gumantung kana ukuran maranéhanana jeung nurani pamekar.
Kami untung gaduh perpustakaan infrastruktur anu tiasa dianggo nyalira.
Kadang-kadang kaayaan timbul nalika sababaraha objék umum teu sabenerna milik lapisan ieu, tapi éta perpustakaan infrastruktur. Ieu direngsekeun ku ngaganti ngaran.
Perhatian pangbadagna ieu bounded konteks. Kajadian éta 3-4 konteks dicampurkeun dina hiji assembly umum tur dipaké silih dina fungsi bisnis sarua. Ieu diperlukeun pikeun ngarti dimana ieu bisa dibagi tur sapanjang naon wates, sarta naon anu kudu dipigawé salajengna kalawan pemetaan division ieu kana majelis kode sumber.
Kami geus ngarumuskeun sababaraha aturan pikeun prosés pamisah kode.
kahiji: Kami henteu deui hoyong ngabagi logika bisnis antara jasa, kagiatan sareng plugins. Kami hoyong ngadamel logika bisnis mandiri dina microservices. Microservices, di sisi séjén, ideally dianggap salaku jasa anu aya sagemblengna bebas. Kuring yakin yén pendekatan ieu rada boros, sarta hese pikeun ngahontal, sabab, contona, jasa dina C # bakal sagala hal disambungkeun ku perpustakaan baku. Sistem kami ditulis dina C #; kami henteu acan nganggo téknologi sanés. Ku alatan éta, urang mutuskeun yén urang bisa mampuh ngagunakeun rakitan teknis umum. Hal utama nyaéta aranjeunna henteu ngandung fragmen logika bisnis. Upami anjeun gaduh bungkus genah dina ORM anu anjeun anggo, teras nyalin tina jasa ka jasa mahal pisan.
Tim kami mangrupikeun kipas desain anu didorong ku domain, janten arsitéktur bawang cocog pikeun kami. Dasar jasa kami sanes lapisan aksés data, tapi hiji rakitan sareng logika domain, anu ngan ukur ngandung logika bisnis sareng teu aya hubunganana sareng infrastruktur. Dina waktos anu sami, urang tiasa mandiri ngarobih rakitan domain pikeun ngabéréskeun masalah anu aya hubunganana sareng kerangka.
Dina tahap ieu urang encountered masalah serius munggaran urang. Ladenan kedah ngarujuk kana hiji rakitan domain, kami hoyong ngadamel logika mandiri, sareng prinsip DRY ngahalangan kami di dieu. Pamekar hoyong nganggo deui kelas ti majelis tatangga pikeun nyegah duplikasi, sareng salaku hasilna, domain mimiti dikaitkeun deui. Kami nganalisa hasil sareng mutuskeun yén sigana masalahna ogé aya di daérah alat panyimpen kode sumber. Kami ngagaduhan gudang ageung anu ngandung sadaya kode sumber. Solusi pikeun sakabéh proyék éta hésé pisan ngumpul dina mesin lokal. Ku alatan éta, solusi leutik misah dijieun pikeun bagian tina proyék, sarta teu saurang ogé forbade nambahkeun sababaraha assembly umum atawa domain ka aranjeunna sarta reusing aranjeunna. Hiji-hijina alat anu henteu ngamungkinkeun urang ngalakukeun ieu nyaéta ulasan kode. Tapi sakapeung ogé gagal.
Teras we mimiti ngalih ka modél anu gaduh repositori anu misah. Logika bisnis henteu deui ngalir tina jasa ka jasa, domain parantos janten mandiri. Konteks wates dirojong langkung jelas. Kumaha urang ngagunakeun deui perpustakaan infrastruktur? Urang dipisahkeun kana gudang misah, lajeng nempatkeun kana bungkusan Nuget, nu urang nempatkeun kana Artifactory. Kalayan parobahan naon waé, rakitan sareng publikasi bakal otomatis.
Jasa kami mimiti ngarujuk bungkusan infrastruktur internal dina cara anu sami sareng anu éksternal. Urang ngundeur perpustakaan éksternal ti Nuget. Pikeun dianggo sareng Artifactory, dimana kami nempatkeun bungkusan ieu, kami nganggo dua manajer pakét. Dina repositories leutik kami ogé dipaké Nuget. Dina repositories kalawan sababaraha layanan, kami dipaké Paket, nu nyadiakeun leuwih konsistensi versi antara modul.
Ku kituna, ku cara dipake dina kode sumber, rada ngarobah arsitéktur sarta misahkeun repositories, urang nyieun jasa urang leuwih bebas.
Masalah infrastruktur
Kalolobaan downsides mun pindah ka microservices patali infrastruktur. Anjeun peryogi panyebaran otomatis, anjeun peryogi perpustakaan énggal pikeun ngajalankeun infrastruktur.
Pamasangan manual di lingkungan
Mimitina, urang masang solusi pikeun lingkungan sacara manual. Pikeun ngajadikeun otomatis prosés ieu, kami nyiptakeun pipa CI / CD. Urang milih prosés pangiriman kontinyu sabab deployment kontinyu teu acan ditarima keur urang tina sudut pandang prosés bisnis. Ku alatan éta, ngirim pikeun operasi dilumangsungkeun maké tombol, sarta pikeun nguji - otomatis.
Kami nganggo Atlassian, Bitbucket pikeun neundeun kode sumber sareng Bambu pikeun ngawangun. Kami resep nyerat skrip ngawangun dina Kue sabab éta sami sareng C #. bungkusan siap-dijieun datang ka Artifactory, sarta Ansible otomatis meunang ka server test, sanggeus éta maranéhna bisa langsung diuji.
logging misah
Dina hiji waktos, salah sahiji ideu monolith nyaéta nyayogikeun logging babarengan. Urang ogé kedah ngartos naon anu kudu dilakukeun sareng log individu anu aya dina disk. Log kami ditulis kana file téks. Urang mutuskeun pikeun ngagunakeun tumpukan ELK baku. Kami henteu nyerat ka ELK langsung ngalangkungan panyadia, tapi mutuskeun yén kami bakal ngarobih log téks sareng nyerat jejak ID dina aranjeunna salaku identifier, nambihan nami jasa, supados log ieu tiasa dirobih engké.
Ku Filebeat urang tiasa ngumpulkeun log urang ti server, teras transformasikeun, anggo Kibana pikeun ngawangun pamundut dina UI, sareng tingali kumaha telepon diarahkeun antara layanan. ID Lacak mangpaat pisan pikeun ieu.
Nguji sarta debugging jasa patali
Mimitina, kami henteu ngartos sapinuhna kumaha debug jasa anu dikembangkeun. Sagalana saderhana sareng monolith; kami ngajalankeun éta dina mesin lokal. Mimitina aranjeunna nyobian ngalakukeun hal anu sami sareng microservices, tapi sakapeung pikeun ngaluncurkeun hiji microservice anjeun kedah ngaluncurkeun sababaraha anu sanés, sareng ieu henteu pikaresepeun. Urang sadar yen urang kudu pindah ka model dimana urang ninggalkeun dina mesin lokal ngan jasa atawa jasa nu urang hoyong debug. jasa sésana dipaké ti server nu cocog konfigurasi kalawan prod. Saatos debugging, salami tés, pikeun tiap tugas, ngan ukur jasa anu dirobih dikaluarkeun ka server uji. Janten, solusina diuji dina bentuk anu bakal muncul dina produksi di hareup.
Aya server anu ngan ngajalankeun versi produksi jasa. Server ieu diperyogikeun upami aya kajadian, pikeun mariksa pangiriman sateuacan panyebaran sareng pikeun latihan internal.
Kami parantos nambihan prosés tés otomatis nganggo perpustakaan Specflow anu populér. Tés dijalankeun sacara otomatis nganggo NUnit langsung saatos panyebaran ti Ansible. Upami liputan tugas pinuh otomatis, maka henteu peryogi uji manual. Sanajan kadang tés manual tambahan masih diperlukeun. Kami nganggo tag dina Jira pikeun nangtukeun tés mana anu kedah dijalankeun pikeun masalah khusus.
Salaku tambahan, kabutuhan pikeun uji beban parantos ningkat; sateuacana dilaksanakeun ngan ukur dina kasus anu jarang. Kami nganggo JMeter pikeun ngajalankeun tés, InfluxDB pikeun nyimpen éta, sareng Grafana pikeun ngawangun grafik prosés.
Naon anu urang kahontal?
Firstly, urang meunang leupas tina konsép "release". Isro anu kaluaran monstrous dua bulan nalika colossus ieu deployed di lingkungan produksi, samentara ngaganggu prosés bisnis. Ayeuna kami nyebarkeun jasa rata-rata unggal 1,5 dinten, ngagolongkeun aranjeunna kusabab aranjeunna beroperasi saatos persetujuan.
Henteu aya kagagalan fatal dina sistem kami. Upami urang ngaleupaskeun microservice sareng bug, maka fungsionalitas anu aya hubunganana sareng éta bakal rusak, sareng sadaya fungsi anu sanés moal kapangaruhan. Ieu greatly ngaronjatkeun pangalaman pamaké.
Urang bisa ngadalikeun pola deployment. Anjeun tiasa milih grup ladenan misah ti sesa solusi, upami diperlukeun.
Sajaba ti éta, kami geus nyata ngurangan masalah ku antrian badag tina perbaikan. Kami ayeuna gaduh tim produk anu misah anu tiasa dianggo sareng sababaraha jasa sacara mandiri. Proses Scrum parantos pas di dieu. Tim khusus tiasa gaduh Pamilik Produk anu misah anu masihan tugas ka éta.
singgetan
- Microservices cocog pisan pikeun decomposing sistem kompléks. Dina prosésna, urang mimiti ngartos naon anu aya dina sistem urang, naon kontéks anu terbatas, dimana watesna. Ieu ngamungkinkeun anjeun leres ngadistribusikaeun perbaikan diantara modul sareng nyegah kabingungan kode.
- Microservices nyadiakeun kauntungan organisasi. Aranjeunna mindeng dikaitkeun ukur salaku arsitéktur, tapi arsitéktur sagala diperlukeun pikeun ngajawab kaperluan bisnis, sarta teu sorangan. Kituna, urang bisa disebutkeun yen microservices anu ogé cocog pikeun ngarengsekeun masalah dina tim leutik, nunjukkeun yen Scrum pohara populér kiwari.
- Separation mangrupa prosés iterative. Anjeun teu tiasa nyandak hiji aplikasi tur saukur ngabagi kana microservices. Produk anu hasilna sigana henteu fungsional. Nalika ngahaturanan jasa mikro, aya mangpaatna pikeun nyerat deui warisan anu tos aya, nyaéta, janten kode anu urang resep sareng langkung nyumponan kabutuhan bisnis dina hal fungsionalitas sareng kacepetan.
A caveat leutik: Waragad pindah ka microservices cukup signifikan. Butuh waktu lila pikeun ngajawab masalah infrastruktur nyalira. Janten upami anjeun gaduh aplikasi alit anu henteu meryogikeun skala khusus, kecuali anjeun gaduh sajumlah ageung palanggan anu bersaing pikeun perhatian sareng waktos tim anjeun, maka microservices panginten henteu janten anu anjeun peryogikeun ayeuna. Ieu rada mahal. Upami anjeun ngamimitian prosés nganggo jasa mikro, maka biayana mimitina langkung luhur tibatan upami anjeun ngamimitian proyék anu sami sareng ngembangkeun monolith.
P.S. Carita anu langkung émosional (saolah-olah pikeun anjeun pribadi) - numutkeun .
Ieu versi lengkep laporan.
sumber: www.habr.com
