Josh Evans flet për botën kaotike dhe plot ngjyra të mikroshërbimeve të Netflix, duke filluar nga bazat - anatomia e mikroshërbimeve, sfidat që lidhen me sistemet e shpërndara dhe përfitimet e tyre. Duke u mbështetur në këtë themel, ai eksploron praktikat kulturore, arkitekturore dhe operacionale që çojnë në zotërimin e mikroshërbimeve.
Ndryshe nga lëvizja operacionale, futja e gjuhëve të reja për ndërkombëtarizimin e shërbimeve dhe teknologjitë e reja si kontejnerët janë vendime të vetëdijshme për të shtuar kompleksitet të ri në mjedis. Ekipi im i operacioneve u standardizua në udhërrëfyesin më të mirë të teknologjisë për Netflix, i cili u krijua në praktikat më të mira të paracaktuara bazuar në Java dhe EC2, por ndërsa biznesi u rrit, zhvilluesit filluan të shtonin komponentë të rinj si Python, Ruby, Node-JS dhe Docker.
Jam shumë krenar që ne ishim të parët që avokuam që produkti ynë të funksionojë mirë pa pritur ankesat e klientëve. Gjithçka filloi mjaft e thjeshtë - ne kishim programe funksionimi në Python dhe disa aplikacione back-office në Ruby, por gjërat u bënë shumë më interesante kur zhvilluesit tanë të uebit njoftuan se do të hiqnin dorë nga JVM dhe do të zhvendosnin ueb-in. aplikim në platformën softuerike Node.js. Pas prezantimit të Docker, gjërat u bënë shumë më komplekse. Ne ndoqëm logjikën dhe teknologjitë me të cilat dolëm u bënë realitet kur i zbatuam për klientët, sepse ato kishin shumë kuptim. Unë do t'ju them pse është kështu.
API Gateway në fakt ka aftësinë për të integruar skriptet e shkëlqyera që mund të veprojnë si pika përfundimtare për zhvilluesit e ndërfaqes së përdoruesit. Ata konvertuan secilin prej këtyre skripteve në atë mënyrë që pasi të bënin ndryshime, ata mund t'i vendosnin ato në prodhim dhe më pas në pajisjet e përdoruesit, dhe të gjitha këto ndryshime u sinkronizuan me pikat fundore që funksiononin në portën API.
Sidoqoftë, kjo përsëriti problemin e krijimit të një monolit të ri ku shërbimi API ishte i mbingarkuar me kod në mënyrë të tillë që të ndodhnin skenarë të ndryshëm dështimi. Për shembull, disa pika fundore u hoqën, ose skriptet gjeneruan në mënyrë të rastësishme kaq shumë versione të diçkaje sa që versionet morën të gjithë kujtesën e disponueshme të shërbimit API.
Ishte logjike që të merreshin këto pika fundore dhe t'i tërhiqnim nga shërbimi API. Për ta bërë këtë, ne krijuam komponentë Node.js që funksiononin si aplikacione të vogla në kontejnerët Docker. Kjo na lejoi të izolonim çdo problem dhe përplasje të shkaktuar nga këto aplikacione të nyjeve.
Kostoja e këtyre ndryshimeve është mjaft e madhe dhe përbëhet nga faktorët e mëposhtëm:
- Mjetet e produktivitetit. Menaxhimi i teknologjive të reja kërkonte mjete të reja sepse ekipit të UI, duke përdorur skripta shumë të mirë për të krijuar një model efikas, nuk iu desh të shpenzonin shumë kohë për të menaxhuar infrastrukturën, ata vetëm duhej të shkruanin skripta dhe të kontrollonin funksionalitetin e tyre.
Opportunity Insight dhe Renditja - Një shembull kryesor janë mjetet e reja të nevojshme për të zbuluar informacionin e drejtuesit të performancës. Ishte e nevojshme të dihej se sa ishte i zënë procesori, si po përdorej memoria dhe mbledhja e këtij informacioni kërkonte mjete të ndryshme. - Fragmentimi i imazheve bazë - AMI e thjeshtë bazë është bërë më e fragmentuar dhe e specializuar.
- Menaxhimi i nyjeve. Nuk ka asnjë arkitekturë ose teknologji të disponueshme që ju lejon të menaxhoni nyjet në cloud, kështu që ne ndërtuam Titus, një platformë për menaxhimin e kontejnerëve që ofron vendosje të shkallëzueshme dhe të besueshme të kontejnerëve dhe integrim në renë kompjuterike me Amazon AWS.
- Dyfishimi i një biblioteke ose platforme. Sigurimi i teknologjive të reja me të njëjtin funksionalitet thelbësor të platformës kërkonte dublimin e saj në mjetet e zhvilluesve Node.js të bazuara në renë kompjuterike.
- Kurba e të mësuarit dhe përvoja industriale. Futja e teknologjive të reja në mënyrë të pashmangshme krijon sfida të reja nga të cilat duhet të kapërcehen dhe të mësohet.
Kështu, ne nuk mund të kufizoheshim në një "rrugë të asfaltuar" dhe duhej të ndërtonim vazhdimisht mënyra të reja për të avancuar teknologjitë tona. Për të ulur kostot, ne kufizuam mbështetjen e centralizuar dhe u fokusuam në JVM, nyjet e reja dhe Docker. Ne i dhamë përparësi ndikimit efektiv, informuam ekipet për koston e vendimeve të tyre dhe i inkurajuam ata të kërkonin mënyra për të ripërdorur zgjidhjet me ndikim të lartë që kishin zhvilluar tashmë. Ne e përdorëm këtë qasje gjatë përkthimit të shërbimit në gjuhë të huaja për të ofruar produktin te klientët ndërkombëtarë. Shembujt përfshijnë bibliotekat relativisht të thjeshta të klientëve që mund të gjenerohen automatikisht, kështu që është mjaft e lehtë të krijohet një version Python, një version Ruby, një version Java, etj.
Ne vazhdimisht kërkonim mundësi për të përdorur teknologji të provuara që e kishin provuar veten në një vend dhe në situata të tjera të ngjashme.
Le të flasim për elementin e fundit - ndryshimet ose variacionet. Shikoni se si konsumi i produktit tonë ndryshon në mënyrë të pabarabartë sipas ditës së javës dhe sipas orës gjatë gjithë ditës. Mund të thuash se ora 9 e mëngjesit është koha më e vështirë për Netflix, kur ngarkesa në sistem arrin maksimumin e saj.
Si mund të arrijmë shpejtësi të lartë të zbatimit të inovacioneve softuerike, pra duke bërë vazhdimisht ndryshime të reja në sistem, pa shkaktuar ndërprerje në ofrimin e shërbimeve dhe pa krijuar shqetësime te klientët tanë? Netflix e arriti këtë përmes përdorimit të Spinnaker, një platformë e re globale e menaxhimit të bazuar në cloud dhe shpërndarjes së vazhdueshme (CD).
Në mënyrë kritike, Spinnaker u krijua për të integruar praktikat tona më të mira në mënyrë që ndërsa vendosim komponentët në prodhim, ne mund ta integrojmë produktin drejtpërdrejt në teknologjinë tonë të shpërndarjes së mediave.
Ne kemi qenë në gjendje të inkorporojmë dy teknologji në tubacionin tonë të shpërndarjes që ne i vlerësojmë shumë: analiza e automatizuar e kanarinave dhe vendosja në faza. Analiza Kanarie do të thotë që ne drejtojmë një rrjedhë trafiku në versionin e ri të kodit dhe kalojmë pjesën tjetër të trafikut të prodhimit përmes versionit të vjetër. Pastaj kontrollojmë se si kodi i ri përballet me detyrën - më mirë ose më keq se ai ekzistues.
Një prezantim i shkallëzuar do të thotë që nëse një prezantim në një rajon ka probleme, ne kalojmë në një prezantim në një rajon tjetër. Në këtë rast, lista e kontrollit të sipërpërmendur duhet të përfshihet në tubacionin e prodhimit. Do t'ju kursej pak kohë dhe do t'ju rekomandoj të shikoni fjalimin tim të mëparshëm, Inxhinieri Global Netflix Operations in the Cloud, nëse jeni të interesuar të zhyteni më thellë në këtë temë. Video regjistrimi i fjalimit mund të shihet duke ndjekur lidhjen në fund të rrëshqitjes.
Në fund të bisedës do të flas shkurtimisht për organizimin dhe arkitekturën e Netflix. Në fillim kishim një skemë të quajtur Dorëzimi Elektronik, që ishte versioni i parë i transmetimit të medias NRDP 1.x. Termi "backstream" mund të përdoret këtu sepse fillimisht përdoruesi mund të shkarkonte përmbajtje vetëm për riprodhim të mëvonshëm në pajisje. Platforma e parë e shpërndarjes dixhitale e Netflix, në vitin 2009, dukej diçka e tillë.
Pajisja e përdoruesit përmbante aplikacionin Netflix, i cili përbëhej nga një ndërfaqe UI, module sigurie, aktivizim dhe riprodhim shërbimi, bazuar në platformën NRDP - Netflix Ready Device Platform.
Në atë kohë ndërfaqja e përdoruesit ishte shumë e thjeshtë. Ai përmbante atë që quhej Queque Reader dhe përdoruesi shkonte në sit për të shtuar diçka në Queque dhe më pas shikonte përmbajtjen e shtuar në pajisjen e tij. Pozitive ishte se ekipi i përparmë dhe ekipi i fundit i përkisnin të njëjtës organizatë të dorëzimit elektronik dhe kishin një marrëdhënie të ngushtë pune. Ngarkesa është krijuar bazuar në XML. Në të njëjtën kohë, u krijua API Netflix për biznesin e DVD-ve, i cili inkurajoi aplikacionet e palëve të treta të drejtojnë trafikun në shërbimin tonë.
Megjithatë, API Netflix ishte i përgatitur mirë për të na ndihmuar me një ndërfaqe inovative të përdoruesit, që përmban meta të dhëna të të gjithë përmbajtjes, informacione se çfarë filmash ishin në dispozicion, gjë që krijonte mundësinë për të gjeneruar lista shikimi. Ai kishte një API gjenerike REST bazuar në skemën JSON, kodin e përgjigjes HTTP, i njëjti që përdoret në arkitekturën moderne dhe një model sigurie OAuth, i cili ishte ajo që kërkohej në atë kohë për një aplikacion të përparmë. Kjo bëri të mundur kalimin nga një model publik i ofrimit të përmbajtjes streaming në një model privat.
Problemi me tranzicionin ishte fragmentimi, pasi tani sistemi ynë operonte dy shërbime të bazuara në parime krejtësisht të ndryshme të funksionimit - një në Rest, JSON dhe OAuth, tjetri në RPC, XML dhe një mekanizëm sigurie të përdoruesit bazuar në sistemin e tokenit NTBA. Kjo ishte arkitektura e parë hibride.
Kishte në thelb një mur zjarri midis dy skuadrave tona sepse fillimisht API nuk ishte shumë mirë me NCCP dhe kjo çoi në fërkime midis ekipeve. Dallimet ishin në shërbimet, protokollet, qarqet, modulet e sigurisë dhe zhvilluesit shpesh duhej të kalonin midis konteksteve krejtësisht të ndryshme.
Lidhur me këtë, pata një bisedë me një nga inxhinierët e lartë të kompanisë, të cilit i bëra pyetjen: “Cila duhet të jetë arkitektura e duhur afatgjatë?” dhe ai bëri kundërpyetjen: “Me siguri jeni më i shqetësuar. në lidhje me pasojat organizative - çfarë ndodh nëse i integrojmë këto gjëra dhe ato thyejnë atë që kemi mësuar të bëjmë mirë? Kjo qasje është shumë e rëndësishme për Ligjin e Conway: "Organizatat që projektojnë sisteme janë të kufizuara nga një dizajn që përsërit strukturën e komunikimit të asaj organizate." Ky është një përkufizim shumë abstrakt, kështu që unë preferoj një më specifik: "Çdo pjesë e softuerit pasqyron strukturën organizative që e ka krijuar atë." Këtu është citati im i preferuar nga Eric Raymond: "Nëse keni katër ekipe zhvilluesish që punojnë në një përpilues, do të përfundoni me një përpilues me katër kalime." Epo, Netflix ka një përpilues me katër kalime, dhe ne kështu punojmë.
Mund të themi se në këtë rast bishti është duke tundur qenin. Prioriteti ynë i parë nuk është zgjidhja, por organizimi; është organizata që drejton arkitekturën që kemi. Gradualisht, nga një grumbull shërbimesh, ne kaluam në një arkitekturë që e quajtëm Blade Runner, sepse këtu po flasim për shërbimet e skajit dhe aftësinë e NCCP për t'u ndarë dhe integruar drejtpërdrejt në proxy Zuul, portën API dhe funksionalitetin përkatës. “copëzat” janë shndërruar në mikroshërbime të reja me veçori më të avancuara sigurie, riprodhimi, klasifikimi i të dhënave, etj.
Kështu, mund të thuhet se strukturat e departamenteve dhe dinamika e kompanisë luajnë një rol të rëndësishëm në formësimin e dizajnit të sistemit dhe janë një faktor që nxit ose pengon ndryshimin. Arkitektura e mikroshërbimeve është komplekse dhe organike, dhe shëndeti i saj bazohet në disiplinë dhe kaos të futur.
Pak reklamë
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com