Arhitektuuristiili valik (osa 2)

Tere, Habr. Täna jätan oma artiklite seeriat, mille kirjutasin spetsiaalselt uue kursuse voolu alguseks. „Tarkvara arhitekt“.

Sissejuhatus

Arhitektuuristiili valimine on üks põhitehnilisi otsuseid teabe süsteemi loomisel. Selles artiklite seerias soovin uurida populaarseimaid rakenduste arhitektuuristiile ja vastata küsimusele, millal on mõni arhitektuuristiil kõige eelistatum. Kirjutamise käigus püüan esitada loogilise ahela, mis selgitab arhitektuuristiilide arengut monoliitidest mikroteenusteni.

V eelmine kord Oleme kokku leppinud, et monoliitil on mitmeid probleeme: suurus, seotuse tase, juurutamine, skaleeritavus, usaldusväärsus ja jäikus.

Seekord tahaksin rääkida võimalustest korraldada süsteem moodulite/teekide kogumina (komponentpõhine arhitektuur) või teenustena (teenuspõhine arhitektuur).

Komponentpõhine arhitektuur

Komponentpõhine arhitektuur tähendab, et süsteem koosneb komponentidest, mida saab kasutada nii praegustes kui ka tulevastes projektides. Süsteemi komponentideks jagamisel arvestatakse: nende taaskasutatavust, asendatavust, kontekstitundlikkust, laiendatavust, kapseldatust ja sõltumatust.

Õigesti kasutatavate komponentide abil lahendatakse "suure mustuse kommi" probleem (suure suuruse + kõrge seotus), kuid komponendid võivad olla nagu kogumisse moodulid või raamatukogud kui ka juurutamise üksused (teenused). Juurutamise üksused ei pruugi alati väljenduda teostatavas protsessis: näiteks veebirakendus ja andmebaas juurutatakse koos.

Enamasti arendatakse monoliite moodulite kogumina. Selline lähenemine tagab arendamise iseseisvuse, kuid jätab endale probleemid iseseisva skaleerimise ja juurutamise, tõrkevaru ja sõltumatuse ühest tehnoloogilisest kultuurist. Just seetõttu on moodul - osaliselt iseseisev komponent.

Selle monoliidi kõige olulisem probleem on see, et moodulite jagamine on puhtalt loogiline ja arendajad võivad seda kergesti rikkuda. Võib ilmuda core moodul, mis järk-järgult muutub prügilaks, sõltuvusgraafikud moodulite vahel võivad kasvada jne. Selliste probleemide vältimiseks peab arendustööd tegema kas väga küps meeskond või «arhitekt», kes täiskohaga tegeleb koodi ülevaatamisega ja hoiab arendajaid, kes loogilist struktuuri rikuvad, kontrolli all.

«Ideaalne» monoliit on komplekt loogiliselt eraldatud mooduleid, millest igaühel on oma andmebaas.

Teenusepõhine arhitektuur

Kui siiski plaanitakse süsteemi korraldada teenuste komplekti kujul, räägime teenusepõhisest arhitektuurist. Selle põhimõtted: rakenduste ühilduvus, kasutajale orienteeritud lähenemine, äriteenuste korduv kasutamine, sõltumatus tehnoloogiatest ja autonoomia (sõltumatu areng, skaleeritavus ja rakendatavus).

Teenusele orienteeritud arhitektuur (SOA = teenusele orienteeritud arhitektuur) lahendab kõik monoliidi nähtud probleemid: muudatuste korral mõjutatakse ainult ühte teenust ning selgelt määratletud API toetab head komponendi kapseldamist.

Kuid asjad ei ole nii sujuvad: SOA toob endaga kaasa uusi probleeme. Kaugkutsed on kallimad kui kohalikud, ja kohustuste ümberjaotamine komponentide vahel on muutunud oluliselt kallimaks.

Muide, sõltumatu juurutamise võimalus on teenuse jaoks väga oluline omadus. Kui teenuseid tuleb juurutada koos või, veel enam, kindlas järjestuses, siis ei saa süsteemi pidada teenusele orienteerituks. Sellisel juhul räägitakse jaotatud monoliidist (see loetakse antipatterniks mitte ainult SOA, vaid ka mikroteenuste arhitektuuri seisukohalt).

Teenusorienteeritud arhitektuuri toetavad hästi arhitektuuri kogukond ja teenusepakkujad. Seetõttu on olemas rohkesti kursusi ja sertifikaate ning hästi välja töötatud mustreid. Nende hulka kuulub näiteks tuntud ettevõtte teenuse buss (ESB = enterprise service bus). Sellegipoolest on ESB teenusepakkujate pärand ning see ei pea tingimata olema SOA-s kasutusel.

Teenuseid orienteeritud arhitektuuri populaarsuse tipp langes umbes 2008. aastasse, millele järgnes järkjärguline langus, mis muutus oluliselt järsemaks pärast mikroteenuste ilmumist (~2015. aasta).

Kokkuvõte

Pärast seda, kui oleme arutanud infotehnoloogiasüsteemide korraldamise võimalusi teenuste ja moodulitena, soovin lõpuks liikuda mikroteenuste arhitektuuri põhimõtete juurde, pöörates järgmisel korral erilist tähelepanu mikroteenuste arhitektuuri ja teenuseid orienteeritud arhitektuuri erinevustele.

Allikas: habr.com