Í þessari grein mun ég tala um hvernig verkefnið sem ég er að vinna að breyttist úr stórum einliða í safn af örþjónustum.
Verkefnið hóf sögu sína fyrir nokkuð löngu síðan, í ársbyrjun 2000. Fyrstu útgáfurnar voru skrifaðar í Visual Basic 6. Með tímanum varð ljóst að þróun á þessu tungumáli yrði erfitt að styðjast við í framtíðinni, þar sem IDE og tungumálið sjálft er illa þróað. Í lok 2000 var ákveðið að skipta yfir í hið efnilegri C#. Nýja útgáfan var skrifuð samhliða endurskoðun á þeirri gömlu, smám saman var skrifaður meira og meira af kóða í .NET. Backend í C# var upphaflega einblínt á þjónustuarkitektúr, en við þróun voru algeng bókasöfn með rökfræði notuð og þjónusta var hleypt af stokkunum í einu ferli. Niðurstaðan var forrit sem við kölluðum „þjónustueininga“.
Einn af fáum kostum þessarar samsetningar var hæfni þjónustu til að hringja hver í aðra í gegnum ytri API. Skýrar forsendur voru fyrir því að skipta yfir í réttari þjónustu og í framtíðinni örþjónustuarkitektúr.
Við hófum vinnu okkar við niðurbrot í kringum 2015. Við höfum ekki enn náð kjörstöðu - það eru enn hluti af stóru verkefni sem varla er hægt að kalla einliða, en þeir líta ekki út eins og örþjónustur heldur. Engu að síður eru framfarirnar umtalsverðar.
Ég mun tala um það í greininni.
efni
Arkitektúr og vandamál núverandi lausnar
Upphaflega leit arkitektúrinn svona út: HÍ er sérstakt forrit, einliti hlutinn er skrifaður í Visual Basic 6, .NET forritið er sett af tengdum þjónustum sem vinna með nokkuð stóran gagnagrunn.
Ókostir fyrri lausnar
Einn bilunarpunktur
Við höfðum einn bilunarpunkt: .NET forritið keyrði í einu ferli. Ef einhver eining mistókst mistókst allt forritið og þurfti að endurræsa það. Þar sem við gerum sjálfvirkan fjölda ferla fyrir mismunandi notendur, vegna bilunar í einum þeirra, gátu allir ekki unnið í nokkurn tíma. Og ef um hugbúnaðarvillu er að ræða, hjálpaði jafnvel öryggisafrit ekki.
Biðröð endurbóta
Þessi galli er frekar skipulagslegur. Umsókn okkar hefur marga viðskiptavini og þeir vilja allir bæta það eins fljótt og auðið er. Áður fyrr var ekki hægt að gera þetta samhliða og allir viðskiptavinir stóðu í röð. Þetta ferli var neikvætt fyrir fyrirtæki vegna þess að þau þurftu að sanna að verkefni þeirra væri dýrmætt. Og þróunarteymið eyddi tíma í að skipuleggja þessa biðröð. Þetta tók mikinn tíma og fyrirhöfn og varan gat á endanum ekki breyst eins hratt og þeir hefðu viljað.
Óákjósanleg nýting auðlinda
Þegar við hýsum þjónustu í einu ferli afrituðum við stillingarnar alltaf algjörlega frá netþjóni til netþjóns. Við vildum setja mest hlaðna þjónustuna sérstaklega til að sóa ekki auðlindum og fá sveigjanlegri stjórn á dreifingarkerfi okkar.
Erfitt að innleiða nútíma tækni
Vandamál sem allir hönnuðir þekkja: það er löngun til að kynna nútíma tækni inn í verkefnið, en það er engin tækifæri. Með stórri einhæfri lausn breytist öll uppfærsla á núverandi bókasafni, svo ekki sé minnst á umskipti yfir í nýtt, í frekar óléttvæg verkefni. Það tekur langan tíma að sanna fyrir liðsstjóranum að þetta muni gefa fleiri bónusa en taugasóun.
Erfiðleikar við að gefa út breytingar
Þetta var alvarlegasta vandamálið - við vorum að gefa út útgáfur á tveggja mánaða fresti.
Hver útgáfa breyttist í alvöru hörmung fyrir bankann, þrátt fyrir prófanir og viðleitni þróunaraðila. Fyrirtækið skildi að í byrjun vikunnar myndi hluti af virkni þess ekki virka. Og teymið skildu að viku alvarlegra atvika biðu þeirra.
Allir höfðu löngun til að breyta ástandinu.
Væntingar frá örþjónustum
Útgáfa íhluta þegar tilbúin. Afhending íhluta þegar tilbúin með því að brjóta niður lausnina og aðskilja mismunandi ferla.
Lítil vöruteymi. Þetta er mikilvægt vegna þess að erfitt var að stjórna stóru teymi sem vann að gamla einstæðunni. Slíkt teymi neyddist til að vinna eftir ströngu ferli, en það vildi meiri sköpunargáfu og sjálfstæði. Aðeins lítil lið höfðu efni á þessu.
Einangrun þjónustu í aðskildum ferlum. Helst myndi ég vilja einangra það í gámum, en fjöldi þjónustu sem er skrifaður í .NET Framework keyrir aðeins undir WindowsÞjónusta byggð á .NET Core er nú að koma fram, en það eru enn fáar af þeim.
Sveigjanleiki í dreifingu. Við viljum sameina þjónustu eins og við þurfum á henni að halda en ekki eins og reglurnar knýja fram þær.
Notkun nýrrar tækni. Þetta er áhugavert fyrir hvaða forritara sem er.
Umskiptivandamál
Auðvitað, ef það væri auðvelt að skipta einliða upp í örþjónustur, væri óþarfi að tala um það á ráðstefnum og skrifa greinar. Það eru margar gildrur í þessu ferli, ég mun lýsa þeim helstu sem hindraði okkur.
Fyrsta vandamálið dæmigert fyrir flesta monoliths: samræmi viðskiptarökfræði. Þegar við skrifum monolith viljum við endurnýta flokkana okkar til að skrifa ekki óþarfa kóða. Og þegar þú ferð yfir í örþjónustur verður þetta vandamál: allur kóðinn er nokkuð þétt tengdur og það er erfitt að aðskilja þjónustuna.
Þegar störf hófust voru yfir 500 verkefni í geymslunni og meira en 700 þúsund línur af kóða. Þetta er frekar stór ákvörðun og annað vandamál. Það var ekki hægt að taka það einfaldlega og skipta því í örþjónustur.
Þriðja vandamálið — skortur á nauðsynlegum innviðum. Reyndar vorum við að afrita frumkóðann handvirkt á netþjónana.
Hvernig á að fara frá monolith yfir í örþjónustur
Útvega örþjónustur
Í fyrsta lagi ákváðum við strax sjálf að aðskilnaður örþjónustu er endurtekið ferli. Okkur var alltaf gert að þróa viðskiptavandamál samhliða. Hvernig við munum útfæra þetta tæknilega er nú þegar vandamál okkar. Þess vegna undirbjuggum við endurtekið ferli. Það virkar ekki á annan hátt ef þú ert með stórt forrit og það er ekki tilbúið til að endurskrifa það í upphafi.
Hvaða aðferðir notum við til að einangra örþjónustur?
Fyrsta leiðin — færa núverandi einingar sem þjónustu. Í þessu sambandi vorum við heppin: það voru þegar skráðar þjónustur sem virkuðu með WCF samskiptareglum. Þeim var skipt í aðskildar samkomur. Við fluttum þá sérstaklega og bættum litlum ræsiforriti við hverja byggingu. Það var skrifað með því að nota hið frábæra Topshelf bókasafn, sem gerir þér kleift að keyra forritið bæði sem þjónustu og sem leikjatölvu. Þetta er þægilegt fyrir villuleit þar sem engin viðbótarverkefni eru nauðsynleg í lausninni.
Þjónustan var tengd samkvæmt viðskiptarökfræði þar sem þær notuðu sameiginlegar samsetningar og unnu með sameiginlegum gagnagrunni. Það væri varla hægt að kalla þær örþjónustur í sinni tæru mynd. Hins vegar gætum við veitt þessa þjónustu sérstaklega, í mismunandi ferlum. Þetta eitt og sér gerði það að verkum að hægt var að draga úr áhrifum þeirra hvert á annað, minnka vandamálið með samhliða þróun og einum bilunarpunkti.
Samsetning með gestgjafanum er bara ein lína af kóða í forritaflokknum. Við földum vinnu með Topshelf í aukabekk.
namespace RBA.Services.Accounts.Host
{
internal class Program
{
private static void Main(string[] args)
{
HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");
}
}
}
Önnur leiðin til að úthluta örþjónustu er: skapa þau til að leysa ný vandamál. Ef á sama tíma vex monolith ekki, þá er þetta nú þegar frábært, sem þýðir að við erum að fara í rétta átt. Til að leysa ný vandamál reyndum við að búa til sérstaka þjónustu. Ef slíkt tækifæri var til staðar, þá bjuggum við til fleiri „kanónískar“ þjónustur sem stjórna algjörlega sínu eigin gagnalíkani, sérstökum gagnagrunni.
Við, eins og margir, byrjuðum með auðkenningar- og heimildaþjónustu. Þeir eru fullkomnir fyrir þetta. Þeir eru sjálfstæðir, að jafnaði hafa þeir sérstakt gagnalíkan. Þeir sjálfir hafa ekki samskipti við einlitinn, aðeins það snýr sér að þeim til að leysa nokkur vandamál. Með því að nota þessar þjónustur geturðu hafið umskipti yfir í nýjan arkitektúr, kemba innviðina á þeim, prófað nokkrar aðferðir sem tengjast netsöfnum osfrv. Við erum ekki með nein teymi í fyrirtækinu okkar sem gætu ekki búið til auðkenningarþjónustu.
Þriðja leiðin til að úthluta örþjónustuSá sem við notum er svolítið sérstakur fyrir okkur. Þetta er að fjarlægja viðskiptarökfræði úr HÍ laginu. Aðalviðmótsforritið okkar er skrifborð; það, eins og bakendinn, er skrifað í C#. Hönnuðir gerðu reglulega mistök og fluttu hluta af rökfræði yfir í notendaviðmótið sem hefði átt að vera til í bakendanum og vera endurnýtt.
Ef þú skoðar raunverulegt dæmi úr kóðanum á HÍ hlutanum, sérðu að megnið af þessari lausn inniheldur raunverulega viðskiptarökfræði sem nýtist í öðrum ferlum, ekki bara til að byggja upp HÍ-formið.
Raunveruleg UI rökfræði er aðeins til staðar í síðustu tveimur línum. Við fluttum það yfir á netþjóninn svo hægt væri að endurnýta það og minnkaði þar með notendaviðmótið og náðum réttum arkitektúr.
Fjórða og mikilvægasta leiðin til að einangra örþjónustur, sem gerir það mögulegt að draga úr einlitinu, er að fjarlægja núverandi þjónustu með vinnslu. Þegar við tökum út núverandi einingar eins og þær eru, er útkoman ekki alltaf að skapi þróunaraðila og viðskiptaferlið gæti hafa orðið úrelt síðan virknin var búin til. Með endurstillingu getum við stutt nýtt viðskiptaferli vegna þess að viðskiptakröfur eru stöðugt að breytast. Við getum bætt frumkóðann, fjarlægt þekkta galla og búið til betra gagnalíkan. Það eru margir kostir sem safnast upp.
Að aðskilja þjónustu frá vinnslu er órjúfanlega tengt hugmyndinni um afmarkað samhengi. Þetta er hugmynd frá Domain Driven Design. Það þýðir hluti af lénslíkaninu þar sem öll hugtök eins tungumáls eru einstaklega skilgreind. Lítum á samhengi trygginga og víxla sem dæmi. Við erum með einhæfa umsókn og við þurfum að vinna með reikninginn í tryggingum. Við gerum ráð fyrir að verktaki finni núverandi reikningsflokk í annarri samsetningu, vísi í hann úr tryggingaflokknum og við munum hafa vinnukóða. DRY meginreglan verður virt, verkefnið verður gert hraðar með því að nota núverandi kóða.
Fyrir vikið kemur í ljós að samhengi reikninga og trygginga tengist. Eftir því sem nýjar kröfur koma fram mun þessi tenging trufla þróun og auka flókið þegar flókið viðskiptarökfræði. Til að leysa þetta vandamál þarftu að finna mörkin milli samhengis í kóðanum og fjarlægja brot þeirra. Til dæmis, í tryggingasamhengi, er vel mögulegt að 20 stafa reikningsnúmer Seðlabanka og dagsetning reikningsins var opnuð nægi.
Til að aðgreina þessi afmörkuðu samhengi frá hvort öðru og hefja ferlið við að aðskilja örþjónustur frá einhæfri lausn, notuðum við nálgun eins og að búa til ytri API innan forritsins. Ef við vissum að einhver eining ætti að verða örþjónusta, einhvern veginn breytt í ferlinu, þá hringdum við strax í rökfræðina sem tilheyrir öðru takmörkuðu samhengi með ytri símtölum. Til dæmis í gegnum REST eða WCF.
Við ákváðum staðfastlega að við myndum ekki forðast kóða sem myndi krefjast dreifðra viðskipta. Í okkar tilviki reyndist frekar auðvelt að fylgja þessari reglu. Við höfum ekki enn lent í aðstæðum þar sem raunverulega er þörf á ströngum dreifðum viðskiptum - endanlegt samræmi milli eininga er alveg nægjanlegt.
Við skulum líta á ákveðið dæmi. Við höfum hugmyndina um hljómsveitarstjóra - leiðsla sem vinnur úr einingu „umsóknarinnar“. Hann stofnar viðskiptavin, reikning og bankakort til skiptis. Ef viðskiptavinur og reikningur eru búnir til með góðum árangri, en ekki tekst að búa til kort, færist forritið ekki í stöðuna „vel heppnuð“ og er áfram í stöðunni „kort ekki búið til“. Í framtíðinni mun bakgrunnsvirkni taka það upp og klára það. Kerfið hefur verið í ósamræmi í nokkurn tíma en við erum almennt sátt við þetta.
Komi upp sú staða að nauðsynlegt sé að vista hluta gagna stöðugt munum við líklegast fara í sameiningu þjónustunnar til að vinna úr henni í einu ferli.
Við skulum skoða dæmi um úthlutun örþjónustu. Hvernig geturðu komið því til framleiðslu tiltölulega örugglega? Í þessu dæmi höfum við sérstakan hluta kerfisins - launaþjónustueiningu, einn af kóðahlutunum sem við viljum búa til örþjónustu.
Fyrst af öllu búum við til örþjónustu með því að endurskrifa kóðann. Við erum að bæta nokkra þætti sem við vorum ekki ánægðir með. Við innleiðum nýjar viðskiptakröfur frá viðskiptavininum. Við bætum við API hlið við tenginguna milli notendaviðmótsins og bakendans, sem mun veita áframsendingu símtala.
Næst sleppum við þessari stillingu í notkun, en í tilraunaástandi. Flestir notendur okkar vinna enn með gamla viðskiptaferla. Fyrir nýja notendur erum við að þróa nýja útgáfu af einhæfa forritinu sem inniheldur ekki lengur þetta ferli. Í meginatriðum erum við með blöndu af einliða og örþjónustu sem starfar sem flugmaður.
Með farsælli flugmaður skiljum við að nýja uppsetningin er örugglega framkvæmanleg, við getum fjarlægt gamla einlitið úr jöfnunni og skilið nýju uppsetninguna eftir í stað gömlu lausnarinnar.
Alls notum við næstum allar núverandi aðferðir til að skipta frumkóða einliða. Öll þau gera okkur kleift að minnka stærð hluta forritsins og þýða þá yfir á ný bókasöfn, sem gerir betri frumkóða.
Vinna með gagnagrunninn
Gagnagrunninum er hægt að skipta verr en frumkóðann, þar sem hann inniheldur ekki aðeins núverandi skema heldur einnig uppsöfnuð söguleg gögn.
Gagnagrunnurinn okkar, eins og margir aðrir, hafði annan mikilvægan galla - gríðarstór stærð hans. Þessi gagnagrunnur var hannaður í samræmi við flókna viðskiptarökfræði einliða, og tengsl söfnuðust upp á milli borða í ýmsum afmörkuðu samhengi.
Í okkar tilfelli, til að toppa öll vandræðin (stór gagnagrunnur, margar tengingar, stundum óljós mörk á milli tafla), kom upp vandamál sem kemur upp í mörgum stórum verkefnum: notkun á sameiginlega gagnagrunnssniðmátinu. Gögn voru tekin úr töflum í gegnum skoðun, í gegnum afritun og send í önnur kerfi þar sem þörf var á þessari afritun. Þar af leiðandi gátum við ekki fært töflurnar í sérstakt skema vegna þess að þær voru virkir notaðar.
Sama skiptingin í takmarkað samhengi í kóðanum hjálpar okkur við aðskilnað. Það gefur okkur venjulega nokkuð góða hugmynd um hvernig við brjótum niður gögnin á gagnagrunnsstigi. Við skiljum hvaða töflur tilheyra einu afmörkuðu samhengi og hverjar öðru.
Við notuðum tvær hnattrænar aðferðir við skiptingu gagnagrunns: skipting á núverandi töflum og skipting með vinnslu.
Að skipta upp núverandi töflum er góð aðferð til að nota ef gagnauppbyggingin er góð, uppfyllir kröfur fyrirtækisins og allir ánægðir með það. Í þessu tilviki getum við aðskilið núverandi töflur í sérstakt skema.
Það þarf deild með vinnslu þegar viðskiptamódelið hefur breyst mikið og töflurnar fullnægja okkur alls ekki lengur.
Að skipta núverandi töflum. Við þurfum að ákveða hvað við munum aðskilja. Án þessarar þekkingar mun ekkert virka og hér mun aðskilnaður afmörkuðu samhengi í kóðanum hjálpa okkur. Að jafnaði, ef þú getur skilið mörk samhengis í frumkóðanum, kemur í ljós hvaða töflur eiga að vera með á listanum fyrir deildina.
Við skulum ímynda okkur að við höfum lausn þar sem tvær monolith einingar hafa samskipti við einn gagnagrunn. Við þurfum að ganga úr skugga um að aðeins ein einingin hafi samskipti við hluta aðskildra taflna og hin byrjar að hafa samskipti við hana í gegnum API. Til að byrja með er nóg að aðeins upptaka fer fram í gegnum API. Þetta er nauðsynlegt skilyrði fyrir því að við getum talað um sjálfstæði smáþjónustu. Lestrartengingar geta haldist svo lengi sem ekkert stórt vandamál er til staðar.
Næsta skref er að við getum aðskilið kóðahlutann sem virkar með aðskildum töflum, með eða án vinnslu, í sérstaka örþjónustu og keyrt hann í sérstöku ferli, ílát. Þetta verður sérstök þjónusta með tengingu við monolith gagnagrunninn og þær töflur sem tengjast honum ekki beint. Mónólítinn hefur enn samskipti við lestur við aftakahlutann.
Síðar munum við fjarlægja þessa tengingu, það er að lesa gögn úr einhæfu forriti frá aðskildum töflum verður einnig flutt yfir í API.
Næst munum við velja úr almenna gagnagrunninum töflurnar sem aðeins nýja örþjónustan virkar með. Við getum fært töflurnar í sérstakt skema eða jafnvel í sérstakan líkamlegan gagnagrunn. Það er enn lestrartenging á milli örþjónustunnar og monolith gagnagrunnsins, en það er ekkert til að hafa áhyggjur af, í þessari uppsetningu getur það lifað í nokkuð langan tíma.
Síðasta skrefið er að fjarlægja allar tengingar alveg. Í þessu tilviki gætum við þurft að flytja gögn úr aðalgagnagrunninum. Stundum viljum við endurnýta nokkur gögn eða möppur sem endurtaka frá ytri kerfum í nokkrum gagnagrunnum. Þetta kemur fyrir okkur reglulega.
Vinnsludeild. Þessi aðferð er mjög svipuð þeirri fyrstu, aðeins í öfugri röð. Við úthlutum strax nýjum gagnagrunni og nýrri örþjónustu sem hefur samskipti við einliðann í gegnum API. En á sama tíma er eftir sett af gagnagrunnstöflum sem við viljum eyða í framtíðinni. Við þurfum það ekki lengur, við skiptum um það í nýju gerðinni.
Til að þetta kerfi virki þurfum við líklega aðlögunartíma.
Þá eru tvær leiðir mögulegar.
First: við afritum öll gögn í nýja og gamla gagnagrunninum. Í þessu tilviki höfum við offramboð á gögnum og samstillingarvandamál gætu komið upp. En við getum tekið tvo mismunandi viðskiptavini. Annar mun vinna með nýju útgáfunni, hinn með gömlu.
Second: við deilum gögnunum í samræmi við sum viðskiptaviðmið. Við vorum til dæmis með 5 vörur í kerfinu sem voru vistaðar í gamla gagnagrunninum. Við setjum þann sjötta innan nýja viðskiptaverkefnisins í nýjan gagnagrunn. En við munum þurfa API gátt sem mun samstilla þessi gögn og sýna viðskiptavininum hvaðan og hvað á að fá.
Báðar aðferðir virka, veldu eftir aðstæðum.
Eftir að við erum viss um að allt virki er hægt að slökkva á þeim hluta einliða sem virkar með gömlum gagnagrunnsbyggingum.
Síðasta skrefið er að fjarlægja gamla gagnaskipulagið.
Til að draga saman getum við sagt að við eigum í vandræðum með gagnagrunninn: það er erfitt að vinna með hann miðað við frumkóðann, það er erfiðara að deila, en það er hægt og ætti að gera það. Við höfum fundið nokkrar leiðir sem gera okkur kleift að gera þetta nokkuð örugglega, en það er samt auðveldara að gera mistök með gögnum en með frumkóða.
Að vinna með frumkóða
Svona leit frumkóðamyndin út þegar við byrjuðum að greina einhæfa verkefnið.
Það má gróflega skipta því í þrjú lög. Þetta er lag af settum einingum, viðbótum, þjónustu og einstökum athöfnum. Reyndar voru þetta aðgangsstaðir innan einhæfrar lausnar. Öll voru þau þétt lokuð með sameiginlegu lagi. Það hafði viðskiptarökfræði sem þjónustan deildi og mikið af tengingum. Hver þjónusta og viðbót notaði allt að 10 eða fleiri algengar samsetningar, allt eftir stærð þeirra og samvisku þróunaraðila.
Við vorum heppin að hafa innviðabókasöfn sem hægt var að nota sérstaklega.
Stundum kom upp sú staða að sumir algengir hlutir tilheyrðu í raun ekki þessu lagi heldur voru innviðasöfn. Þetta var leyst með því að endurnefna.
Stærsta áhyggjuefnið var bundið samhengi. Það gerðist að 3-4 samhengi var blandað saman í einni sameiginlegri samkomu og notuð hvort annað innan sömu viðskiptaaðgerða. Nauðsynlegt var að skilja hvar þetta væri hægt að skipta og eftir hvaða mörkum og hvað ætti að gera næst við að kortleggja þessa skiptingu í frumkóðasamstæður.
Við höfum mótað nokkrar reglur fyrir kóðaskiptingarferlið.
Fyrsta: Við vildum ekki lengur deila viðskiptarökfræði milli þjónustu, starfsemi og viðbóta. Við vildum gera viðskiptarökfræði sjálfstæða innan örþjónustu. Örþjónustur eru hins vegar helst hugsaðar sem þjónustu sem er til algjörlega sjálfstætt. Ég tel að þessi nálgun sé nokkuð eyðsluleg og erfitt að ná því, því td þjónusta í C# verður hvort sem er tengd með venjulegu bókasafni. Kerfið okkar er skrifað í C#; við höfum ekki enn notað aðra tækni. Þess vegna ákváðum við að við hefðum efni á að nota sameiginlegar tæknisamkomur. Aðalatriðið er að þeir innihalda ekki brot af viðskiptarökfræði. Ef þú ert með þæginda umbúðir yfir ORM sem þú ert að nota, þá er mjög dýrt að afrita það frá þjónustu til þjónustu.
Liðið okkar er aðdáandi lénsdrifna hönnunar, svo laukarkitektúr hentaði okkur vel. Grunnurinn að þjónustu okkar er ekki gagnaaðgangslagið, heldur samsetning með lénsrökfræði, sem inniheldur aðeins viðskiptarökfræði og hefur engin tengsl við innviðina. Á sama tíma getum við sjálfstætt breytt lénssamsetningunni til að leysa vandamál sem tengjast ramma.
Á þessu stigi lentum við í fyrsta alvarlega vandamálinu okkar. Þjónustan varð að vísa til eins lénssamsetningar, við vildum gera rökfræðina óháða og DRY meginreglan hamlaði okkur mjög hér. Þróunaraðilar vildu endurnýta flokka frá nálægum samkomum til að forðast tvíverknað og í kjölfarið fóru lén að vera tengd saman aftur. Við greindum niðurstöðurnar og ákváðum að vandamálið liggi kannski líka á sviði frumkóðageymslubúnaðarins. Við vorum með stóra geymslu sem innihélt allan frumkóðann. Lausnin fyrir allt verkefnið var mjög erfitt að setja saman á staðbundinni vél. Þess vegna voru búnar til aðskildar litlar lausnir fyrir hluta verkefnisins og enginn bannaði að bæta einhverjum sameiginlegum eða lénssamsetningum við þær og endurnýta þær. Eina tólið sem leyfði okkur ekki að gera þetta var endurskoðun kóða. En stundum tókst það líka.
Síðan fórum við að færa okkur yfir í líkan með aðskildum geymslum. Viðskiptarökfræði flæðir ekki lengur frá þjónustu til þjónustu, lén eru sannarlega orðin sjálfstæð. Afmarkað samhengi er stutt betur. Hvernig endurnýtum við innviðabókasöfn? Við skildum þá í sérstaka geymslu, settum þá í Nuget pakka, sem við settum í Artifactory. Með öllum breytingum fer samsetning og birting sjálfkrafa fram.
Þjónusta okkar fór að vísa til innri innviðapakka á sama hátt og ytri. Við hleðum niður ytri bókasöfnum frá Nuget. Til að vinna með Artifactory, þar sem við settum þessa pakka, notuðum við tvo pakkastjóra. Í litlum geymslum notuðum við einnig Nuget. Í geymslum með margar þjónustur notuðum við Paket, sem veitir meiri útgáfusamræmi milli eininga.
Þannig, með því að vinna í frumkóðann, breyta aðeins arkitektúrnum og aðskilja geymslurnar, gerum við þjónustu okkar sjálfstæðari.
Innviðavandamál
Flestir gallarnir við að flytja yfir í örþjónustu eru innviðatengdir. Þú þarft sjálfvirka dreifingu, þú þarft ný bókasöfn til að keyra innviðina.
Handvirk uppsetning í umhverfi
Upphaflega settum við upp lausnina fyrir umhverfi handvirkt. Til að gera þetta ferli sjálfvirkt, bjuggum við til CI/CD leiðslu. Við völdum stöðugt afhendingarferlið vegna þess að samfelld dreifing er ekki enn ásættanleg fyrir okkur frá sjónarhóli viðskiptaferla. Þess vegna fer sending til notkunar fram með hnappi og til prófunar - sjálfkrafa.
Við notum Atlassian, Bitbucket til að geyma frumkóða og Bamboo til að byggja. Okkur finnst gaman að skrifa byggingarhandrit í Cake vegna þess að það er það sama og C#. Tilbúnir pakkar koma til Artifactory og Ansible kemst sjálfkrafa á prófunarþjónana, eftir það er hægt að prófa þá strax.
Aðskilin skógarhögg
Einhvern tíma var ein af hugmyndum monolithsins að bjóða upp á sameiginlega skógarhögg. Við þurftum líka að skilja hvað á að gera við einstaka annála sem eru á diskunum. Logarnir okkar eru skrifaðir í textaskrár. Við ákváðum að nota venjulegan ELK stafla. Við skrifuðum ekki beint til ELK í gegnum þjónustuveiturnar, heldur ákváðum að breyta textaskránum og skrifa rakningarauðkennið í þá sem auðkenni og bæta við þjónustuheitinu, svo hægt væri að flokka þessa annála síðar.
Með Filebeat getum við safnað skráningum okkar frá netþjónum, umbreyta þeim síðan, nota Kibana til að smíða fyrirspurnir í notendaviðmótinu og sjá hvernig símtalið var beint á milli þjónustu. Rakningarauðkenni eru mjög gagnleg fyrir þetta.
Prófun og villuleit tengd þjónusta
Upphaflega skildum við ekki að fullu hvernig ætti að kemba þjónustuna sem verið er að þróa. Allt var einfalt með monolith; við keyrðum það á staðbundinni vél. Í fyrstu reyndu þeir að gera slíkt hið sama með örþjónustur, en stundum til að ræsa eina örþjónustu að fullu þarftu að ræsa nokkrar aðrar, og það er óþægilegt. Við áttum okkur á því að við þurfum að fara yfir í líkan þar sem við skiljum aðeins eftir þjónustuna eða þjónustuna sem við viljum kemba. Þjónustan sem eftir er er notuð frá netþjónum sem passa við uppsetninguna með prod. Eftir villuleit, meðan á prófun stendur, fyrir hvert verkefni, eru aðeins breyttar þjónustur gefnar út á prófunarþjóninn. Þannig er lausnin prófuð í því formi sem hún mun birtast í framleiðslu í framtíðinni.
Það eru netþjónar sem keyra aðeins framleiðsluútgáfur af þjónustu. Þessir netþjónar eru nauðsynlegir ef upp koma atvik, til að athuga afhendingu fyrir uppsetningu og fyrir innri þjálfun.
Við höfum bætt við sjálfvirku prófunarferli með því að nota hið vinsæla Specflow bókasafn. Próf keyra sjálfkrafa með NUnit strax eftir uppsetningu frá Ansible. Ef verkefnaþekjan er fullkomlega sjálfvirk, þá er engin þörf á handvirkum prófunum. Þó að stundum þurfi enn frekari handvirk próf. Við notum merki í Jira til að ákvarða hvaða próf eigi að keyra fyrir tiltekið mál.
Að auki hefur þörfin fyrir álagsprófun aukist; áður var það aðeins framkvæmt í mjög sjaldgæfum tilfellum. Við notum JMeter til að keyra próf, InfluxDB til að geyma þau og Grafana til að búa til ferligraf.
Hverju höfum við áorkað?
Í fyrsta lagi losuðum við okkur við hugtakið „útgáfu“. Horfin eru tveggja mánaða voðalegu útgáfurnar þegar þessi kólossi var settur í framleiðsluumhverfi og truflaði viðskiptaferla tímabundið. Núna sendum við þjónustu að meðaltali á 1,5 daga fresti og flokkum hana þar sem hún fer í notkun eftir samþykki.
Það eru engar banvænar bilanir í kerfinu okkar. Ef við gefum út örþjónustu með villu, þá verður virkni tengd henni biluð og öll önnur virkni verður ekki fyrir áhrifum. Þetta bætir notendaupplifunina til muna.
Við getum stjórnað dreifingarmynstrinu. Þú getur valið þjónustuhópa sérstaklega frá restinni af lausninni, ef þörf krefur.
Að auki höfum við dregið verulega úr vandanum með mikilli biðröð af endurbótum. Við erum nú með aðskilin vöruteymi sem vinna með hluta þjónustunnar sjálfstætt. Scrum ferlið passar nú þegar vel hér. Tiltekið teymi getur haft sérstakan vörueiganda sem úthlutar því verkefnum.
Yfirlit
- Örþjónustur henta vel til að brjóta niður flókin kerfi. Í því ferli förum við að skilja hvað er í kerfinu okkar, hvaða takmarkaða samhengi það er, hvar mörk þeirra liggja. Þetta gerir þér kleift að dreifa endurbótum á réttan hátt á milli eininga og koma í veg fyrir rugling á kóða.
- Örþjónusta veitir skipulagslegan ávinning. Oft er aðeins talað um þá sem arkitektúr, en hvaða arkitektúr sem er þarf til að leysa viðskiptaþarfir, en ekki ein og sér. Þess vegna getum við sagt að örþjónustur henti vel til að leysa vandamál í litlum teymum, í ljósi þess að Scrum er mjög vinsælt núna.
- Aðskilnaður er endurtekið ferli. Þú getur ekki tekið forrit og einfaldlega skipt því í örþjónustur. Varan sem myndast er ólíkleg til að vera virk. Þegar örþjónustur eru tileinkaðar er hagkvæmt að endurskrifa núverandi arfleifð, það er að breyta honum í kóða sem okkur líkar og uppfyllir betur þarfir fyrirtækja hvað varðar virkni og hraða.
Lítill fyrirvari: Kostnaðurinn við að fara yfir í örþjónustur er töluverður. Það tók langan tíma að leysa innviðavandann einn. Þannig að ef þú ert með lítið forrit sem krefst ekki sérstakrar mælingar, nema þú sért með mikinn fjölda viðskiptavina sem keppa um athygli og tíma liðsins þíns, þá er örþjónusta kannski ekki það sem þú þarft í dag. Það er frekar dýrt. Ef þú byrjar ferlið með örþjónustu, þá verður kostnaðurinn í upphafi hærri en ef þú byrjar sama verkefni með þróun einliða.
PS Tilfinningafyllri saga (og eins og fyrir þig persónulega) - skv .
Hér er heildarútgáfan af skýrslunni.
Heimild: www.habr.com
