{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Mikroteenused: mis need on, miks ja millal neid rakendada","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Olen juba ammu tahtnud kirjutada artiklit mikroteenuste arhitektuurist, kuid mind on pidevalt pidurdanud kaks asjaolu \u2014 mida s\u00fcgavamale ma teemasse s\u00fcvenen, seda rohkem tundub mulle, et see, mida ma tead, on ilmselge, ning see, mida ma ei tea, vajab veel uurimist. Teisalt usun, et mul on juba praegu m\u00f5tteid, millest laiema publikuni r\u00e4\u00e4kida. Seega on alternatiivsed arvamused teretulnud.
\n<\/a><\/noindex><\/p>\n

Conway seadus ja seos \u00e4ri, organisatsiooni ja infotehnoloogilise s\u00fcsteemi vahel<\/h2>\n

\nT\u00f5lgin ennast taas:<\/p>\n

\u00abIga organisatsioon, mis projekteerib mingisugust s\u00fcsteemi (laiemas m\u00f5ttes), saab disaini, mille struktuur kopeerib selle organisatsiooni meeskondade struktuuri.\u00bb
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Minu arvates seondub see seadus pigem ettev\u00f5tte korraldamise otstarbekuse kui otseselt infosis\u00fcsteemiga. Selgitan n\u00e4ite kaudu. Oletame, et meil on piisavalt stabiilne \u00e4riv\u00f5imalus, mille eluts\u00fckkel on piisavalt pikk, et oleks m\u00f5ttekas ettev\u00f5tte korraldamine (see ei ole tr\u00fckiviga, kuid mulle meeldib see termin, mille ma endale olen omistanud). Loomulikult peab selle ettev\u00f5tte tugis\u00fcsteem olema organisatoorselt ja protsessiliselt koosk\u00f5las selle \u00e4riga.<\/p>\n

\u00c4rile orienteeritud infosis\u00fcsteemid<\/h2>\n

\n\"Mikroteenused:
\n
\nSelgitan n\u00e4ite kaudu. Oletame, et on olemas \u00e4riv\u00f5imalus pitsa m\u00fc\u00fcgi korraldamiseks. V1 versioonis (nimetame seda enne infotehnoloogiat) oli ettev\u00f5te pitsakohvik, kassa ja kohaletoimetamisteenus. See versioon p\u00fcsis kaua, kuna \u00fcmbruse muutuvus oli madal. Seej\u00e4rel tuli versioon 2 \u2014 arenenum, mis oskab kasutada infosis\u00fcsteemi oma p\u00f5hialustena monoliitne arhitektuur. Ja siin, minu arvates, tekib lihtsalt kohutav eba\u00f5iglus monoliitide suhtes \u2014 v\u00e4idetav monoliitne arhitektuur ei vasta ettev\u00f5tte domeenimudelile<\/b>. Ja kui see t\u00f5esti nii oleks, ei saaks s\u00fcsteem \u00fcldse t\u00f6\u00f6tada - see oleks vastuolus Conway seaduse ja terve m\u00f5istusega. Ei, monoliitne arhitektuur vastab t\u00e4iesti \u00e4rimudelile selle ettev\u00f5tte arengu praeguses etapis \u2014 m\u00f5tlen loomulikult etappi, kus s\u00fcsteem on juba loodud ja kasutusele v\u00f5etud. T\u00e4iesti suurep\u00e4rane t\u00f5siasi, et s\u00f5ltumata arhitektuurilisest l\u00e4henemisviisist, t\u00f6\u00f6tab teenustele orienteeritud arhitektuur versioon 3 ja mikroteenuste arhitektuur versioon N v\u00f5rdselt h\u00e4sti. Mis on konks?<\/p>\n

K\u00f5ik voolab, k\u00f5ik muutub v\u00f5i on mikroteenused keerukuse vastu v\u00f5itlemise vahend?<\/h2>\n

\n Enne j\u00e4tkamist vaatame m\u00f5ningaid ekslikke arusaamu mikroteenuste arhitektuuri kohta.<\/p>\n

Mikroteenuste l\u00e4henemise toetajad r\u00e4\u00e4givad sageli sellest, et monoliidi jagamine mikroteenusteks lihtsustab arendamist, v\u00e4hendades eraldi teenuste koodibaasi. Minu arvates on see v\u00e4ide t\u00e4ielik jama. T\u00f5siselt, kas monoliidiga ja homogeense koodiga koost\u00f6\u00f6 n\u00e4ib keeruline? Kui see t\u00f5epoolest nii oleks, ehitataks k\u00f5ik projektid algusest peale mikroteenustena, kuid praktika n\u00e4itab, et migratsioon monoliidilt mikroteenustele on palju levinum. Keerukus ei kao kuhugi, see lihtsalt liigub eraldi moodulitelt liidestele (olgu need siis andmebusid, RPC, API-d v\u00f5i muud protokollid) ja orkestreerimis\u00fcsteemidele. Ja see on keeruline! <\/p>\n

Heterogeense tekki kasutamise eelis on samuti kahtlane. Ma ei vaidle sellele, et see on v\u00f5imalik, kuid tegelikkuses esineb see harva (Eelnevalt \u00f6eldes, see peab siiski olema olemas \u2014 pigem tagaj\u00e4rjena kui eelise t\u00f5ttu).<\/p>\n

Toote ja teenuse eluts\u00fckkel<\/h2>\n

\nVaata uuesti \u00fclalolevat diagrammi. Ma ei m\u00e4rkinud ettev\u00f5tte versiooni eluiga juhuslikult \u2013 t\u00e4nap\u00e4evastes tingimustes on just \u00e4ri versioonide vahelise \u00fclemineku kiirus selle edu m\u00e4\u00e4rav tegur. Toote edukus s\u00f5ltub \u00e4ri-ideede kontrollimise kiirusest.<\/b>. Ja siin on minu arvates peidus mikroteenuste arhitektuuri peamine eelis. Aga liikuge samm-sammult edasi. <\/p>\n

Liigume informatsioonis\u00fcsteemide evolutsiooni j\u00e4rgmisele tasemele \u2013 teenuseorienteeritud arhitektuurile SOA. Nii et mingil hetkel eraldasime oma tootest pikaajalised teenused<\/b> \u2013 pikaajalised selles m\u00f5ttes, et toote versioonide vahetusel on lootust, et teenuse eluiga on pikem kui toote j\u00e4rgmise versiooni eluiga. Loogiline oleks mitte neid \u00fcldse muuta \u2013 meile on oluline just j\u00e4rgmisele versioonile \u00fclemineku kiirus.<\/b>. Kuid kahjuks peame teenustes pidevalt muudatusi tegema \u2013 ja siin sobib meile k\u00f5ik, nii DevOps praktikad, konteineriseerimine kui ka k\u00f5ik muu, mis p\u00e4he tuleb. Kuid see ei ole ikka veel mikroteenused! <\/p>\n

Mikroteenused kui lahendus keerukuse... konfiguratsiooni haldamiseks<\/h2>\n

\n Ja n\u00fc\u00fcd saame l\u00f5puks liikuda mikroteenuste m\u00e4\u00e4rava rolli juurde \u2014 see on l\u00e4henemine, mis lihtsustab toote konfiguratsiooni haldamist. T\u00e4psemalt \u00f6eldes kirjeldab iga mikroteenuse funktsioon just toote sisemisse \u00e4rifunktsiooni vastavalt domeenimudelile \u2014 ja need on juba asjad, mis ei ela l\u00fchiajalises versioonis, vaid pikaajalises \u00e4riv\u00f5imaluses. Ja \u00fcleminek j\u00e4rgmisse tooteversiooni toimub s\u00f5na otseses m\u00f5ttes m\u00e4rkamatult \u2014 te muudate\/loodate \u00fche mikroteenuse, v\u00f5i v\u00f5ib-olla isegi lihtsalt nende vastastikuse tegevuse skeemi ja \u00e4kki olete juba tulevikus, j\u00e4ttes seljataha nutvad konkurendid, kes j\u00e4tkuvalt h\u00fcppavad oma monoliitsete versioonide vahel. Kujutage n\u00fc\u00fcd ette, et teil on piisavalt suur hulk mikroteenuseid, millel on eelnevalt m\u00e4\u00e4ratletud liidesed ja \u00e4riv\u00f5imalused. Ja te tulete ja ehitate oma toote struktuuri valmis mikroteenustest \u2014 lihtsalt joonistades diagrammi n\u00e4iteks. Palju \u00f5nne \u2014 teil on platvorm \u2014 ja n\u00fc\u00fcd saate endale \u00e4ri \u00fcles ehitada. Unistused, unistused. <\/p>\n

J\u00e4reldused<\/h2>\n

<\/p>\n