Kaixo, Habr. Gaur ikastaroaren korronte berri bati hasiera emateko espresuki idatzi ditudan argitalpen sorta batekin jarraitzen dut. .
Sarrera
Estilo arkitektonikoa aukeratzea informazio-sistema bat eraikitzeko orduan oinarrizko erabaki teknikoetako bat da. Artikulu sorta honetan, eraikuntza-aplikazioetarako arkitektura-estilo ezagunenak aztertzea eta zein arkitektura-estilo hobesten den galderari erantzutea proposatzen dut. Aurkezpen prozesuan, monolitoetatik mikrozerbitzuetara estilo arkitektonikoen garapena azaltzen duen kate logiko bat marrazten saiatuko naiz.
Azken aldian monolito mota ezberdinei eta horiek eraikitzeko osagaien erabilerari buruz hitz egin genuen, bai eraikitzeko osagaiak bai hedatzeko osagaiak. Zerbitzuetara bideratutako arkitektura ulertzen dugu.
Orain, azkenik, mikrozerbitzuen arkitektura baten ezaugarri nagusiak definituko ditugu.
Arkitekturen erlazioa
Aurreko artikuluetan emandako definizioetan oinarrituta, edozein zerbitzu osagai bat dela ulertu behar da, baina zerbitzu guztiak ez direla mikrozerbitzuak.
Mikrozerbitzuen arkitekturaren ezaugarriak
Mikrozerbitzuen arkitekturaren ezaugarri nagusiak hauek dira:
- Negozio-gaitasunen inguruan antolatuta
- Produktuak ez proiektuak
- Amaiera-puntu adimendunak eta tutu mutuak
- Gobernantza Deszentralizatua
- Datuen kudeaketa deszentralizatua
- Azpiegituren Automatizazioa
- Porroterako diseinua
- Garapen ebolutiboa duen arkitektura (Evolutionary Design)
1. puntua zerbitzuetara bideratutako arkitekturatik dator, mikrozerbitzuak zerbitzuen kasu berezi bat direlako. Beste puntu batzuk kontuan hartu behar dira.
Negozio-gaitasunen inguruan antolatuta
Orain beharrezkoa da Conwayren legea gogoratzea: sistemak sortzen dituzten erakundeek bere arkitektura antolatzen dute, erakunde horien baitako elkarrekintzaren egitura kopiatuz. Adibide gisa, konpilatzaile bat sortzearen kasua gogora dezakegu: zazpi laguneko talde batek zazpi pasatako konpilatzaile bat garatu zuen, eta bosteko talde batek bost pasatako konpilatzailea.
Monolitoez eta mikrozerbitzuez ari bagara, orduan garapena sail funtzionalek antolatzen badute (backend, frontend, datu-baseen administratzaileak), orduan monolito klasiko bat lortuko dugu.
Mikrozerbitzuak lortzeko, taldeak negozio-gaitasunaren arabera antolatu behar dira (eskaerak, bidalketak, katalogo-taldea). Antolakuntza honi esker, taldeek aplikazioaren zati zehatzak eraikitzera bideratu ahal izango dira.
Produktuak ez proiektuak
Talde batek garatutako funtzionalitateak beste talde batzuetara transferitzen dituen proiektuaren ikuspegia guztiz desegokia da mikrozerbitzuen arkitektura baten kasuan. Taldeak sistemari lagundu behar dio bere bizitza-ziklo osoan. Amazonek, mikrozerbitzuen inplementazioko liderretako batek, adierazi zuen: "eraikitzen duzu, exekutatzen duzu". Produktuaren ikuspegiari esker, taldeak negozioaren beharrak senti ditzake.
Amaiera-puntu adimendunak eta tutu mutuak
SOA arkitekturak arreta handia jarri zien komunikazio kanalei, bereziki Enterprise Service Bus-ari. Horrek maiz Erroneous Spaghetti Box-era ekartzen du, hau da, monolitoaren konplexutasuna zerbitzuen arteko konexioen konplexutasunean bihurtzen da. Mikrozerbitzuen arkitekturak komunikazio-metodo sinpleak baino ez ditu erabiltzen.
Gobernantza Deszentralizatua
Mikrozerbitzuei buruzko funtsezko erabakiak mikrozerbitzuak benetan garatzen dituzten pertsonek hartu behar dituzte. Hemen, funtsezko erabakiek aukerak esan nahi dituzte
programazio-lengoaiak, hedapen-metodologia, interfaze publikoko kontratuak, etab.
Datuen kudeaketa deszentralizatua
Ikuspegi estandarrak, aplikazioa datu-base bakarrean oinarritzen dena, ezin du kontuan hartu zerbitzu zehatz bakoitzaren berezitasunak. MSAk datuen kudeaketa deszentralizatua dakar, hainbat teknologiaren erabilera barne.
Azpiegituren Automatizazioa
MSAk etengabeko hedapen eta entrega prozesuak onartzen ditu. Hau prozesuak automatizatuz soilik lor daiteke. Aldi berean, zerbitzu ugari zabaltzeak jada ez du zerbait beldurgarria dirudi. Inplementazio prozesua aspergarria bihurtu beharko litzateke. Bigarren alderdia produktu-inguruneko zerbitzuen kudeaketarekin lotuta dago. Automatizaziorik gabe, ingurune eragile ezberdinetan exekutatzen diren prozesuak kudeatzea ezinezkoa bihurtzen da.
Porroterako diseinua
MSA zerbitzu ugari porrot egiteko joera dute. Aldi berean, sistema banatu batean erroreak kudeatzea ez da lan hutsala. Aplikazio-arkitekturak erresistentea izan behar du akats horiei. Rebecca Parsons-ek uste du oso garrantzitsua dela zerbitzuen arteko prozesuan komunikazioa ere ez erabiltzea; horren ordez, HTTPra jotzen dugu komunikaziorako, eta hori ez da hain fidagarria.
Garapen ebolutiboa duen arkitektura (Evolutionary Design)
MSA sistemaren arkitektura ebolutiboki garatu beharko litzateke. Komeni da beharrezkoak diren aldaketak zerbitzu bakar baten mugetara mugatzea. Gainerako zerbitzuetan duen eragina ere kontuan hartu behar da. Ikuspegi tradizionala arazo hau bertsioekin konpontzen saiatzea da, baina MSAk bertsioak erabiltzea proposatzen du
azken aukera gisa.
Ondorioa
Aurreko guztiaren ondoren, mikrozerbitzuak zer diren formula dezakegu. Mikrozerbitzuen arkitektura aplikazio bakar bat zerbitzu txikien bilduma gisa garatzeko hurbilketa bat da, bakoitza bere prozesuan exekutatzen dena eta mekanismo arinen bidez elkarreraginean, askotan HTTP baliabideen API bat. Zerbitzu hauek negozio-gaitasunen arabera eraikitzen dira eta modu independentean inplementa daitezke erabat erabiliz
hedapen-mekanismo automatizatua. Zerbitzu hauen kudeaketa zentralizatuaren gutxieneko maila bat dago, programazio-lengoaia ezberdinetan idatzi daitekeena eta datuak biltegiratzeko teknologia desberdinak erabil daitezkeena.
Iturria: www.habr.com