Tere, Habr. Täna jätan oma artiklite seeriat, mille kirjutasin spetsiaalselt uue kursuse voolu alguseks. .
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.
Viimati rääkisime erinevatest monoliitidest ja komponentide kasutamisest nende loomisel, sealhulgas nii koostekomponentide kui ka juurutuskomponentide kohta. Uurisime teenusetiheduse arhitektuuri.
Nüüd määratleme lõpuks mikroteenuste arhitektuuri peamised omadused.
Arhitektuuride suhted
On oluline mõista, et eelnevate artiklite põhjal võib ükskõik milline teenus olla komponent, kuid mitte iga teenus ei ole mikroteenus.
Mikroteenuste arhitektuuri omadused
Mikroteenuste arhitektuuri põhijooned on:
- Organiseerimine vastavalt ärivõimalustele (Organized around Business Capabilities)
- Tooted, mitte projektid (Products not Projects)
- Nutikas sisenemine ja rumalad kanalid (Smart endpoints and dumb pipes)
- Detsentraliseeritud juhtimine (Decentralized Governance)
- Detsentraliseeritud andmehaldus (Decentralized Data Management)
- Infrastruktuuri automatiseerimine (Infrastructure Automation)
- Veakindel disain (Design for failure)
- Evolutsiooniline disain
Esimene punkt tuleneb teenustele orienteeritud arhitektuurist, kuna mikroteenused on teenuste erijuht. Teised punktid väärivad eraldi käsitlemist.
Organiseerimine vastavalt ärivõimalustele (Organized around Business Capabilities)
On oluline meenutada Conway seadust: organisatsioonid, mis loovad süsteeme, korraldavad nende arhitektuuri kopeerides siseseid suhtlemisstruktuure. Näiteks tuuakse esile juhtum, kus seitse liikmest koosnev meeskond töötas välja seitsme läbimisega kompilaatori, samas kui viiest inimesest koosnev rühm töötas välja viie läbimisega kompilaatori.
Kui räägime monoliitidest ja mikroteenustest, siis olukorras, kus arendus on korraldatud funktsionaalsete osade kaupa (tagaplaan, esiplaan, andmebaasi administraatorid), saame klassikalise monoliidi.
Mikroteenuste saamiseks tuleks meeskondi korraldada vastavalt ärivõimalustele (tellimuste, tarnete, katalooge käsitlevad meeskonnad). Selline organisatsioon võimaldab meeskondadel keskenduda rakenduse konkreetsete osade loomisele.
Tooted, mitte projektid (Products not Projects)
Projektipõhine lähenemine, kus meeskond edastab arendatud funktsionaalsuse teistele meeskondadele mikroteenuste arhitektuuris, ei ole absoluutselt sobiv. Meeskond peab toetama süsteemi kogu selle elutsükli vältel. Amazon, üks mikroteenuste rakendamise lipulaevu, on öelnud: "sa lood toote ja sa käitad selle" ("you build, you run it"). Tootepõhine lähenemine võimaldab meeskonnal tunda äri vajadusi.
Nutikas sisenemine ja rumalad kanalid (Smart endpoints and dumb pipes)
SOA arhitektuur pööras suurt tähelepanu suhtluskanalitele, eelkõige Enterprise Service Bus'ile (ettevõtte teenuste buss). See toob sageli kaasa Erroneous Spaghetti Box'i, st monoliidi keerukus muutub teenuste vaheliste ühenduste keerukuseks. Mikroteenuste arhitektuuris kasutatakse vaid lihtsaid suhtlemisviise.
Detsentraliseeritud juhtimine (Decentralized Governance)
Mikroteenuste võtmeotsused peavad olema tehtud inimestelt, kes tõeliselt arendavad mikroteenuseid. Siin mõistetakse võtmeotsuste all valikuid
programmeermisvõlke, juurutamise metodoloogiaid, avalike liideste lepinguid jne.
Detsentraliseeritud andmehaldus (Decentralized Data Management)
Standardsest lähenemine, kus rakendus toetub ühele andmebaasile, ei suuda arvestada iga konkreetse teenuse eripära. MSA eeldab hajutatud andmehaldust, sealhulgas erinevate tehnoloogiate rakendamist.
Infrastruktuuri automatiseerimine (Infrastructure Automation)
MSA toetab pideva juurutamise ja tarnimise protsesse. Seda on võimalik saavutada ainult protsesside automatiseerimise kaudu. Sellega ei tundugi suure hulga teenuste juurutamine enam hirmutavana. Juurutamiste protsess peab olema igav. Teise aspektina on tegemist teenuste haldamisega tootmisvõttes. Ilma automatiseerimiseta muutub eri operatsioonikeskkondades jooksvaid protsesside haldamine võimatuks.
Veakindel disain (Design for failure)
Arvukad MSA teenused on vigadele altid. Samas on vigade käsitlemine hajutatud süsteemis üsna keeruline ülesanne. Rakenduste arhitektuur peab olema vastupidav sellistele riketele. Rebecca Parsons peab väga oluliseks, et me ei kasuta enam isegi protsessisisest suhtlemist teenuste vahel, vaid kasutame selle asemel suhtlemiseks HTTP-d, mis ei ole kaugeltki nii usaldusväärne.
Evolutsiooniline disain
MSA süsteemi arhitektuur peab arenema järk-järgult. Soovitav on piirata vajalikud muudatused ühe teenuse piiridesse. Samuti tuleb arvestada mõju teistele teenustele. Traditsiooniline lähenemine on püüda seda probleemi lahendada versioonihaldusega, kuid MSA eelneb versioonihalduse kasutamine.
viimase abinõuna.
Kokkuvõte
Käesolevast arutelust saab kokkuvõtvalt sõnastada, mis on mikroteenused. Mikroteenuste arhitektuur on lähenemine eraldi rakenduse arendamiseks väikeste teenuste kogumina, kus iga teenus töötab oma protsessis ja suhtleb kergendatud mehhanismide kaudu, sageli HTTP-ressursside API-liidese kaudu. Need teenused on üles ehitatud ärivõimalustele ja neid saab iseseisvalt juurutada täiesti automatiseeritud juurutusmehhanismiga.
Neid teenuseid iseloomustab minimaalne tsentraliseeritud juhtimine, ning need võivad olla kirjutatud erinevates programmeerimiskeeltes ja kasutada erinevaid andmesalvestustehnoloogiaid.
Allikas: habr.com
