Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.

Selles artiklis räägin, kuidas projekt, millega töötan, muutus suurest monoliidist mikroteenuste kogumiks.

Projekt alustas oma teekonda üsna ammu, 2000. aastate alguses. Esimesed versioonid kirjutati Visual Basic 6-s. Aja jooksul sai selgeks, et selle keele arendamine tulevikus on keeruline, kuna IDE ja keel ise arenesid aeglaselt. 2000. aastate lõpus otsustati liikuda perspektiivikama C#-ni. Uut versiooni kirjutati paralleelselt vana täiendamisega, järjest rohkem koodi oli .NET-is. Backend C#-is oli algselt suunatud teenuse arhitektuurile, kuid arendamise käigus kasutati ühiseid raamatukogusid, mis sisaldasid loogikat, ja teenuseid käivitati ühes protsessis. Tulemuseks oli rakendus, mida me nimetasime "teenusteks mõeldud monoliidiks".

Üks väheseid sellise ühenduse eeliseid oli see, et teenused said üksteist välise API kaudu kutsuda. Oli ilmseid eeltingimusi üleminekuks õigemale teenuse arhitektuurile ja tulevikus ka mikroteenuste arhitektuurile.

Oma dekodeerimistööd alustasime umbes 2015. aastal. Kuigi me ei ole veel saavutanud ideaalset olekut — suur projekt, millest osad on juba raskesti nimetatavad monoliitideks, kuid ka mikroteenusteks nad ei sarnane. Siiski on edusamm märkimisväärne.
Sellest räägin artiklis.

Sisukord

• Arhitektuur ja olemasoleva lahenduse probleemid
• Ootused mikroteenustelt
• Ülemineku probleemid
• Kuidas liikuda monoliidilt mikroteenustele
  • Esimene viis
  • Teine meetod
  • Kolmas meetod
  • Neljas meetod
• Töötamine BDs
  • Olemasolevate tabelite eraldamine
  • Eraldamine ümbertöötamisega
• Töö lähtekoodiga
• Infrastruktuuri probleemid
  • Käsitsi paigaldamine keskkondadesse
  • Eraldi logimine
  • Seotud teenuste testimine ja silumine

Arhitektuur ja olemasoleva lahenduse probleemid

Algne arhitektuur nägi välja järgmine: UI - eraldi rakendus, monoliitne osa kirjutatud Visual Basic 6-s, .NET rakendus oli seotud teenuste kogum, mis töötas üsna suure andmebaasiga.

Endise lahenduse puudused

Üksik veaallikas
Meil oli üksikud tõrkepunkt: .NET rakendus töötas ühes protsessis. Kui mõnes moodulis tekkis tõrge, lakkas kogu rakendus töötamast ja tuli taaskäivitada. Kuna automatiseerime suures koguses protsesse erinevatele kasutajatele, ei saanud kõik nende tõttu mõnda aega tööd teha. Ja programmivea korral ei aidanud ka varukoopia.

Töötlemise järjekord
See puudus on pigem organisatsiooniline. Meie rakenduses on palju kliente, ja kõik nad tahavad, et arendustööd tehtaks võimalikult kiiresti. Varem ei olnud seda paralleelselt teha võimalik ja kõik kliendid pidid järjekorras olema. See protsess tekitas äri seas negatiivset tagasisidet, kuna nad pidid tõestama, et nende ülesanne on väärtuslik. Arendusmeeskond kulutas aega järjekorra korraldamisele. See võttis palju aega ja energiat, ning toode ei saanud lõpuks muutuda nii kiiresti, kui nad sooviksid.

Ebaoptimaalne ressursside kasutamine
Teenuste paigutamisel ühte protsessi kopeerisime alati konfiguratsiooni täielikult serverilt serverile. Soovisime paigutada kõige koormatumad teenused eraldi, et mitte raisata ressursse, ning saavutada paindlikum hallatavus meie deploymendi skeemis.

Kaasaegsete tehnoloogiate rakendamine on keeruline
Loodud arendajatele tuntud probleem: on soov rakendada projekti kaasaegseid tehnoloogiaid, kuid võimalust pole. Suure monoliitse lahenduse korral muutub iga praeguse teegi uuendamine, rääkimata uuele üleminekust, üsna keeruliseks ülesandeks. Peab kaua tõestama tiimijuhile, et see toob rohkem kasu kui kulutatud närvid.

Muudatuste väljaandmise keerukus
See oli kõige tõsisem probleem – andsime välja versioone iga kahe kuu tagant.
Iga väljaanne muutus pangale tõeliseks katastroofiks, vaatamata testimisele ja arendajate pingutustele. Äri mõistis, et neil ei tööta nädala alguses osa funktsionaalsusest. Arendajad mõistsid, et neid ootab ees tõsiste sündmuste nädal.
Soov olukorda muuta oli kõigil.

Ootused mikroteenustelt

Komponentide väljaandmine valmisoleku järgi. Komponentide väljaandmine vastavalt valmisolekule, tänu lahenduse dekodeerimisele ja erinevate protsesside eraldamisele.

Väikesed tootegrupid. See on oluline, sest suure meeskonna juhtimine vanade monoliitide kallal oli keeruline. Selline meeskond pidi töötama rangete protsesside järgi, samas kui rohkem loovust ja sõltumatust oleks olnud soovitav. Seda suudavad endale lubada vaid väiksed meeskonnad.

Teenuste isoleerimine eraldi protsessidesse. Ideaalis oleks soovitud isoleerida konteinerites, kuid suur hulk teenuseid, mis on kirjutatud .NET Frameworkis, töötavad ainult Windowsis. Praegu ilmuvad teenused .NET Core'is, kuid neid on seni veel vähe.

Paindlikkus juurutamisel. Sooviksime kombineerida teenuseid nii, nagu see meile vajalik, mitte nagu kood meid sunnib.

Uute tehnoloogiate kasutamine. See on huvitav iga programmeerija jaoks.

Ülemineku probleemid

Loomulikult, kui monoliiti oleks lihtne mikroteenusteks jagada, ei räägiks sellest konverentsidel ega kirjutataks artikleid. Selles protsessis on palju takistusi, kirjeldan peamisi, mis meid segasid.

Esimene probleem tüüpiline enamikule monoliitidele: äriloogika seotus. Kui kirjutame monoliidi, siis tahame taaskasutada meie klasse, et vältida liigset koodi kirjutamist. Kuid mikroteenustele üleminekul muutub see probleemiks: kogu kood on piisavalt tugevalt seotud ja teenuste eristamine on keeruline.

Tööde alguse hetkel oli meie repositooriumis üle 500 projekti ja üle 700 tuhande koodi rea. See on üsna suur lahendus ja teine probleem. Lihtsalt võtta ja jagada see mikroteenusteks ei olnud võimalik.

Kolmas probleem — vajalikku infrastruktuuri puudumine. Tegelikult tegelesime allika koodi käsitsi kopeerimisega serveritesse.

Kuidas liikuda monoliidilt mikroteenustele

Mikroteenuste eristamine

Esiteks, määrasime endale kohe, et mikroteenuste eristamine on iteratiivne protsess. Meilt nõuti pidevalt, et areneve idee ülesanne tehakse paralleelselt. Kuidas me seda tehniliselt teostame — see on juba meie probleem. Seetõttu olime valmis iteratiivseks protsessiks. Teistmoodi ei ole võimalik, kui teil on suur rakendus ja see ei ole algselt selleks ette valmistatud, et seda ümber kirjutatakse.

Milliseid meetodeid me kasutame mikroteenuste eristamiseks?

Esimene viis — väljastama olemasolevaid mooduleid teenustena. Meie puhul oli õnne, et olid juba loodud teenused, mis töötasid WCF protokolli järgi. Need olid jagatud erinevatesse kogumitesse. Me edasi kandsime need eraldi, lisades igale kogumile väikese käivitamismoduli. See oli kirjutatud suurepärase Topshelf teegi abil, mis võimaldab rakendust käivitada nii teenusena kui ka käsurealt. See on mugav silumise jaoks, kuna ei ole vaja täiendavaid projekte lahenduses.

Teenused olid seotud äriloogikaga, kuna kasutasid ühiseid kogumeid ja töötasid ühise andmebaasiga. Neid oli raske pidada puhasteks mikroteenusteks. Siiski, saime neid teenuseid eraldi välja anda, erinevates protsessides. Isegi see võimaldas vähendada nende omavahelist mõju, leevendades paralleelse arendamise ja ühtse tõrkepunkti probleemi.

Hosti kogum on Program klassis vaid üks rida koodi. Tööd Topshelfiga peitsime me tugiklassi.

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner.Run("RBA.Services.Accounts.Host");

       }
    }
}

Teine viis mikroteenuste eristamiseks: luua neid uute ülesannete lahendamiseks. Kui samal ajal monoliit ei kasva, on see juba suurepärane, see tähendab, et liigume õiges suunas. Uute ülesannete lahendamiseks püüdsime luua eraldi teenuseid. Kui see oli võimalik, siis lõime „kanonilisemaid“ teenuseid, mis haldavad täielikult oma andmemudelit ja eraldi andmebaasi.

Me, nagu paljud, alustasime autentimise ja volitamise teenustega. Need sobivad selleks ideaalselt. Need on sõltumatud, reeglina on neil eraldi andmemudel. Need ei suhtle monoliidiga, vaid vaid monoliit pöördub nende poole, et lahendada teatud ülesandeid. Nendel teenustel saab alustada üleminekut uuele arhitektuurile, siluda neid infrastruktuuri, proovida erinevaid lähenemisviise, mis on seotud võrguteekide jms-ga. Meie organisatsioonis ei ole ühtegi meeskonda, kellel ei õnnestuks luua autentimise teenust.

Kolmas viis mikroteenuste eristamiseks, mida me kasutame, on meie jaoks veidi spetsiifiline. See tähendab äriloogika eraldamist UI-kihist. Meie põhiliides on lauaarvuti rakendus, mis on nagu ka backend kirjutatud C#. Arendajad on aeg-ajalt teinud vigu ja viinud UI-sse looge, mis peaks olema backendis ja taaskasutatav.

Kui vaatame konkreetset näidet UI-osa koodist, siis on näha, et suur osa sellest lahendusest sisaldab endas tõelist äriloogikat, mis on kasulik ka muudes protsessides, mitte ainult UI-vormi koostamiseks.

Tõelisest UI-logikast on seal ainult viimane paar rida. Me viisime selle serverisse, et saaksime seda taaskasutada, vähendades seeläbi UI-d ja saavutades õige arhitektuuri.

Neljas, kõige olulisem viis mikroteenuste eraldamiseks, mis aitab vähendada monoliiti, on olemasolevate teenuste edasiviimine koos ümberehitusega. Kui me toome olemasolevad moodulid sellisena välja, pole tulemus arendajatele alati meelepärane ja äriprotsess võib ajaga vananeda, alates funktsionaalsuse loomisest. Refaktoreerimise kaudu saame toetada uusi äriprotsesse, sest äri nõuded muutuvad pidevalt. Saame parandada algset koodi, eemaldada tuntud defekte ja luua kvaliteetsema andmemudeli. Saame palju eeliseid.

Teenuste eraldamine ümberehitusega on tihedalt seotud piiratud konteksti mõistega. See mõisted on objektorienteeritud projekteerimise termin. See tähistab domeenimudeli osa, kus kõik arusaamiskeele terminid on üheselt määratletud. Vaatame näiteks kindlustuse ja arve konteksti. Meil on monoliitne rakendus ja on vajalik töötada kindlustustes arvega. Ootame, et arendaja leiab teisest kogumist olemasoleva klassi "Arve", teeb viite klassist "Kindlustus" ja me saame töötava koodi. DRY põhimõtet järgides saab ülesanne, kasutades olemasolevat koodi, kiiremini teostatud.

Kokkuvõttes selgub, et arve- ja kindlustuskontekstid on omavahel seotud. Kui tekivad uued nõuded, häirib see seos arendust, suurendades juba nii keerulise äri loogika keerukust. Selle probleemi lahendamiseks tuleb koodis leida piirid kontekstide vahel ja eemaldada nende rikkumised. Näiteks kindlustuse konteksti jaoks võib piisata 20-kohalisest arve numbrist ja arve avamise kuupäevast.

Kuna need piiratud kontekstid tuleb üksteisest eraldada ja alustada mikroteenuste eraldamise protsessi monoliitsest lahendusest, kasutasime lähenemist, kus loodi rakenduses välist API-d. Kui me teadsime, et mõni moodul peab muutuma mikroteenuseks, tegime kohe väljakutseid loogikale, mis kuulub teise piiratud konteksti, väliste kutsungite kaudu. Näiteks REST või WCF kaudu.

Oleme endale kindlaks teinud, et ei väldi koodi, mis nõuab jaotatud tehingute tegemist. Meie puhul oli seda reeglit üsna lihtne järgida. Meil ei ole siiani tekkinud selliseid olukordi, kus tõeliselt vajalikud oleksid ranged jaotatud tehingud — lõppkokkuvõttes on piisav vaheline järjepidevus moodulite vahel.

Vaatame konkreetset näidet. Meil on kontseptsioon orkestrandist — torustik, mis töötleb „taotluse“ üksust. See loob järjestikku kliendi, arve ja pangakaardi. Kui klient ja arve on edukalt loodud, kuid kaardi loomine ebaõnnestub, ei muutu taotlus olekusse „õnnestunud“, vaid jääb olekusse „kaart ei ole loodud“. Tulevikus haarab taustategevus selle üles ja lõpetab. Süsteem on mõnda aega ebasümpaatne, kuid see meid sisuliselt rahuldab.

Kui siiski tekib olukord, kus on vaja kooskõlas hoida osa andmeid, siis tõenäoliselt läheneme teenuse suurendamisele, et seda ühes protsessis töötelda.

Vaatame mikroteenuse eraldamise näidet. Kuidas saame selle suhteliselt ohutult tootmisse viia? Selles näites on meil süsteemi eraldi osa — palgaarvestuse moodul, mille osa koodist tahame muuta mikroteenuseks.

Esimese asjana loome mikroteenuse, kirjutades koodi ümber. Parandame mõned asjad, mis meid ei rahuldanud. Rakendame uusi ärinõudeid tellijalt. Lisame UI ja backend'i vahele API Gateway, mis tagab kõnede edastamise.

Seejärel viime selle konfiguratsiooni tootmisse, kuid pilootseisundis. Enamik kasutajaid töötab endiselt vanade äri protsessidega. Uutele kasutajatele arendame uue versiooni monoliidist, mis seda protsessi enam ei sisalda. Sisuliselt töötab meil pilootprojekti korras monoliidi ja mikroteenuse ühendus.

Eduka pilootprojekti korral mõistame, et uus konfiguratsioon on tõepoolest toimiv, saame vanast monoliidist vabaneda ja jätta uue konfiguratsiooni vana lahenduse asemele.

Kokkuvõttes kasutame praktiliselt kõiki olemasolevaid meetodeid monoliidi lähtekoodi eraldamiseks. Need kõik võimaldavad meil vähendada rakenduse osi ja viia need üle uutele raamatukogudele, luues parema lähtekoodi.

Töötamine BDs

Andmebaasi jagamine on keerulisem kui lähtekoodi jagamine, kuna see sisaldab mitte ainult praegust skeemi, vaid ka kogunenud ajaloolisi andmeid.

Meie andmebaasil, nagu paljudel teistel, oli veel üks oluline puudus — tohutu suurus. Seda andmebaasi kavandati keerulise monoliidi äri loogika kohaselt ning nende tabelite vahel, mis kuuluvad erinevatesse piiratud konteksti, on akumuleerunud seoseid.

Meie puhul, kui kõik halb on kokku tulnud (suur andmebaas, palju seoseid, vahel arusaamatud piirid tabelite vahel), tekkis probleem, millega paljudes suurtes projektides silmitsi seista: jagatud andmebaasi malli rakendamine. Andmeid võeti tabelitest vaate kaudu, replikatsiooni kaudu ja saadeti teistesse süsteemidesse, kus seda replikatsiooni nõuti. Tulemuseks oli see, et me ei saanud tabeliteid eraldi skeemi viia, sest neid kasutati aktiivselt.

Jagamisel aitab meid see piiratud kontekstide eraldamine koodis. See annab meile tavaliselt piisavalt hea ülevaate andmete jagamisest andmebaasi tasandil. Me mõistame, millised tabelid kuuluvad ühte piiratud konteksti ja millised teise.

Me rakendasime kahte globaalset meetodit andmebaasi jagamiseks: olemasolevate tabelite eraldamine ja eraldamine ümberkujundamisega.

Olemasolevate tabelite eraldamine on meetod, mida on hea rakendada, kui andmestruktuur on kvaliteetne, rahuldab ärinõudeid ja kõigile sobib. Sel juhul saame olemasolevad tabelid eraldada eraldi skeemi.

Eraldamine ümberkujundamisega on vajalik, kui äri mudel on oluliselt muutunud ja tabelid ei rahulda meid enam.

Olemasolevate tabelite eraldamine. Peame määratlema, mida me eraldame. Ilma selle teadmiseta ei saa me midagi teha, ja siin aitab meid koodis piiratud konteksti jagamine. Üldiselt, kui õnnestub mõista konteksti piire algkoodis, saab selgeks, millised tabelid peaksid olema eraldamise loendis.

Kujutame ette, et meil on lahendus, kus kaks monoliidi moodulit suhtlevad ühe andmebaasiga. Peame tegema nii, et eraldatavate tabelite osaga suhtleb ainult üks moodul, samas kui teine hakkab sellega suhtlema läbi API. Alguses piisab, kui API kaudu on ainult kirjutamine. See on vajalik tingimus, et saaksime rääkida mikroteenuste sõltumatusest. Lugemise seosed võivad jääda, seni kuni see ei põhjusta suuri probleeme.

Järgmise sammu käigus saame juba eraldada koodiosa, mis töötab eraldatavate tabelitega, ümberkujundamisega või ilma, eraldi mikroteenuseks ja käivitada selle eraldi protsessis, konteineris. See on eraldi teenus, millel on ühendus monoliidi andmebaasiga ja nende tabelitega, mis ei kuulu otseselt sinna. Monoliit suhtleb veel lugemise kaudu eraldatud osaga.

Hiljem eemaldame selle seose, st monoliidi rakenduse andmete lugemine eraldatavatest tabelitest viiakse samuti API-le.

Edasi eraldame üldisest andmebaasist tabelid, millega töötab ainult uus mikroteenus. Saame tabelid viia eraldi skeemi või isegi eraldi füüsilisse andmebaasi. Jääb lugemise seos mikroteenuse ja monoliidi andmebaasi vahel, kuid selles pole midagi hullu; sellises konfiguratsioonis võib see piisavalt kaua elada.

Viimane samm on täielikult eemaldada kõik seosed. Selle korral võib meil olla vajalik andmete migreerimine põhivaatest. Mõnikord soovime taaskasutada mõningaid väliste süsteemide replitseeritavaid andmeid või registrite andmeid mitmes erinevas andmebaasis. Meil esineb seda perioodiliselt.

Üksus üleviidud töötlusega. See meetod sarnaneb väga esimesega, kuid käib vastupidises järjekorras. Meil luuakse kohe uus andmebaas ja uus mikroteenus, mis suhtleb monoliidiga API kaudu. Samas jääb alles andmebaasi tabelite kogum, mille me soovime tulevikus eemaldada. Me ei vaja seda enam, uues mudelis asendasime selle.

Et see skeem töötaks, on meil tõenäoliselt vajalik üleminekuperiood.

Edasi on kaks võimalikku lähenemist.

Esimene: dubleerime kõik andmed uutes ja vanades andmebaasides. Sel juhul tekib meil andmete üleküllus, võivad tekkida sünkroniseerimisprobleemid. Kuid sel juhul saame võtta kaks erinevat klienti. Üks töötab uue versiooniga, teine vana versiooniga.

Teine: jagame andmeid mingi ärimärgi järgi. Näiteks, meil oli süsteemis 5 toodet, mis on salvestatud vanasse andmebaasi. Kuuendat uue ärilise ülesande raames paneme uude andmebaasi. Kuid meil on vaja API Gateway't, mis sünkroniseerib need andmed ja näitab kliendile, kust ja mida võtta.

Mõlemad lähenemised on toimivad, valige sõltuvalt olukorrast.

Pärast seda, kui oleme veendunud, et kõik töötab, saab osa monoliidist, mis töötab vanade andmebaasi struktuuridega, välja lülitada.

Viimane samm on vanade andmestruktuuride eemaldamine.

Kokkuvõtteks võib öelda, et meil on andmebaasidega probleeme: sellega on töötamine keerulisem võrreldes allikakoodiga, eraldamine on raskem, kuid seda on võimalik ja vajalik teha. Oleme leidnud mõned meetodid, mis võimaldavad seda teha piisavalt ohutult, sest andmetes eksida on lihtsam kui allikakoodis.

Töö lähtekoodiga

Nii nägi välja algse koodi skeem, kui me alustasime monoliitprojekti analüüsi.

Seda võib tinglikult jagada kolmeks kihiks. See on käivitatavate moodulite, pluginate, teenuste ja eraldi tegevuste kiht. Tegelikult olid need sisenemisvahendid monoliitsetes lahendustes. Kõik need olid tihedalt seotud Common kihiga. See sisaldas äriloogikat, mida teenused kasutasid ühiselt, ja rohkesti seoseid. Iga teenus ja plugin kasutas kuni 10 ja rohkem common-kogumite, sõltuvalt nende suurusest ja arendajate aususest.

Meil vedas, meil olid infrastruktuuri raamatukogud, mida sai eraldi kasutada.

Mõnikord juhtus, et mõned Common-objektid ei kuulunud tegelikult sellesse kihti, vaid olid infrastruktuuri raamatukogud. See lahendati ümbernimetamise teel.

Enim muret tekitasid piiratud kontekstid. Juhtus, et 3-4 konteksti olid segatud ühte Common-kogumisse ja kasutasid üksteist sama ärifunktsioonide raames. Oli vajalik mõista, kus seda saab jagada ja millistel piiridel, ning mida edasi teha selle jagamise kaardistamisega lähtekoodi kogumitesse.

Formuleerisime mõned reeglid koodi jagamise protsessi jaoks.

Esiteks: me ei soovinud enam äriloogika jagamist teenuste, tegevuste ja pluginatega. Soovisime teha äriloogika mikroteenuste piires sõltumatuks. Teiselt poolt, mikroteenuseid peaks ideaaljuhul käsitlema teenustena, mis eksisteerivad täiesti iseseisvalt. Ma arvan, et see lähenemine on mõnevõrra raiskav ja seda on raske saavutada, kuna näiteks C# teenused on igal juhul ühendatud standardraamatukoguga. Meie süsteem on kirjutatud C#-s, teisi tehnoloogiaid pole seni kasutusele võetud. Seetõttu otsustasime, et saame endale lubada kasutada ühiseid tehnilisi kogumeid. Peamine on, et neis ei tohi olla äriloogika fraktsioone. Kui sul on mugav wrapper ORM-i, mida kasutad, siis selle kopeerimine teenusest teenusesse on väga kulukas.

Meie meeskond on objekt-orienteeritud disaini fänne, seega sobis meile «sibula arhitektuur» suurepäraselt. Meie teenuste aluseks pole andmejuhtimise kiht, vaid domeeniloogikaga töötlemine, mis sisaldab vaid äriloogikat ja on eemaldatud infrastruktuuri seostest. Sel viisil saame eraldi täiustada domeeni töötlust, et lahendada raamistikuga seotud probleeme.

Sellel etapil puutusime kokku esimese tõsise probleemiga. Teenus pidi viitama ühele domeenitöötlusele, kuid loogika soovisime teha sõltumatuks, ja DRY-printsiip takistas meid. Arendajad soovisid vältida dubleerimist ja taaskasutada klasse naaberkomplektidest, mistõttu alustas domeenide omavaheline sidumine uuesti. Analüüsime tulemusi ja otsustasime, et probleem võib peituda ka allika koodi salvestamise struktuuris. Meil oli suur hoidla, kus olid kõik allikakoodid. Projekti lahendust oli väga raske koguda kohalikul masinal. Seetõttu loodi projekti osade jaoks eraldi väiksed lahendused, ja keegi ei keelanud neisse lisada mingit ühiskomplekti või domeenitöötlust ja taaskasutada. Ainsana ei lubanud seda teha koodikontroll, kuid ka see andis vahel tõrkeid.

Siis hakkasime üle minema eraldi hoidlate mudelile. Äriloogika enam ei lekinud teenusest teenusesse, domeenid said tõeliselt sõltumatuks. Piiritletud kontekste toetatakse selgemini. Kuidas me sel perioodil infrastruktuuri raamatukogusid taaskasutame? Me eraldasime need eraldi hoidlasse ja seejärel panime Nuget-pakettidesse, mis asus Artifactorys. Iga muudetud korral toimub kogumine ja avaldamine automaatselt.

Meie teenused hakkasid viitama sisemistele infrastruktuuri pakettidele täpselt nagu välistingimustes. Välistingimuste raamatukogud laadime Nugetist alla. Artifactory tööks, kuhu me need paketid panime, kasutasime kahte pakettide haldurit. Ka väikestes hoidlates kasutasime Nugetit. Mitme teenusega hoidlates kasutasime Paketit, mis tagab modulite versioonide vahel suurema ühtsuse.

Seega, töötades lähtekoodiga, muutes veidi arhitektuuri ja jagades hoidlaid, muudame meie teenused iseseisvamaks.

Infrastruktuuri probleemid

Enamik mikroteenuste ülemineku puudustest on seotud infrastruktuuriga. Teil on vaja automatiseeritud juurutamist, vajalikud on uued lood infrastruktuuri tööks.

Käsitsi paigaldamine keskkondadesse

Alguses seadsime keskkonnanõudeid käsitsi. Selle protsessi automatiseerimiseks lõime CI/CD toru. Valisime pideva toimetamise protsessi, sest pidev juurutamine ei ole meie äriprotsesside seisukohalt praegu vastuvõetav. Seetõttu toimub kasutuselevõtt nupuvajutusega, testimine aga automaatselt.

Kasutame Atlassianit, Bitbucketit lähtekoodide talletamiseks ja Bamboo't koostamiseks. Meile meeldib kirjutada koostamisskripte Cake'is, sest see on sama, mis C#. Artifactorysse tulevad juba valmis paketid ning Ansible jõuab automaatselt testserveritele, kus neid saab kohe testida.

Eraldi logimine

Oma aega, oli monoliidi üheks ideeks tagada ühtne logimine. Me peame ka aru saama, mida teha eraldi logidega, mis asuvad kettal. Logid kirjutatakse meil tekstifailidesse. Otsustasime kasutada standardset ELK stacki. Me ei hakanud ELKi kirjutama otse pakkujate kaudu, vaid otsustasime täiustada tekstilogisid ja salvestada neisse jälgimise ID identificatorina, lisades teenuse nime, et neid logisid hiljem analüüsida.

Filebeati abil saame koguda oma logisid serverid, seejärel neid töödelda, kasutada Kibana't päringute koostamiseks UI-s ja vaadata, kuidas teenuste vahel kutsed toimusid. Sellel aitab oluliselt jälgimise ID.

Seotud teenuste testimine ja silumine

Alguses ei mõistnud me täielikult, kuidas seadistada arendatavaid teenuseid. Monoliidi puhul oli kõik lihtne, käivitasime selle kohalikul masinal. Alguses püüdsime sama teha ka mikroteenustega, kuid mõnikord, et täielikult käivitada üks mikroteenus, peab käivitama ka mitmeid teisi, mis on ebamugav. Mõistsime, et on vaja liikuda mudelile, kus jätame kohalikule masinale ainult teenuse või teenused, mida soovime seadistada. Ülejäänud teenuseid kasutatakse serveritelt, mis on konfiguratsioonilt kooskõlas tootmisserveriga. Pärast seadistamist, testimise käigus antakse igale ülesandele testserveris välja ainult muudetud teenused. Nii testitakse lahendust just selles vormis, milles see tulevikus tootmisse jõuab.

On serverid, millel on ainult tootmisversioonid teenustest. Need serverid on vajalikud hädaolukordade puhul, tarnimise kontrollimiseks enne juurutamist ja sisekoolitusteks.

Lisandunud on automaatsete testimiste protsess populaarses Specflow teegis. Testid käivituvad automaatselt NUnit'i abil otse pärast juurutamist Ansible'i kaudu. Kui ülesande katmine on täielikult automatiseeritud, ei ole käsitsi testimist vajalik. Kuigi mõnikord on siiski vajalik täiendav käsitsi testimine. Konkreetses ülesandes käivitatavate testide määramiseks kasutame Jira-s silte.

Lisaks on kasvanud vajadus koormustestimise järele, mida varem viidi läbi ainult harvade juhtumite puhul. Testide käivitamiseks kasutame JMeterit, nende säilitamiseks InfluxDB-d ja protsessi graafikute koostamiseks Grafana't.

Mida me saavutasime?

Esiteks oleme vabanenud mõistet "väljalase". Kaks kuud kestnud hiiglaslikud väljalasked, mil see masin juurutati tootmiskeskkonnas, rikkuvad ajutiselt äriprotsesse, on kadunud. Praegu juurutame teenuseid keskmiselt iga 1,5 päeva järel, grupeerides need, kuna nad tulevad kasutusele pärast kooskõlastamist.

Meie süsteemis pole fataalseid tõrkeid. Kui oleme välja saanud mikroteenuse, milles on viga, siis seotud funktsionaalsus lakkab toimimast, kuid ülejäänud funktsionaalsus jääb terveks. See parandab kasutajakogemust oluliselt.

Me saame hallata juurutusskeemi. Teenuste rühmad saavad vajadusel eralduda muu lahendusest.

Lisaks oleme oluliselt vähendanud suure tagastustööde järjekorra probleemi. Meil on tekkinud eraldi tootemeeskonnad, mis töötavad sõltumatult osade teenustega. Siin sobib juba hästi Scrumi protsess. Konkreetse meeskonna jaoks võib olla eraldi tooteomanik, kes seab neile ülesandeid.

Elulookirjeldus

• Mikroteenused sobivad hästi keerukate süsteemide dekompositsiooniks. Protsessis hakkame aru saama, mis meie süsteemis on, millised on olemasolevad piiratud kontekstid ja kus need piirid kulgevad. See võimaldab õigesti jaotada täiendused moodulite kaupa ning vältida koodi segadusse ajamist.
• Mikroteenused pakuvad organisatsioonilisi eeliseid. Neist räägitakse sageli ainult arhitektuurina, kuid iga arhitektuur on vajalik ärivajaduste rahuldamiseks, mitte iseenesest. Seetõttu saame öelda, et mikroteenused sobivad väga hästi probleemide lahendamiseks väikeste meeskondadega, arvestades, et Scrum on hetkel väga populaarne.
• Eraldamine on iteratiivne protsess. Ei saa võtta rakendust ja lihtsalt jagada seda mikroteenusteks. Saadud toode ei pruugi olla töökindel. Mikroteenuste eraldamisel on kasulik olemasolev pärand kood ümber kirjutada, et muuta see meie soovide kohaselt ja paremini rahuldada ärivajadusi funktsionaalsuse ja kiirusel.

  Väike hoiatuseks: üleminek mikroteenustele on üsna kulukas. Ainult infrastruktuuriprobleemi lahendamiseks kulus palju aega. Seetõttu, kui teil on väike rakendus, mis ei vaja spetsiifilist skaleerimist, kui teil ei ole suurt hulka kliente, kes võitlevad teie meeskonna tähelepanu ja aja nimel, siis võivad mikroteenused täna olla just see, mida te ei vaja. See on piisavalt kallis. Kui alustada protsessi mikroteenustega, siis kulud alguses on suuremad kui sama projekti alustamine monoliidi arendamisega.

  P.S. Rohkem emotsionaalne jutt (ja justkui isiklikult teile) – lingil.
  Siin on ettekande täisteksts.

Allikas: habr.com