Kaixo, habr. Ikastaro berri baterako izen-ematea zabalik dago oraintxe bertan OTUSen . Ikastaroa hasi bezperan, nire jatorrizko artikulua partekatu nahi dut zuekin.
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.
Historia apur bat
Garatzaileei galdetzen saiatzen bazara: "Zergatik behar ditugu mikrozerbitzuak?", hainbat erantzun jasoko dituzu. Entzungo duzu mikrozerbitzuek eskalagarritasuna hobetzen dutela, kodea ulertzeko errazago egiten dutela, akatsen tolerantzia hobetzen dutela eta batzuetan "zure kodea garbitzeko" aukera ematen dutela entzungo duzu. Ikus dezagun historia mikrozerbitzuen sorreraren atzean dagoen helburua ulertzeko.
Laburbilduz, gure egungo ulerkeran mikrozerbitzuak honela sortu ziren: 2011n, James Lewis-ek, hainbat enpresaren lana aztertuz, arreta jarri zuen "mikro-aplikazio" eredu berri baten sorreran, zeinak SOA optimizatu zuen hedapena bizkortzeari dagokionez. zerbitzuak. Zertxobait beranduago, 2012an, arkitekturaren goi bilera batean, ereduari mikrozerbitzu izena jarri zioten. Horrela, mikrozerbitzuak ezartzearen hasierako helburua ezagunak hobetzea zen merkaturatzeko garaia.
Mikrozerbitzuak gorakada handian zeuden 2015ean. Zenbait ikerketaren arabera, ez zen hitzaldi bakar bat ere osatu mikrozerbitzuen gaiari buruzko txostenik gabe. Gainera, hitzaldi batzuk mikrozerbitzuei soilik eskaini zaizkie. Gaur egun, proiektu asko arkitektura-estilo hau erabiltzen hasten dira, eta proiektuak ondare-kode asko baditu, seguruenik mikrozerbitzuetara migrazioa aktiboki egiten ari da.
Aurreko guztia gorabehera, garatzaile kopuru nahiko txiki batek oraindik definitu dezake "mikrozerbitzua" kontzeptua. Baina honetaz apur bat geroago hitz egingo dugu...
Monolitoa
Mikrozerbitzuak kontrastatzen dituen arkitektura estiloa monolitoa da (edo bat-batean). Seguruenik, ez du zentzurik monolito bat zer den esateak, beraz, berehala zerrendatuko ditut arkitektura-estilo honen desabantailak, estilo arkitektonikoak garatzen hasi zirenak: tamaina, konektibitatea, hedapena, eskalagarritasuna, fidagarritasuna eta zurruntasuna. Jarraian, hutsune bakoitzari bereizita begiratzea proposatzen dut.
tamaina
Monolitoa oso handia da. Eta normalean datu-base oso handi batekin komunikatzen da. Aplikazioa handiegia bihurtzen da garatzaile batek ulertzeko. Kode hau lantzen denbora asko eman dutenek bakarrik lan egin dezakete monolitoarekin, hasiberriek, berriz, denbora asko igaroko dute monolitoa asmatzen saiatzen eta ez dago asmatuko duten bermerik. Normalean, monolito batekin lan egiten denean, beti dago "baldintzadun" seniorren bat, monolitoa gutxi-asko ondo ezagutzen duena eta urte eta erdiko epean beste garatzaile berrien eskuak jotzen dituena. Jakina, baldintzapeko senior bat porrot puntu bakarra da, eta bere irteerak monolitoaren heriotza ekar dezake.
Lotura
Monolitoa "lokatz bola handia" da, eta aldaketak ezusteko ondorioak ekar ditzake. Leku batean aldaketak eginez, monolitoa beste batean kaltetu dezakezu (Β«belarria urratu zenuen, *@ erori zenΒ» bera). Monolitoko osagaiek harreman oso konplexuak eta, batez ere, begi-bistakoak ez izateagatik gertatzen da.
Inplementazioa
Monolito bat zabaltzea, bere osagaien arteko harreman konplexuak direla eta, prozesu luzea da erritual propioa duena. Horrelako erritual bat normalean ez dago guztiz estandarizatua eta "ahoz" transmititzen da.
Eskalagarritasuna
Monolith moduluek baliabide-behar kontrajarriak izan ditzakete, hardwareari dagokionez konpromisoa hartu behar delarik. Imajinatu A eta B zerbitzuez osatutako monolito bat duzula. A zerbitzua disko gogorraren tamaina eskatzen du, eta B zerbitzua RAMan. Kasu honetan, monolitoa instalatuta dagoen makinak bi zerbitzuen eskakizunak onartu behar ditu, edo eskuz, zerbitzuetako bat artifizialki desgaitu beharko duzu.
Beste adibide bat (klasikoagoa): A zerbitzua B zerbitzua baino askoz ere ezagunagoa da, beraz, 100 zerbitzu A eta 10 zerbitzu B egotea nahi duzu. Berriz ere, bi aukera: edo 100 monolito guztiz zabaltzen ditugu, edo batzuetan. B zerbitzuak eskuz desgaitu beharko dira.
Fidagarritasuna
Zerbitzu guztiak batera kokatzen direnez, monolitoa erortzen bada, zerbitzu guztiak aldi berean erortzen dira. Izan ere, baliteke hori ez izatea hain txarra, gutxienez ez da hutsegite partzialik egongo sistema banatu batean, baina, bestalde, erabiltzaileen % 0.001ek erabiltzen duen funtzionalitate akats baten ondorioz, erabiltzaile guztiak gal ditzakezu. zure sistemaren.
Inertzia
Monolitoaren tamaina dela eta, zaila da teknologia berrietara aldatzea. Ondorioz, senior berari eustea aparteko zeregina da. Proiektu baten hasieran aukeratutako pila teknologikoa produktuaren garapena oztopatzen duen bloke bihur daiteke.
Ondorioa
Hurrengoan, jendeak arazo hauek konpontzen saiatu diren osagaietara eta SOAra pasatuz hitz egingo dugu.
Irakurri gehiago:
Iturria: www.habr.com