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.
В monolitoa jorratu dugu eta monolitoak arazo ugari dituela ondorioztatu dugu: tamaina, konektibitatea, hedapena, eskalagarritasuna, fidagarritasuna eta zurruntasuna.
Oraingoan sistema bat modulu/liburutegien (osagaietara bideratutako arkitektura) edo zerbitzuen (zerbitzuetara zuzendutako arkitektura) multzo gisa antolatzeko aukerei buruz hitz egitea proposatzen dut.
Osagaietara bideratutako arkitektura
Osagaietara zuzendutako arkitekturak sistema bat exekutatzea dakar, egungo zein etorkizuneko proiektuetan erabil daitezkeen osagaien multzo gisa. Sistema bat osagaietan banatzean, honako hauek hartzen dira kontuan: haien berrerabilgarritasuna, ordezkagarritasuna, testuinguruaren independentzia, hedagarritasuna, kapsulatzea eta independentzia.
Osagaiak behar bezala erabilita, “zikinkeria bola handia” (tamaina handia + akoplamendu handia) arazoa konpontzen da, eta osagaiak beraiek muntaketa-unitateak (moduluak, liburutegiak) zein hedapen-unitateak (zerbitzuak) izan daitezke. Inplementazio-unitateak ez dira beti exekutatzen ari den prozesuarekin mapatzen: adibidez, web aplikazio bat eta datu-base bat batera zabaltzen dira.
Gehienetan, monolitoak modulu multzo gisa garatzen dira. Ikuspegi honek garapen independentea dakar, baina eskalatze eta hedapen independentearen arazoak, akatsen tolerantzia eta teknologia pila orokorretik independentziaren arazoak diraute. Horregatik, modulua osagai partzialki independentea da.
Horrelako monolito baten arazo handiena moduluetan zatitzea guztiz logikoa dela eta garatzaileek erraz urratu dezaketela da. Oinarrizko modulu bat ager daiteke, pixkanaka zabortegi bihurtzen dena, moduluen arteko mendekotasun grafikoa hazi daiteke, etab. Arazo horiek saihesteko, garapena oso heldu den talde batek egin behar du, edo lanaldi osoko kodea berrikusten diharduen "arkitekto" baten gidaritzapean eta egitura logikoa urratzen duten garatzaileen eskuak jotzen dituena.
Monolito "ideala" logikoki bereizitako moduluen multzoa da, eta horietako bakoitzak bere datu-basean begiratzen du.
Zerbitzuetara bideratutako arkitektura
Sistema zerbitzu multzo baten moduan antolatu behar bada, zerbitzuetara bideratutako arkitekturaz ari gara. Bere printzipioak erabiltzaileengan zentratutako aplikazioen elkarreragingarritasuna, negozio-zerbitzuen berrerabilpena, teknologia pilaren independentzia eta autonomia (eboluzio independentea, eskalagarritasuna eta hedapena) dira.
Zerbitzuetara zuzendutako arkitekturak (SOA = service oriented architecture) monolito baten identifikatutako arazo guztiak konpontzen ditu: aldaketa bat gertatzen denean zerbitzu bakarrari eragiten dio, eta ondo definitutako API batek osagaien kapsulatze ona onartzen du.
Baina dena ez da hain leuna: SOAk arazo berriak sortzen ditu. Urruneko deiak tokikoak baino garestiagoak dira, eta osagaien artean ardurak birbanatzea nabarmen garestitu da.
Bide batez, hedapen independentea egiteko aukera zerbitzuaren ezaugarri oso garrantzitsua da. Zerbitzuak batera hedatu behar badira edo, gainera, sekuentzia jakin batean, orduan sistema ezin da zerbitzuetara zuzendutakotzat jo. Kasu honetan, banatutako monolito bati buruz hitz egiten dute (SOAren ikuspuntutik ez ezik, mikrozerbitzuen arkitekturaren ikuspuntutik ere kontrako eredutzat hartzen da).
Zerbitzuetara bideratutako arkitekturak ongi onartzen dute arkitektura komunitateak eta saltzaileek. Honek ikastaro eta ziurtagiri asko egotea dakar, ondo garatutako ereduak. Azken honek, adibidez, enpresa-zerbitzu-bus ezaguna (ESB = enpresa-zerbitzu-busa). Aldi berean, ESB saltzaileen ekipajea da; ez du zertan SOAn erabili behar.
Zerbitzuetara bideratutako arkitekturaren ospeak 2008 inguruan jo zuen goia, eta, ondoren, gainbehera hasi zen, mikrozerbitzuen etorreraren ondoren nabarmenagoa izan zena (~ 2015).
Ondorioa
Informazio-sistemak zerbitzu eta modulu moduan antolatzeko aukerak eztabaidatu ondoren, azkenik, mikrozerbitzuen arkitekturaren printzipioetara pasatzea eta arreta berezia jartzea mikrozerbitzuen arkitekturaren eta zerbitzuetara bideratutako arkitekturaren arteko desberdintasunari hurrengo zatian proposatzen dut.
Iturria: www.habr.com