Tahtsin juba pikka aega kirjutada artiklit mikroteenuste arhitektuuri teemal, kuid kaks asja takistasid mind - mida rohkem teemasse süvenesin, seda enam tundus mulle, et see, mida ma tean, on ilmne ja mida ma ei tea. t tea, tuleb uurida ja uurida. Teisalt arvan, et laia publiku seas on juba, mida arutada. Nii et alternatiivsed arvamused on teretulnud.
Conway seadus ning äri, organisatsiooni ja infosüsteemi suhe
Taaskord luban endal tsiteerida:
"Iga organisatsioon, mis kavandab süsteemi (laiemas mõttes), saab disaini, mille struktuur kordab selle organisatsiooni meeskondade struktuuri."
- Melvyn Conway, 1967
Minu meelest on see seadus pigem seotud ettevõtluse korraldamise otstarbekusega, mitte otseselt infosüsteemiga. Lubage mul selgitada näitega. Oletame, et meil on üsna stabiilne ärivõimalus, mille elutsükkel on nii pikk, et ettevõtet on mõtet korraldada (see pole kirjaviga, aga mulle väga meeldib see varastatud termin.) Loomulikult on selle ettevõtte tugisüsteem vastab organisatsiooniliselt ja protsessiliselt sellele äritegevusele.
Infosüsteemide äriline orientatsioon
Lubage mul selgitada näitega. Oletame, et on ärivõimalus korraldada pitsat müüv ettevõte. V1 versioonis (nimetagem seda eelinfoks) oli ettevõtteks pizzeria, kassaaparaat ja kohaletoimetamisteenus. See versioon oli pikaealine madala keskkonnamuutuse tingimustes. Seejärel tuli selle asemele versioon 2 – arenenum ja suudab monoliitse arhitektuuriga äritegevuses kasutada oma tuumaks olevat infosüsteemi. Ja siin on minu arvates monoliitidega seoses lihtsalt kohutav ebaõiglus - väidetavalt monoliitne arhitektuur ei vasta domeeni ärimudelile. Jah, kui see nii oleks, ei saaks süsteem üldse töötada – see on vastuolus sellesama Conway seaduse ja terve mõistusega. Ei, monoliitne arhitektuur on selles äriarengu etapis täielikult kooskõlas ärimudeliga – ma pean loomulikult silmas etappi, mil süsteem on juba loodud ja tööle pandud. On täiesti imeline tõsiasi, et sõltumata arhitektuurilisest lähenemisest töötavad nii teenusekeskse arhitektuuri versioon 3 kui ka mikroteenuste arhitektuuri versioon N võrdselt hästi. Mis on saak?
Kõik voolab, kõik muutub või on mikroteenused vahend keerukuse vastu võitlemiseks?
Enne kui jätkame, vaatame mõningaid väärarusaamu mikroteenuste arhitektuuri kohta.
Mikroteenuste lähenemisviisi kasutamise pooldajad väidavad sageli, et monoliidi jagamine mikroteenusteks lihtsustab arendusmeetodit, vähendades üksikute teenuste koodibaasi. Minu meelest on see väide täielik jama. Tõsiselt, ilmne interaktsioon monoliidi ja homogeense koodi sees tundub keeruline? Kui see tõesti nii oleks, ehitataks kõik projektid algselt mikroteenustena, samas kui praktika näitab, et migratsioon monoliidilt mikroteenustele on palju levinum. Keerukus ei kao, see lihtsalt liigub üksikutelt moodulitelt liidestesse (olgu selleks andmesiinid, RPC, API-d ja muud protokollid) ja orkestreerimissüsteemidesse. Ja see on raske!
Küsitav on ka heterogeense virna kasutamise eelis. Ma ei vaidle vastu, et see on ka võimalik, kuid tegelikkuses juhtub seda harva (Edaspidi vaadates - see peaks juhtuma - aga pigem tagajärjena kui eelisena).
Toote elutsükkel ja teenuse elutsükkel
Vaadake veel kord ülaltoodud diagrammi. Pole juhus, et ma märkisin ettevõtte eraldi versiooni elutsükli kahanemist - tänapäevastes tingimustes on ettevõtte edukuse määravaks versioonide vahel ülemineku kiirendamine. Toote edukuse määrab selles sisalduvate ärihüpoteeside testimise kiirus. Ja siin peitub minu arvates mikroteenuste arhitektuuri peamine eelis. Aga lähme järjekorras.
Liigume edasi infosüsteemide evolutsiooni järgmisse etappi – SOA teenustele orienteeritud arhitektuuri juurde. Niisiis, mingil kindlal hetkel tõstsime oma tootes esile pikaealised teenused - pikaealine selles mõttes, et toote versioonide vahel liikudes on võimalus, et teenuse elutsükkel on pikem kui toote järgmise versiooni elutsükkel. Loogiline oleks neid üldse mitte muuta – meie Oluline on järgmisele versioonile ülemineku kiirus. Kuid paraku oleme sunnitud teenustes pidevalt muudatusi tegema – ja siin töötab meie jaoks kõik, DevOpsi tavad, konteinerisse paigutamine ja nii edasi – kõik, mis pähe tuleb. Kuid need pole ikkagi mikroteenused!
Mikroteenused kui vahend keerukuse vastu võitlemiseks... konfiguratsioonihaldus
Ja siin saame lõpuks liikuda edasi mikroteenuste määrava rolli juurde – see on lähenemine, mis lihtsustab toote konfiguratsioonihaldust. Täpsemalt kirjeldab iga mikroteenuse funktsioon täpselt domeeni mudeli järgi toote sees olevat ärifunktsiooni - ja need on asjad, mis ei ela mitte lühiajalises versioonis, vaid pikaajalises ärivõimaluses. Ja üleminek toote järgmisele versioonile toimub sõna otseses mõttes märkamatult - muudate/lisate ühte mikroteenust ja võib-olla ka lihtsalt nende suhtluse skeemi ning äkki leiate end tulevikust, jättes selja taha nutvad konkurendid, kes jätkavad hüppamist versioonide vahel. nende monoliite. Kujutage nüüd ette, et on olemas üsna suur hulk eelmääratletud liideste ja ärivõimalustega mikroteenuseid. Ja sina tuled ja ehitad valmis mikroteenustest oma toote struktuuri – lihtsalt joonistades näiteks skeemi. Õnnitleme – teil on platvorm – ja nüüd saate enda jaoks äri meelitada. Unistused Unistused.
Järeldused
- Süsteemi arhitektuuri peaks määrama selle komponentide elutsükkel. Kui komponent elab tooteversiooni sees, ei ole mõtet mikroteenuse lähenemisviisi kasutades süsteemi keerukamaks muuta.
- Mikroteenuste arhitektuur peaks põhinema domeenimudelil – kuna ärivõimalus on kõige pikema elueaga domeen
- Tarnetavad (DevOps praktikad) ja orkestreerimine on mikroteenuste arhitektuuri jaoks ühed olulisemad – põhjusel, et komponentide muutumise kiiruse kasv seab tarnekiirusele ja kvaliteedile kõrgemaid nõudmisi.
Allikas: www.habr.com