Di vê gotarê de, ez ê biaxivim ka projeya ku ez li ser dixebitim çawa ji monolîtek mezin veguherî komek mîkroxizmet.
Projeyê ji demeke dirêj berê, di destpêka sala 2000-an de, dîroka xwe dest pê kir. Guhertoyên pêşîn di Visual Basic 6-ê de hatin nivîsandin. Bi demê re, diyar bû ku pêşveçûna bi vî zimanî dê di pêşerojê de piştgirîkirina dijwar be, ji ber ku IDE û ziman bi xwe jî kêm pêşketiye. Di dawiya salên 2000-an de, biryar hate girtin ku ji bo C#-ya bêtir hêvîdar veguherîne. Guhertoya nû bi revîzyona kevin re paralel hat nivîsandin, gav bi gav di .NET-ê de bêtir kod hatin nivîsandin. Backend di C# de di destpêkê de li ser mîmariya karûbarek bû, lê di dema pêşkeftinê de, pirtûkxaneyên hevpar ên bi mantiqê hatin bikar anîn, û karûbar di pêvajoyek yekane de hatin destpêkirin. Encam serîlêdanek bû ku me jê re digot "monolîtek karûbar".
Yek ji çend avantajên vê kombînasyonê şiyana karûbaran bû ku bi navgîniya API-yek derveyî ve bangî hev bikin. Ji bo derbasbûna karûbarek rasttir, û di pêşerojê de, mîmariya mîkroxizmetê, şertên zelal hebûn.
Me di derdora sala 2015’an de dest bi xebatên xwe yên hilweşandinê kir. Em hîn negihiştine rewşek îdeal - hîn jî beşên projeyek mezin hene ku bi zorê meriv dikare jê re monolît bi nav bike, lê ew jî wekî mîkroxizmetan xuya nakin. Lêbelê, pêşveçûn girîng e.
Ez ê di gotarê de behsa wê bikim.
Contains
Mîmarî û pirsgirêkên çareseriya heyî
Di destpêkê de, mîmarî weha xuya bû: UI serîlêdanek cihêreng e, beşa monolîtîk di Visual Basic 6-ê de hatî nivîsandin, serîlêdana .NET komek karûbarên têkildar e ku bi databasek pir mezin re dixebite.
Dezawantajên çareseriya berê
Yek xala têkçûnê
Yek xala têkçûna me hebû: Serlêdana .NET di pêvajoyek yekane de xebitî. Ger modulek têk çû, tevaya serîlêdanê têk çû û pêdivî bû ku ji nû ve were destpêkirin. Ji ber ku em hejmareke mezin ji pêvajoyên ji bo bikarhênerên cihêreng otomatîk dikin, ji ber têkçûnek di yek ji wan de, her kes nikare ji bo demekê bixebite. Û di rewşeke çewtiyek nermalavê de, tewra hilanînê jî ne alîkar bû.
Dora pêşveçûnan
Ev kêmasî bi awayekî rêxistinî ye. Serlêdana me gelek xerîdar hene, û ew hemî dixwazin wê di zûtirîn dem de baştir bikin. Berê, ne gengaz bû ku vê yekê paralel bikin, û hemî xerîdar di rêzê de sekinîn. Ev pêvajo ji bo karsaziyan neyînî bû ji ber ku ew neçar bûn ku îspat bikin ku peywira wan hêja ye. Û tîmê pêşkeftinê wext derbas kir ji bo organîzekirina vê rêzê. Vê yekê gelek dem û hewldan girt, û hilber di dawiyê de nekare bi qasî ku wan dixwest biguhezîne.
Bikaranîna suboptimal ya çavkaniyan
Dema ku karûbarên mêvandariyê di pêvajoyek yekane de, me her gav bi tevahî veavakirinê ji serverek ji serverê re kopî kir. Me xwest ku karûbarên herî giran ji hev cuda bi cih bikin da ku çavkaniyan winda nekin û li ser nexşeya xweya bicîhkirinê kontrolek maqûltir bi dest bixin.
Bicîhanîna teknolojiyên nûjen zehmet e
Pirsgirêkek ku ji hemî pêşdebiran re naskirî ye: xwestek heye ku teknolojiyên nûjen di projeyê de bidin nasîn, lê derfet tune. Bi çareseriyek monolîtîk a mezin, her nûvekirina pirtûkxaneya heyî, ku nebêje veguheztina yek nû, vediguhere peywirek bêkêmasî. Demek dirêj hewce dike ku meriv ji serokê tîmê re îspat bike ku ev ê ji nervên xerabûyî bêtir bonusan bîne.
Zehmetiya derxistina guhertinan
Pirsgirêka herî giran ev bû - me her du mehan carekê serbestberdan derdixist.
Tevî ceribandin û hewildanên pêşdebiran, her berdan ji bo bankê veguherî felaketek rastîn. Karsaz fêm kir ku di destpêka hefteyê de hin fonksiyonên wê dê nexebitin. Û pêşdebiran fêm kir ku hefteyek bûyerên giran li benda wan in.
Daxwaza her kesî hebû ku rewşê biguherîne.
Hêviyên ji microservices
Pirsgirêka pêkhateyan dema amade ye. Radestkirina pêkhateyan dema ku amade be bi hilweşandina çareseriyê û veqetandina pêvajoyên cihêreng.
Tîmên hilberên piçûk. Ev girîng e ji ber ku tîmek mezin a ku li ser monolîta kevn xebitî, birêvebirina dijwar bû. Tîmek weha neçar bû ku li gorî pêvajoyek hişk bixebite, lê wan bêtir dahênerî û serxwebûn dixwest. Tenê tîmên piçûk dikarin vê yekê bidin.
Tecrîdkirina xizmetên di pêvajoyên cuda de. Bi awayekî îdeal, ez dixwazim wê di konteyneran de îzole bikim, lê hejmareke mezin ji karûbarên ku di .NET Framework de hatine nivîsandin tenê di bin de dixebitin. WindowsNiha xizmetên li ser .NET Core-ê têne çêkirin, lê hîn jî kêm ji wan hene.
nermbûna bicîkirinê. Em dixwazin karûbaran bi awayê ku em jê re hewce dikin tevbigerin, û ne bi awayê ku kod wê ferz dike.
Bikaranîna teknolojiyên nû. Ev ji bo her bernamenûsek balkêş e.
Pirsgirêkên veguherînê
Bê guman, heke hêsan bû ku yekdestiyek di nav mîkroservisan de bişkînin, dê ne hewce be ku li ser konferansan biaxivin û gotaran binivîsin. Di vê pêvajoyê de gelek xeletî hene, ez ê yên sereke yên ku me asteng kirin vebêjim.
Pirsgirêka yekem tîpîk ji bo piraniya monolîtan: hevrêziya mantiqa karsaziyê. Dema ku em monolîtek dinivîsin, em dixwazin dersên xwe ji nû ve bikar bînin da ku kodek nehewce nenivîsin. Û dema ku diçin mîkroxizmetan, ev dibe pirsgirêk: hemî kod bi hişk ve girêdayî ye, û zehmet e ku karûbaran ji hev veqetînin.
Di dema destpêkirina xebatê de, depo zêdetirî 500 proje û zêdetirî 700 hezar rêzikên kodê hebûn. Ev biryareke pir mezin e û pirsgirêka duyemîn. Ne mimkun bû ku meriv wê bi tenê bigire û wê di mîkroservisan de dabeş bike.
Pirsgirêka sêyemîn - nebûna binesaziya pêwîst. Bi rastî, me bi destan koda çavkaniyê li pêşkêşkeran kopî dikir.
Meriv çawa ji monolîtê berbi mîkroservisan ve diçe
Pêşkêşkirina microservices
Pêşîn, me tavilê ji xwe re destnîşan kir ku veqetandina mîkroxizmetan pêvajoyek dubare ye. Her dem ji me dihat xwestin ku pirsgirêkên karsaziyê bi hev re pêş bixin. Em ê vê ji aliyê teknîkî ve çawa pêk bînin jixwe pirsgirêka me ye. Ji ber vê yekê, me ji bo pêvajoyek dubare amade kir. Ger serîlêdanek we ya mezin hebe û ew di destpêkê de ne amade ye ku ji nû ve were nivîsandin ew ê bi rengek din nexebite.
Em kîjan rêbazan bikar tînin da ku mîkroservisan veqetînin?
Ya yekemîn - modulên heyî wekî karûbar biguhezînin. Di vî warî de, em bi şens bûn: jixwe karûbarên qeydkirî hebûn ku bi karanîna protokola WCF xebitîn. Di meclîsên cuda de hatin veqetandin. Me wan ji hev cuda veguhezand, li her avahîsaziyek destanek piçûk zêde kir. Ew bi karanîna pirtûkxaneya hêja Topshelf hate nivîsandin, ku dihêle hûn serîlêdanê hem wekî karûbar û hem jî wekî konsolê bimeşînin. Ev ji bo debugkirinê rehet e ji ber ku di çareseriyê de ti projeyên zêde ne hewce ne.
Karûbar li gorî mantiqa karsaziyê ve girêdayî bûn, ji ber ku wan meclîsên hevpar bikar anîn û bi databasek hevpar re xebitîn. Ew bi zorê dikarin di forma xweya paqij de mîkroxizmet bêne gotin. Lêbelê, em dikarin van karûbaran ji hev cuda, di pêvajoyên cûda de peyda bikin. Vê yekê tenê gengaz kir ku bandora wan li ser hev kêm bikin, pirsgirêk bi pêşveçûna paralel û yek xalek têkçûn kêm bikin.
Civîna bi mêvandar re di pola Bernameyê de tenê yek rêzek kodê ye. Me karê bi Topshelf re di pola alîkar de veşart.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
Awayê duyemîn ji bo veqetandina mîkroservisan ev e: wan ji bo çareserkirina pirsgirêkên nû çêbikin. Ger di heman demê de yekdestî mezin nebe, ev jixwe xweş e, ku tê vê wateyê ku em di rêça rast de diçin. Ji bo çareserkirina pirsgirêkên nû, me hewl da ku xizmetên cuda çêbikin. Ger derfetek wusa hebûya, wê hingê me karûbarên bêtir "kanonîkî" çêkir ku bi tevahî modela daneya xwe, databasek cihêreng îdare dikin.
Me, mîna gelekan, bi karûbarên verastkirin û destûrnameyê dest pê kir. Ew ji bo vê yekê bêkêmasî ne. Ew serbixwe ne, wekî qaîdeyek, wan modelek daneya cûda heye. Ew bi xwe bi yekdestdariyê re têkilî nakin, tenê ew ji wan re vedigere ku hin pirsgirêkan çareser bike. Bi karanîna van karûbaran, hûn dikarin dest bi veguheztina mîmariyek nû bikin, binesaziya li ser wan derxînin, hin nêzîkatiyên têkildarî pirtûkxaneyên torê biceribînin, hwd. Di rêxistina me de tîmên me nînin ku nekarin karûbarek erêkirinê biafirînin.
Rêya sêyemîn a veqetandina mîkroservisanYa ku em bikar tînin ji bo me hinekî taybetî ye. Ev rakirina mantiqa karsaziyê ji qata UI ye. Serîlêdana meya UI ya sereke sermaseya wê ye, mîna paşnavê, bi C# tê nivîsandin. Pêşdebiran bi awayekî periyodîk xeletî kirin û beşên mantiqê veguheztin UI-ya ku diviyabû di paşperdeyê de hebûna û ji nû ve were bikar anîn.
Ger hûn li mînakek rastîn ji koda beşa UI-yê binêrin, hûn dikarin bibînin ku piraniya vê çareseriyê mantiqa karsaziya rastîn dihewîne ku di pêvajoyên din de bikêr e, ne tenê ji bo avakirina forma UI.
Mantiqa UI ya rastîn tenê di çend rêzikên paşîn de heye. Me ew veguhezand serverê da ku ew ji nû ve were bikar anîn, bi vî rengî UI kêm bike û mîmariya rast bi dest bixe.
Rêya çaremîn û herî girîng a veqetandina mîkroservisan, ku kêmkirina monolîtê gengaz dike, rakirina karûbarên heyî yên bi pêvajoyê re ye. Gava ku em modulên heyî wekî ku derdixin, encam her gav ne li gorî dilê pêşdebiran e, û dibe ku pêvajoya karsaziyê ji dema ku fonksiyonê hatî afirandin kevn bûye. Bi refaktorkirinê, em dikarin piştgirî bidin pêvajoyek karsaziyek nû ji ber ku hewcedariyên karsaziyê bi domdarî diguhezin. Em dikarin koda çavkaniyê çêtir bikin, kêmasiyên naskirî rakin, û modelek daneya çêtir biafirînin. Gelek feydeyên peyda dibin.
Veqetandina karûbaran ji pêvajoyê bi têgîna çarçoweya sînorkirî ve girêdayî ye. Ev têgehek ji Domain Driven Design e. Ew tê wateya beşek modela domainê ku tê de hemî şertên zimanek yekane bi yekta têne diyar kirin. Werin em wekî mînak li çarçoweya bîme û fatûreyan binêrin. Serlêdanek me ya yekparêz heye, û pêdivî ye ku em bi hesabê di bîmeyê de bixebitin. Em li bendê ne ku pêşdebir di meclîsek din de çînek Hesabê heyî bibîne, jê re ji pola Bîmeyê referans bike, û em ê koda xebatê hebe. Prensîba DRY dê were rêz kirin, bi karanîna koda heyî dê peywir zûtir were kirin.
Wekî encamek, derdikeve holê ku çarçoveyên hesab û bîmeyê bi hev ve girêdayî ne. Gava ku hewcedariyên nû derdikevin, ev hevgirtin dê di pêşveçûnê de asteng bike, tevliheviya mantiqa karsaziya jixwe tevlihev zêde bike. Ji bo çareserkirina vê pirsgirêkê, hûn hewce ne ku di kodê de sînorên di navbera kontekstan de bibînin û binpêkirinên wan rakin. Mînakî, di çarçoveya sîgorteyê de, pir mimkun e ku hejmareke hesabê Bankeya Navendî ya 20-hejmar û roja ku hesabê vebû bes be.
Ji bo veqetandina van çarçoveyên sînorkirî ji hevûdu û destpêkirina pêvajoya veqetandina mîkroxizmetên ji çareseriyek yekparêz, me nêzîkatiyek wekî afirandina API-yên derveyî di hundurê serîlêdanê de bikar anî. Ger me dizanibû ku hin modul divê bibe mîkroxizmetek, bi rengek di hundurê pêvajoyê de were guheztin, wê hingê me tavilê bi bangên derveyî ve bang li mantiqa ku girêdayî çarçoveyek din a tixûbdar e kir. Mînakî, bi rêya REST an WCF.
Me bi zexmî biryar da ku em ê ji koda ku hewcedarî danûstendinên belavkirî hewce dike dûr nekevin. Di rewşa me de, şopandina vê qaîdeyê pir hêsan e. Em hîna rastî rewşên nehatine ku bi rastî danûstendinên belavkirî yên hişk hewce ne - hevrêziya paşîn a di navbera modulan de bes e.
Ka em li mînakek taybetî binêrin. Têgîna me ya orkestrator heye - boriyek ku sazûmana "serlêdanê" dike. Ew di dorê de xerîdar, hesabek û qerta bankê çêdike. Ger xerîdar û hesab bi serfirazî werin afirandin, lê çêkirina qertafê têk neçe, serîlêdan naçe rewşa "serketî" û di statûya "kart nehatiye çêkirin" de dimîne. Di pêşerojê de, çalakiya paşîn dê wê hilde û biqedîne. Ev demek e pergal di nav nakokiyan de ye, lê bi giştî em ji vê yekê razî ne.
Ger rewşek çêbibe ku pêdivî ye ku bi domdarî beşek daneyê were hilanîn, em ê bi îhtîmalek mezin biçin yekkirina karûbarê da ku wê di yek pêvajoyê de pêvajoyê bikin.
Ka em li mînakek veqetandina mîkroxizmetê binêrin. Meriv çawa dikare wê bi rengek bi ewlehî bîne hilberînê? Di vê nimûneyê de, me beşek veqetandî ya pergalê heye - modulek karûbarê mûçeyê, yek ji beşên kodê yên ku em dixwazin mîkroservisê çêbikin.
Berî her tiştî, em bi ji nû ve nivîsandina kodê mîkroxizmetek diafirînin. Em hin aliyên ku em jê razî nebûn baştir dikin. Em daxwazên karsaziya nû ji xerîdar bicîh dikin. Em Gatewayek API-ê li pêwendiya di navbera UI û paşîn de zêde dikin, ku dê şandina bangê peyda bike.
Dûv re, em vê veavakirinê berdidin xebatê, lê di rewşek pîlot de. Piraniya bikarhênerên me hîn jî bi pêvajoyên karsaziya kevnar re dixebitin. Ji bo bikarhênerên nû, em guhertoyek nû ya serîlêdana monolîtîk ku êdî vê pêvajoyê nahewîne pêşdixin. Di bingeh de, me têkeliyek yekdestdar û mîkroxizmetek ku wekî pîlot dixebite heye.
Bi pîlotek serketî re, em fam dikin ku veavakirina nû bi rastî kargêr e, em dikarin monolîta kevn ji hevkêşeyê derxînin û veavakirina nû li şûna çareseriya kevn bihêlin.
Bi tevahî, em hema hema hemî rêbazên heyî ji bo dabeşkirina koda çavkaniyê ya monolîtê bikar tînin. Hemî ew dihêlin ku em qebareya beşên serîlêdanê kêm bikin û wan wergerînin pirtûkxaneyên nû, koda çavkaniyê çêtir çêbikin.
Bi databasê re dixebitin
Database dikare ji koda çavkaniyê xirabtir were dabeş kirin, ji ber ku ew ne tenê nexşeya heyî, lê di heman demê de daneyên dîrokî yên berhevkirî jî dihewîne.
Databasa me, mîna gelekên din, kêmasiyek din a girîng hebû - mezinahiya wê ya mezin. Ev databas li gorî mentiqê karsaziya tevlihev a yekdestpêkê hate sêwirandin, û têkiliyên di navbera tabloyên cûrbecûr şertên sînorkirî de hatine berhev kirin.
Di doza me de, ji bo serpêhatiya hemî pirsgirêkan (danûstendeyên mezin, gelek girêdan, carinan sînorên ne diyar ên di navbera tabloyan de), pirsgirêkek ku di gelek projeyên mezin de çêdibe derket holê: karanîna şablona databasa hevpar. Daneyên ji tabloyan bi dîtinê, bi dubarekirinê ve hatin girtin û ji pergalên din ên ku hewcedariya vê dubarekirinê hebû re hatin şandin. Wekî encamek, me nekarî tabloyan bixin nav nexşeyek veqetandî ji ber ku ew bi rengek çalak hatine bikar anîn.
Di kodê de heman dabeşkirin di nav çarçoveyên tixûbdar de di veqetandinê de ji me re dibe alîkar. Ew bi gelemperî ramanek pir baş dide me ka em çawa daneyan di asta databasê de vediqetînin. Em fam dikin ka kîjan tablo ji yek çarçoveyek sînorkirî re û kîjan ji ya din re ye.
Me du rêbazên gerdûnî yên dabeşkirina databasê bikar anîn: dabeşkirina tabloyên heyî û dabeşkirina bi pêvajoyê.
Dabeşkirina tabloyên heyî rêbazek baş e ku meriv bikar bîne ger avahiya daneyê baş be, hewcedariyên karsaziyê bicîh bîne, û her kes jê kêfxweş e. Di vê rewşê de, em dikarin tabloyên heyî di şemayek cûda de veqetînin.
Dema ku modela karsaziyê pir guherîbe, dezgehek bi pêvajoyê hewce ye, û tablo êdî qet me têr nakin.
Parçekirina tabloyên heyî. Divê em diyar bikin ka em ê çi ji hev veqetînin. Bêyî vê zanînê, tiştek dê nexebite, û li vir veqetandina çarçoveyên sînorkirî yên di kodê de dê alîkariya me bike. Wekî qaîdeyek, heke hûn dikarin sînorên kontekstan di koda çavkaniyê de fêm bikin, diyar dibe ku kîjan tablo divê di navnîşê de ji bo beşê were veqetandin.
Ka em bifikirin ku me çareseriyek heye ku tê de du modulên monolît bi yek databasê re têkilî daynin. Pêdivî ye ku em pê ewle bin ku tenê modulek bi beşa tabloyên veqetandî re têkildar dibe, û ya din jî bi API-ê re dest bi têkiliyê dike. Ji bo destpêkê, bes e ku tenê tomar bi navgîniya API-ê ve tête kirin. Ji bo em behsa serxwebûna mîkroxizmetan bikin ev şertek pêwîst e. Têkiliyên xwendinê dikarin bimînin heya ku pirsgirêkek mezin tune.
Pêngava paşîn ev e ku em dikarin beşa kodê ya ku bi tabloyên veqetandî, bi an bêyî pêvajoyê re dixebite, veqetînin nav mîkroxizmetek cihêreng û wê di pêvajoyek cihê, konteynir de bimeşînin. Ev dê karûbarek cihêreng be bi girêdana bi databasa monolît û wan tabloyên ku rasterast bi wê re têkildar nabin. Monolît hîn jî ji bo xwendinê bi beşa veqetandî re têkilî dike.
Dûv re em ê vê pêwendiyê derxînin, ango, xwendina daneya ji serîlêdanek monolîtîk ji tabloyên veqetandî jî dê li API-ê were veguheztin.
Dûv re, em ê ji databasa gelemperî tabloyên ku tenê mîkroxizmeta nû pê re dixebite hilbijêrin. Em dikarin tabloyan berbi şemayek veqetandî an tewra danegehek fîzîkî ya cihêreng vegerînin. Dîsa jî têkiliyek xwendinê di navbera mîkroxizmet û databasa monolîtê de heye, lê tiştek ku meriv pê xemgîn bibe tune, di vê veavakirinê de ew dikare demek dirêj bijî.
Pêngava paşîn ev e ku meriv hemî pêwendiyan bi tevahî jê bike. Di vê rewşê de, dibe ku em hewce bike ku daneyên ji databasa sereke veguhezînin. Carinan em dixwazin ku hin daneyan an pelrêçiyên ku ji pergalên derveyî têne dubare kirin di gelek databasan de ji nû ve bikar bînin. Ev yek dem bi dem bi me re dibe.
beşa Processing. Ev rêbaz pir dişibe ya yekem, tenê di rêza berevajî de. Em tavilê databasek nû û mîkroxizmetek nû vediqetînin ku bi monolîtê re bi navgîniya API-yê re têkildar dibe. Lê di heman demê de, komek tabloyên databasê yên ku em dixwazin di pêşerojê de jêbikin, dimîne. Êdî hewcedariya me bi wê nîne, me ew di modela nû de guherand.
Ji bo ku ev nexşe bixebite, îhtîmalek heye ku em hewceyê serdemek veguhêz bin.
Wê demê du nêzîkatiyên gengaz hene.
Yekemîn: Em hemî daneyan di databasên nû û kevn de dubare dikin. Di vê rewşê de, me zêdebûna daneyan heye û dibe ku pirsgirêkên hevdemkirinê derkevin. Lê em dikarin du xerîdarên cûda bigirin. Yek dê bi guhertoya nû re bixebite, yê din bi ya kevin re bixebite.
Duyemîn: em daneyan li gorî hin pîvanên karsaziyê dabeş dikin. Mînakî, di pergalê de 5 hilberên me hebûn ku di databasa kevn de hatibûn hilanîn. Em şeşemîn di nav peywira karsaziya nû de di databasek nû de cîh dikin. Lê em ê hewceyê Gatewayek API-yê bikin ku dê van daneyan hevdeng bike û xerîdar nîşan bide ku ji ku û çi bigire.
Her du nêzîkatî dixebitin, li gorî rewşê hilbijêrin.
Piştî ku em pê bawer in ku her tişt dixebite, beşa monolîtê ya ku bi strukturên databasa kevn re dixebite dikare were betal kirin.
Pêngava paşîn rakirina strukturên daneya kevn e.
Bi kurtasî, em dikarin bibêjin ku pirsgirêkên me bi databasê re hene: li gorî koda çavkaniyê xebitandina wê dijwar e, parvekirina wê dijwartir e, lê dikare û divê were kirin. Me hin awayan dît ku rê didin me ku em vê yekê bi ewlehî bikin, lê dîsa jî hêsan e ku meriv xeletiyan bi daneyan re ji koda çavkaniyê bike.
Bi koda çavkaniyê re dixebitin
Dema ku me dest bi analîzkirina projeya monolîtîk kir ev e ku diyagrama koda çavkaniyê wekî xuya bû.
Ew bi qasî sê qatan dikare were dabeş kirin. Ev qatek modul, pêvek, karûbar û çalakiyên kesane yên hatî destpêkirin e. Bi rastî, ev xalên têketinê di nav çareseriyek yekparêz de bûn. Hemî wan bi qatek Hevpar bi hişkî hatine girtin. Mantiqa karsaziya wê ya ku karûbar parve dikirin û gelek girêdan hebû. Her karûbar û pêvek heya 10 an bêtir civînên hevpar bikar anîn, li gorî mezinahiya wan û wijdana pêşdebiran.
Em bi şens bûn ku pirtûkxaneyên binesaziyê hebûn ku dikarin ji hev cuda werin bikar anîn.
Carinan rewşek derket holê ku hin tiştên hevpar bi rastî ne girêdayî vê qatê bûn, lê pirtûkxaneyên binesaziyê bûn. Ev bi guherandina navan çareser bû.
Metirsiya herî mezin li ser mijarên sînorkirî bû. Wusa çêbû ku 3-4 çarçove di yek meclîsa hevpar de tevlihev bûn û di nav heman fonksiyonên karsaziyê de hevûdu bikar anîn. Pêwîst bû ku were fam kirin ku ev dikare li ku derê were dabeş kirin û li ser kîjan sînoran, û bi nexşeya vê dabeşkirinê di civînên koda çavkaniyê de çi were kirin.
Me ji bo pêvajoya dabeşkirina kodê gelek qaîdeyên formule kirine.
Yekemîn: Me êdî nedixwest mantiqa karsaziyê di navbera karûbar, çalakî û pêvekan de parve bikin. Me dixwest ku mantiqa karsaziyê di nav mîkroservisan de serbixwe bikin. Ji hêla din ve, mîkroxizmet bi îdeal wekî karûbarên ku bi tevahî serbixwe hene têne fikirîn. Ez bawer dikim ku ev nêzîkatî hinekî bêserûber e, û gihîştina wê dijwar e, ji ber ku, mînakî, karûbarên di C# de dê di her rewşê de bi pirtûkxaneyek standard ve were girêdan. Pergala me bi C# hatiye nivîsandin me hîn teknolojiyên din bikar neaniye. Ji ber vê yekê, me biryar da ku em dikarin meclîsên teknîkî yên hevpar bikar bînin. Ya sereke ev e ku ew perçeyên mantiqa karsaziyê nagirin. Ger we li ser ORM-ya ku hûn bikar tînin pêçekek hêsan heye, wê hingê kopîkirina wê ji karûbarê karûbar pir biha ye.
Tîma me heyranê sêwirana domê ye, ji ber vê yekê mîmariya pîvazê ji me re guncanek mezin bû. Bingeha karûbarên me ne qata gihîştina daneyê ye, lê meclîsek bi mantiqê domainê ye, ku tenê mantiqa karsaziyê dihewîne û bi binesaziyê re têkiliyek tune. Di heman demê de, em dikarin serbixwe meclîsa domainê biguhezînin da ku pirsgirêkên girêdayî çarçoweyan çareser bikin.
Di vê qonaxê de em rastî pirsgirêka xwe ya yekem a cidî hatin. Karûbar neçar bû ku ji meclîsa yek domainê re vebêje, me dixwest ku mantiqê serbixwe bikin, û prensîba DRY li vir me pir asteng kir. Pêşdebiran dixwest ku dersên ji meclîsên cîran ji nû ve bikar bînin da ku ji dubarebûnê dûr nekevin, û wekî encamek, domên dîsa dest bi girêdana bi hev re kirin. Me encam analîz kir û biryar da ku dibe ku pirsgirêk di qada amûra hilanîna koda çavkaniyê de jî hebe. Me depoyek mezin hebû ku tê de hemî koda çavkaniyê vedihewîne. Çareseriya tevahiya projeyê pir dijwar bû ku li ser makîneyek herêmî bicive. Ji ber vê yekê, çareseriyên piçûk ên cihêreng ji bo beşên projeyê hatin afirandin, û kes qedexe kir ku hin kombûnek hevpar an domainê li wan zêde bike û wan ji nû ve bikar bîne. Yekane amûra ku destûr neda me ku em vê yekê bikin vekolîna kodê bû. Lê carinan ew jî têk çû.
Dûv re me dest bi veguheztina modelek bi depoyên cihê kir. Mantiqa karsaziyê êdî ji karûbar ber bi karûbarê ve diherike, domain bi rastî serbixwe bûne. Têkiliyên sînorkirî bi zelaltir têne piştgirî kirin. Em çawa pirtûkxaneyên binesaziyê ji nû ve bikar tînin? Me ew di depoyek cihê de veqetandin, dûv re ew xistin nav pakêtên Nuget, ku me xist nav Artifactory. Bi her guhertinê re, civîn û weşandin bixweber pêk tê.
Karûbarên me dest bi referanskirina pakêtên binesaziya hundurîn bi heman rengî wekî yên derveyî kirin. Em pirtûkxaneyên derveyî ji Nuget dakêşin. Ji bo ku em bi Artifactory re bixebitin, ku me van pakêtan bi cih kir, me du rêveberên pakêtê bikar anîn. Di depoyên piçûk de me Nuget jî bikar anî. Di depoyên bi gelek karûbaran de, me Paket bikar anî, ku di navbera modulan de bêtir hevahengiya guhertoyê peyda dike.
Bi vî rengî, bi xebata li ser koda çavkaniyê, hinekî guheztina mîmariyê û veqetandina depoyan, em karûbarên xwe serbixwetir dikin.
Pirsgirêkên binesaziyê
Piraniya kêmasiyên ku diçin mîkroxizmetan bi binesaziyê ve girêdayî ne. Hûn ê hewceyê bicîhkirina otomatîkî bin, hûn ê hewceyê pirtûkxaneyên nû bin ku binesaziyê bimeşînin.
Sazkirina Manual li derdorên
Di destpêkê de, me çareseriya ji bo hawîrdoran bi destan saz kir. Ji bo otomatîkkirina vê pêvajoyê, me boriyek CI/CD çêkir. Me pêvajoya radestkirina domdar hilbijart ji ber ku bicîhkirina domdar ji hêla pêvajoyên karsaziyê ve hîn ji me re nayê pejirandin. Ji ber vê yekê, şandina ji bo operasyonê bi bişkojkê ve tête kirin, û ji bo ceribandinê - bixweber.
Em Atlassian, Bitbucket ji bo hilanîna koda çavkaniyê û Bamboo ji bo avahiyê bikar tînin. Em hez dikin ku li Cake skrîptên çêkirinê binivîsin ji ber ku ew heman C# ye. Pakêtên amade têne Artifactory, û Ansible bixweber digihîje serverên ceribandinê, piştî ku ew tavilê têne ceribandin.
Têketina veqetandî
Demekê, yek ji ramanên monolîtê peydakirina têketina hevpar bû. Di heman demê de hewce bû ku em fêm bikin ka meriv bi têketinên kesane yên ku li ser dîskê ne çi bikin. Têketinên me li pelên nivîsê têne nivîsandin. Me biryar da ku em stackek standard ELK bikar bînin. Me rasterast bi rêya pêşkêşvanan ji ELK'ê re nenivîsî, lê biryar da ku em ê têketinên nivîsê biguhezînin û nasnameya şopê di wan de wekî nasnameyek binivîsin, navê karûbarê lê zêde bikin, da ku ev têketin paşê bêne pars kirin.
Bi Filebeat re em dikarin tomarên xwe ji pêşkêşkerên, dû re wan veguherînin, Kibana bikar bînin da ku di UI de lêpirsînan ava bikin, û bibînin ka bang çawa di navbera karûbaran de hatiye rêve kirin. Nasnameyên şopandinê ji bo vê yekê pir bikêr in.
Karûbarên peywendîdar ceribandin û xelet kirin
Di destpêkê de, me bi tevahî fêm nekir ka meriv çawa karûbarên ku têne pêşve xistin xelet kirin. Her tişt bi monolîtê re hêsan bû, me ew li ser makîneyek herêmî da meşandin. Di destpêkê de wan hewl da ku bi mîkroxizmetan re heman tiştî bikin, lê carinan ji bo ku hûn mîkroxizmetek bi tevahî bidin destpêkirin hûn hewce ne ku çend kesên din bidin destpêkirin, û ev nerehet e. Me fêm kir ku pêdivî ye ku em biçin modelek ku em li ser makîneya herêmî tenê karûbar an karûbarên ku em dixwazin xelet bikin bihêlin. Karûbarên mayî ji serverên ku veavakirinê bi prod re hevber dikin têne bikar anîn. Piştî xeletkirinê, di dema ceribandinê de, ji bo her peywirê, tenê karûbarên guhertî ji servera testê re têne şandin. Bi vî rengî, çareserî di forma ku ew ê di pêşerojê de di hilberînê de xuya bibe tê ceribandin.
Server hene ku tenê guhertoyên hilberîna karûbaran dimeşînin. Van serveran di bûyera bûyeran de, ji bo kontrolkirina radestkirinê berî bicîhkirinê û ji bo perwerdehiya navxweyî hewce ne.
Me bi karanîna pirtûkxaneya populer Specflow pêvajoyek ceribandina otomatîkî lê zêde kiriye. Ceribandin bixweber bi karanîna NUnit-ê tavilê piştî bicîhkirina ji Ansible ve têne meşandin. Ger vegirtina peywirê bi tevahî otomatîk be, wê hingê hewcedariya ceribandina destan tune. Her çend carinan ceribandina desta ya zêde hîn jî hewce ye. Em etîketan li Jira bikar tînin da ku diyar bikin ka kîjan ceribandin ji bo pirsgirêkek taybetî bimeşînin.
Wekî din, hewcedariya ceribandina barkirinê zêde bûye, berê tenê di rewşên kêm de dihat kirin. Em JMeter bikar tînin da ku ceribandinan bimeşînin, InfluxDB ji bo hilanîna wan, û Grafana ji bo avakirina grafikên pêvajoyê bikar tînin.
Me çi bi dest xist?
Pêşî, me ji têgeha "serbest" xilas kir. Dema ku ev kolos di hawîrdorek hilberînê de hate bicîh kirin, serbestberdanên cinawirên du-mehî derbas bûn, û pêvajoyên karsaziyê bi demkî têkbirin. Naha em karûbaran bi navînî her 1,5 rojan carekê dişoxilînin, wan kom dikin ji ber ku ew piştî pejirandinê diçin xebitandinê.
Di pergala me de têkçûnên kujer nînin. Ger em mîkroxizmetek bi xeletiyek azad bikin, wê hingê fonksiyona ku pê re têkildar dibe têk bibe, û hemî fonksiyonên din dê bandor nebe. Ev pir ezmûna bikarhêner çêtir dike.
Em dikarin şêwaza belavkirinê kontrol bikin. Ger hewce be, hûn dikarin komên karûbaran ji yên mayî yên çareseriyê veqetînin hilbijêrin.
Digel vê yekê, me bi rêzek mezin a çêtirkirinan re pirsgirêk bi girîngî kêm kir. Naha tîmên hilberên me yên cihê hene ku bi hin karûbaran re serbixwe dixebitin. Pêvajoya Scrum jixwe li vir cîhek baş e. Dibe ku tîmek taybetî xwediyê xwedan hilberek cihêreng be ku peywiran jê re destnîşan dike.
Nîqaş
- Microservis ji bo hilweşandina pergalên tevlihev baş in. Di vê pêvajoyê de, em dest pê dikin ku fêm bikin ka di pergala me de çi heye, çi çarçoveyên sînorkirî hene, sînorên wan li ku derê ne. Ev rê dide we ku hûn başbûnên rast di nav modulan de belav bikin û pêşî li tevliheviya kodê bigirin.
- Microservis feydeyên rêxistinî peyda dikin. Ew bi gelemperî tenê wekî mîmarî têne axaftin, lê her mîmarî hewce ye ku hewcedariyên karsaziyê çareser bike, û ne bi serê xwe. Ji ber vê yekê, em dikarin bibêjin ku mîkroxizmet ji bo çareserkirina pirsgirêkan di tîmên piçûk de baş in, ji ber ku Scrum nuha pir populer e.
- Veqetandin pêvajoyek dubare ye. Hûn nekarin serîlêdanek bigirin û bi hêsanî wê li mîkroservisan dabeş bikin. Hilbera encam ne gengaz e ku fonksiyonel be. Dema ku mîkroxizmet têne veqetandin, sûdmend e ku meriv mîrateya heyî ji nû ve binivîsîne, ango, wê veguherîne koda ku em jê hez dikin û di warê fonksiyon û lezê de hewcedariyên karsaziyê çêtir peyda dike.
Hişyariyek piçûk: Mesrefên çûyîna mîkroxizmetan pir girîng in. Ji bo çareserkirina pirsgirêka binesaziyê bi tena serê xwe demek dirêj girt. Ji ber vê yekê heke we serîlêdanek piçûk heye ku hewceyê pîvanek taybetî nake, heya ku we hejmareke mezin xerîdar ji bo baldarî û wextê tîmê we pêşbaziyê nekin, wê hingê dibe ku mîkroxizmet ne yên ku hûn îro hewce ne bin. Ew pir biha ye. Heke hûn pêvajoyê bi mîkroxizmetan re dest pê bikin, wê hingê lêçûn dê di destpêkê de ji ya ku hûn heman projeyê bi pêşkeftina monolîtek dest pê bikin zêdetir be.
PS Çîrokek bêtir hestyarî (û wekî ku ji bo we bixwe ye) - li gorî .
Li vir guhertoya tevahî ya raporê ye.
Source: www.habr.com
