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.
Eelmisel korral rääkisime erinevat tüüpi monoliitidest ja komponentide kasutamisest nende ehitamisel, nii ehituskomponentide kui ka juurutuskomponentide osas. Mõistame teenusekeskset arhitektuuri.
Nüüd määratleme lõpuks mikroteenuste arhitektuuri peamised omadused.
Arhitektuuride seos
Tuleb mõista, et eelmistes artiklites toodud definitsioonide põhjal on iga teenus komponent, kuid mitte iga teenus pole mikroteenus.
Mikroteenuste arhitektuuri omadused
Mikroteenuste arhitektuuri peamised omadused on järgmised:
- Organiseeritud ärivõimaluste ümber
- Tooted, mitte projektid
- Nutikad lõpp-punktid ja lollid torud
- Detsentraliseeritud valitsemine
- Detsentraliseeritud andmehaldus
- Infrastruktuuri automatiseerimine
- Disain ebaõnnestumiseks
- Evolutsioonilise arenguga arhitektuur (Evolutionary Design)
1. punkt pärineb teenustele orienteeritud arhitektuurist, kuna mikroteenused on teenuste erijuht. Muud punktid väärivad eraldi käsitlemist.
Organiseeritud ärivõimaluste ümber
Nüüd on vaja meeles pidada Conway seadust: süsteeme loovad organisatsioonid korrastavad selle arhitektuuri, kopeerides nende organisatsioonide interaktsiooni struktuuri. Näitena võib meenutada kompilaatori loomise juhtumit: seitsmeliikmeline meeskond töötas välja seitsmekäigulise kompilaatori ja viieliikmeline meeskond viiekäigulise kompilaatori.
Kui räägime monoliitidest ja mikroteenustest, siis kui arendust korraldavad funktsionaalsed osakonnad (backend, frontend, andmebaasi administraatorid), siis saame klassikalise monoliidi.
Mikroteenuste saamiseks peavad meeskonnad olema organiseeritud ärivõimekuse järgi (tellimused, saadetised, kataloogimeeskond). See organisatsioon võimaldab meeskondadel keskenduda rakenduse teatud osade loomisele.
Tooted, mitte projektid
Projektilähenemine, kus meeskond annab väljatöötatud funktsionaalsuse teistele meeskondadele üle, on mikroteenuse arhitektuuri puhul täiesti sobimatu. Meeskond peab toetama süsteemi kogu selle elutsükli vältel. Amazon, üks mikroteenuste juurutamise eestvedajaid, märkis: "te ehitate, juhite seda." Tootepõhine lähenemine võimaldab meeskonnal tunnetada ettevõtte vajadusi.
Nutikad lõpp-punktid ja lollid torud
SOA arhitektuur pööras suurt tähelepanu suhtluskanalitele, eriti Enterprise Service Busile. Mis viib sageli eksliku spagettikastini, see tähendab, et monoliidi keerukus muutub teenustevaheliste ühenduste keerukuseks. Mikroteenuste arhitektuur kasutab ainult lihtsaid suhtlusviise.
Detsentraliseeritud valitsemine
Peamised otsused mikroteenuste kohta peaksid langetama inimesed, kes mikroteenuseid tegelikult arendavad. Siin tähendavad võtmeotsused valikuid
programmeerimiskeeled, juurutamise metoodika, avaliku liidese lepingud jne.
Detsentraliseeritud andmehaldus
Tavaline lähenemine, mille puhul rakendus tugineb ühele andmebaasile, ei saa arvestada iga konkreetse teenuse eripäradega. MSA hõlmab detsentraliseeritud andmehaldust, sealhulgas erinevate tehnoloogiate kasutamist.
Infrastruktuuri automatiseerimine
MSA toetab pidevat juurutamise ja tarnimise protsesse. Seda on võimalik saavutada ainult protsesside automatiseerimisega. Samal ajal ei tundu suure hulga teenuste juurutamine enam midagi hirmutavat. Kasutusprotsess peaks muutuma igavaks. Teine aspekt on seotud teenusehaldusega tootekeskkonnas. Ilma automatiseerimiseta muutub erinevates töökeskkondades töötavate protsesside haldamine võimatuks.
Disain ebaõnnestumiseks
Paljud MSA teenused võivad ebaõnnestuda. Samas pole vigade käsitlemine hajutatud süsteemis tühine ülesanne. Rakenduse arhitektuur peab olema selliste tõrgete suhtes vastupidav. Rebecca Parsons peab väga oluliseks, et me ei kasutaks enam isegi teenuste vahelist suhtlust, vaid kasutame suhtluseks HTTP-d, mis pole kaugeltki nii usaldusväärne.
Evolutsioonilise arenguga arhitektuur (Evolutionary Design)
MSA süsteemi arhitektuur peaks arenema evolutsiooniliselt. Soovitav on piirata vajalikke muudatusi ühe teenuse piirides. Arvesse tuleb võtta ka mõju teistele teenustele. Traditsiooniline lähenemisviis on proovida seda probleemi lahendada versioonimise abil, kuid MSA soovitab kasutada versioonimist
viimase abinõuna.
Järeldus
Pärast kõike eelnevat saame sõnastada, mis on mikroteenused. Mikroteenuste arhitektuur on lähenemisviis ühe rakenduse arendamiseks väikeste teenuste kogumina, millest igaüks töötab oma protsessis ja suhtleb kergete mehhanismide, sageli HTTP ressursi API kaudu. Need teenused on üles ehitatud ärivõimalustele ja neid saab täielikult kasutada iseseisvalt
automatiseeritud juurutusmehhanism. Nendel teenustel on minimaalne tsentraliseeritud haldus, mida saab kirjutada erinevates programmeerimiskeeltes ja kasutada erinevaid andmesalvestustehnoloogiaid.
Allikas: www.habr.com