Arhitektuuristiili valik (osa 2)

Tere, Habr. Täna jätkan artiklite seeriat, mille kirjutasingi uue kursuse alguseks „Software Architect“.

Sissejuhatus

Arhitektuuristiili valik on üks peamisi tehnilisi otsuseid teabe süsteemi loomisel. Selles artiklite seerias käsitleme kõige populaarsemaid rakenduste arhitektuuristiile ja vastame küsimusele, millal on milline arhitektuuristiil kõige eelistatum. Käsitlen loogilist ahelat, mis selgitab arhitektuuristiilide arengut monoliitsetest mikroteenustele.

Uues eelmine kord Me oleme uurinud monoliiti ja jõudnud järeldusele, et monoliidil on mitmeid probleeme: suurus, seotus, juurutamine, skaleeritavus, usaldusväärsus ja jäikus.

Seekord soovin rääkida süsteemi korraldamise võimalustest modulaarsena/raamatukogude kujul (komponendipõhine arhitektuur) või teenustena (teenuspõhine arhitektuur).

Komponendipõhine arhitektuur

Komponendipõhine arhitektuur tugineb süsteemi ülesehitusele, mis koosneb komponentidest, mida saab kasutada nii praegustes kui ka tulevastes projektides. Süsteemi komponentideks jagamisel arvestatakse: nende korduvkasutatavust, asendatavust, kontekstist sõltumatust, laiendatavust, kapseldatavust ja iseseisvust.

Õigesti kasutades ei teki probleemi „suure räpane komaga” (suurus + kõrge seotus), ja komponendid võivad esindada nii kogumisi (modulid, raamatukogud) kui ka juurutamisüksusi (teenused). Juurutamisüksused ei pruugi alati olla seotud käivitatava protsessiga: näiteks veebirakendus ja andmebaas juurutatakse koos.

Enamasti arendatakse monoliite modulaarsete komplektidena. See lähenemine tagab arenduse iseseisvuse, kuid samas jäävad probleemid iseseisva skaleeritavuse ja juurutamise, tõrke- ja tehnoloogiahalli sõltumatuse lahendamata. Seetõttu on moodul osaliselt iseseisev komponent.

Selle monoliidi peamine probleem on see, et jagamine mooduliteks on puhtalt loogiline ja arendajad võivad seda kergesti rikkuda. Võib tekkida core moodul, mis järk-järgult muutub prügilaks, moodulite vahel võivad sõltuvuste grafid paisuda jne. Selliste probleemide vältimiseks peaks arendus toimuma kas väga küpse meeskonna poolt või „arhitekti” juhendamisel, kes töötab täistööajaga koodivaatamiste kallal ja hoiab silma peal loogilist struktuuri rikkuvatel arendajatel.

„Täiuslik” monoliit on koosnev loogiliselt eraldatud moodulitest, millest igaühel on oma andmebaas.

Teenuspõhine arhitektuur

Kui siiski plaanitakse süsteemi korraldada teenuste kogumina, siis räägime teenustepõhisest arhitektuurist. Selle printsiibid: rakenduste ühilduvus, kasutajakesksus, äriteenuste korduv kasutamine, sõltumatud tehnoloogiakomplektidest ja autonoomsus (iseseisev evolutsioon, skaleeritavus ja rakendamine).

Teenustepõhine arhitektuur (SOA = service oriented architecture) lahendab kõik monoliidi probleemid: muudatuste korral mõjutatakse ainult teenust, samas kui selgelt määratletud API toetab head komponentide kapseldamist.

Kuid mitte kõik ei ole nii sujuv: SOA toob esile uusi probleeme. Kaugkutsed on kallimad kui kohalikud ning ülesannete jaotamine komponentide vahel muutus oluliselt kallimaks.

Muide, iseseisva rakendamise võimalus on teenuse väga oluline omadus. Kui teenuseid tuleb rakendada koos või veelgi enam, kindlas järjestuses, siis ei saa süsteemi pidada teenustepõhiseks. Sellisel juhul räägitakse hajutatud monoliidist (mis loetakse antipatterniks mitte ainult SOA vaatepunktist, vaid ka mikroteenuste arhitektuurist).

Teenustepõhist arhitektuuri toetavad hästi arhitektuuri kogukond ja tarnijad. Seetõttu on olemas palju kursusi ja sertifikaate, samuti hästi läbi töötatud mustreid. Nendesse kuulub näiteks tuntud ettevõtte teenuste buss (ESB = enterprise service bus). Samas on ESB tarnijate pagas, see ei pea tingimata olema SOA-s kasutusel.

Teenustepõhise arhitektuuri populaarsuse tipp langes umbes 2008. aastasse, pärast mida see hakkas langema, mis muutus oluliselt järsemaks pärast mikroteenuste ilmumist (~2015. aasta).

Kokkuvõte

Pärast seda, kui oleme arutanud võimalusi teabe süsteemide korraldamiseks teenuste ja moodulitena, soovitan lõpuks liikuda mikroteenuste arhitektuuri printsiipide juurde ja pöörata erilist tähelepanu mikroteenuste arhitektuuri eristumisele teenustepõhisest järgmises osas.

Allikas: habr.com