{"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 neid on vaja ja millal neid rakendada","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Olen juba ammu tahtnud kirjutada artikli mikroteenuste arhitektuurist, kuid mind on pidevalt pidurdanud kaks asjaolu: mida s\u00fcgavamale ma sellesse teemasse sukeldusin, seda rohkem tundus mulle, et mis ma tean \u2014 on ilmne, ja mis ma ei tea \u2014 seda tuleb veel \u00f5ppida. Teiselt poolt arvan, et on juba millestki arutleda ja laiema publikuni j\u00f5uda. Nii et alternatiivsed arvamused on teretulnud.
\n<\/a><\/noindex><\/p>\n

Conway seadus ja suhe \u00e4ri, organisatsiooni ja teabe s\u00fcsteemi vahel<\/h2>\n

\nLuban endale veel kord tsiteerida:<\/p>\n

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

Minu arvates seondub see seadus rohkem \u00e4riorganisatsiooni otstarbekuse kui otse teabe s\u00fcsteemiga. Selgitan n\u00e4iteks. Oletame, et meil on piisavalt stabiilne \u00e4ri v\u00f5imalus eluts\u00fckliga, mis on nii pikk, et on m\u00f5istlik asutada ettev\u00f5te (see ei ole tr\u00fckiviga, aga mulle meeldib see termin, mille ma endale t\u00f5in). Loomulikult peab selle \u00e4ri toetav s\u00fcsteem olema organisatsiooniliselt ja protsesside poolest koosk\u00f5las selle ettev\u00f5ttega.<\/p>\n

\u00c4ri suunitlus teabe s\u00fcsteemidesse<\/h2>\n

\n\"Mikroteenused:
\n
\nSelgitan n\u00e4iteks. Oletame, et meil on \u00e4ri v\u00f5imalus pizza m\u00fc\u00fcmise korraldamiseks. V1 versioonis (nimetame seda enneinfotehnoloogiliseks) oli ettev\u00f5te pitsakohvik, kassas\u00fcsteem ja kohaletoimetamisteenus. See versioon oli pikaealine madala keskkonna muutlikkuse tingimustes. Siis tuli uus versioon 2 \u2014 arenenum ja suuteline kasutama oma p\u00f5hialuseks infotehnoloogilist s\u00fcsteemi \u00e4riga monoliitsete arhitektuuride jaoks. Ja siin, minu arvates tekib t\u00f5eliselt kohutav eba\u00f5iglus monoliitide suhtes \u2014 v\u00e4idetavalt ei vasta monoliitne arhitektuur \u00e4ri domeeni mudelile<\/b>. Kui see nii oleks, ei saaks s\u00fcsteem \u00fcldse t\u00f6\u00f6tada - see oleks vastuolus sama Conway seaduse ja m\u00f5istusega. Ei, monoliitne arhitektuur vastab t\u00e4ielikult \u00e4ri mudelile selle \u00e4ri arenguetapis - ma m\u00f5tlen etappi, kus s\u00fcsteem on juba loodud ja kasutusele v\u00f5etud. \u00dctlemata tore on see, et olenemata arhitektuurilisest l\u00e4henemisest, t\u00f6\u00f6tavad teenustele orienteeritud arhitektuur versioon 3 ja mikroteenuste arhitektuur versioon N sama h\u00e4sti. Kus on peidus konks?<\/p>\n

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

\n Enne kui j\u00e4tkame, vaatame m\u00f5ningaid v\u00e4\u00e4rarusaamu, mis on seotud mikroteenuste arhitektuuriga.<\/p>\n

Mikroteenuste l\u00e4henemise pooldajad r\u00e4\u00e4givad sageli sellest, et monoliidi jagamine mikroteenusteks lihtsustab arendust, v\u00e4hendades \u00fcksikute teenuste koodibaasi. Minu arvates on see v\u00e4ide t\u00e4ielik jama. T\u00f5siselt, kas monoliidi ja homogeense koodi omavaheline interaktsioon tundub keeruline? Kui see t\u00f5esti nii oleks, ehitataks k\u00f5ik projektid algselt mikroteenustena, samas kui praktika n\u00e4itab, et \u00fcleminek monoliidist mikroteenustele on palju sagedasem. Keerukus ei kao kuhugi, see lihtsalt liigub eraldi moodulitest liidestesse (olgu need siis andmebusid, RPC, API ja muud protokollid) ja orkestreerimise s\u00fcsteemidesse. Ja see on keeruline! <\/p>\n

Heterogeense tehnoloogia kasutamise eelised on samuti k\u00fcsitavad. Ma ei vaidle vastu, et see on v\u00f5imalik, kuid reaalsuses esineb see harva (eess\u00f5na - see peaks olema olemas - aga pigem tagaj\u00e4rjena, mitte eelise t\u00f5ttu).<\/p>\n

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

\nVaadake uuesti \u00fclaltoodud diagrammi. Ma ei pannud t\u00e4hele, et \u00fcksiku versiooni eluts\u00fckkel v\u00e4heneb - t\u00e4nap\u00e4eva tingimustes on just ettev\u00f5tte versioonide vahetuse kiirus m\u00e4\u00e4rav selle eduks. Toote eduv\u00f5ti on selle kaudu testitud \u00e4ri-h\u00fcpoteeside kiirus.<\/b>. Ja just siin on minu arvates peidetud mikroteenuste arhitektuuri v\u00f5tmeeelis. Kuid liikume j\u00e4rjekorras edasi. <\/p>\n

Liigume j\u00e4rgmise sammu suunas infotehnoloogia s\u00fcsteemide evolutsioonis \u2014 teenustele orienteeritud arhitektuur SOA. Nii et mingil hetkel oleme oma tootes eraldanud pikaajalised teenused<\/b> \u2014 pikaajalised selles m\u00f5ttes, et toote versioonide vahetusel on v\u00f5imalus, et teenuse eluts\u00fckkel on pikem kui toote j\u00e4rgmise versiooni eluts\u00fckkel. Loogiline oleks, et me ei muudaks neid \u00fcldse \u2014 meil on oluline just j\u00e4rgmise versiooni kiire \u00fcleminek<\/b>. Kuid kahjuks oleme sunnitud teenustes pidevalt muudatusi tegema \u2014 ja siin sobib meile k\u00f5ik, DevOps praktikatest, konteineriseerimisest ja muust \u2014 k\u00f5ik, mis p\u00e4he tuleb. Kuid see ei ole veel mikroteenused! <\/p>\n

Mikroteenused kui vahend keerukuse\u2026 konfigureerimise haldamise vastu<\/h2>\n

\n Ja siin saame l\u00f5puks r\u00e4\u00e4kida mikroteenuste m\u00e4\u00e4ravast rollist \u2014 see on l\u00e4henemine, mis lihtsustab toote konfigureerimise haldamist. T\u00e4psemalt \u00f6eldes, iga mikroteenuse funktsioon kirjeldab just \u00e4rifunktsiooni toote sees vastavalt domeenimudelile \u2014 need on asjad, mis ei ela l\u00fchiajalise versiooni, vaid pikaajalise \u00e4riv\u00f5imaluse sees. Ja j\u00e4rgmisse toote versiooni \u00fcleminek toimub s\u00f5na otseses m\u00f5ttes m\u00e4rkamatult \u2014 te muudate\/puudutate \u00fchte mikroteenust v\u00f5i v\u00f5ib-olla lihtsalt nendevahelist skeemi ja \u00e4kitselt leiate end juba tulevikus, j\u00e4ttes tagaplaanile nutvad konkurendid, kes j\u00e4tkavad h\u00fcppamist oma monoliitsete versioonide vahel. N\u00fc\u00fcd kujutage 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 n\u00fc\u00fcd platvorm \u2014 ja n\u00fc\u00fcd saate oma ettev\u00f5tte lihtsalt klikkida. Unen\u00e4od, unen\u00e4od. <\/p>\n

J\u00e4reldused<\/h2>\n

<\/p>\n