Yn yr erthygl hon, byddaf yn siarad am sut y trawsnewidiodd y prosiect rwy'n gweithio arno o fod yn fonolith mawr i set o ficrowasanaethau.
Dechreuodd y prosiect ei hanes gryn dipyn yn ôl, ar ddechrau 2000. Ysgrifennwyd y fersiynau cyntaf yn Visual Basic 6. Dros amser, daeth yn amlwg y byddai datblygiad yn yr iaith hon yn anodd ei gefnogi yn y dyfodol, ers yr IDE ac mae'r iaith ei hun wedi datblygu'n wael. Ar ddiwedd y 2000au, penderfynwyd newid i'r C# mwy addawol. Ysgrifennwyd y fersiwn newydd ochr yn ochr â'r adolygiad o'r hen un, yn raddol ysgrifennwyd mwy a mwy o god yn .NET. Roedd backend yn C # yn canolbwyntio i ddechrau ar bensaernïaeth gwasanaeth, ond yn ystod y datblygiad, defnyddiwyd llyfrgelloedd cyffredin â rhesymeg, a lansiwyd gwasanaethau mewn un broses. Y canlyniad oedd cais a alwn ni yn “fonolith gwasanaeth.”
Un o ychydig fanteision y cyfuniad hwn oedd gallu gwasanaethau i alw ei gilydd trwy API allanol. Roedd rhagofynion clir ar gyfer trosglwyddo i wasanaeth mwy cywir, ac yn y dyfodol, pensaernïaeth microwasanaeth.
Dechreuon ni ein gwaith ar ddadelfennu tua 2015. Nid ydym wedi cyrraedd cyflwr delfrydol eto - mae rhannau o brosiect mawr o hyd na ellir prin eu galw'n fonolithau, ond nid ydynt yn edrych fel microwasanaethau ychwaith. Serch hynny, mae cynnydd yn sylweddol.
Byddaf yn siarad amdano yn yr erthygl.
Cynnwys
Pensaernïaeth a phroblemau'r ateb presennol
I ddechrau, roedd y bensaernïaeth yn edrych fel hyn: mae'r UI yn gais ar wahân, mae'r rhan monolithig wedi'i ysgrifennu yn Visual Basic 6, mae'r cymhwysiad .NET yn set o wasanaethau cysylltiedig sy'n gweithio gyda chronfa ddata eithaf mawr.
Anfanteision y datrysiad blaenorol
Pwynt sengl o fethiant
Cawsom un pwynt o fethiant: rhedodd y cais .NET mewn un broses. Os methodd unrhyw fodiwl, methodd y rhaglen gyfan a bu'n rhaid ei ailgychwyn. Gan ein bod yn awtomeiddio nifer fawr o brosesau ar gyfer gwahanol ddefnyddwyr, oherwydd methiant yn un ohonynt, ni allai pawb weithio am beth amser. Ac rhag ofn y bydd gwall meddalwedd, nid oedd hyd yn oed copi wrth gefn yn helpu.
Ciw o welliannau
Mae'r anfantais hon braidd yn sefydliadol. Mae gan ein cais lawer o gwsmeriaid, ac maen nhw i gyd eisiau ei wella cyn gynted â phosibl. Yn flaenorol, roedd yn amhosibl gwneud hyn ochr yn ochr, ac roedd pob cwsmer yn sefyll yn unol. Roedd y broses hon yn negyddol i fusnesau oherwydd roedd yn rhaid iddynt brofi bod eu tasg yn werthfawr. A threuliodd y tîm datblygu amser yn trefnu'r ciw hwn. Cymerodd hyn lawer o amser ac ymdrech, ac yn y pen draw ni allai'r cynnyrch newid mor gyflym ag y byddent wedi dymuno.
Defnydd is-optimaidd o adnoddau
Wrth gynnal gwasanaethau mewn un broses, rydym bob amser yn copïo'r ffurfweddiad yn gyfan gwbl o'r gweinydd i'r gweinydd. Roeddem am osod y gwasanaethau sydd wedi'u llwytho fwyaf ar wahân er mwyn peidio â gwastraffu adnoddau a chael rheolaeth fwy hyblyg dros ein cynllun defnyddio.
Anodd rhoi technolegau modern ar waith
Problem sy'n gyfarwydd i bob datblygwr: mae awydd i gyflwyno technolegau modern i'r prosiect, ond nid oes cyfle. Gyda datrysiad monolithig mawr, mae unrhyw ddiweddariad o'r llyfrgell gyfredol, heb sôn am y newid i un newydd, yn troi'n dasg braidd yn ddibwys. Mae'n cymryd amser hir i brofi i'r arweinydd tîm y bydd hyn yn dod â mwy o fonysau na nerfau a wastreffir.
Anhawster cyhoeddi newidiadau
Hon oedd y broblem fwyaf difrifol - roeddem yn rhyddhau datganiadau bob dau fis.
Trodd pob datganiad yn drychineb go iawn i'r banc, er gwaethaf profion ac ymdrechion y datblygwyr. Roedd y busnes yn deall na fyddai rhai o'i swyddogaethau'n gweithio ar ddechrau'r wythnos. Ac roedd y datblygwyr yn deall bod wythnos o ddigwyddiadau difrifol yn aros amdanynt.
Roedd gan bawb awydd i newid y sefyllfa.
Disgwyliadau gan ficrowasanaethau
Cyhoeddi cydrannau pan yn barod. Dosbarthu cydrannau pan fyddant yn barod trwy ddadelfennu'r hydoddiant a gwahanu gwahanol brosesau.
Timau cynnyrch bach. Mae hyn yn bwysig oherwydd roedd tîm mawr yn gweithio ar yr hen fonolith yn anodd ei reoli. Gorfodwyd tîm o'r fath i weithio yn ôl proses lem, ond roedd arnynt eisiau mwy o greadigrwydd ac annibyniaeth. Dim ond timau bach allai fforddio hyn.
Ynysu gwasanaethau mewn prosesau ar wahân. Yn ddelfrydol, roeddwn i eisiau ei ynysu mewn cynwysyddion, ond mae nifer fawr o wasanaethau a ysgrifennwyd yn y Fframwaith .NET yn rhedeg ar Windows yn unig. Mae gwasanaethau sy'n seiliedig ar .NET Core bellach yn ymddangos, ond ychydig ohonynt sydd eto.
Hyblygrwydd lleoli. Hoffem gyfuno gwasanaethau yn y ffordd yr ydym eu hangen, ac nid y ffordd y mae'r cod yn ei orfodi.
Defnydd o dechnolegau newydd. Mae hyn yn ddiddorol i unrhyw raglennydd.
Problemau pontio
Wrth gwrs, pe bai'n hawdd torri monolith yn ficrowasanaethau, ni fyddai angen siarad amdano mewn cynadleddau ac ysgrifennu erthyglau. Mae llawer o beryglon yn y broses hon; disgrifiaf y prif rai a’n rhwystrodd.
Problem gyntaf nodweddiadol ar gyfer y rhan fwyaf o fonolithau: cydlyniad rhesymeg busnes. Pan fyddwn yn ysgrifennu monolith, rydym am ailddefnyddio ein dosbarthiadau er mwyn peidio ag ysgrifennu cod diangen. Ac wrth symud i ficrowasanaethau, mae hyn yn dod yn broblem: mae'r holl god wedi'i gyplysu'n eithaf tynn, ac mae'n anodd gwahanu'r gwasanaethau.
Ar adeg dechrau'r gwaith, roedd gan yr ystorfa fwy na 500 o brosiectau a mwy na 700 mil o linellau cod. Mae hwn yn benderfyniad eithaf mawr a ail broblem. Nid oedd yn bosibl ei gymryd a'i rannu'n ficrowasanaethau.
Trydydd broblem — diffyg seilwaith angenrheidiol. Mewn gwirionedd, roeddem yn copïo'r cod ffynhonnell â llaw i'r gweinyddwyr.
Sut i symud o fonolith i ficrowasanaethau
Darparu Microwasanaethau
Yn gyntaf, fe wnaethom benderfynu ar unwaith drosom ein hunain bod gwahanu microwasanaethau yn broses ailadroddol. Roedd yn ofynnol bob amser i ni ddatblygu problemau busnes ochr yn ochr. Mae sut y byddwn yn gweithredu hyn yn dechnegol eisoes yn broblem i ni. Felly, gwnaethom baratoi ar gyfer proses ailadroddol. Ni fydd yn gweithio mewn unrhyw ffordd arall os oes gennych gais mawr ac nid yw'n barod i gael ei ailysgrifennu i ddechrau.
Pa ddulliau ydyn ni'n eu defnyddio i ynysu microwasanaethau?
Y ffordd gyntaf — symud modiwlau presennol fel gwasanaethau. Yn hyn o beth, roeddem yn ffodus: roedd gwasanaethau cofrestredig eisoes yn gweithio gan ddefnyddio protocol WCF. Gwahanwyd hwy yn gynulliadau ar wahan. Fe wnaethon ni eu cludo ar wahân, gan ychwanegu lansiwr bach at bob adeilad. Fe'i hysgrifennwyd gan ddefnyddio llyfrgell wych Topshelf, sy'n eich galluogi i redeg y rhaglen fel gwasanaeth ac fel consol. Mae hyn yn gyfleus ar gyfer dadfygio gan nad oes angen unrhyw brosiectau ychwanegol yn yr ateb.
Cysylltwyd y gwasanaethau yn unol â rhesymeg busnes, gan eu bod yn defnyddio gwasanaethau cyffredin ac yn gweithio gyda chronfa ddata gyffredin. Prin y gellid eu galw'n ficrowasanaethau yn eu ffurf bur. Fodd bynnag, gallem ddarparu’r gwasanaethau hyn ar wahân, mewn prosesau gwahanol. Roedd hyn yn unig yn ei gwneud hi'n bosibl lleihau eu dylanwad ar ei gilydd, gan leihau'r broblem gyda datblygiad cyfochrog ac un pwynt methiant.
Dim ond un llinell o god yn y dosbarth Rhaglen yw cydosod gyda'r gwesteiwr. Fe wnaethon ni guddio gwaith gyda Topshelf mewn dosbarth ategol.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
Yr ail ffordd i ddyrannu microwasanaethau yw: eu creu i ddatrys problemau newydd. Os nad yw'r monolith yn tyfu ar yr un pryd, mae hyn eisoes yn rhagorol, sy'n golygu ein bod yn symud i'r cyfeiriad cywir. Er mwyn datrys problemau newydd, rydym yn ceisio creu gwasanaethau ar wahân. Pe bai cyfle o’r fath, yna fe wnaethom greu mwy o wasanaethau “canonaidd” sy’n rheoli eu model data eu hunain yn llwyr, sef cronfa ddata ar wahân.
Fe wnaethom ni, fel llawer, ddechrau gyda gwasanaethau dilysu ac awdurdodi. Maent yn berffaith ar gyfer hyn. Maent yn annibynnol, fel rheol, mae ganddynt fodel data ar wahân. Nid ydynt eu hunain yn rhyngweithio â'r monolith, dim ond mae'n troi atynt i ddatrys rhai problemau. Gan ddefnyddio'r gwasanaethau hyn, gallwch chi ddechrau'r newid i bensaernïaeth newydd, dadfygio'r seilwaith arnyn nhw, rhoi cynnig ar rai dulliau sy'n ymwneud â llyfrgelloedd rhwydwaith, ac ati. Nid oes gennym unrhyw dimau yn ein sefydliad na allent greu gwasanaeth dilysu.
Y drydedd ffordd i ddyrannu microwasanaethauMae'r un rydyn ni'n ei ddefnyddio ychydig yn benodol i ni. Dyma ddileu rhesymeg busnes o'r haen UI. Ein prif gais UI yw bwrdd gwaith; mae, fel yr ôl-wyneb, wedi'i ysgrifennu yn C #. Roedd y datblygwyr yn gwneud camgymeriadau o bryd i'w gilydd ac yn trosglwyddo rhannau o resymeg i'r UI a ddylai fod wedi bodoli yn y backend a chael eu hailddefnyddio.
Os edrychwch ar enghraifft wirioneddol o god y rhan UI, gallwch weld bod y rhan fwyaf o'r datrysiad hwn yn cynnwys rhesymeg busnes go iawn sy'n ddefnyddiol mewn prosesau eraill, nid yn unig ar gyfer adeiladu'r ffurflen UI.
Dim ond yn y cwpl o linellau olaf y mae'r rhesymeg UI go iawn yno. Fe wnaethom ei drosglwyddo i'r gweinydd fel y gellid ei ailddefnyddio, a thrwy hynny leihau'r UI a chyflawni'r bensaernïaeth gywir.
Y bedwaredd ffordd a'r pwysicaf o ynysu microwasanaethau, sy'n ei gwneud hi'n bosibl lleihau'r monolith, yw dileu'r gwasanaethau presennol gyda phrosesu. Pan fyddwn yn cymryd modiwlau sy'n bodoli eisoes, nid yw'r canlyniad bob amser at ddant y datblygwyr, ac efallai bod y broses fusnes wedi dyddio ers i'r swyddogaeth gael ei chreu. Gydag ailffactorio, gallwn gefnogi proses fusnes newydd oherwydd bod gofynion busnes yn newid yn gyson. Gallwn wella'r cod ffynhonnell, dileu diffygion hysbys, a chreu model data gwell. Mae llawer o fanteision yn cronni.
Mae cysylltiad annatod rhwng gwahanu gwasanaethau a phrosesu a'r cysyniad o gyd-destun ffiniol. Mae hwn yn gysyniad o Domain Driven Design. Mae'n golygu adran o'r model parth lle mae holl dermau un iaith wedi'u diffinio'n unigryw. Gadewch i ni edrych ar gyd-destun yswiriant a biliau fel enghraifft. Mae gennym gais monolithig, ac mae angen inni weithio gyda'r cyfrif mewn yswiriant. Disgwyliwn i'r datblygwr ddod o hyd i ddosbarth Cyfrif presennol mewn gwasanaeth arall, cyfeirio ato o'r dosbarth Yswiriant, a bydd gennym god gweithio. Bydd yr egwyddor SYCH yn cael ei barchu, bydd y dasg yn cael ei gwneud yn gyflymach trwy ddefnyddio'r cod presennol.
O ganlyniad, mae'n ymddangos bod cyd-destunau cyfrifon ac yswiriant yn gysylltiedig. Wrth i ofynion newydd ddod i'r amlwg, bydd y cyplu hwn yn ymyrryd â datblygiad, gan gynyddu cymhlethdod rhesymeg busnes sydd eisoes yn gymhleth. I ddatrys y broblem hon, mae angen ichi ddod o hyd i'r ffiniau rhwng cyd-destunau yn y cod a chael gwared ar eu troseddau. Er enghraifft, yng nghyd-destun yswiriant, mae'n eithaf posibl y bydd rhif cyfrif Banc Canolog 20 digid a dyddiad agor y cyfrif yn ddigonol.
Er mwyn gwahanu'r cyd-destunau ffiniol hyn oddi wrth ei gilydd a dechrau'r broses o wahanu microwasanaethau oddi wrth ddatrysiad monolithig, gwnaethom ddefnyddio dull fel creu APIs allanol o fewn y cymhwysiad. Pe baem yn gwybod y dylai rhyw fodiwl ddod yn ficrowasanaeth, wedi'i addasu rywsut o fewn y broses, yna gwnaethom alwadau ar unwaith i'r rhesymeg sy'n perthyn i gyd-destun cyfyngedig arall trwy alwadau allanol. Er enghraifft, trwy REST neu WCF.
Fe wnaethom benderfynu’n bendant na fyddem yn osgoi cod a fyddai’n gofyn am drafodion dosbarthedig. Yn ein hachos ni, roedd yn eithaf hawdd dilyn y rheol hon. Nid ydym eto wedi dod ar draws sefyllfaoedd lle mae gwir angen trafodion gwasgaredig llym - mae'r cysondeb terfynol rhwng modiwlau yn eithaf digonol.
Gadewch i ni edrych ar enghraifft benodol. Mae gennym y cysyniad o gerddorfawr - piblinell sy'n prosesu endid y “cais”. Mae'n creu cleient, cyfrif a cherdyn banc yn eu tro. Os yw'r cleient a'r cyfrif yn cael eu creu'n llwyddiannus, ond bod creu'r cerdyn yn methu, nid yw'r cais yn symud i'r statws “llwyddiannus” ac yn aros yn y statws “cerdyn heb ei greu”. Yn y dyfodol, bydd gweithgaredd cefndirol yn ei godi a'i orffen. Mae’r system wedi bod mewn cyflwr o anghysondeb ers peth amser, ond rydym yn fodlon ar hyn ar y cyfan.
Os cyfyd sefyllfa pan fydd angen cadw rhan o'r data yn gyson, byddwn yn fwy na thebyg yn mynd am gydgrynhoi'r gwasanaeth er mwyn ei brosesu mewn un broses.
Gadewch i ni edrych ar enghraifft o ddyrannu microwasanaeth. Sut allwch chi ddod ag ef i gynhyrchu yn gymharol ddiogel? Yn yr enghraifft hon, mae gennym ran ar wahân o'r system - modiwl gwasanaeth cyflogres, yr hoffem wneud microwasanaeth yn un o'r adrannau cod ohono.
Yn gyntaf oll, rydym yn creu microwasanaeth trwy ailysgrifennu'r cod. Rydym yn gwella rhai agweddau nad oeddem yn hapus â hwy. Rydym yn gweithredu gofynion busnes newydd gan y cwsmer. Rydym yn ychwanegu Porth API i'r cysylltiad rhwng yr UI a'r backend, a fydd yn darparu anfon galwadau ymlaen.
Nesaf, rydym yn rhyddhau'r cyfluniad hwn ar waith, ond mewn cyflwr peilot. Mae'r rhan fwyaf o'n defnyddwyr yn dal i weithio gyda hen brosesau busnes. Ar gyfer defnyddwyr newydd, rydym yn datblygu fersiwn newydd o'r cymhwysiad monolithig nad yw bellach yn cynnwys y broses hon. Yn y bôn, mae gennym gyfuniad o fonolith a microwasanaeth yn gweithio fel peilot.
Gyda chynllun peilot llwyddiannus, rydym yn deall bod y cyfluniad newydd yn wir yn ymarferol, gallwn dynnu'r hen monolith o'r hafaliad a gadael y cyfluniad newydd yn lle'r hen ddatrysiad.
Yn gyfan gwbl, rydym yn defnyddio bron pob dull presennol ar gyfer hollti cod ffynhonnell monolith. Mae pob un ohonynt yn caniatáu inni leihau maint rhannau o'r rhaglen a'u cyfieithu i lyfrgelloedd newydd, gan wneud cod ffynhonnell gwell.
Gweithio gyda'r gronfa ddata
Gellir rhannu'r gronfa ddata yn waeth na'r cod ffynhonnell, gan ei bod yn cynnwys nid yn unig y sgema cyfredol, ond hefyd data hanesyddol cronedig.
Roedd gan ein cronfa ddata, fel llawer o rai eraill, anfantais bwysig arall - ei maint enfawr. Cynlluniwyd y gronfa ddata hon yn unol â rhesymeg fusnes gymhleth monolith, a chododd perthnasoedd rhwng y tablau o wahanol gyd-destunau terfyn.
Yn ein hachos ni, i ben yr holl drafferthion (cronfa ddata fawr, llawer o gysylltiadau, weithiau ffiniau aneglur rhwng tablau), cododd problem sy'n digwydd mewn llawer o brosiectau mawr: y defnydd o'r templed cronfa ddata a rennir. Cymerwyd data o dablau trwy olwg, trwy ddyblygiad, a'i drosglwyddo i systemau eraill lle'r oedd angen yr atgynhyrchu hwn. O ganlyniad, ni allem symud y tablau i mewn i sgema ar wahân oherwydd eu bod yn cael eu defnyddio'n weithredol.
Mae'r un rhaniad i gyd-destunau cyfyngedig yn y cod yn ein helpu i wahanu. Fel arfer mae'n rhoi syniad eithaf da i ni o sut rydym yn dadansoddi'r data ar lefel y gronfa ddata. Rydym yn deall pa dablau sy'n perthyn i un cyd-destun ffiniol a pha rai i'r llall.
Defnyddiwyd dau ddull byd-eang o rannu cronfeydd data: rhannu tablau presennol a rhannu â phrosesu.
Mae rhannu tablau presennol yn ddull da i'w ddefnyddio os yw'r strwythur data yn dda, yn bodloni gofynion busnes, a phawb yn hapus ag ef. Yn yr achos hwn, gallwn wahanu tablau presennol yn sgema ar wahân.
Mae angen adran gyda phrosesu pan fo'r model busnes wedi newid yn fawr, ac nid yw'r tablau bellach yn ein bodloni o gwbl.
Hollti byrddau presennol. Mae angen inni benderfynu beth y byddwn yn ei wahanu. Heb y wybodaeth hon, ni fydd dim yn gweithio, ac yma bydd gwahanu cyd-destunau ffiniol yn y cod yn ein helpu. Fel rheol, os gallwch ddeall ffiniau cyd-destunau yn y cod ffynhonnell, daw'n amlwg pa dablau y dylid eu cynnwys yn y rhestr ar gyfer yr adran.
Gadewch i ni ddychmygu bod gennym ateb lle mae dau fodiwl monolith yn rhyngweithio ag un gronfa ddata. Mae angen i ni sicrhau mai dim ond un modiwl sy'n rhyngweithio â'r adran o dablau ar wahân, a'r llall yn dechrau rhyngweithio ag ef trwy'r API. I ddechrau, mae'n ddigon mai dim ond recordio sy'n cael ei wneud trwy'r API. Mae hwn yn amod angenrheidiol inni siarad am annibyniaeth microwasanaethau. Gall cysylltiadau darllen aros cyn belled nad oes problem fawr.
Y cam nesaf yw y gallwn wahanu'r adran o'r cod sy'n gweithio gyda thablau wedi'u gwahanu, gyda phrosesu neu hebddo, yn ficrowasanaeth ar wahân a'i redeg mewn proses ar wahân, sef cynhwysydd. Bydd hwn yn wasanaeth ar wahân gyda chysylltiad â'r gronfa ddata monolith a'r tablau hynny nad ydynt yn ymwneud yn uniongyrchol ag ef. Mae'r monolith yn dal i ryngweithio ar gyfer darllen gyda'r rhan datodadwy.
Yn ddiweddarach byddwn yn dileu'r cysylltiad hwn, hynny yw, bydd darllen data o gais monolithig o dablau wedi'u gwahanu hefyd yn cael eu trosglwyddo i'r API.
Nesaf, byddwn yn dewis o'r gronfa ddata gyffredinol y tablau y mae'r microwasanaeth newydd yn unig yn gweithio gyda nhw. Gallwn symud y tablau i sgema ar wahân neu hyd yn oed i gronfa ddata ffisegol ar wahân. Mae cysylltiad darllen o hyd rhwng y microservice a'r gronfa ddata monolith, ond nid oes dim i boeni amdano, yn y cyfluniad hwn gall fyw am amser eithaf hir.
Y cam olaf yw dileu pob cysylltiad yn llwyr. Yn yr achos hwn, efallai y bydd angen i ni fudo data o'r brif gronfa ddata. Weithiau rydym am ailddefnyddio rhywfaint o ddata neu gyfeiriaduron a atgynhyrchwyd o systemau allanol mewn sawl cronfa ddata. Mae hyn yn digwydd i ni o bryd i'w gilydd.
Adran brosesu. Mae'r dull hwn yn debyg iawn i'r un cyntaf, dim ond yn y drefn arall. Rydym yn dyrannu cronfa ddata newydd ar unwaith a microwasanaeth newydd sy'n rhyngweithio â'r monolith trwy API. Ond ar yr un pryd, erys set o dablau cronfa ddata yr ydym am eu dileu yn y dyfodol. Nid oes ei angen arnom mwyach; fe wnaethom ei ddisodli yn y model newydd.
Er mwyn i’r cynllun hwn weithio, mae’n debygol y bydd angen cyfnod pontio arnom.
Yna mae dau ddull posibl.
Cyntaf: rydym yn dyblygu'r holl ddata yn y cronfeydd data hen a newydd. Yn yr achos hwn, mae gennym ddata dileu swyddi a gall problemau cydamseru godi. Ond gallwn gymryd dau gleient gwahanol. Bydd un yn gweithio gyda'r fersiwn newydd, a'r llall gyda'r hen un.
Ail: rydym yn rhannu'r data yn ôl rhai meini prawf busnes. Er enghraifft, roedd gennym 5 cynnyrch yn y system a oedd yn cael eu storio yn yr hen gronfa ddata. Rydym yn gosod y chweched un o fewn y dasg busnes newydd mewn cronfa ddata newydd. Ond bydd angen Porth API arnom a fydd yn cydamseru'r data hwn ac yn dangos i'r cleient o ble a beth i'w gael.
Mae'r ddau ddull yn gweithio, dewiswch yn dibynnu ar y sefyllfa.
Ar ôl i ni fod yn siŵr bod popeth yn gweithio, gellir analluogi'r rhan o'r monolith sy'n gweithio gyda hen strwythurau cronfa ddata.
Y cam olaf yw cael gwared ar yr hen strwythurau data.
I grynhoi, gallwn ddweud bod gennym ni broblemau gyda'r gronfa ddata: mae'n anodd gweithio gydag ef o'i gymharu â'r cod ffynhonnell, mae'n anoddach ei rannu, ond gellir a dylid ei wneud. Rydym wedi dod o hyd i rai ffyrdd sy'n ein galluogi i wneud hyn yn eithaf diogel, ond mae'n dal yn haws gwneud camgymeriadau gyda data na gyda'r cod ffynhonnell.
Gweithio gyda chod ffynhonnell
Dyma sut olwg oedd ar y diagram cod ffynhonnell pan ddechreuon ni ddadansoddi'r prosiect monolithig.
Gellir ei rannu'n fras yn dair haen. Dyma haen o fodiwlau, ategion, gwasanaethau a gweithgareddau unigol a lansiwyd. Mewn gwirionedd, pwyntiau mynediad o fewn datrysiad monolithig oedd y rhain. Roedd pob un ohonynt wedi'u selio'n dynn â haen Gyffredin. Roedd ganddo resymeg fusnes yr oedd y gwasanaethau'n ei rhannu a llawer o gysylltiadau. Roedd pob gwasanaeth ac ategyn yn defnyddio hyd at 10 neu fwy o gynulliadau cyffredin, yn dibynnu ar eu maint a chydwybod y datblygwyr.
Roeddem yn ffodus i gael llyfrgelloedd seilwaith y gellid eu defnyddio ar wahân.
Weithiau cododd sefyllfa pan nad oedd rhai gwrthrychau cyffredin yn perthyn i'r haen hon mewn gwirionedd, ond yn llyfrgelloedd seilwaith. Datryswyd hyn trwy ailenwi.
Y pryder mwyaf oedd cyd-destunau cyfyngedig. Digwyddodd bod 3-4 cyd-destun yn gymysg mewn un Cynulliad Cyffredin ac yn defnyddio ei gilydd o fewn yr un swyddogaethau busnes. Roedd angen deall lle y gellid ei rannu ac ar hyd pa ffiniau, a beth i'w wneud nesaf wrth fapio'r rhaniad hwn yn gynulliadau cod ffynhonnell.
Rydym wedi llunio nifer o reolau ar gyfer y broses hollti cod.
Y cyntaf: Nid oeddem bellach eisiau rhannu rhesymeg busnes rhwng gwasanaethau, gweithgareddau ac ategion. Roeddem am wneud rhesymeg busnes yn annibynnol o fewn microwasanaethau. Mae microwasanaethau, ar y llaw arall, yn ddelfrydol yn cael eu hystyried yn wasanaethau sy'n bodoli'n gwbl annibynnol. Credaf fod y dull hwn braidd yn wastraffus, ac mae’n anodd ei gyflawni, oherwydd, er enghraifft, bydd gwasanaethau yn C# beth bynnag yn cael eu cysylltu gan lyfrgell safonol. Mae ein system wedi'i hysgrifennu yn C#; nid ydym wedi defnyddio technolegau eraill eto. Felly, penderfynasom y gallem fforddio defnyddio gwasanaethau technegol cyffredin. Y prif beth yw nad ydynt yn cynnwys unrhyw ddarnau o resymeg busnes. Os oes gennych chi ddeunydd lapio cyfleustra dros yr ORM rydych chi'n ei ddefnyddio, yna mae ei gopïo o wasanaeth i wasanaeth yn ddrud iawn.
Mae ein tîm yn gefnogwr o ddylunio sy'n cael ei yrru gan barth, felly roedd pensaernïaeth winwnsyn yn ffit wych i ni. Nid yr haen mynediad data yw sail ein gwasanaethau, ond cynulliad â rhesymeg parth, sy'n cynnwys rhesymeg busnes yn unig ac nad oes ganddo unrhyw gysylltiadau â'r seilwaith. Ar yr un pryd, gallwn addasu'r cynulliad parth yn annibynnol i ddatrys problemau sy'n ymwneud â fframweithiau.
Ar y cam hwn daethom ar draws ein problem ddifrifol gyntaf. Roedd yn rhaid i'r gwasanaeth gyfeirio at un cynulliad parth, roeddem am wneud y rhesymeg yn annibynnol, ac roedd yr egwyddor SYCH yn ein rhwystro yn fawr yma. Roedd y datblygwyr eisiau ailddefnyddio dosbarthiadau o gynulliadau cyfagos i osgoi dyblygu, ac o ganlyniad, dechreuodd parthau gael eu cysylltu â'i gilydd eto. Fe wnaethom ddadansoddi'r canlyniadau a phenderfynu efallai bod y broblem hefyd yn gorwedd yn ardal y ddyfais storio cod ffynhonnell. Roedd gennym ystorfa fawr yn cynnwys yr holl god ffynhonnell. Roedd yr Ateb ar gyfer y prosiect cyfan yn anodd iawn i'w ymgynnull ar beiriant lleol. Felly, crëwyd datrysiadau bach ar wahân ar gyfer rhannau o'r prosiect, ac ni waharddodd neb ychwanegu rhywfaint o gynulliad cyffredin neu barth atynt a'u hailddefnyddio. Yr unig offeryn nad oedd yn caniatáu i ni wneud hyn oedd adolygu cod. Ond weithiau fe fethodd hefyd.
Yna dechreuon ni symud i fodel gyda storfeydd ar wahân. Nid yw rhesymeg busnes bellach yn llifo o wasanaeth i wasanaeth, mae parthau wedi dod yn wirioneddol annibynnol. Cefnogir cyd-destunau ffiniol yn gliriach. Sut mae ailddefnyddio llyfrgelloedd seilwaith? Fe wnaethon ni eu gwahanu i ystorfa ar wahân, yna eu rhoi mewn pecynnau Nuget, y gwnaethom eu rhoi yn Artifactory. Gydag unrhyw newid, mae cydosod a chyhoeddi yn digwydd yn awtomatig.
Dechreuodd ein gwasanaethau gyfeirio at becynnau seilwaith mewnol yn yr un modd â phecynnau allanol. Rydym yn lawrlwytho llyfrgelloedd allanol o Nuget. I weithio gydag Artifactory, lle gosodwyd y pecynnau hyn, fe wnaethom ddefnyddio dau reolwr pecyn. Mewn storfeydd bach fe wnaethom hefyd ddefnyddio Nuget. Mewn storfeydd gyda gwasanaethau lluosog, fe wnaethom ddefnyddio Paket, sy'n darparu mwy o gysondeb fersiwn rhwng modiwlau.
Felly, trwy weithio ar y cod ffynhonnell, newid y bensaernïaeth ychydig a gwahanu'r ystorfeydd, rydym yn gwneud ein gwasanaethau'n fwy annibynnol.
Problemau seilwaith
Mae'r rhan fwyaf o'r anfanteision i symud i ficrowasanaethau yn ymwneud â seilwaith. Bydd angen defnydd awtomataidd arnoch, bydd angen llyfrgelloedd newydd arnoch i redeg y seilwaith.
Gosod â llaw mewn amgylcheddau
I ddechrau, fe wnaethom osod yr ateb ar gyfer amgylcheddau â llaw. Er mwyn awtomeiddio'r broses hon, rydym wedi creu piblinell CI/CD. Dewisasom y broses gyflenwi barhaus oherwydd nid yw defnydd parhaus yn dderbyniol i ni eto o safbwynt prosesau busnes. Felly, mae anfon ar gyfer gweithrediad yn cael ei wneud gan ddefnyddio botwm, ac ar gyfer profi - yn awtomatig.
Rydym yn defnyddio Atlassian, Bitbucket ar gyfer storio cod ffynhonnell a Bambŵ ar gyfer adeiladu. Rydyn ni'n hoffi ysgrifennu sgriptiau adeiladu yn Cacen oherwydd mae'r un peth â C#. Daw pecynnau parod i Artifactory, ac mae Ansible yn cyrraedd y gweinyddwyr prawf yn awtomatig, ac ar ôl hynny gellir eu profi ar unwaith.
Logio ar wahân
Ar un adeg, un o syniadau'r monolith oedd darparu boncyffion ar y cyd. Roedd angen i ni hefyd ddeall beth i'w wneud gyda'r logiau unigol sydd ar y disgiau. Ysgrifennir ein logiau i ffeiliau testun. Fe benderfynon ni ddefnyddio pentwr ELK safonol. Ni wnaethom ysgrifennu at ELK yn uniongyrchol trwy'r darparwyr, ond penderfynwyd y byddem yn addasu'r logiau testun ac yn ysgrifennu'r ID olrhain ynddynt fel dynodwr, gan ychwanegu enw'r gwasanaeth, fel y gellid dosrannu'r logiau hyn yn ddiweddarach.
Gan ddefnyddio Filebeat, rydym yn cael y cyfle i gasglu ein logiau o weinyddion, yna eu trawsnewid, defnyddio Kibana i adeiladu ymholiadau yn yr UI a gweld sut aeth yr alwad rhwng gwasanaethau. Mae Trace ID yn helpu llawer gyda hyn.
Profi a dadfygio gwasanaethau cysylltiedig
I ddechrau, nid oeddem yn deall yn iawn sut i ddadfygio'r gwasanaethau a oedd yn cael eu datblygu. Roedd popeth yn syml gyda'r monolith; fe wnaethon ni ei redeg ar beiriant lleol. Ar y dechrau fe wnaethon nhw geisio gwneud yr un peth gyda microwasanaethau, ond weithiau i lansio un microwasanaeth yn llawn mae angen i chi lansio sawl un arall, ac mae hyn yn anghyfleus. Sylweddolom fod angen i ni symud i fodel lle rydym yn gadael ar y peiriant lleol dim ond y gwasanaeth neu'r gwasanaethau yr ydym am eu dadfygio. Defnyddir y gwasanaethau sy'n weddill o weinyddion sy'n cyd-fynd â'r ffurfweddiad â prod. Ar ôl dadfygio, yn ystod y profion, ar gyfer pob tasg, dim ond y gwasanaethau newydd a roddir i'r gweinydd prawf. Felly, mae'r ateb yn cael ei brofi yn y ffurf y bydd yn ymddangos yn y cynhyrchiad yn y dyfodol.
Mae yna weinyddion sydd ond yn rhedeg fersiynau cynhyrchu o wasanaethau. Mae angen y gweinyddion hyn rhag ofn y bydd digwyddiadau, i wirio danfoniad cyn defnyddio ac ar gyfer hyfforddiant mewnol.
Rydym wedi ychwanegu proses brofi awtomataidd gan ddefnyddio'r llyfrgell Specflow boblogaidd. Mae profion yn rhedeg yn awtomatig gan ddefnyddio NUnit yn syth ar ôl eu defnyddio o Ansible. Os yw cwmpas y dasg yn gwbl awtomatig, yna nid oes angen profi â llaw. Er weithiau mae angen profion llaw ychwanegol o hyd. Rydym yn defnyddio tagiau yn Jira i benderfynu pa brofion i'w rhedeg ar gyfer mater penodol.
Yn ogystal, mae'r angen am brofi llwyth wedi cynyddu; yn flaenorol dim ond mewn achosion prin y'i cynhaliwyd. Rydym yn defnyddio JMeter i redeg profion, InfluxDB i'w storio, a Grafana i adeiladu graffiau proses.
Beth ydym ni wedi'i gyflawni?
Yn gyntaf, cawsom wared ar y cysyniad o “rhyddhau”. Mae'r datganiadau gwrthun o ddau fis wedi mynd pan gafodd y colossus hwn ei ddefnyddio mewn amgylchedd cynhyrchu, gan amharu ar brosesau busnes dros dro. Nawr rydym yn defnyddio gwasanaethau bob 1,5 diwrnod ar gyfartaledd, gan eu grwpio oherwydd eu bod yn dod i rym ar ôl eu cymeradwyo.
Nid oes unrhyw fethiannau angheuol yn ein system. Os byddwn yn rhyddhau microwasanaeth gyda nam, yna bydd y swyddogaeth sy'n gysylltiedig ag ef yn cael ei dorri, ac ni fydd yr holl swyddogaethau eraill yn cael eu heffeithio. Mae hyn yn gwella profiad y defnyddiwr yn fawr.
Gallwn reoli'r patrwm lleoli. Gallwch ddewis grwpiau o wasanaethau ar wahân i weddill yr ateb, os oes angen.
Yn ogystal, rydym wedi lleihau'r broblem yn sylweddol gyda chiw mawr o welliannau. Mae gennym bellach dimau cynnyrch ar wahân sy'n gweithio gyda rhai o'r gwasanaethau yn annibynnol. Mae'r broses Scrum eisoes yn ffitio'n dda yma. Efallai y bydd gan dîm penodol Berchennog Cynnyrch ar wahân sy'n aseinio tasgau iddo.
Crynodeb
- Mae microwasanaethau yn addas iawn ar gyfer dadelfennu systemau cymhleth. Yn y broses, rydym yn dechrau deall beth sydd yn ein system, pa gyd-destunau cyfyngedig sydd, a ble mae eu ffiniau. Mae hyn yn caniatáu ichi ddosbarthu gwelliannau'n gywir ymhlith modiwlau ac atal dryswch cod.
- Mae microwasanaethau yn darparu buddion sefydliadol. Yn aml, dim ond fel pensaernïaeth y sonnir amdanynt, ond mae angen unrhyw bensaernïaeth i ddatrys anghenion busnes, ac nid ar ei phen ei hun. Felly, gallwn ddweud bod microwasanaethau yn addas iawn ar gyfer datrys problemau mewn timau bach, o ystyried bod Scrum yn boblogaidd iawn nawr.
- Mae gwahanu yn broses ailadroddol. Ni allwch gymryd cais a'i rannu'n ficrowasanaethau. Mae'r cynnyrch canlyniadol yn annhebygol o fod yn ymarferol. Wrth neilltuo microwasanaethau, mae'n fuddiol ailysgrifennu'r etifeddiaeth bresennol, hynny yw, ei droi'n god yr ydym yn ei hoffi ac sy'n diwallu anghenion busnes yn well o ran ymarferoldeb a chyflymder.
Cafeat bach: Mae costau symud i ficrowasanaethau yn eithaf sylweddol. Cymerodd amser hir i ddatrys y broblem seilwaith yn unig. Felly os oes gennych chi gymhwysiad bach nad oes angen ei raddio'n benodol, oni bai bod gennych chi nifer fawr o gwsmeriaid yn cystadlu am sylw ac amser eich tîm, yna efallai nad microwasanaethau yw'r hyn sydd ei angen arnoch chi heddiw. Mae'n eithaf drud. Os byddwch chi'n dechrau'r broses gyda microwasanaethau, yna bydd y costau i ddechrau yn uwch na phe baech chi'n dechrau'r un prosiect gyda datblygiad monolith.
ON Stori fwy emosiynol (ac fel petai i chi yn bersonol) - yn ôl .
Dyma fersiwn llawn yr adroddiad.
Ffynhonnell: hab.com