🥇Arhitektuurilise stiili valik (osa 3)

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.

Viimati rääkisime erinevatest monoliitide tüüpides ja komponentidest nende ehitamisel, sealhulgas nii kogumite kui ka juurutamise komponentidest. Tutvusime teenusorienteeritud arhitektuuriga.

Nüüd määratleme lõpuks mikroteenuste arhitektuuri peamised omadused.

Arhitektuuride suhted

Oluline on mõista, et eelnevates artiklite määratluste põhjal on iga teenus komponent, kuid mitte iga teenus on mikroteenus.

Mikroteenuste arhitektuuri omadused

Mikroteenuste arhitektuuri peamised omadused on:

Organiseeritud äri võimaluste järgi (Organized around Business Capabilities)
Tooted, mitte projektid (Products not Projects)
Ahned sisenemispunktid ja rumalad kanalid (Smart endpoints and dumb pipes)
Keskendumine detsentraliseeritud juhtimisele (Decentralized Governance)
Keskendumine detsentraliseeritud andmehaldusele (Decentralized Data Management)
Infrastruktuuri automatiseerimine (Infrastructure Automation)
Vigade kaitse (Design for failure)
Evolutsiooniga arenguga arhitektuur (Evolutionary Design)

Esimene punkt pärineb teenusorienteeritud arhitektuurist, kuna mikroteenused on teenuste erivorm. Teised punktid väärivad eraldi käsitlemist.

Organiseeritud äri võimaluste järgi (Organized around Business Capabilities)

Nüüd on vajalik meenutada Conway seadust: organisatsioonid, kes loovad süsteeme, korraldavad nende arhitektuuri vastavalt nende organisatsioonide koostööstruktuurile. Näitena võib tuua kompilaatori loomise: seitsmest inimesest koosnev meeskond töötas välja seitsme läbimisega kompilaatori, samas kui viie inimesega meeskond lõi viie läbimisega kompilaatori.

Kui räägime monolüütidest ja mikroteenustest, siis juhul, kui arendus on korraldatud funktsionaalsete osakondade kaupa (taust, esiplaan, andmebaasiadministraatorid), saame klassikalise monoliidi.

Mikroteenuste saamiseks tuleb meeskonnad organiseerida vastavalt ärivõimalustele (tellimuste, väljaveo, katalooge käsitlev meeskond). Selline korraldus annab meeskondadele võimaluse keskenduda rakenduse konkreetsete osade loomisele.

Tooted, mitte projektid (Products not Projects)

Ehkki projekti lähenemine, kus meeskond edastab välja arendatud funktsionaalsuse teistele meeskondadele mikroteenuste arhitektuuri korral, ei sobi. Meeskond peab süsteemi toetama kogu selle elutsükli vältel. Ettevõte Amazon, üks mikroteenuste rakendamise lipulaevu, on öelnud: "sa lood toote ja sina ka käivitad selle" ("you build, you run it"). Toote lähenemine võimaldab meeskonnal tajuda äri vajadusi.

Ahned sisenemispunktid ja rumalad kanalid (Smart endpoints and dumb pipes)

SOA arhitektuur on suure tähelepanu pööranud suhtluskanalitele, sealhulgas Enterprise Service Bus'ile (ettevõtte teenuste buss). See toob sageli kaasa Erroneous Spaghetti Box'i, st monoliidi keerukus muutub teenuste vaheliseks keerukuseks. Mikroteenuste arhitektuuris kasutatakse vaid lihtsaid suhtlemisviise.

Keskendumine detsentraliseeritud juhtimisele (Decentralized Governance)

Mikroteenuste põhiteemad peaksid olema inimeste poolt, kes tegelikult arendavad mikroteenuseid. Siin mõistetakse põhiteemade all valikut.
programmeerimiskeeled, juurutamismeetodid, avalike liideste lepingud jne.

Keskendumine detsentraliseeritud andmehaldusele (Decentralized Data Management)

Standardsed lähenemisviisid, kus rakendus toetub ühele andmebaasile, ei saa arvestada iga konkreetse teenuse spetsiifikaga. MSA eeldab andmete detsentraliseeritud haldamist, sealhulgas erinevate tehnoloogiate rakendamist.

Infrastruktuuri automatiseerimine (Infrastructure Automation)

MSA toetab pidevat juurutamise ja kohaletoimetamise protsessi. Seda saab saavutada ainult protsesside automatiseerimise kaudu. Samuti ei näe suuri teenuste juurutamise protsessid enam midagi hirmutavat. Juurutamisprotsess peab muutuma igavaks. Teine aspekt on teenuste haldamine toote keskkonnas. Ilma automatiseerimiseta muutub teiste operatiivkeskkondades käivitatud protsesside haldamine võimatuks.

Vigade kaitse (Design for failure)

Hulgal appetid MSA on talitlushäired. Sellegipoolest on veahaldus jaotatud süsteemis üpris keeruline ülesanne. Rakenduste arhitektuur peab olema sellistele tšehkidele vastupidav. Rebecca Parsons peab väga oluliseks, et me ei kasutaks enam isegi protsessi sisest suhtlemist teenuste vahel, nende vahel suhtlemiseks eelistame HTTP-d, mis ei ole sugugi nii usaldusväärne.

Evolutsiooniga arenguga arhitektuur (Evolutionary Design)

MSA süsteemi arhitektuur peab arenema evolutsiooniliselt. Soovitav on piirata vajalikke muudatusi ühe teenuse piirides. Tuleb samuti arvestada mõju teistele teenustele. Traditsiooniline lähenemine on püüda probleem lahendada versioonihalduse kaudu, kuid MSA eelõuab versioonihalduse kasutamist
äärmiselt äärmuslikuna.

Kokkuvõte

Kokkuvõttes saab sõnastada, mis on mikroteenused. Mikrosüsteemide arhitektuur on lähenemine eraldi rakenduse väljatöötamisele, mis koosneb väikeste teenuste kogumist, millest igaüks töötab oma protsessis ja suhtleb läbi kergendatud mehhanismide, sageli HTTP ressursside API-liidese kaudu. Need teenused on üles ehitatud ärivõimalustele ja neid saab iseseisvalt juurutada täielikult
automaatse juurutusmehhanismi abil. Nende teenuste jaoks on minimaalne tsentraliseeritud haldus, mis võivad olla kirjutatud erinevates programmeerimiskeeltes ja kasutada erinevaid andmehoidlatehnoloogiaid.