Hilabeteak eman dituzu zure monolitoa mikrozerbitzuetan birdiseinatzen, eta azkenean denak elkartu dira etengailua iraultzeko. Lehen web orrialdera zoaz... eta ez da ezer gertatzen. Berriro kargatu duzu - eta berriro ere ezer onik ez, gunea hain da motela ez duela minutu batzuetan erantzuten. Zer gertatu da?
Bere hitzaldian, Jimmy Bogardek "autopsia" bat egingo du benetako mikrozerbitzuen hondamendiari buruz. Aurkitu zituen modelatze-, garapen- eta ekoizpen-arazoak erakutsiko ditu, eta bere taldeak poliki-poliki banatutako monolito berria sanoaren azken irudian nola eraldatu zuen. Diseinu-akatsak guztiz saihestea ezinezkoa den arren, diseinu-prozesuaren hasieran gutxienez arazoak identifikatu ditzakezu azken produktua sistema banatu fidagarri bihurtzen dela ziurtatzeko.
Kaixo guztioi, Jimmy naiz eta gaur mikrozerbitzuak eraikitzerakoan mega hondamendiak nola saihestu ditzakezun entzungo duzue. Urte eta erdi inguruan lan egin nuen enpresa baten istorioa da, euren ontziak iceberg batekin talka ez egiteko. Istorio hau behar bezala kontatzeko, denboran atzera egin beharko dugu eta enpresa hau non hasi zen eta bere IT azpiegitura denboran zehar nola hazi den hitz egin beharko dugu. Hondamendi honetan errugabeen izenak babesteko, enpresa honen izena Bell Computers-era aldatu dut. Hurrengo diapositibak 90eko hamarkadaren erdialdean horrelako enpresen IT azpiegiturak nolakoak ziren erakusten du. Hau ordenagailuko hardware-denda funtzionatzeko HP Tandem Mainframe zerbitzari handi unibertsal baten arkitektura tipikoa da.
Eskaerak, salmentak, itzulketak, produktuen katalogoak eta bezero-base guztiak kudeatzeko sistema bat eraiki behar zuten, beraz, garai hartan mainframe irtenbiderik ohikoena aukeratu zuten. Sistema erraldoi honek konpainiari buruzko informazio guztia zuen, ahal zen guztia, eta transakzio guztiak mainframe honen bidez egiten ziren. Arrautza guztiak saski batean gordetzen zituzten eta hori normala zela pentsatu zuten. Hemen sartzen ez den gauza bakarra posta bidezko katalogoak eta eskaerak telefonoz egitea dira.
Denborarekin, sistema gero eta handiagoa izan zen, eta zabor kopuru handia pilatu zen bertan. Gainera, COBOL ez da munduko hizkuntzarik adierazgarriena, beraz, sistema zabor zati handi eta monolitiko bat izan zen. 2000. urterako, ikusi zuten enpresa askok webguneak zeudela, eta horien bidez euren negozio guztia burutzen zuten, eta euren lehen dot-com webgune komertziala eraikitzea erabaki zuten.
Hasierako diseinuak nahiko polita zeukan eta goi-mailako bell.com gune bat eta aplikazio indibidualetarako azpidomeinu batzuek osatzen zuten: catalog.bell.com, accounts.bell.com, orders.bell.com, product search search.bell. com. Azpidomeinu bakoitzak ASP.Net 1.0 markoa eta bere datu-baseak erabiltzen zituen, eta denek sistemaren backendarekin hitz egiten zuten. Hala ere, eskaera guztiak prozesatzen eta exekutatzen jarraitu zuten mainframe handi bakar batean, eta bertan zabor guztia geratzen zen, baina frontend-a webgune bereiziak ziren aplikazio indibidualekin eta datu-base bereiziekin.
Beraz, sistemaren diseinuak ordenatua eta logikoa zuen, baina benetako sistema hurrengo diapositiban erakusten den bezala zen.
Elementu guztiek elkarren artean deiak bideratzen zituzten, APIetara atzitu zituzten, hirugarrenen dll-ak txertatuta eta antzekoak. Askotan gertatzen zen bertsio-kontrol sistemek beste norbaiten kodea hartu, proiektuaren barruan sartzea eta gero dena hautsi egiten zela. MS SQL Server 2005-ek esteka-zerbitzarien kontzeptua erabili zuen, eta diapositibako geziak erakutsi ez nituen arren, datu-baseetako bakoitzak elkarri ere hitz egin zion, ez baitago ezer txarrik taulak eraikitzea hainbat datu-baseetatik lortutako datuetan oinarrituta.
Orain sistemaren eremu logiko desberdinen artean nolabaiteko bereizketa zutenez, hau zikinkeria zati banatua bihurtu zen, eta zabor zati handiena mainframe backend-ean geratzen zen oraindik.
Dibertigarria zen mainframe hau Bell Computers-en lehiakideek eraiki zutela eta haien aholkulari teknikoek mantentzen zutela. Bere aplikazioen errendimendu desegokiaz sinetsita, konpainiak horiek kentzea eta sistema birdiseinatzea erabaki zuen.
Lehendik zegoen aplikazioa 15 urtez egon zen ekoizten, hau da, ASP.Net-en oinarritutako aplikazioen errekorra. Zerbitzuak mundu osoko eskaerak onartu zituen, eta aplikazio bakar honen urteko diru-sarrerak milioi dolarra iritsi ziren. Mozkinaren zati garrantzitsu bat bell.com webguneak sortu zuen. Ostiral Beltzetan, gunearen bidez egindako eskaerak milioi batzuetara iritsi ziren. Hala ere, zegoen arkitekturak ez zuen inolako garapenik ahalbidetzen, sistemaren elementuen interkonexio zurrunek ia ez baitzuten zerbitzuan aldaketarik egin.
Arazorik larriena herrialde batetik eskaera bat egin, beste batean ordaindu eta hirugarren bati bidaltzea izan zen, merkataritza-eskema hori oso ohikoa den mundu mailako enpresetan arren. Lehendik zegoen webguneak ez zuen horrelakorik onartzen, beraz, eskaera horiek telefonoz onartu eta egin behar izan zituzten. Horrek arkitektura aldatzeari buruz gero eta gehiago pentsatzea ekarri zuen konpainiak, batez ere mikrozerbitzuetara aldatzeari buruz.
Gauza adimenduna egin zuten beste enpresei begiratuz antzeko arazo bat nola konpondu zuten ikusteko. Irtenbide horietako bat Netflix zerbitzuen arkitektura izan zen, API baten eta kanpoko datu-base baten bidez konektatutako mikrozerbitzuez osatua.
Bell Computers-eko zuzendaritzak halako arkitektura bat eraikitzea erabaki zuen, oinarrizko printzipio batzuei eutsiz. Lehenik eta behin, datu-bikoizketa ezabatu zuten datu-base partekatuaren ikuspegia erabiliz. Ez zen daturik bidali; aitzitik, behar zuten guztiek iturri zentralizatu batera jo behar zuten. Horren ondoren, isolamendua eta autonomia izan ziren -zerbitzu bakoitza besteekiko independentea zen-. Web APIa erabat denetarako erabiltzea erabaki zuten; datuak lortu nahi bazenitu edo beste sistema batean aldaketak egin nahi bazituen, dena Web APIaren bidez egiten zen. Azken gauza handia "Bell on Bell" izeneko mainframe berri bat izan zen, lehiakideen hardwarean oinarritutako "Bell" mainframearen aurka.
Beraz, 18 hilabetetan zehar, oinarrizko printzipio horien inguruan eraiki zuten sistema eta aurreprodukziora eraman zuten. Asteburuaren ostean lanera itzuliz, garatzaileak elkartu eta sistema berria konektatuta zegoen zerbitzari guztiak aktibatu zituzten. 18 hilabeteko lana, ehunka garatzaile, Bell hardware modernoena - eta emaitza positiborik ez! Honek jende asko etsitu du sistema hau ordenagailu eramangarrietan askotan exekutatu dutelako eta dena ondo zegoelako.
Adimentsuak ziren arazo hau konpontzeko diru guztia botatzeko. Etengailudun zerbitzari-rack modernoenak instalatu zituzten, gigabit zuntz optikoa erabili zuten, RAM kopuru izugarria duen zerbitzari-hardwarerik indartsuena, dena konektatu, konfiguratu eta berriro ere, ezer ez! Orduan, arrazoia denbora-muga izan zitekeela susmatzen hasi ziren, beraz, web-ezarpen guztietan sartu ziren, API-ren ezarpen guztietan eta denbora-muga konfigurazio osoa eguneratu zuten gehienezko balioetara, horrela egin zezaketen guztia eseri eta zerbait gertatuko zen arte itxaron zuten. gunera. Itxaron eta itxaron eta 9 minutu eta erdiz egon ziren webgunea azkenean kargatu arte.
Horren ostean, egungo egoerak azterketa sakon bat behar zuela ohartu ziren, eta gonbidatu gintuzten. Jakin genuen lehenengo gauza izan zen garapenaren 18 hilabete guztietan ez zela benetako "mikro" bat sortu; dena handitu zen. Honen ostean, post-mortem bat idazten hasi ginen, βatzera begirakoβ edo βatzera begirako tristeβ izenez ere ezagutzen dena, βerrua ekaitzβ bezala ere ezagutzen dena, βgarun ekaitzaβ antzekoa, hondamendiaren zergatia ulertzeko.
Hainbat arrasto izan genituen, horietako bat trafikoaren erabateko saturazioa zen API deiaren unean. Zerbitzu-arkitektura monolitiko bat erabiltzen duzunean, berehala uler dezakezu zer gertatu den okerra, hutsegitea eragin zezakeen guztiaren berri ematen duen pila-arrasto bakarra duzulako. Zerbitzu mordo bat aldi berean API bera sartzen den kasuan, ez dago arrastoaren jarraipena egiteko modurik WireShark bezalako sarearen monitorizazio tresna osagarriak erabiltzea izan ezik, horri esker eskaera bakarra aztertu eta inplementazioan zer gertatu den jakin dezakezu. Beraz, web orri bat hartu eta ia 2 aste eman genituen puzzlearen piezak elkartzen, hainbat dei eginez eta bakoitzak zer ekarri zuen aztertzen.
Begira argazki hau. Kanpoko eskaera batek zerbitzuari itzultzen diren barne dei asko egiteko eskatzen diola erakusten du. Ematen du barne dei bakoitzak salto gehigarriak egiten dituela eskaera horri modu independentean eman ahal izateko, ezin duelako beste inora itzuli beharrezko informazioa lortzeko. Irudi honek zentzurik gabeko deien kaskada bat dirudi, kanpoko eskaerak zerbitzu osagarriak deitzen baititu, beste zerbitzu osagarri batzuk deitzen dituztenak, eta abar, ia infinituan.
Diagrama honetako kolore berdeak zirkulu erdi bat erakusten du, zeinetan zerbitzuek elkarri deitzen diote: A zerbitzuak B zerbitzuari deitzen dio, B zerbitzuak C zerbitzuari deitzen dio eta berriro A zerbitzuari deitzen dio. Ondorioz, "banatutako blokeoa" lortzen dugu. Eskaera bakar batek sareko mila API dei sortu zituen, eta sistemak akatsen tolerantziarik eta begizta babesik ez zuenez, eskaerak huts egingo luke API dei horietako batek ere huts egingo balu.
Matematika batzuk egin genituen. API dei bakoitzak 150 ms baino gehiagoko SLA eta % 99,9ko funtzionamendua zuen. Eskaera batek 200 dei ezberdin eragin zituen, eta kasurik onenean, orria 200 x 150 ms = 30 segundotan erakutsi zitekeen. Jakina, hau ez zen ona. %99,9ko erabilgarritasuna 200ez biderkatuta, %0ko erabilgarritasuna lortu dugu. Arkitektura hori hasiera-hasieratik porrotera kondenatuta zegoen.
Garatzaileei galdetu genien nola ez zuten arazo hau antzeman 18 hilabeteko lanaren ondoren? Agertu zen exekutatzen zuten kodearen SLA bakarrik zenbatu zutela, baina bere zerbitzuak beste zerbitzu bat deituz gero, ez zuten denbora hori zenbatu beren SLAn. Prozesu batean abiarazi zen guztia 150 ms-ko balioari atxikitzen zitzaion, baina beste zerbitzu-prozesu batzuetarako sarbideak atzerapen osoa hainbat aldiz handitu zuen. Ikasitako lehen ikasgaia hauxe izan zen: "Zure SLA kontrolatzen al duzu, edo SLAk zu kontrolatzen du?" Gure kasuan, azken hau izan zen.
Deskubritu genuen hurrengo gauza, Peter Deitch-ek eta James Gosling-ek formulatutako konputazio banatuaren kontzeptu okerraren berri bazekitela izan zen, baina lehen zatiari ez zioten jaramonik egin. "Sarea fidagarria da", "zero latentzia" eta "ekarpen infinitua" adierazpenak uste okerrak direla dio. Beste uste okerrak "sarea segurua da", "topologia ez da inoiz aldatzen", "beti dago administratzaile bakarra", "datuen transferentziaren kostua zero da" eta "sarea homogeneoa da".
Akats bat egin zuten beren zerbitzua tokiko makinetan probatu zutelako eta ez zirelako inoiz kanpoko zerbitzuekin konektatu. Lokalean garatzean eta tokiko cachea erabiltzean, ez zuten inoiz sareko saltorik aurkitu. Garapenaren 18 hilabete guztietan, inoiz ez zuten galdetu zer gerta zitekeen kanpoko zerbitzuak kaltetuta egongo balira.
Aurreko irudian zerbitzuen mugak ikusten badituzu, guztiak okerrak direla ikusiko duzu. Zerbitzuen mugak nola definitzeko aholkuak ematen dituzten iturri ugari daude, eta gehienek gaizki egiten dute, Microsoft-ek hurrengo diapositikoan bezala.
Irudi hau "Mikrozerbitzuak nola eraiki" gaiari buruzko MS blogekoa da. Honek web aplikazio sinple bat, negozio-logika bloke bat eta datu-base bat erakusten ditu. Eskaera zuzenean dator, ziurrenik weberako zerbitzari bat egongo da, negoziorako zerbitzari bat eta datu-baserako beste bat. Trafikoa handitzen baduzu, irudia pixka bat aldatuko da.
Hona hemen bi web zerbitzarien artean trafikoa banatzeko karga-orekatzailea, web zerbitzuaren eta negozio-logikaren artean kokatutako cache bat eta negozio-logikaren eta datu-basearen arteko beste cache bat. Hau da, hain zuzen, Bell-ek karga orekatzeko eta hedapen urdin/berdearen aplikaziorako erabili zuen arkitektura 2000ko hamarkadaren erdialdean. Noizbait arte dena ondo funtzionatu zuen, eskema hau egitura monolitiko baterako pentsatuta zegoen eta.
Hurrengo irudiak erakusten du nola MS-k gomendatzen duen monolito batetik mikrozerbitzuetara pasatzea; besterik gabe, zerbitzu nagusietako bakoitza mikrozerbitzu bereizietan zatitzea. Eskema hau ezartzean Bell-ek akats bat egin zuen.
Beren zerbitzu guztiak maila ezberdinetan banatu zituzten, eta horietako bakoitzak banakako zerbitzu asko zituen. Esaterako, web-zerbitzuak edukiak errendatzeko eta autentifikatzeko mikrozerbitzuak barne hartzen zituen, negozio-logika-zerbitzuak eskaerak eta kontuaren informazioa prozesatzeko mikrozerbitzuez osatuta zegoen, datu-basea datu espezializatuekin mikrozerbitzu mordo batean banatuta zegoen. Weba, negozio-logika eta datu-basea estaturik gabeko zerbitzuak ziren.
Hala ere, argazki hau guztiz okerra zen, ez baitzuen mapatu enpresaren IT klusterretik kanpoko negozio-unitaterik. Eskema honek ez zuen kontuan hartzen kanpoko munduarekin inolako loturarik, eta, beraz, ez zegoen argi nola lortu, adibidez, hirugarrenen negozio-analisiak. Kontuan hartzen dut, gainera, hainbat zerbitzu asmatu zituztela, langile indibidualen karrerak garatzeko, ahalik eta jende gehien kudeatu nahi zuten horretarako diru gehiago lortzeko.
Uste zuten mikrozerbitzuetara pasatzea beren barneko N mailako geruza fisikoaren azpiegitura hartzea bezain erraza zela Docker bertan itsatsi. Ikus dezagun N-mailako arkitektura tradizionala nolakoa den.
4 maila ditu: UI erabiltzaile-interfaze maila, negozio logika maila, datu-sarbide maila eta datu-basea. Progresiboagoa da DDD (Domain-Driven Design), edo softwarera zuzendutako arkitektura, non erdiko bi maila domeinu objektuak eta biltegi bat diren.
Arkitektura honetan aldaketa-eremu desberdinak, ardura-eremu desberdinak aztertzen saiatu nintzen. N-mailako aplikazio tipiko batean, egitura bertikalki goitik behera zeharkatzen duten aldaketa-eremu desberdinak sailkatzen dira. Hauek dira Katalogoa, Konfigurazio ezarpenak ordenagailu indibidualetan eta Checkout egiaztapenak, nire taldeak kudeatzen dituenak.
Eskema honen berezitasuna da aldaketa-eremu horien mugek negozio-logika mailan ez ezik, datu-basera ere hedatzen direla.
Ikus dezagun zer esan nahi duen zerbitzu bat izatea. Zerbitzuaren definizio baten 6 propietate bereizgarriak dira: softwarea da:
- erakunde jakin batek sortu eta erabili;
- sistemaren barruan informazio mota jakin baten edukiaren, tratamenduaren eta/edo hornitzearen arduraduna da;
- modu independentean eraiki, zabaldu eta exekutatu daiteke behar operatibo zehatzak asetzeko;
- kontsumitzaileekin eta beste zerbitzu batzuekin komunikatzen da, akordioetan edo kontratu-bermeetan oinarritutako informazioa emanez;
- baimenik gabeko sarbideetatik babesten du eta bere informazioa galtzetik;
- akatsak kudeatzen ditu informazioaren kalterik ez ekartzeko moduan.
Propietate horiek guztiak "autonomia" hitz batean adieraz daitezke. Zerbitzuek bata bestearengandik independentean funtzionatzen dute, zenbait murrizketa betetzen dituzte eta kontratuak definitzen dituzte, zeinen arabera pertsonek behar duten informazioa jaso dezaketen. Ez dut teknologia zehatzik aipatu, erabilera nabaria baita.
Ikus dezagun orain mikrozerbitzuen definizioa:
- mikrozerbitzu bat tamaina txikikoa da eta arazo zehatz bat konpontzeko diseinatuta dago;
- Mikrozerbitzua autonomoa da;
- Mikrozerbitzuen arkitektura bat sortzean, hirigintzaren metafora erabiltzen da. Hau da Sam Newman-en, Building Microservices liburuaren definizioa.
Testuinguru mugatuaren definizioa Eric Evansen Domain-Driven Design liburutik hartua da. Hau DDDren eredu nagusi bat da, arkitektura-diseinu-zentro batean, arkitektura-eredu bolumetrikoekin lan egiten duena, Testuinguru mugatu desberdinetan banatuz eta haien arteko elkarrekintzak esplizituki definituz.
Besterik gabe, Testuinguru mugatuak modulu jakin bat zein esparrutan erabil daitekeen adierazten du. Testuinguru honen barruan logikoki bateratutako eredu bat dago, adibidez, zure negozio-domeinuan ikus daitekeena. Eskaeretan parte hartzen duten langileei βnor den bezeroaβ galdetzen badiozu, definizio bat jasoko duzu, salmentan parte hartzen dutenei galdetzen badiozu, beste bat, eta interpreteek hirugarren definizio bat emango dizute.
Beraz, Testuinguru mugatuak dio gure zerbitzuen kontsumitzailea zer den definizio argirik eman ezin badugu, defini ditzagun termino honen esanahiari buruz hitz egin dezakegun mugak, eta ondoren defini ditzagun definizio ezberdin horien arteko trantsizio-puntuak. Hau da, eskaerak egitearen ikuspuntutik bezero bati buruz ari bagara, honek hau eta bestea esan nahi du, eta salmentaren ikuspuntutik bada, honek hau eta bestea.
Mikrozerbitzu baten hurrengo definizioa edozein motatako barne-eragiketak enkapsulatzea da, lan-prozesuko osagaiak ingurunera "isurtzea" saihestuz. Ondoren, "kanpo interakzioetarako edo kanpoko komunikazioetarako kontratu esplizituen definizioa" dator, SLAetatik itzultzen diren kontratuen ideiak adierazten duena. Azken definizioa zelula edo zelula baten metafora da, hau da, mikrozerbitzu baten barruan eragiketa-multzo baten kapsulatze osoa eta kanpo munduarekin komunikatzeko errezeptoreak bertan egotea esan nahi du.
Hortaz, Bell Computers-eko mutilei esan genien: "Ezin dugu sortu duzun kaosarik konpondu, ez duzulako dirurik horretarako, baina zerbitzu bakarra konponduko dugu hori guztia egiteko. zentzuaβ. Une honetan, gure zerbitzu bakarra nola konpondu genuen kontatzen hasiko naiz, eskaerei 9 minutu eta erdi baino azkarrago erantzun diezaien.
22:30 min
Oso laster jarraitzeko...
Publizitate apur bat
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com