{"id":35906,"date":"2019-10-31T22:07:29","date_gmt":"2019-10-31T19:07:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/perehod-ot-monolita-k-mikroservisam-istoriya-i-praktika\/"},"modified":"2019-10-31T22:07:29","modified_gmt":"2019-10-31T19:07:29","slug":"perehod-ot-monolita-k-mikroservisam-istoriya-i-praktika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/perehod-ot-monolita-k-mikroservisam-istoriya-i-praktika","title":{"rendered":"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Selles artiklis r\u00e4\u00e4gin, kuidas projekt, millega t\u00f6\u00f6tan, muutus suurest monoliidist mikroteenuste kogumiks.<\/p>\n<p>Projekt alustas oma teekonda \u00fcsna 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\u00f5pus otsustati liikuda perspektiivikama C#-ni. Uut versiooni kirjutati paralleelselt vana t\u00e4iendamisega, j\u00e4rjest rohkem koodi oli .NET-is. Backend C#-is oli algselt suunatud teenuse arhitektuurile, kuid arendamise k\u00e4igus kasutati \u00fchiseid raamatukogusid, mis sisaldasid loogikat, ja teenuseid k\u00e4ivitati \u00fches protsessis. Tulemuseks oli rakendus, mida me nimetasime \"teenusteks m\u00f5eldud monoliidiks\". <\/p>\n<p>\u00dcks v\u00e4heseid sellise \u00fchenduse eeliseid oli see, et teenused said \u00fcksteist v\u00e4lise API kaudu kutsuda. Oli ilmseid eeltingimusi \u00fcleminekuks \u00f5igemale teenuse arhitektuurile ja tulevikus ka mikroteenuste arhitektuurile. <\/p>\n<p>Oma dekodeerimist\u00f6\u00f6d alustasime umbes 2015. aastal. Kuigi me ei ole veel saavutanud ideaalset olekut \u2014 suur projekt, millest osad on juba raskesti nimetatavad monoliitideks, kuid ka mikroteenusteks nad ei sarnane. Siiski on edusamm m\u00e4rkimisv\u00e4\u00e4rne. <br \/>\nSellest r\u00e4\u00e4gin artiklis.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/132bb4ea6b9dbcdd202ee090f2b86289.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Sisukord<\/h3>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#1\"> Arhitektuur ja olemasoleva lahenduse probleemid<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#2\">Ootused mikroteenustelt<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#3\">\u00dclemineku probleemid<\/a><\/noindex><\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"#4\">Kuidas liikuda monoliidilt mikroteenustele<\/a><\/noindex>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#5\">Esimene viis<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#6\">Teine meetod<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#7\">Kolmas meetod<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#8\">Neljas meetod<\/a><\/noindex><\/li>\n<\/ul>\n<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#9\">T\u00f6\u00f6tamine BDs<\/a><\/noindex>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#10\">Olemasolevate tabelite eraldamine<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#11\">Eraldamine \u00fcmbert\u00f6\u00f6tamisega<\/a><\/noindex><\/li>\n<\/ul>\n<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#12\">T\u00f6\u00f6 l\u00e4htekoodiga<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#13\">Infrastruktuuri probleemid<\/a><\/noindex>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#16\">K\u00e4sitsi paigaldamine keskkondadesse<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#14\">Eraldi logimine<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#15\">Seotud teenuste testimine ja silumine<\/a><\/noindex><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"1\"><\/a><\/noindex><b><\/p>\n<h3>Arhitektuur ja olemasoleva lahenduse probleemid<\/h3>\n<p><\/b><br \/>\nAlgne arhitektuur n\u00e4gi v\u00e4lja j\u00e4rgmine: UI - eraldi rakendus, monoliitne osa kirjutatud Visual Basic 6-s, .NET rakendus oli seotud teenuste kogum, mis t\u00f6\u00f6tas \u00fcsna suure andmebaasiga.<\/p>\n<p><b>Endise lahenduse puudused<\/b><\/p>\n<p><u>\u00dcksik veaallikas<\/u><br \/>\nMeil oli \u00fcksikud t\u00f5rkepunkt: .NET rakendus t\u00f6\u00f6tas \u00fches protsessis. Kui m\u00f5nes moodulis tekkis t\u00f5rge, lakkas kogu rakendus t\u00f6\u00f6tamast ja tuli taask\u00e4ivitada. Kuna automatiseerime suures koguses protsesse erinevatele kasutajatele, ei saanud k\u00f5ik nende t\u00f5ttu m\u00f5nda aega t\u00f6\u00f6d teha. Ja programmivea korral ei aidanud ka varukoopia. <\/p>\n<p><u>T\u00f6\u00f6tlemise j\u00e4rjekord<\/u><br \/>\nSee puudus on pigem organisatsiooniline. Meie rakenduses on palju kliente, ja k\u00f5ik nad tahavad, et arendust\u00f6\u00f6d tehtaks v\u00f5imalikult kiiresti. Varem ei olnud seda paralleelselt teha v\u00f5imalik ja k\u00f5ik kliendid pidid j\u00e4rjekorras olema. See protsess tekitas \u00e4ri seas negatiivset tagasisidet, kuna nad pidid t\u00f5estama, et nende \u00fclesanne on v\u00e4\u00e4rtuslik. Arendusmeeskond kulutas aega j\u00e4rjekorra korraldamisele. See v\u00f5ttis palju aega ja energiat, ning toode ei saanud l\u00f5puks muutuda nii kiiresti, kui nad sooviksid.<\/p>\n<p><u>Ebaoptimaalne ressursside kasutamine<\/u><br \/>\nTeenuste paigutamisel \u00fchte protsessi kopeerisime alati konfiguratsiooni t\u00e4ielikult serverilt serverile. Soovisime paigutada k\u00f5ige koormatumad teenused eraldi, et mitte raisata ressursse, ning saavutada paindlikum hallatavus meie deploymendi skeemis.<\/p>\n<p><u>Kaasaegsete tehnoloogiate rakendamine on keeruline<\/u><br \/>\nLoodud arendajatele tuntud probleem: on soov rakendada projekti kaasaegseid tehnoloogiaid, kuid v\u00f5imalust pole. Suure monoliitse lahenduse korral muutub iga praeguse teegi uuendamine, r\u00e4\u00e4kimata uuele \u00fcleminekust, \u00fcsna keeruliseks \u00fclesandeks. Peab kaua t\u00f5estama tiimijuhile, et see toob rohkem kasu kui kulutatud n\u00e4rvid. <\/p>\n<p><u>Muudatuste v\u00e4ljaandmise keerukus<\/u><br \/>\nSee oli k\u00f5ige t\u00f5sisem probleem \u2013 andsime v\u00e4lja versioone iga kahe kuu tagant. <br \/>\nIga v\u00e4ljaanne muutus pangale t\u00f5eliseks katastroofiks, vaatamata testimisele ja arendajate pingutustele. \u00c4ri m\u00f5istis, et neil ei t\u00f6\u00f6ta n\u00e4dala alguses osa funktsionaalsusest. Arendajad m\u00f5istsid, et neid ootab ees t\u00f5siste s\u00fcndmuste n\u00e4dal. <br \/>\nSoov olukorda muuta oli k\u00f5igil. <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"2\"><\/a><\/noindex><b><\/p>\n<h3>Ootused mikroteenustelt<\/h3>\n<p><\/b><br \/>\n<u>Komponentide v\u00e4ljaandmine valmisoleku j\u00e4rgi. <\/u>Komponentide v\u00e4ljaandmine vastavalt valmisolekule, t\u00e4nu lahenduse dekodeerimisele ja erinevate protsesside eraldamisele.<\/p>\n<p><u>V\u00e4ikesed tootegrupid.<\/u> See on oluline, sest suure meeskonna juhtimine vanade monoliitide kallal oli keeruline. Selline meeskond pidi t\u00f6\u00f6tama rangete protsesside j\u00e4rgi, samas kui rohkem loovust ja s\u00f5ltumatust oleks olnud soovitav. Seda suudavad endale lubada vaid v\u00e4iksed meeskonnad.<\/p>\n<p><u>Teenuste isoleerimine eraldi protsessidesse.<\/u> Ideaalis oleks soovitud isoleerida konteinerites, kuid suur hulk teenuseid, mis on kirjutatud .NET Frameworkis, t\u00f6\u00f6tavad ainult Windowsis. Praegu ilmuvad teenused .NET Core'is, kuid neid on seni veel v\u00e4he.<\/p>\n<p><u>Paindlikkus juurutamisel.<\/u> Sooviksime kombineerida teenuseid nii, nagu see meile vajalik, mitte nagu kood meid sunnib.<\/p>\n<p><u>Uute tehnoloogiate kasutamine.<\/u> See on huvitav iga programmeerija jaoks.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"3\"><\/a><\/noindex><b><\/p>\n<h3>\u00dclemineku probleemid<\/h3>\n<p><\/b><br \/>\nLoomulikult, kui monoliiti oleks lihtne mikroteenusteks jagada, ei r\u00e4\u00e4giks sellest konverentsidel ega kirjutataks artikleid. Selles protsessis on palju takistusi, kirjeldan peamisi, mis meid segasid.<\/p>\n<p><b>Esimene probleem<\/b> t\u00fc\u00fcpiline enamikule monoliitidele: \u00e4riloogika seotus. Kui kirjutame monoliidi, siis tahame taaskasutada meie klasse, et v\u00e4ltida liigset koodi kirjutamist. Kuid mikroteenustele \u00fcleminekul muutub see probleemiks: kogu kood on piisavalt tugevalt seotud ja teenuste eristamine on keeruline.<\/p>\n<p>T\u00f6\u00f6de alguse hetkel oli meie repositooriumis \u00fcle 500 projekti ja \u00fcle 700 tuhande koodi rea. See on \u00fcsna suur lahendus ja <b>teine probleem<\/b>. Lihtsalt v\u00f5tta ja jagada see mikroteenusteks ei olnud v\u00f5imalik.<\/p>\n<p><b>Kolmas probleem<\/b> \u2014 vajalikku infrastruktuuri puudumine. Tegelikult tegelesime allika koodi k\u00e4sitsi kopeerimisega serveritesse.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"4\"><\/a><\/noindex><b><\/p>\n<h3>Kuidas liikuda monoliidilt mikroteenustele<\/h3>\n<p><\/b><br \/>\n<u>Mikroteenuste eristamine<\/u><\/p>\n<p>Esiteks, m\u00e4\u00e4rasime endale kohe, et mikroteenuste eristamine on iteratiivne protsess. Meilt n\u00f5uti pidevalt, et areneve idee \u00fclesanne tehakse paralleelselt. Kuidas me seda tehniliselt teostame \u2014 see on juba meie probleem. Seet\u00f5ttu olime valmis iteratiivseks protsessiks. Teistmoodi ei ole v\u00f5imalik, kui teil on suur rakendus ja see ei ole algselt selleks ette valmistatud, et seda \u00fcmber kirjutatakse.<\/p>\n<p>Milliseid meetodeid me kasutame mikroteenuste eristamiseks?<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"5\"><\/a><\/noindex><b>Esimene viis <\/b>\u2014 v\u00e4ljastama olemasolevaid mooduleid teenustena. Meie puhul oli \u00f5nne, et olid juba loodud teenused, mis t\u00f6\u00f6tasid WCF protokolli j\u00e4rgi. Need olid jagatud erinevatesse kogumitesse. Me edasi kandsime need eraldi, lisades igale kogumile v\u00e4ikese k\u00e4ivitamismoduli. See oli kirjutatud suurep\u00e4rase Topshelf teegi abil, mis v\u00f5imaldab rakendust k\u00e4ivitada nii teenusena kui ka k\u00e4surealt. See on mugav silumise jaoks, kuna ei ole vaja t\u00e4iendavaid projekte lahenduses.<\/p>\n<p>Teenused olid seotud \u00e4riloogikaga, kuna kasutasid \u00fchiseid kogumeid ja t\u00f6\u00f6tasid \u00fchise andmebaasiga. Neid oli raske pidada puhasteks mikroteenusteks. Siiski, saime neid teenuseid eraldi v\u00e4lja anda, erinevates protsessides. Isegi see v\u00f5imaldas v\u00e4hendada nende omavahelist m\u00f5ju, leevendades paralleelse arendamise ja \u00fchtse t\u00f5rkepunkti probleemi.<\/p>\n<p>Hosti kogum on Program klassis vaid \u00fcks rida koodi. T\u00f6\u00f6d Topshelfiga peitsime me tugiklassi.<\/p>\n<pre><code class=\"plaintext\">namespace RBA.Services.Accounts.Host\n{\n   internal class Program\n   {\n      private static void Main(string[] args)\n      {\n        HostRunner.Run(\"RBA.Services.Accounts.Host\");\n\n       }\n    }\n}\n<\/code><\/pre>\n<p>\n<noindex><a rel=\"nofollow\" name=\"6\"><\/a><\/noindex><b>Teine viis mikroteenuste eristamiseks:<\/b> luua neid uute \u00fclesannete lahendamiseks. Kui samal ajal monoliit ei kasva, on see juba suurep\u00e4rane, see t\u00e4hendab, et liigume \u00f5iges suunas. Uute \u00fclesannete lahendamiseks p\u00fc\u00fcdsime luua eraldi teenuseid. Kui see oli v\u00f5imalik, siis l\u00f5ime \u201ekanonilisemaid\u201c teenuseid, mis haldavad t\u00e4ielikult oma andmemudelit ja eraldi andmebaasi. <\/p>\n<p>Me, nagu paljud, alustasime autentimise ja volitamise teenustega. Need sobivad selleks ideaalselt. Need on s\u00f5ltumatud, reeglina on neil eraldi andmemudel. Need ei suhtle monoliidiga, vaid vaid monoliit p\u00f6\u00f6rdub nende poole, et lahendada teatud \u00fclesandeid. Nendel teenustel saab alustada \u00fcleminekut uuele arhitektuurile, siluda neid infrastruktuuri, proovida erinevaid l\u00e4henemisviise, mis on seotud v\u00f5rguteekide jms-ga. Meie organisatsioonis ei ole \u00fchtegi meeskonda, kellel ei \u00f5nnestuks luua autentimise teenust. <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"7\"><\/a><\/noindex><b>Kolmas viis mikroteenuste eristamiseks<\/b>, mida me kasutame, on meie jaoks veidi spetsiifiline. See t\u00e4hendab \u00e4riloogika eraldamist UI-kihist. Meie p\u00f5hiliides 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. <\/p>\n<p>Kui vaatame konkreetset n\u00e4idet UI-osa koodist, siis on n\u00e4ha, et suur osa sellest lahendusest sisaldab endas t\u00f5elist \u00e4riloogikat, mis on kasulik ka muudes protsessides, mitte ainult UI-vormi koostamiseks. <\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/74c7b90ff94b343816ab3ac2fa0673c6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT\u00f5elisest UI-logikast on seal ainult viimane paar rida. Me viisime selle serverisse, et saaksime seda taaskasutada, v\u00e4hendades seel\u00e4bi UI-d ja saavutades \u00f5ige arhitektuuri.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"8\"><\/a><\/noindex><b>Neljas, k\u00f5ige olulisem viis mikroteenuste eraldamiseks<\/b>, mis aitab v\u00e4hendada monoliiti, on olemasolevate teenuste edasiviimine koos \u00fcmberehitusega. Kui me toome olemasolevad moodulid sellisena v\u00e4lja, pole tulemus arendajatele alati meelep\u00e4rane ja \u00e4riprotsess v\u00f5ib ajaga vananeda, alates funktsionaalsuse loomisest. Refaktoreerimise kaudu saame toetada uusi \u00e4riprotsesse, sest \u00e4ri n\u00f5uded muutuvad pidevalt. Saame parandada algset koodi, eemaldada tuntud defekte ja luua kvaliteetsema andmemudeli. Saame palju eeliseid.<\/p>\n<p>Teenuste eraldamine \u00fcmberehitusega on tihedalt seotud piiratud konteksti m\u00f5istega. See m\u00f5isted on objektorienteeritud projekteerimise termin. See t\u00e4histab domeenimudeli osa, kus k\u00f5ik arusaamiskeele terminid on \u00fcheselt m\u00e4\u00e4ratletud. Vaatame n\u00e4iteks kindlustuse ja arve konteksti. Meil on monoliitne rakendus ja on vajalik t\u00f6\u00f6tada kindlustustes arvega. Ootame, et arendaja leiab teisest kogumist olemasoleva klassi \"Arve\", teeb viite klassist \"Kindlustus\" ja me saame t\u00f6\u00f6tava koodi. DRY p\u00f5him\u00f5tet j\u00e4rgides saab \u00fclesanne, kasutades olemasolevat koodi, kiiremini teostatud.<\/p>\n<p>Kokkuv\u00f5ttes selgub, et arve- ja kindlustuskontekstid on omavahel seotud. Kui tekivad uued n\u00f5uded, h\u00e4irib see seos arendust, suurendades juba nii keerulise \u00e4ri loogika keerukust. Selle probleemi lahendamiseks tuleb koodis leida piirid kontekstide vahel ja eemaldada nende rikkumised. N\u00e4iteks kindlustuse konteksti jaoks v\u00f5ib piisata 20-kohalisest arve numbrist ja arve avamise kuup\u00e4evast. <\/p>\n<p>Kuna need piiratud kontekstid tuleb \u00fcksteisest eraldada ja alustada mikroteenuste eraldamise protsessi monoliitsest lahendusest, kasutasime l\u00e4henemist, kus loodi rakenduses v\u00e4list API-d. Kui me teadsime, et m\u00f5ni moodul peab muutuma mikroteenuseks, tegime kohe v\u00e4ljakutseid loogikale, mis kuulub teise piiratud konteksti, v\u00e4liste kutsungite kaudu. N\u00e4iteks REST v\u00f5i WCF kaudu.<\/p>\n<p>Oleme endale kindlaks teinud, et ei v\u00e4ldi koodi, mis n\u00f5uab jaotatud tehingute tegemist. Meie puhul oli seda reeglit \u00fcsna lihtne j\u00e4rgida. Meil ei ole siiani tekkinud selliseid olukordi, kus t\u00f5eliselt vajalikud oleksid ranged jaotatud tehingud \u2014 l\u00f5ppkokkuv\u00f5ttes on piisav vaheline j\u00e4rjepidevus moodulite vahel.<\/p>\n<p>Vaatame konkreetset n\u00e4idet. Meil on kontseptsioon orkestrandist \u2014 torustik, mis t\u00f6\u00f6tleb \u201etaotluse\u201c \u00fcksust. See loob j\u00e4rjestikku kliendi, arve ja pangakaardi. Kui klient ja arve on edukalt loodud, kuid kaardi loomine eba\u00f5nnestub, ei muutu taotlus olekusse \u201e\u00f5nnestunud\u201c, vaid j\u00e4\u00e4b olekusse \u201ekaart ei ole loodud\u201c. Tulevikus haarab taustategevus selle \u00fcles ja l\u00f5petab. S\u00fcsteem on m\u00f5nda aega ebas\u00fcmpaatne, kuid see meid sisuliselt rahuldab.<\/p>\n<p>Kui siiski tekib olukord, kus on vaja koosk\u00f5las hoida osa andmeid, siis t\u00f5en\u00e4oliselt l\u00e4heneme teenuse suurendamisele, et seda \u00fches protsessis t\u00f6\u00f6telda. <\/p>\n<p>Vaatame mikroteenuse eraldamise n\u00e4idet. Kuidas saame selle suhteliselt ohutult tootmisse viia? Selles n\u00e4ites on meil s\u00fcsteemi eraldi osa \u2014 palgaarvestuse moodul, mille osa koodist tahame muuta mikroteenuseks.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/346af271b0c3f99897d330e56f713f18.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsimese asjana loome mikroteenuse, kirjutades koodi \u00fcmber. Parandame m\u00f5ned asjad, mis meid ei rahuldanud. Rakendame uusi \u00e4rin\u00f5udeid tellijalt. Lisame UI ja backend'i vahele API Gateway, mis tagab k\u00f5nede edastamise. <\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/bec8d68f20f3ec53af0cef225a51c2b3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeej\u00e4rel viime selle konfiguratsiooni tootmisse, kuid pilootseisundis. Enamik kasutajaid t\u00f6\u00f6tab endiselt vanade \u00e4ri protsessidega. Uutele kasutajatele arendame uue versiooni monoliidist, mis seda protsessi enam ei sisalda. Sisuliselt t\u00f6\u00f6tab meil pilootprojekti korras monoliidi ja mikroteenuse \u00fchendus.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/27e98812746bb7f142fa3a3c3a03b52f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEduka pilootprojekti korral m\u00f5istame, et uus konfiguratsioon on t\u00f5epoolest toimiv, saame vanast monoliidist vabaneda ja j\u00e4tta uue konfiguratsiooni vana lahenduse asemele.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/11dcf1d771b57d3921c0aa91b82646e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKokkuv\u00f5ttes kasutame praktiliselt k\u00f5iki olemasolevaid meetodeid monoliidi l\u00e4htekoodi eraldamiseks. Need k\u00f5ik v\u00f5imaldavad meil v\u00e4hendada rakenduse osi ja viia need \u00fcle uutele raamatukogudele, luues parema l\u00e4htekoodi.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"9\"><\/a><\/noindex><b><\/p>\n<h3>T\u00f6\u00f6tamine BDs<\/h3>\n<p><\/b><br \/>\nAndmebaasi jagamine on keerulisem kui l\u00e4htekoodi jagamine, kuna see sisaldab mitte ainult praegust skeemi, vaid ka kogunenud ajaloolisi andmeid.<\/p>\n<p>Meie andmebaasil, nagu paljudel teistel, oli veel \u00fcks oluline puudus \u2014 tohutu suurus. Seda andmebaasi kavandati keerulise monoliidi \u00e4ri loogika kohaselt ning nende tabelite vahel, mis kuuluvad erinevatesse piiratud konteksti, on akumuleerunud seoseid.<\/p>\n<p>Meie puhul, kui k\u00f5ik 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\u00f5eti tabelitest vaate kaudu, replikatsiooni kaudu ja saadeti teistesse s\u00fcsteemidesse, kus seda replikatsiooni n\u00f5uti. Tulemuseks oli see, et me ei saanud tabeliteid eraldi skeemi viia, sest neid kasutati aktiivselt.<\/p>\n<p>Jagamisel aitab meid see piiratud kontekstide eraldamine koodis. See annab meile tavaliselt piisavalt hea \u00fclevaate andmete jagamisest andmebaasi tasandil. Me m\u00f5istame, millised tabelid kuuluvad \u00fchte piiratud konteksti ja millised teise.<\/p>\n<p>Me rakendasime kahte globaalset meetodit andmebaasi jagamiseks: olemasolevate tabelite eraldamine ja eraldamine \u00fcmberkujundamisega.<\/p>\n<p>Olemasolevate tabelite eraldamine on meetod, mida on hea rakendada, kui andmestruktuur on kvaliteetne, rahuldab \u00e4rin\u00f5udeid ja k\u00f5igile sobib. Sel juhul saame olemasolevad tabelid eraldada eraldi skeemi.<\/p>\n<p>Eraldamine \u00fcmberkujundamisega on vajalik, kui \u00e4ri mudel on oluliselt muutunud ja tabelid ei rahulda meid enam.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"10\"><\/a><\/noindex><b>Olemasolevate tabelite eraldamine.<\/b> Peame m\u00e4\u00e4ratlema, mida me eraldame. Ilma selle teadmiseta ei saa me midagi teha, ja siin aitab meid koodis piiratud konteksti jagamine. \u00dcldiselt, kui \u00f5nnestub m\u00f5ista konteksti piire algkoodis, saab selgeks, millised tabelid peaksid olema eraldamise loendis.<\/p>\n<p>Kujutame ette, et meil on lahendus, kus kaks monoliidi moodulit suhtlevad \u00fche andmebaasiga. Peame tegema nii, et eraldatavate tabelite osaga suhtleb ainult \u00fcks moodul, samas kui teine hakkab sellega suhtlema l\u00e4bi API. Alguses piisab, kui API kaudu on ainult kirjutamine. See on vajalik tingimus, et saaksime r\u00e4\u00e4kida mikroteenuste s\u00f5ltumatusest. Lugemise seosed v\u00f5ivad j\u00e4\u00e4da, seni kuni see ei p\u00f5hjusta suuri probleeme.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/1602637ad752ac055f475cfa45d95e95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJ\u00e4rgmise sammu k\u00e4igus saame juba eraldada koodiosa, mis t\u00f6\u00f6tab eraldatavate tabelitega, \u00fcmberkujundamisega v\u00f5i ilma, eraldi mikroteenuseks ja k\u00e4ivitada selle eraldi protsessis, konteineris. See on eraldi teenus, millel on \u00fchendus monoliidi andmebaasiga ja nende tabelitega, mis ei kuulu otseselt sinna. Monoliit suhtleb veel lugemise kaudu eraldatud osaga. <\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/36011f4e6be4f6a2f19f2f074b645dcb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHiljem eemaldame selle seose, st monoliidi rakenduse andmete lugemine eraldatavatest tabelitest viiakse samuti API-le.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/290f91bbfccac2a4b384078e4cf4e337.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEdasi eraldame \u00fcldisest andmebaasist tabelid, millega t\u00f6\u00f6tab ainult uus mikroteenus. Saame tabelid viia eraldi skeemi v\u00f5i isegi eraldi f\u00fc\u00fcsilisse andmebaasi. J\u00e4\u00e4b lugemise seos mikroteenuse ja monoliidi andmebaasi vahel, kuid selles pole midagi hullu; sellises konfiguratsioonis v\u00f5ib see piisavalt kaua elada.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/ab947ac6a38ffbccd4e2b51103aef609.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nViimane samm on t\u00e4ielikult eemaldada k\u00f5ik seosed. Selle korral v\u00f5ib meil olla vajalik andmete migreerimine p\u00f5hivaatest. M\u00f5nikord soovime taaskasutada m\u00f5ningaid v\u00e4liste s\u00fcsteemide replitseeritavaid andmeid v\u00f5i registrite andmeid mitmes erinevas andmebaasis. Meil esineb seda perioodiliselt.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/f40cf17dd56b9575751e370c44f08344.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" name=\"11\"><\/a><\/noindex><b>\u00dcksus \u00fcleviidud t\u00f6\u00f6tlusega.<\/b> See meetod sarnaneb v\u00e4ga esimesega, kuid k\u00e4ib vastupidises j\u00e4rjekorras. Meil luuakse kohe uus andmebaas ja uus mikroteenus, mis suhtleb monoliidiga API kaudu. Samas j\u00e4\u00e4b alles andmebaasi tabelite kogum, mille me soovime tulevikus eemaldada. Me ei vaja seda enam, uues mudelis asendasime selle.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/c94932033e47cfa1fd56595ab9a19246.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt see skeem t\u00f6\u00f6taks, on meil t\u00f5en\u00e4oliselt vajalik \u00fcleminekuperiood.<\/p>\n<p>Edasi on kaks v\u00f5imalikku l\u00e4henemist.<\/p>\n<p><b>Esimene<\/b>: dubleerime k\u00f5ik andmed uutes ja vanades andmebaasides. Sel juhul tekib meil andmete \u00fclek\u00fcllus, v\u00f5ivad tekkida s\u00fcnkroniseerimisprobleemid. Kuid sel juhul saame v\u00f5tta kaks erinevat klienti. \u00dcks t\u00f6\u00f6tab uue versiooniga, teine vana versiooniga.<\/p>\n<p><b>Teine<\/b>: jagame andmeid mingi \u00e4rim\u00e4rgi j\u00e4rgi. N\u00e4iteks, meil oli s\u00fcsteemis 5 toodet, mis on salvestatud vanasse andmebaasi. Kuuendat uue \u00e4rilise \u00fclesande raames paneme uude andmebaasi. Kuid meil on vaja API Gateway't, mis s\u00fcnkroniseerib need andmed ja n\u00e4itab kliendile, kust ja mida v\u00f5tta.<\/p>\n<p>M\u00f5lemad l\u00e4henemised on toimivad, valige s\u00f5ltuvalt olukorrast.<\/p>\n<p>P\u00e4rast seda, kui oleme veendunud, et k\u00f5ik t\u00f6\u00f6tab, saab osa monoliidist, mis t\u00f6\u00f6tab vanade andmebaasi struktuuridega, v\u00e4lja l\u00fclitada. <\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/973bf5015bdf49a290a5b901f89628cc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nViimane samm on vanade andmestruktuuride eemaldamine. <\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/fe83acc07077b7eb3717138e3c20c005.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKokkuv\u00f5tteks v\u00f5ib \u00f6elda, et meil on andmebaasidega probleeme: sellega on t\u00f6\u00f6tamine keerulisem v\u00f5rreldes allikakoodiga, eraldamine on raskem, kuid seda on v\u00f5imalik ja vajalik teha. Oleme leidnud m\u00f5ned meetodid, mis v\u00f5imaldavad seda teha piisavalt ohutult, sest andmetes eksida on lihtsam kui allikakoodis. <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"12\"><\/a><\/noindex><b><\/p>\n<h3>T\u00f6\u00f6 l\u00e4htekoodiga<\/h3>\n<p><\/b><br \/>\nNii n\u00e4gi v\u00e4lja algse koodi skeem, kui me alustasime monoliitprojekti anal\u00fc\u00fcsi.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/a6d886e37117ccf8f63106d6616aa653.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeda v\u00f5ib tinglikult jagada kolmeks kihiks. See on k\u00e4ivitatavate moodulite, pluginate, teenuste ja eraldi tegevuste kiht. Tegelikult olid need sisenemisvahendid monoliitsetes lahendustes. K\u00f5ik need olid tihedalt seotud Common kihiga. See sisaldas \u00e4riloogikat, mida teenused kasutasid \u00fchiselt, ja rohkesti seoseid. Iga teenus ja plugin kasutas kuni 10 ja rohkem common-kogumite, s\u00f5ltuvalt nende suurusest ja arendajate aususest.<\/p>\n<p>Meil vedas, meil olid infrastruktuuri raamatukogud, mida sai eraldi kasutada. <\/p>\n<p>M\u00f5nikord juhtus, et m\u00f5ned Common-objektid ei kuulunud tegelikult sellesse kihti, vaid olid infrastruktuuri raamatukogud. See lahendati \u00fcmbernimetamise teel.<\/p>\n<p>Enim muret tekitasid piiratud kontekstid. Juhtus, et 3-4 konteksti olid segatud \u00fchte Common-kogumisse ja kasutasid \u00fcksteist sama \u00e4rifunktsioonide raames. Oli vajalik m\u00f5ista, kus seda saab jagada ja millistel piiridel, ning mida edasi teha selle jagamise kaardistamisega l\u00e4htekoodi kogumitesse.<\/p>\n<p>Formuleerisime m\u00f5ned reeglid koodi jagamise protsessi jaoks.<\/p>\n<p><b>Esiteks<\/b>: me ei soovinud enam \u00e4riloogika jagamist teenuste, tegevuste ja pluginatega. Soovisime teha \u00e4riloogika mikroteenuste piires s\u00f5ltumatuks. Teiselt poolt, mikroteenuseid peaks ideaaljuhul k\u00e4sitlema teenustena, mis eksisteerivad t\u00e4iesti iseseisvalt. Ma arvan, et see l\u00e4henemine on m\u00f5nev\u00f5rra raiskav ja seda on raske saavutada, kuna n\u00e4iteks C# teenused on igal juhul \u00fchendatud standardraamatukoguga. Meie s\u00fcsteem on kirjutatud C#-s, teisi tehnoloogiaid pole seni kasutusele v\u00f5etud. Seet\u00f5ttu otsustasime, et saame endale lubada kasutada \u00fchiseid tehnilisi kogumeid. Peamine on, et neis ei tohi olla \u00e4riloogika fraktsioone. Kui sul on mugav wrapper ORM-i, mida kasutad, siis selle kopeerimine teenusest teenusesse on v\u00e4ga kulukas.<\/p>\n<p>Meie meeskond on objekt-orienteeritud disaini f\u00e4nne, seega sobis meile \u00absibula arhitektuur\u00bb suurep\u00e4raselt. Meie teenuste aluseks pole andmejuhtimise kiht, vaid domeeniloogikaga t\u00f6\u00f6tlemine, mis sisaldab vaid \u00e4riloogikat ja on eemaldatud infrastruktuuri seostest. Sel viisil saame eraldi t\u00e4iustada domeeni t\u00f6\u00f6tlust, et lahendada raamistikuga seotud probleeme.<\/p>\n<p>Sellel etapil puutusime kokku esimese t\u00f5sise probleemiga. Teenus pidi viitama \u00fchele domeenit\u00f6\u00f6tlusele, kuid loogika soovisime teha s\u00f5ltumatuks, ja DRY-printsiip takistas meid. Arendajad soovisid v\u00e4ltida dubleerimist ja taaskasutada klasse naaberkomplektidest, mist\u00f5ttu alustas domeenide omavaheline sidumine uuesti. Anal\u00fc\u00fcsime tulemusi ja otsustasime, et probleem v\u00f5ib peituda ka allika koodi salvestamise struktuuris. Meil oli suur hoidla, kus olid k\u00f5ik allikakoodid. Projekti lahendust oli v\u00e4ga raske koguda kohalikul masinal. Seet\u00f5ttu loodi projekti osade jaoks eraldi v\u00e4iksed lahendused, ja keegi ei keelanud neisse lisada mingit \u00fchiskomplekti v\u00f5i domeenit\u00f6\u00f6tlust ja taaskasutada. Ainsana ei lubanud seda teha koodikontroll, kuid ka see andis vahel t\u00f5rkeid.<\/p>\n<p>Siis hakkasime \u00fcle minema eraldi hoidlate mudelile. \u00c4riloogika enam ei lekinud teenusest teenusesse, domeenid said t\u00f5eliselt s\u00f5ltumatuks. Piiritletud kontekste toetatakse selgemini. Kuidas me sel perioodil infrastruktuuri raamatukogusid taaskasutame? Me eraldasime need eraldi hoidlasse ja seej\u00e4rel panime Nuget-pakettidesse, mis asus Artifactorys. Iga muudetud korral toimub kogumine ja avaldamine automaatselt.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/8ddbc750dc7c6d397a459acf7825de90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMeie teenused hakkasid viitama sisemistele infrastruktuuri pakettidele t\u00e4pselt nagu v\u00e4listingimustes. V\u00e4listingimuste raamatukogud laadime Nugetist alla. Artifactory t\u00f6\u00f6ks, kuhu me need paketid panime, kasutasime kahte pakettide haldurit. Ka v\u00e4ikestes hoidlates kasutasime Nugetit. Mitme teenusega hoidlates kasutasime Paketit, mis tagab modulite versioonide vahel suurema \u00fchtsuse.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/672a25a70a481bff68baebe963184ccd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeega, t\u00f6\u00f6tades l\u00e4htekoodiga, muutes veidi arhitektuuri ja jagades hoidlaid, muudame meie teenused iseseisvamaks.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"13\"><\/a><\/noindex><b><\/p>\n<h3>Infrastruktuuri probleemid<\/h3>\n<p><\/b><br \/>\nEnamik mikroteenuste \u00fclemineku puudustest on seotud infrastruktuuriga. Teil on vaja automatiseeritud juurutamist, vajalikud on uued lood infrastruktuuri t\u00f6\u00f6ks.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"16\"><\/a><\/noindex><b>K\u00e4sitsi paigaldamine keskkondadesse<\/b><\/p>\n<p>Alguses seadsime keskkonnan\u00f5udeid k\u00e4sitsi. Selle protsessi automatiseerimiseks l\u00f5ime CI\/CD toru. Valisime pideva toimetamise protsessi, sest pidev juurutamine ei ole meie \u00e4riprotsesside seisukohalt praegu vastuv\u00f5etav. Seet\u00f5ttu toimub kasutuselev\u00f5tt nupuvajutusega, testimine aga automaatselt.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/0fc092326a48813398c6f3a031197bab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKasutame Atlassianit, Bitbucketit l\u00e4htekoodide 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\u00f5uab automaatselt testserveritele, kus neid saab kohe testida.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/fcc743cfaa4a24b906ceeb40ec1ba0a0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" name=\"14\"><\/a><\/noindex><b><\/p>\n<h3>Eraldi logimine<\/h3>\n<p><\/b><br \/>\nOma aega, oli monoliidi \u00fcheks ideeks tagada \u00fchtne 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\u00e4iustada tekstilogisid ja salvestada neisse j\u00e4lgimise ID identificatorina, lisades teenuse nime, et neid logisid hiljem anal\u00fc\u00fcsida.<\/p>\n<p><img decoding=\"async\" alt=\"Siirdumine monoliidilt mikroteenustele: ajalugu ja praktika.\" src=\"\/wp-content\/uploads\/2019\/07\/8e58c66ac134e65abe34b59939f31483.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFilebeati abil saame koguda oma logisid <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/et\/server\/\"   title=\"serverid\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1338\">serverid<\/a>, seej\u00e4rel neid t\u00f6\u00f6delda, kasutada Kibana't p\u00e4ringute koostamiseks UI-s ja vaadata, kuidas teenuste vahel kutsed toimusid. Sellel aitab oluliselt j\u00e4lgimise ID.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"15\"><\/a><\/noindex><b><\/p>\n<h3>Seotud teenuste testimine ja silumine<\/h3>\n<p><\/b><br \/>\nAlguses ei m\u00f5istnud me t\u00e4ielikult, kuidas seadistada arendatavaid teenuseid. Monoliidi puhul oli k\u00f5ik lihtne, k\u00e4ivitasime selle kohalikul masinal. Alguses p\u00fc\u00fcdsime sama teha ka mikroteenustega, kuid m\u00f5nikord, et t\u00e4ielikult k\u00e4ivitada \u00fcks mikroteenus, peab k\u00e4ivitama ka mitmeid teisi, mis on ebamugav. M\u00f5istsime, et on vaja liikuda mudelile, kus j\u00e4tame kohalikule masinale ainult teenuse v\u00f5i teenused, mida soovime seadistada. \u00dclej\u00e4\u00e4nud teenuseid kasutatakse serveritelt, mis on konfiguratsioonilt koosk\u00f5las tootmisserveriga. P\u00e4rast seadistamist, testimise k\u00e4igus antakse igale \u00fclesandele testserveris v\u00e4lja ainult muudetud teenused. Nii testitakse lahendust just selles vormis, milles see tulevikus tootmisse j\u00f5uab.<\/p>\n<p>On serverid, millel on ainult tootmisversioonid teenustest. Need serverid on vajalikud h\u00e4daolukordade puhul, tarnimise kontrollimiseks enne juurutamist ja sisekoolitusteks.<\/p>\n<p>Lisandunud on automaatsete testimiste protsess populaarses Specflow teegis. Testid k\u00e4ivituvad automaatselt NUnit'i abil otse p\u00e4rast juurutamist Ansible'i kaudu. Kui \u00fclesande katmine on t\u00e4ielikult automatiseeritud, ei ole k\u00e4sitsi testimist vajalik. Kuigi m\u00f5nikord on siiski vajalik t\u00e4iendav k\u00e4sitsi testimine. Konkreetses \u00fclesandes k\u00e4ivitatavate testide m\u00e4\u00e4ramiseks kasutame Jira-s silte.<\/p>\n<p>Lisaks on kasvanud vajadus koormustestimise j\u00e4rele, mida varem viidi l\u00e4bi ainult harvade juhtumite puhul. Testide k\u00e4ivitamiseks kasutame JMeterit, nende s\u00e4ilitamiseks InfluxDB-d ja protsessi graafikute koostamiseks Grafana't.<\/p>\n<p><b><\/p>\n<h3>Mida me saavutasime?<\/h3>\n<p><\/b><br \/>\nEsiteks oleme vabanenud m\u00f5istet \"v\u00e4ljalase\". Kaks kuud kestnud hiiglaslikud v\u00e4ljalasked, mil see masin juurutati tootmiskeskkonnas, rikkuvad ajutiselt \u00e4riprotsesse, on kadunud. Praegu juurutame teenuseid keskmiselt iga 1,5 p\u00e4eva j\u00e4rel, grupeerides need, kuna nad tulevad kasutusele p\u00e4rast koosk\u00f5lastamist.<\/p>\n<p>Meie s\u00fcsteemis pole fataalseid t\u00f5rkeid. Kui oleme v\u00e4lja saanud mikroteenuse, milles on viga, siis seotud funktsionaalsus lakkab toimimast, kuid \u00fclej\u00e4\u00e4nud funktsionaalsus j\u00e4\u00e4b terveks. See parandab kasutajakogemust oluliselt.<\/p>\n<p>Me saame hallata juurutusskeemi. Teenuste r\u00fchmad saavad vajadusel eralduda muu lahendusest.<\/p>\n<p>Lisaks oleme oluliselt v\u00e4hendanud suure tagastust\u00f6\u00f6de j\u00e4rjekorra probleemi. Meil on tekkinud eraldi tootemeeskonnad, mis t\u00f6\u00f6tavad s\u00f5ltumatult osade teenustega. Siin sobib juba h\u00e4sti Scrumi protsess. Konkreetse meeskonna jaoks v\u00f5ib olla eraldi tooteomanik, kes seab neile \u00fclesandeid. <\/p>\n<p><b><\/p>\n<h3>Elulookirjeldus<\/h3>\n<p><\/b><\/p>\n<ul>\n<li>Mikroteenused sobivad h\u00e4sti keerukate s\u00fcsteemide dekompositsiooniks. Protsessis hakkame aru saama, mis meie s\u00fcsteemis on, millised on olemasolevad piiratud kontekstid ja kus need piirid kulgevad. See v\u00f5imaldab \u00f5igesti jaotada t\u00e4iendused moodulite kaupa ning v\u00e4ltida koodi segadusse ajamist. <\/li>\n<li>Mikroteenused pakuvad organisatsioonilisi eeliseid. Neist r\u00e4\u00e4gitakse sageli ainult arhitektuurina, kuid iga arhitektuur on vajalik \u00e4rivajaduste rahuldamiseks, mitte iseenesest. Seet\u00f5ttu saame \u00f6elda, et mikroteenused sobivad v\u00e4ga h\u00e4sti probleemide lahendamiseks v\u00e4ikeste meeskondadega, arvestades, et Scrum on hetkel v\u00e4ga populaarne.<\/li>\n<li>Eraldamine on iteratiivne protsess. Ei saa v\u00f5tta rakendust ja lihtsalt jagada seda mikroteenusteks. Saadud toode ei pruugi olla t\u00f6\u00f6kindel. Mikroteenuste eraldamisel on kasulik olemasolev p\u00e4rand kood \u00fcmber kirjutada, et muuta see meie soovide kohaselt ja paremini rahuldada \u00e4rivajadusi funktsionaalsuse ja kiirusel.\n<p><i>V\u00e4ike hoiatuseks:<\/i> \u00fcleminek mikroteenustele on \u00fcsna kulukas. Ainult infrastruktuuriprobleemi lahendamiseks kulus palju aega. Seet\u00f5ttu, kui teil on v\u00e4ike rakendus, mis ei vaja spetsiifilist skaleerimist, kui teil ei ole suurt hulka kliente, kes v\u00f5itlevad teie meeskonna t\u00e4helepanu ja aja nimel, siis v\u00f5ivad mikroteenused t\u00e4na 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>\n<p>P.S. Rohkem emotsionaalne jutt (ja justkui isiklikult teile) \u2013 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=qTNbx18DzpQ\">lingil<\/a><\/noindex>. <br \/>\nSiin on ettekande t\u00e4isteksts.<\/li>\n<\/ul>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/raiffeisenbank\/blog\/458404\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0440\u043e\u0435\u043a\u0442, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e, \u043f\u0440\u0435\u0432\u0440\u0430\u0449\u0430\u043b\u0441\u044f \u0438\u0437 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u0432 \u043d\u0430\u0431\u043e\u0440 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0430\u043b \u0441\u0432\u043e\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e, \u0432 \u043d\u0430\u0447\u0430\u043b\u0435 2000. \u041f\u0435\u0440\u0432\u044b\u0435 \u0432\u0435\u0440\u0441\u0438\u0438 \u0431\u044b\u043b\u0438 \u043d\u0430\u043f\u0438\u0441\u0430\u043d\u044b \u043d\u0430 Visual Basic 6. \u0421 \u0442\u0435\u0447\u0435\u043d\u0438\u0435\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0441\u0442\u0430\u043b\u043e \u043f\u043e\u043d\u044f\u0442\u043d\u043e, \u0447\u0442\u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0443 \u043d\u0430 \u044d\u0442\u043e\u043c \u044f\u0437\u044b\u043a\u0435 \u0432 \u0431\u0443\u0434\u0443\u0449\u0435\u043c \u0431\u0443\u0434\u0435\u0442 \u0441\u043b\u043e\u0436\u043d\u043e \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0442\u044c, \u0442\u0430\u043a \u043a\u0430\u043a IDE [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26858,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35906","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0440\u043e\u0435\u043a\u0442, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e, \u043f\u0440\u0435\u0432\u0440\u0430\u0449\u0430\u043b\u0441\u044f \u0438\u0437 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u0432 \u043d\u0430\u0431\u043e\u0440 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0430\u043b \u0441\u0432\u043e\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e, \u0432 \u043d\u0430\u0447\u0430\u043b\u0435 2000.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/perehod-ot-monolita-k-mikroservisam-istoriya-i-praktika\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0435\u0440\u0435\u0445\u043e\u0434 \u043e\u0442 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u043a \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u0430\u043c: \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0440\u043e\u0435\u043a\u0442, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e, \u043f\u0440\u0435\u0432\u0440\u0430\u0449\u0430\u043b\u0441\u044f \u0438\u0437 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u0432 \u043d\u0430\u0431\u043e\u0440 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0430\u043b \u0441\u0432\u043e\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e, \u0432 \u043d\u0430\u0447\u0430\u043b\u0435 2000.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/perehod-ot-monolita-k-mikroservisam-istoriya-i-praktika\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:07:29+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:07:29+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00dcleminek monoliidilt mikroteenustele: ajalugu ja praktika | ProHoster","description":"Selles artiklis r\u00e4\u00e4gin, kuidas projekt, millega ma t\u00f6\u00f6tan, muutus suurest monoliidist mikroteenuste kogumiks. Projekt alustas oma teekonda juba pikka aega tagasi, 2000. aastate alguses.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/perehod-ot-monolita-k-mikroservisam-istoriya-i-praktika","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0435\u0440\u0435\u0445\u043e\u0434 \u043e\u0442 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u043a \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u0430\u043c: \u0438\u0441\u0442\u043e\u0440\u0438\u044f \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430 | ProHoster","og:description":"\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043f\u0440\u043e\u0435\u043a\u0442, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u043c \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e, \u043f\u0440\u0435\u0432\u0440\u0430\u0449\u0430\u043b\u0441\u044f \u0438\u0437 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430 \u0432 \u043d\u0430\u0431\u043e\u0440 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432. \u041f\u0440\u043e\u0435\u043a\u0442 \u043d\u0430\u0447\u0430\u043b \u0441\u0432\u043e\u044e \u0438\u0441\u0442\u043e\u0440\u0438\u044e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e, \u0432 \u043d\u0430\u0447\u0430\u043b\u0435 2000.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/perehod-ot-monolita-k-mikroservisam-istoriya-i-praktika","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:07:29+00:00","article:modified_time":"2019-10-31T19:07:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35906","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:04:56","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:54:38","updated":"2026-02-09 17:04:56","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35906","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=35906"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35906\/revisions"}],"predecessor-version":[{"id":158582,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35906\/revisions\/158582"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/26858"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=35906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=35906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=35906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}