Badirudi mikrozerbitzuen gorakada atzean geratu dela. Jada ez dugu astean hainbat aldiz irakurtzen "Nola eraman nuen nire monolitoa 150 zerbitzura". Orain zentzuzko pentsamendu gehiago entzuten ditut: "Ez dut monolitoa gorroto, eraginkortasuna besterik ez dut axola". Hainbat migrazio ere ikusi genituen . Aplikazio handi batetik zerbitzu txikiago batzuetara pasatzean, hainbat arazo berri konpondu beharko dituzu. Zerrenda ditzagun ahalik eta laburren.
Ezarpena: oinarrizko kimikatik mekanika kuantikora
Oinarrizko datu-basea eta aplikazioa atzeko prozesu batekin konfiguratzea prozesu nahiko erraza izan zen. Irakurgaia Github-en argitaratzen dut - eta askotan ordu bat igaro ondoren, ordu pare bat gehienez, dena funtzionatzen du eta proiektu berri bat hasten dut. Kodea gehitzea eta exekutatzea, gutxienez hasierako ingurunerako, lehenengo egunean egiten da. Baina mikrozerbitzuetan ausartzen bagara, hasierako abiarazte-denborak gora egiten du. Bai, orain Docker dugu orkestrazioarekin eta K8 makinen multzo bat, baina programatzaile hasiberri batentzat hori guztia askoz ere konplikatuagoa da. Junior askorentzat, benetan alferrikako konplikazioa den zama da.
Sistema ez da ulertzen erraza
Zentratu gaitezen gure juniorretan une batez. Aplikazio monolitikoekin, akatsen bat gertatuz gero, erraza zen haren jarraipena egitea eta berehala arazketara pasatzea. Orain beste zerbitzu batekin hitz egiten ari den zerbitzu bat dugu, beste zerbitzu bat prozesatzen ari den mezu-bus batean zerbait ilaran jartzen ari dena, eta orduan errore bat gertatzen da. Pieza horiek guztiak bateratu behar ditugu azkenean A Service 11 bertsioa exekutatzen ari dela jakiteko, eta Service E dagoeneko 12 bertsioaren zain dagoela. Hau oso desberdina da nire erregistro bateratu estandartik: terminal/arazketa interaktibo bat erabili behar izatea oinez joateko. prozesuaren bidez urratsez urrats. Arazketa eta ulermena berez zailago bihurtu dira.
Araztu ezin bada, agian probatuko ditugu
Etengabeko integrazioa eta etengabeko garapena ohiko bihurtzen ari dira. Ikusten ditudan aplikazio berri gehienek automatikoki probak sortzen eta exekutatzen dituzte bertsio berri bakoitzean eta erregistratu aurretik probak egin eta berrikusi behar dira. Utzi behar ez diren prozesu bikainak dira eta aldaketa handia izan dute enpresa askorentzat. Baina orain, zerbitzua benetan probatzeko, nire aplikazioaren funtzionamendu-bertsio osoa atera behar dut. Gogoratzen al duzu 8 zerbitzuko K150 klusterra duen ingeniari berri hura? Beno, orain gure CI sistemari sistema horiek guztiak nola ekartzen irakatsiko diogu, dena benetan funtzionatzen duela egiaztatzeko. Esfortzu handiegia da ziurrenik, beraz, zati bakoitza modu isolatuan probatuko dugu: ziur nago gure zehaztapenak nahiko onak direla, APIak garbiak direla eta zerbitzuaren hutsegite bat isolatuta dagoela eta ez diela besteei eragingo.
Konpromiso guztiek dute arrazoi on bat. Ezta?
Arrazoi asko daude mikrozerbitzuetara pasatzeko. Ikusi dut hori malgutasun handiagoa lortzeko, taldeak eskalatzeko, errendimendurako, iraunkortasun hobea emateko. Baina, egia esan, hamarkadak inbertitu ditugu eboluzionatzen jarraitzen duten monolitoak garatzeko tresna eta praktiketan. Teknologia ezberdinetako profesionalekin lan egiten dut. Normalean eskalatzeaz hitz egiten dugu, Postgres datu-baseko nodo bakar baten mugetara iristen direlako. Elkarrizketa gehienak ingurukoak dira .
Baina beti interesatzen zait haien arkitektura ezagutzea. Mikrozerbitzuetarako trantsizioaren zein fasetan daude? Interesgarria da ingeniari gehiago beren aplikazio monolitikoarekin pozik daudela esaten ikustea. Jende askok etekina aterako dio mikrozerbitzuei, eta onurak migrazio-bidean izandako gorabeherak baino handiagoak izango dira. Baina pertsonalki, mesedez, eman nire aplikazio monolitikoa, hondartzan leku bat, eta guztiz pozik nago.
Iturria: www.habr.com