Tere, Habr. Täna jätkan väljaannete sarja, mille kirjutasin spetsiaalselt kursuse uue voo alustamiseks. .
Sissejuhatus
Arhitektuuristiili valik on infosüsteemi ehitamisel üks fundamentaalseid tehnilisi otsuseid. Selles artiklite sarjas teen ettepaneku analüüsida ehitusrakenduste kõige populaarsemaid arhitektuuristiile ja vastata küsimusele, millal on kõige eelistatavam arhitektuuristiil. Esitluse käigus püüan joonestada loogilise ahela, mis selgitab arhitektuuristiilide arengut monoliitidest mikroteenusteni.
В tegelesime monoliidiga ja jõudsime järeldusele, et monoliidil on mitmeid probleeme: suurus, ühenduvus, kasutuselevõtt, mastaapsus, töökindlus ja jäikus.
Seekord teen ettepaneku rääkida süsteemi korraldamise võimalustest moodulite/teekide kogumina (komponentorienteeritud arhitektuur) või teenustena (teenusele orienteeritud arhitektuur).
Komponentidele orienteeritud arhitektuur
Komponentidele orienteeritud arhitektuur hõlmab süsteemi käivitamist komponentide kogumina, mida saab kasutada nii praegustes kui ka tulevastes projektides. Süsteemi komponentideks jagamisel võetakse arvesse: nende korduvkasutatavus, asendatavus, kontekstist sõltumatus, laiendatavus, kapseldatavus ja sõltumatus.
Komponentide õigel kasutamisel lahendatakse “suure mustusepalli” probleem (suur suurus + kõrge haakeseade) ning komponendid ise võivad esindada nii montaažiüksusi (mooduleid, teeke) kui ka juurutusüksusi (teenuseid). Juurutusüksused ei ole alati jooksva protsessiga seotud: näiteks juurutatakse veebirakendus ja andmebaas koos.
Kõige sagedamini töötatakse monoliite välja moodulite komplektina. See lähenemine viib iseseisva arenguni, kuid sõltumatu skaleerimise ja juurutamise, tõrketaluvuse ja üldisest tehnoloogiavirust sõltumatuse probleemid jäävad alles. Seetõttu on moodul osaliselt sõltumatu komponent.
Suurim probleem sellise monoliidi puhul on see, et mooduliteks jaotus on puhtalt loogiline ja arendajad võivad seda kergesti rikkuda. Võib tekkida tuumikmoodul, mis muutub järk-järgult prügimäeks, moodulite vaheliste sõltuvuste graafik võib kasvada jne. Selliste probleemide vältimiseks peaks arendustöö toimuma kas väga küpse meeskonna poolt või täiskohaga koodiülevaatusega tegeleva “arhitekti” juhendamisel, kes lööb käed loogilist struktuuri rikkuvatele arendajatele.
"Ideaalne" monoliit on loogiliselt eraldatud moodulite komplekt, millest igaüks vaatab oma andmebaasi.
Teenusele orienteeritud arhitektuur
Kui süsteem peaks olema organiseeritud teenuste komplekti kujul, siis räägime teenustele orienteeritud arhitektuurist. Selle põhimõtted on kasutajakeskne rakenduste koostalitlusvõime, äriteenuste taaskasutamine, tehnoloogiapaki sõltumatus ja autonoomia (sõltumatu areng, mastaapsus ja juurutamine).
Teenusele orienteeritud arhitektuur (SOA = service oriented architecture) lahendab kõik monoliidi tuvastatud probleemid: muudatus mõjutab ainult ühte teenust ja täpselt määratletud API toetab komponentide head kapseldamist.
Kuid kõik pole nii sujuv: SOA tekitab uusi probleeme. Kaugkõned on kallimad kui kohalikud ja vastutuse ümberjagamine komponentide vahel on muutunud oluliselt kallimaks.
Muide, iseseisva juurutamise võimalus on teenuse väga oluline omadus. Kui teenuseid tuleb juurutada koos või pealegi kindlas järjestuses, siis ei saa süsteemi pidada teenusekeskseks. Sel juhul räägitakse hajutatud monoliidist (mida peetakse antimustriks mitte ainult SOA, vaid ka mikroteenuste arhitektuuri seisukohalt).
Arhitektuurikogukond ja müüjad toetavad hästi teenustele orienteeritud arhitektuuri. See eeldab paljude kursuste ja sertifikaatide olemasolu, hästi välja töötatud mustreid. Viimase alla kuuluvad näiteks üldtuntud ettevõtte teenindusbuss (ESB = enterprise service bus). Samas on ESB hankijate pagas, seda ei pea tingimata SOA-s kasutama.
Teeninduskeskse arhitektuuri populaarsus saavutas haripunkti 2008. aasta paiku, misjärel hakkas see langema, mis muutus oluliselt dramaatilisemaks pärast mikroteenuste tulekut (~2015).
Järeldus
Pärast seda, kui oleme arutanud võimalusi infosüsteemide korrastamiseks teenuste ja moodulitena, teen ettepaneku liikuda lõpuks edasi mikroteenuste arhitektuuri põhimõtete juurde ning pöörata järgmises osas erilist tähelepanu mikroteenuste arhitektuuri ja teenusekeskse arhitektuuri erinevusele.
Allikas: www.habr.com