Mikroteenused: mis need on, miks neid on vaja ja millal neid rakendada

Olen juba ammu tahtnud kirjutada artikli mikroteenuste arhitektuurist, kuid mind on pidevalt pidurdanud kaks asjaolu: mida sügavamale ma sellesse teemasse sukeldusin, seda rohkem tundus mulle, et mis ma tean — on ilmne, ja mis ma ei tea — seda tuleb veel õppida. Teiselt poolt arvan, et on juba millestki arutleda ja laiema publikuni jõuda. Nii et alternatiivsed arvamused on teretulnud.

Conway seadus ja suhe äri, organisatsiooni ja teabe süsteemi vahel

Luban endale veel kord tsiteerida:

„Iga organisatsioon, mis projekteerib mingisuguse süsteemi (laiemas mõttes), saab disaini, mille struktuur kopeerib selle organisatsiooni meeskondade struktuuri.”
— Melvyn Conway, 1967

Minu arvates seondub see seadus rohkem äriorganisatsiooni otstarbekuse kui otse teabe süsteemiga. Selgitan näiteks. Oletame, et meil on piisavalt stabiilne äri võimalus elutsükliga, mis on nii pikk, et on mõistlik asutada ettevõte (see ei ole trükiviga, aga mulle meeldib see termin, mille ma endale tõin). Loomulikult peab selle äri toetav süsteem olema organisatsiooniliselt ja protsesside poolest kooskõlas selle ettevõttega.

Äri suunitlus teabe süsteemidesse

Selgitan näiteks. Oletame, et meil on äri võimalus pizza müümise korraldamiseks. V1 versioonis (nimetame seda enneinfotehnoloogiliseks) oli ettevõte pitsakohvik, kassasüsteem ja kohaletoimetamisteenus. See versioon oli pikaealine madala keskkonna muutlikkuse tingimustes. Siis tuli uus versioon 2 — arenenum ja suuteline kasutama oma põhialuseks infotehnoloogilist süsteemi äriga monoliitsete arhitektuuride jaoks. Ja siin, minu arvates tekib tõeliselt kohutav ebaõiglus monoliitide suhtes — väidetavalt ei vasta monoliitne arhitektuur äri domeeni mudelile. Kui see nii oleks, ei saaks süsteem üldse töötada - see oleks vastuolus sama Conway seaduse ja mõistusega. Ei, monoliitne arhitektuur vastab täielikult äri mudelile selle äri arenguetapis - ma mõtlen etappi, kus süsteem on juba loodud ja kasutusele võetud. Ütlemata tore on see, et olenemata arhitektuurilisest lähenemisest, töötavad teenustele orienteeritud arhitektuur versioon 3 ja mikroteenuste arhitektuur versioon N sama hästi. Kus on peidus konks?

Kõik voolab, kõik muutub või on mikroteenused keerukuse vastu võitlemise vahend?

Enne kui jätkame, vaatame mõningaid väärarusaamu, mis on seotud mikroteenuste arhitektuuriga.

Mikroteenuste lähenemise pooldajad räägivad sageli sellest, et monoliidi jagamine mikroteenusteks lihtsustab arendust, vähendades üksikute teenuste koodibaasi. Minu arvates on see väide täielik jama. Tõsiselt, kas monoliidi ja homogeense koodi omavaheline interaktsioon tundub keeruline? Kui see tõesti nii oleks, ehitataks kõik projektid algselt mikroteenustena, samas kui praktika näitab, et üleminek 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üsteemidesse. Ja see on keeruline!

Heterogeense tehnoloogia kasutamise eelised on samuti küsitavad. Ma ei vaidle vastu, et see on võimalik, kuid reaalsuses esineb see harva (eessõna - see peaks olema olemas - aga pigem tagajärjena, mitte eelise tõttu).

Toote ja teenuse elutsükkel

Vaadake uuesti ülaltoodud diagrammi. Ma ei pannud tähele, et üksiku versiooni elutsükkel väheneb - tänapäeva tingimustes on just ettevõtte versioonide vahetuse kiirus määrav selle eduks. Toote eduvõti on selle kaudu testitud äri-hüpoteeside kiirus.. Ja just siin on minu arvates peidetud mikroteenuste arhitektuuri võtmeeelis. Kuid liikume järjekorras edasi.

Liigume järgmise sammu suunas infotehnoloogia süsteemide evolutsioonis — teenustele orienteeritud arhitektuur SOA. Nii et mingil hetkel oleme oma tootes eraldanud pikaajalised teenused — pikaajalised selles mõttes, et toote versioonide vahetusel on võimalus, et teenuse elutsükkel on pikem kui toote järgmise versiooni elutsükkel. Loogiline oleks, et me ei muudaks neid üldse — meil on oluline just järgmise versiooni kiire üleminek. Kuid kahjuks oleme sunnitud teenustes pidevalt muudatusi tegema — ja siin sobib meile kõik, DevOps praktikatest, konteineriseerimisest ja muust — kõik, mis pähe tuleb. Kuid see ei ole veel mikroteenused!

Mikroteenused kui vahend keerukuse… konfigureerimise haldamise vastu

Ja siin saame lõpuks rääkida mikroteenuste määravast rollist — see on lähenemine, mis lihtsustab toote konfigureerimise haldamist. Täpsemalt öeldes, iga mikroteenuse funktsioon kirjeldab just ärifunktsiooni toote sees vastavalt domeenimudelile — need on asjad, mis ei ela lühiajalise versiooni, vaid pikaajalise ärivõimaluse sees. Ja järgmisse toote versiooni üleminek toimub sõna otseses mõttes märkamatult — te muudate/puudutate ühte mikroteenust või võib-olla lihtsalt nendevahelist skeemi ja äkitselt leiate end juba tulevikus, jättes tagaplaanile nutvad konkurendid, kes jätkavad hüppamist oma monoliitsete versioonide vahel. Nüüd kujutage ette, et teil on piisavalt suur hulk mikroteenuseid, millel on eelnevalt määratletud liidesed ja ärivõimalused. Ja te tulete ja ehitate oma toote struktuuri valmis mikroteenustest — lihtsalt joonistades diagrammi näiteks. Palju õnne — teil on nüüd platvorm — ja nüüd saate oma ettevõtte lihtsalt klikkida. Unenäod, unenäod.

Järeldused

• Süsteemi arhitektuur peab olema määratud selle komponentide elutsükliga. Kui komponent elab toote versiooni raames — pole mõtet suurendada süsteemi keerukust, rakendades mikroteenuste lähenemist.
• Mikroteenuste arhitektuur peaks põhinema domeenimudelil — põhjusel, et ärivõimalus on kõige pikaajalisem valdkond
• Tarnepraktikad (DevOps praktikad) ja orkestratsioon on mikroteenuste arhitektuuri jaoks äärmiselt olulised, kuna komponentide muutmise kiirus seab nõuded tarnimise kiirus ja kvaliteedi suhtes.

Allikas: habr.com