Olen juba ammu tahtnud kirjutada artiklit mikroteenuste arhitektuurist, kuid mind on pidevalt pidurdanud kaks asjaolu — mida sügavamale ma teemasse süvenen, 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õtteid, millest laiema publikuni rääkida. Seega on alternatiivsed arvamused teretulnud.
Conway seadus ja seos äri, organisatsiooni ja infotehnoloogilise süsteemi vahel
Tõlgin ennast taas:
«Iga organisatsioon, mis projekteerib mingisugust süsteemi (laiemas mõttes), saab disaini, mille struktuur kopeerib selle organisatsiooni meeskondade struktuuri.»
— Melvyn Conway, 1967
Minu arvates seondub see seadus pigem ettevõtte korraldamise otstarbekuse kui otseselt infosisüsteemiga. Selgitan näite kaudu. Oletame, et meil on piisavalt stabiilne ärivõimalus, mille elutsükkel on piisavalt pikk, et oleks mõttekas ettevõtte korraldamine (see ei ole trükiviga, kuid mulle meeldib see termin, mille ma endale olen omistanud). Loomulikult peab selle ettevõtte tugisüsteem olema organisatoorselt ja protsessiliselt kooskõlas selle äriga.
Ärile orienteeritud infosisüsteemid
Selgitan näite kaudu. Oletame, et on olemas ärivõimalus pitsa müügi korraldamiseks. V1 versioonis (nimetame seda enne infotehnoloogiat) oli ettevõte pitsakohvik, kassa ja kohaletoimetamisteenus. See versioon püsis kaua, kuna ümbruse muutuvus oli madal. Seejärel tuli versioon 2 — arenenum, mis oskab kasutada infosisüsteemi oma põhialustena monoliitne arhitektuur. Ja siin, minu arvates, tekib lihtsalt kohutav ebaõiglus monoliitide suhtes — väidetav monoliitne arhitektuur ei vasta ettevõtte domeenimudelile. Ja kui see tõesti nii oleks, ei saaks süsteem üldse töötada - see oleks vastuolus Conway seaduse ja terve mõistusega. Ei, monoliitne arhitektuur vastab täiesti ärimudelile selle ettevõtte arengu praeguses etapis — mõtlen loomulikult etappi, kus süsteem on juba loodud ja kasutusele võetud. Täiesti suurepärane tõsiasi, et sõltumata arhitektuurilisest lähenemisviisist, töötab teenustele orienteeritud arhitektuur versioon 3 ja mikroteenuste arhitektuur versioon N võrdselt hästi. Mis on konks?
Kõik voolab, kõik muutub või on mikroteenused keerukuse vastu võitlemise vahend?
Enne jätkamist vaatame mõningaid ekslikke arusaamu mikroteenuste arhitektuuri kohta.
Mikroteenuste lähenemise toetajad räägivad sageli sellest, et monoliidi jagamine mikroteenusteks lihtsustab arendamist, vähendades eraldi teenuste koodibaasi. Minu arvates on see väide täielik jama. Tõsiselt, kas monoliidiga ja homogeense koodiga koostöö näib keeruline? Kui see tõepoolest nii oleks, ehitataks kõik projektid algusest peale mikroteenustena, kuid praktika näitab, 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õi muud protokollid) ja orkestreerimisüsteemidele. Ja see on keeruline!
Heterogeense tekki kasutamise eelis on samuti kahtlane. Ma ei vaidle sellele, et see on võimalik, kuid tegelikkuses esineb see harva (Eelnevalt öeldes, see peab siiski olema olemas — pigem tagajärjena kui eelise tõttu).
Toote ja teenuse elutsükkel
Vaata uuesti ülalolevat diagrammi. Ma ei märkinud ettevõtte versiooni eluiga juhuslikult – tänapäevastes tingimustes on just äri versioonide vahelise ülemineku kiirus selle edu määrav tegur. Toote edukus sõltub äri-ideede kontrollimise kiirusest.. Ja siin on minu arvates peidus mikroteenuste arhitektuuri peamine eelis. Aga liikuge samm-sammult edasi.
Liigume informatsioonisüsteemide evolutsiooni järgmisele tasemele – teenuseorienteeritud arhitektuurile SOA. Nii et mingil hetkel eraldasime oma tootest pikaajalised teenused – pikaajalised selles mõttes, et toote versioonide vahetusel on lootust, et teenuse eluiga on pikem kui toote järgmise versiooni eluiga. Loogiline oleks mitte neid üldse muuta – meile on oluline just järgmisele versioonile ülemineku kiirus.. Kuid kahjuks peame teenustes pidevalt muudatusi tegema – ja siin sobib meile kõik, nii DevOps praktikad, konteineriseerimine kui ka kõik muu, mis pähe tuleb. Kuid see ei ole ikka veel mikroteenused!
Mikroteenused kui lahendus keerukuse... konfiguratsiooni haldamiseks
Ja nüüd saame lõpuks liikuda mikroteenuste määrava rolli juurde — see on lähenemine, mis lihtsustab toote konfiguratsiooni haldamist. Täpsemalt öeldes kirjeldab iga mikroteenuse funktsioon just toote sisemisse ärifunktsiooni vastavalt domeenimudelile — ja need on juba asjad, mis ei ela lühiajalises versioonis, vaid pikaajalises ärivõimaluses. Ja üleminek järgmisse tooteversiooni toimub sõna otseses mõttes märkamatult — te muudate/loodate ühe mikroteenuse, või võib-olla isegi lihtsalt nende vastastikuse tegevuse skeemi ja äkki olete juba tulevikus, jättes seljataha nutvad konkurendid, kes jätkuvalt hüppavad oma monoliitsete versioonide vahel. Kujutage nüüd 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 platvorm — ja nüüd saate endale äri üles ehitada. Unistused, unistused.
Järeldused
- Süsteemi arhitektuur peab olema määratletud selle komponentide elutsükli alusel. Kui komponent elab toote versiooni raames, siis pole mõtet süsteemi keerukust suurendada, rakendades mikroteenuste lähenemist.
- Mikroteenuste arhitektuur peaks põhinema domeenimudelil — sest äri võimalus on kõige pikaajalisem valdkond.
- Tarnetavad tavad (DevOps praktika) ja orkestreerimine mängivad mikroteenuste arhitektuuris ühte tähtsaimat rolli — kuna komponentide muutmise kiirus nõuab suuremaid nõudeid tarnimise kiiruselt ja kvaliteedilt.
Allikas: habr.com
