Josh Evansek Netflix-eko mikrozerbitzuen mundu kaotiko eta koloretsuari buruz hitz egiten du, oinarrietatik hasita: mikrozerbitzuen anatomia, sistema banatuekin lotutako erronkei eta haien onurak. Oinarri horretatik abiatuta, mikrozerbitzuak menperatzea dakarten praktika kultural, arkitektonikoak eta operatiboak aztertzen ditu.
Deriva operatiboa ez bezala, zerbitzuak nazioartekotzeko hizkuntza berriak eta teknologia berriak, hala nola edukiontziak, ingurumenari konplexutasun berria gehitzeko erabaki kontzienteak dira. Nire operazio-taldeak Netflix-en teknologia-bide-orririk onena estandarizatu zuen, Java eta EC2-n oinarritutako aldez aurretik definitutako jardunbide egokietan sartuta, baina negozioa hazi ahala, garatzaileak osagai berriak gehitzen hasi ziren, hala nola Python, Ruby, Node-JS eta Docker.
Oso harro nago gure produktuak ondo funtziona dezan defendatzen lehenak izan garelako bezeroen kexak itxaron gabe. Dena nahikoa sinple hasi zen: programa eragileak geneukan Python-en eta Ruby-n back-office aplikazio batzuk, baina gauzak askoz ere interesgarriago bihurtu ziren gure web garatzaileek JVM-a baztertu eta weba mugituko zutela iragarri zutenean. aplikazioa Node software plataformarako js. Docker aurkeztu ondoren, gauzak askoz konplexuagoak bihurtu ziren. Logika jarraitu genuen eta sortu genituen teknologiak errealitate bihurtu ziren bezeroentzat inplementatu genituenean, zentzu handia zutelako. Esango dizut zergatik den horrela.
API Gateway-k UI garatzaileentzako amaierako puntu gisa jarduteko script bikainak integratzeko gaitasuna du. Script horietako bakoitza modu horretan bihurtu zuten, aldaketak egin ondoren, ekoizpenera eta, ondoren, erabiltzailearen gailuetara zabaldu ahal izateko, eta aldaketa horiek guztiak API atebidean exekutatzen ziren puntuekin sinkronizatu ziren.
Hala ere, honek monolito berri bat sortzeko arazoa errepikatu zuen, non API zerbitzua kodez gainkargatuta zegoen moduan, hainbat hutsegite eszenatoki gertatu ziren. Esate baterako, amaierako puntu batzuk kendu ziren, edo scriptek ausaz zerbaiten hainbeste bertsio sortu zituzten, non bertsioek API zerbitzuaren memoria erabilgarri guztia hartzen zuten.
Logikoa zen amaiera puntu hauek hartu eta API zerbitzutik ateratzea. Horretarako, Docker edukiontzietan aplikazio txiki gisa exekutatzen ziren Node.js osagaiak sortu genituen. Horri esker, nodo-aplikazio hauek eragindako edozein arazo eta hutsegite isolatu ahal izan dugu.
Aldaketa hauen kostua nahiko handia da eta faktore hauek ditu:
- Produktibitate-tresnak. Teknologia berriak kudeatzeko tresna berriak behar ziren, zeren UI taldeak, eredu eraginkor bat sortzeko script oso onak erabiliz, ez zuen denbora asko eman behar azpiegitura kudeatzen, scriptak idatzi eta funtzionaltasuna egiaztatu besterik ez baitzuten behar.
Aukeren ikuspegia eta ordenazioa - Adibide garrantzitsu bat errendimendu-gidariaren informazioa ezagutzeko behar diren tresna berriak dira. Prozesadoreak zenbat okupatzen zuen, memoria nola erabiltzen zen jakin behar zen eta informazio hori biltzeko tresna desberdinak behar ziren. - Oinarrizko irudien zatiketa - oinarrizko AMI sinplea zatikatu eta espezializatuagoa bihurtu da.
- Nodoen kudeaketa. Ez dago eskuragarri hodeian nodoak kudeatzeko aukera ematen duen arkitektura edo teknologiarik eskuragarri, beraz, Titus eraiki dugu, edukiontzien kudeaketarako plataforma bat, Amazon AWS-rekin edukiontzien inplementazio eta hodeiko integrazio eskalagarri eta fidagarria eskaintzen duena.
- Liburutegi edo plataforma baten bikoizketa. Teknologia berriak plataformaren oinarrizko funtzionalitate berdinak eskaintzeak hodeian oinarritutako Node.js garatzaile-tresnetan bikoiztu behar zuen.
- Ikaskuntza kurba eta esperientzia industriala. Teknologia berriak sartzeak, ezinbestean, gainditu eta ikasi beharreko erronka berriak sortzen ditu.
Horrela, ezin ginen βasfaltatuβ batera mugatu eta etengabe eraiki behar izan genituen gure teknologiak aurrera egiteko modu berriak. Kostuak murrizteko, laguntza zentralizatua mugatu genuen eta JVMra, nodo berrietara eta Dockerra bideratu ginen. Eragin eraginkorra lehenetsi genuen, taldeei euren erabakien kostuaren berri eman eta lehendik garatu zituzten eragin handiko irtenbideak berrerabiltzeko moduak bilatzera animatu genituen. Ikuspegi hau erabili dugu zerbitzua atzerriko hizkuntzetara itzultzean produktua nazioarteko bezeroei emateko. Adibideen artean automatikoki sor daitezkeen bezero liburutegi nahiko sinpleak daude, beraz, nahiko erraza da Python bertsio bat, Ruby bertsio bat, Java bertsio bat eta abar sortzea.
Leku batean eta antzeko beste egoera batzuetan frogatutako teknologiak erabiltzeko aukerak bilatzen ari ginen etengabe.
Hitz egin dezagun azken elementuaz: aldaketak edo aldaerak. Begira nola aldatzen den gure produktuaren kontsumoa asteko egunaren arabera eta egunean zehar orduen arabera. Esan liteke 9:XNUMXak direla Netflix-en unerik gogorrena, sistemaren karga maximoa iristen denean.
Nola lor dezakegu software-berrikuntzen inplementazio-abiadura handia, hau da, sisteman etengabe aldaketa berriak egitea, zerbitzuen ematean etenik eragin gabe eta gure bezeroei eragozpenik sortu gabe? Netflix-ek Spinnaker-en erabilerarekin lortu zuen, hodeian oinarritutako kudeaketa eta etengabeko entrega (CD) plataforma global berri bat.
Larriki, Spinnaker gure jardunbide onenak integratzeko diseinatu zen, osagaiak ekoizpenean zabaltzen ditugun heinean, irteera zuzenean gure komunikabideen bidalketa teknologian integratu ahal izateko.
Oso baloratzen ditugun bi teknologia txertatu ahal izan ditugu gure bidalketa-bidean: analisi automatizatua eta inplementazio mailakatua. Kanarietako analisiak esan nahi du trafiko-jario bat kodearen bertsio berrira bideratzen dugula, eta gainerako ekoizpen-trafikoa bertsio zaharretik pasatzen dugula. Ondoren, kode berriak zereginari nola aurre egiten dion egiaztatuko dugu, lehendik dagoena baino hobeto edo okerrago.
Inplementazio mailakatu batek esan nahi du eskualde batean inplementazio batek arazoak baditu, beste eskualde bateko inplementazio batera mugitzen garela. Kasu horretan, goian aipatutako egiaztapen-zerrenda ekoizpen-bidean sartu beharko da. Denbora pixka bat aurreztuko dizut eta nire aurreko hitzaldia ikustea gomendatzen dizut, Ingeniaritza Global Netflix Operations in the Cloud, gai honetan sakontzeko interesa baduzu. Hitzaldiaren bideo-grabazioa diapositibaren behealdean dagoen esteka jarraituz ikus daiteke.
Hitzaldiaren amaieran, Netflix-en antolakuntza eta arkitekturaz hitz egingo dut labur. Hasieran, Electronic Delivery izeneko eskema bat genuen, hau da, NRDP 1.x multimedia streaming-en lehen bertsioa izan zen. Hemen "backstream" terminoa erabil daiteke, hasieran erabiltzaileak edukia bakarrik deskargatu zezakeelako gero gailuan erreproduzitzeko. Netflix-en lehen entrega digitaleko plataformak, 2009an, antzeko zerbait zuen.
Erabiltzailearen gailuak Netflix aplikazioa zuen, UI interfazea, segurtasun moduluak, zerbitzuen aktibazioa eta erreprodukzioa osatzen zutena, NRDP plataforman oinarrituta - Netflix Ready Device Platform.
Garai hartan erabiltzailearen interfazea oso erraza zen. Queque Reader deitzen zena zuen, eta erabiltzailea gunera joaten zen Queque-ri zerbait gehitzeko eta gero gehitutako edukia bere gailuan ikusteko. Alde positiboa izan zen front end taldea eta back end taldea Electronic Delivery erakunde berekoak zirela eta lan harreman estua zutela. Karga erabilgarria XMLn oinarrituta sortu da. Aldi berean, DVD negoziorako Netflix APIa sortu zen, hirugarrenen aplikazioak gure zerbitzura trafikoa bideratzeko bultzatu zuena.
Hala ere, Netflix APIa ondo prestatuta zegoen erabiltzaile-interfaze berritzaile batekin laguntzeko, eduki guztiaren metadatuak, zein film erabilgarri zeudenei buruzko informazioa, eta horrek ikusitako zerrendak sortzeko gaitasuna sortu zuen. JSON eskeman, HTTP Response Code, arkitektura modernoan erabiltzen den berbera eta OAuth segurtasun-eredu bat zituen JSON eskeman oinarritutako REST API generikoa, garai hartan front-end aplikazio baterako behar zena. Horri esker, edukia streaming bidez emateko eredu publikotik pribatura pasatzea ahalbidetu zen.
Trantsizioaren arazoa zatikatzea izan zen, orain gure sistemak funtzionamendu-printzipio guztiz desberdinetan oinarritutako bi zerbitzu funtzionatzen baitzituen: bata Rest, JSON eta OAuth-en, bestea RPC, XML-n eta NTBA token sisteman oinarritutako erabiltzaileen segurtasun-mekanismoa. Hau izan zen lehen arkitektura hibridoa.
Funtsean, gure bi taldeen arteko suebaki bat zegoen, hasieran APIa ez zelako oso ondo eskalatzen NCCPrekin eta horrek taldeen arteko marruskadura ekarri zuen. Desberdintasunak zerbitzuetan, protokoloetan, zirkuituetan, segurtasun moduluetan zeuden eta garatzaileek askotan testuinguru guztiz desberdinetatik aldatu behar izaten zuten.
Horren harira, elkarrizketa bat izan nuen enpresako goi mailako ingeniarietako batekin, eta hari galdera egin nion: βZein izan beharko litzateke epe luzerako arkitektura egokia?β, eta kontrako galdera egin zidan: βZiurrenik, gehiago arduratzen zara. antolakuntzaren ondorioei buruz - zer gertatzen da gauza hauek integratzen baditugu eta ondo egiten ikasitakoa hausten badute? Ikuspegi hau oso garrantzitsua da Conwayren Legearekin: "Sistemak diseinatzen dituzten erakundeak erakunde horren komunikazio-egitura errepikatzen duen diseinu batek mugatuta daude". Definizio oso abstraktua da hau, beraz, zehatzago bat nahiago dut: "Edozein software-k islatzen du hura sortu duen antolaketa-egitura". Hona hemen Eric Raymond-en nire aipu gogokoena: "Lau garatzaile-talde badituzu konpilatzaile batean lanean, lau pasatako konpilatzaile batekin amaituko zara". Tira, Netflix-ek lau pasatako konpilatzailea du, eta horrela funtzionatzen dugu.
Kasu honetan buztana txakurra astintzen ari dela esan dezakegu. Gure lehentasuna ez da irtenbidea, erakundea baizik; erakundea da daukagun arkitektura bultzatzen duena. Pixkanaka-pixkanaka, zerbitzuen nahasketa batetik, Blade Runner deitu genuen arkitektura batera pasatu ginen, hemen ertze-zerbitzuez eta NCCPk zuzenean bereizi eta zuzenean integratzeko Zuul proxy-an, API atebidean eta dagokien funtzionaletan ari garelako. "Piezak" mikrozerbitzu berri bihurtu dira, segurtasun, errepikapen, datuen sailkapen eta abar aurreratuagoekin.
Hortaz, esan daiteke departamentu-egiturek eta enpresa-dinamikek zeresan handia dutela sistemaren diseinua moldatzeko eta aldaketa sustatzen edo eragozten duen faktorea direla. Mikrozerbitzuen arkitektura konplexua eta organikoa da, eta bere osasuna diziplinan eta sartutako kaosean oinarritzen da.
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