Mikrozerbitzuen arkitekturaren gaiari buruzko artikulu bat idatzi nahi nuen denbora luzez, baina bi gauzak geldiarazten ninduten: zenbat eta gehiago sakondu gaian, orduan eta gehiago iruditzen zitzaidan ezagutzen dudana agerikoa dela eta zer egiten dudana. Ez dakit aztertu eta aztertu behar da. Bestalde, uste dut dagoeneko badagoela zer eztabaidatu publiko zabal baten artean. Beraz, iritzi alternatiboak ongi etorriak dira.
Conway-ren legea eta negozioaren, erakundearen eta informazio-sistemaren arteko harremana
Berriro ere aipatzeko aukera emango diot:
"Sistema bat (zentzu zabalean) diseinatzen duen edozein erakundek diseinu bat jasoko du, zeinaren egiturak erakunde horretako taldeen egitura errepikatzen duen".
- Melvyn Conway, 1967
Nire ustez, lege honek negozio bat antolatzearen bideragarritasunarekin erlazionatzen du, zuzenean informazio sistemarekin baino. Adibide batekin azalduko dut. Demagun nahiko egonkorra den negozio-aukera bat dugula, hain luzeko bizitza-zikloarekin, non zentzuzkoa den enpresa bat antolatzeak (hau ez da akatsa, baina lapurtu dudan termino hau asko gustatzen zait). Jakina, negozio honen euskarri-sistema. antolamenduz eta prozesuz negozio honi dagozkio .
Informazio sistemen negozio-orientazioa
Adibide batekin azalduko dut. Demagun pizza saltzen duen negozio bat antolatzeko negozio aukera dagoela. V1 bertsioan (dei dezagun aurre-informazioa), konpainia pizzeria, kutxazain bat eta entrega zerbitzua zen. Bertsio honek luze iraun zuen ingurumen-aldakortasun txikiko baldintzetan. Gero, 2. bertsioa etorri zen hura ordezkatzeko - aurreratuagoa eta arkitektura monolitikoko negozioetarako informazio-sistema bat erabiltzeko gai. Eta hemen, nire ustez, injustizia izugarria besterik ez dago monolitoei dagokienez - ustez arkitektura monolitikoa ez dator bat domeinuko negozio ereduarekin. Bai, hori horrela balitz, sistemak ezingo luke batere funtzionatuko, Conwayren lege eta zentzu beraren kontraesanean. Ez, arkitektura monolitikoa guztiz koherentea da negozio-garapenaren fase honetan negozio-ereduarekin; noski, sistema dagoeneko sortu eta martxan jarri den etapa esan nahi dut. Gertaera guztiz zoragarria da ikuspegi arkitektonikoa edozein dela ere, zerbitzuetara zuzendutako arkitekturaren 3. bertsioa eta mikrozerbitzuen arkitekturaren N bertsioa berdin-berdin funtzionatuko dutela. Zein da harrapaketa?
Dena dabil, dena aldatzen da edo mikrozerbitzuak konplexutasunari aurre egiteko baliabideak dira?
Jarraitu aurretik, ikus ditzagun mikrozerbitzuen arkitekturari buruzko zenbait uste oker.
Mikrozerbitzuen ikuspegia erabiltzearen aldekoek askotan esaten dute monolito bat mikrozerbitzuetan apurtzeak garapenaren ikuspegia errazten duela zerbitzu indibidualen kodearen oinarria murriztuz. Nire ustez, adierazpen hau erabateko zentzugabekeria da. Serio, kode monolito eta homogeneo baten barruan dagoen interakzioa konplikatua dirudi? Benetan horrela balitz, proiektu guztiak mikrozerbitzu gisa eraikiko lirateke hasieran, praktikak erakusten duen bitartean monolitotik mikrozerbitzuetara migratzea askoz ohikoagoa dela. Konplexutasuna ez da desagertzen; modulu indibidualetatik interfazeetara (izan datu-busak, RPC, APIak eta beste protokolo batzuk) eta orkestrazio sistemetara igarotzen da. Eta hau zaila da!
Pila heterogeneoa erabiltzearen abantaila ere zalantzazkoa da. Ez dut argudiatuko hori ere posible denik, baina errealitatean oso gutxitan gertatzen da (Aurrera begira -hau gertatu beharko litzateke-, abantaila gisa baino ondorio gisa baizik).
Produktuen bizi-zikloa eta zerbitzu-bizi-zikloa
Eman beste begirada bat goiko diagramari. Ez da kasualitatea negozio baten bertsio bereizi baten bizi-zikloaren beherakada nabaritzea; baldintza modernoetan, negozio baten trantsizioa bizkortzea da bere arrakastarako erabakigarria. Produktu baten arrakasta negozioaren hipotesiak probatzeko abiadurak zehazten du. Eta hemen dago, nire ustez, mikrozerbitzuen arkitekturaren abantaila nagusia. Baina goazen ordenan.
Joan gaitezen informazio sistemen bilakaeraren hurrengo fasera: SOA zerbitzuetara bideratutako arkitekturara. Beraz, une jakin batean gure produktuan nabarmendu genuen iraupen luzeko zerbitzuak - Bizitza luzea, produktu baten bertsioen artean mugitzean, zerbitzuaren bizi-zikloa produktuaren hurrengo bertsioaren bizi-zikloa baino luzeagoa izateko aukera dago. Logikoa litzateke horiek batere ez aldatzea βgukβ Garrantzitsuena hurrengo bertsiorako trantsizio-abiadura da. Baina, tamalez, zerbitzuetan etengabeko aldaketak egitera behartuta gaude -eta hemen denak funtzionatzen digu, DevOps praktikak, edukiontzia eta abar- burura etortzen zaigun guztia. Baina hauek oraindik ez dira mikrozerbitzuak!
Mikrozerbitzuak konplexutasunari aurre egiteko baliabide gisa... konfigurazio kudeaketa
Eta hemen, azkenik, mikrozerbitzuen definizio-eginkizunera pasa gaitezke - produktuen konfigurazioaren kudeaketa errazten duen ikuspegia da. Xehetasun gehiagorekin, mikrozerbitzu bakoitzaren funtzioak produktuaren barruko negozio-funtzioa zehazki deskribatzen du domeinu-ereduaren arabera, eta horiek ez dira iraupen laburrean bertsio batean bizi diren gauzak, baizik eta iraupen luzeko negozio-aukera batean. Eta produktuaren hurrengo bertsiorako trantsizioa literalki ohartu gabe gertatzen da - mikrozerbitzu bat aldatzen/gehitzen duzu, eta agian haien elkarrekintzaren eskema besterik ez, eta bat-batean etorkizunean aurkitzen zara, bertsioen artean jauzi egiten jarraitzen duten lehiakide negarrez atzean utziz. haien monolitoak. Orain imajinatu mikrozerbitzuen bolumen handi samarra dagoela aurrez definitutako interfazeekin eta negozio-gaitasunekin. Eta prest dauden mikrozerbitzuetatik zure produktuaren egitura eraikitzen duzu, diagrama bat marraztuz, adibidez. Zorionak - plataforma bat duzu - eta orain negozioak erakar ditzakezu. Ametsak Ametsak.
Findings
- Sistemaren arkitektura bere osagaien bizi-zikloaren arabera zehaztu behar da. Osagai bat produktuaren bertsio batean bizi bada, ez du balio sistemaren konplexutasuna areagotzea mikrozerbitzuen ikuspegia erabiliz.
- Mikrozerbitzuen arkitektura domeinu-ereduan oinarritu behar da, negozio-aukera iraupen luzeko domeinua delako
- Bidalketa praktikak (DevOps praktikak) eta orkestrazioa mikrozerbitzuen arkitekturarako garrantzitsuenetako bat dira - osagaien aldaketa-tasa handitzeak entregaren abiadura eta kalitatearen eskakizunak areagotzen dituelako.
Iturria: www.habr.com