Josh Evans taler om den kaotiske og farverige verden af Netflix-mikrotjenester, begyndende med det helt basale - mikrotjenesternes anatomi, udfordringerne forbundet med distribuerede systemer og deres fordele. Med udgangspunkt i dette grundlag udforsker han de kulturelle, arkitektoniske og operationelle praksisser, der fører til mesterskab af mikrotjenester.
I modsætning til driftsdrift er introduktionen af nye sprog til serviceinternationalisering og nye teknologier såsom containere bevidste beslutninger om at tilføje ny kompleksitet til miljøet. Mit driftsteam standardiserede på den bedste teknologiske køreplan for Netflix, som var indbygget i foruddefinerede bedste praksis baseret på Java og EC2, men efterhånden som virksomheden voksede, begyndte udviklere at tilføje nye komponenter såsom Python, Ruby, Node-JS og Docker.
Jeg er meget stolt over, at vi var de første, der gik ind for, at vores produkt skulle fungere godt uden at vente på kundeklager. Det hele startede simpelt nok - vi havde betjeningsprogrammer i Python og et par back-office-applikationer i Ruby, men tingene blev meget mere interessante, da vores webudviklere meddelte, at de ville droppe JVM og ville flytte nettet applikation til Node-softwareplatformen. js. Efter introduktionen af Docker blev tingene meget mere komplekse. Vi fulgte logikken, og de teknologier, vi fandt på, blev til virkelighed, da vi implementerede dem for kunderne, fordi de gav meget mening. Jeg vil fortælle dig, hvorfor det er sådan.
API Gateway har faktisk evnen til at integrere fantastiske scripts, der kan fungere som slutpunkter for UI-udviklere. De konverterede hvert af disse scripts på en sådan måde, at de efter at have foretaget ændringer kunne implementere dem til produktion og derefter til brugerenheder, og alle disse ændringer blev synkroniseret med endepunkter, der kørte i API-gatewayen.
Dette gentog imidlertid problemet med at skabe en ny monolit, hvor API-tjenesten var overbelastet med kode på en sådan måde, at der opstod forskellige fejlscenarier. For eksempel blev nogle endepunkter fjernet, eller scripts genererede tilfældigt så mange versioner af noget, at versionerne optog al den tilgængelige hukommelse i API-tjenesten.
Det var logisk at tage disse endepunkter og trække dem ud af API-tjenesten. For at gøre dette oprettede vi Node.js-komponenter, der kørte som små applikationer i Docker-containere. Dette gjorde det muligt for os at isolere eventuelle problemer og nedbrud forårsaget af disse node-applikationer.
Omkostningerne ved disse ændringer er ret store og består af følgende faktorer:
- Produktivitetsværktøjer. Håndtering af nye teknologier krævede nye værktøjer, fordi UI-teamet, der brugte meget gode scripts til at skabe en effektiv model, ikke behøvede at bruge meget tid på at administrere infrastrukturen, de skulle kun skrive scripts og kontrollere deres funktionalitet.
Mulighedsindsigt og sortering - Et centralt eksempel er de nye værktøjer, der er nødvendige for at afdække oplysninger om ydeevnedrivere. Det var nødvendigt at vide, hvor meget processoren var optaget, hvordan hukommelsen blev brugt, og indsamling af disse oplysninger krævede forskellige værktøjer. - Fragmentering af basisbilleder - den simple basis AMI er blevet mere fragmenteret og specialiseret.
- Nodestyring. Der er ingen hyldearkitektur eller teknologi tilgængelig, der giver dig mulighed for at administrere noder i skyen, så vi byggede Titus, en containeradministrationsplatform, der giver skalerbar og pålidelig containerimplementering og cloudintegration med Amazon AWS.
- Duplikering af et bibliotek eller en platform. At levere nye teknologier med den samme kernefunktionalitet af platformen krævede at duplikere den til cloud-baserede Node.js-udviklerværktøjer.
- Læringskurve og industriel erfaring. Introduktionen af nye teknologier skaber uundgåeligt nye udfordringer, som skal overvindes og læres af.
Vi kunne således ikke begrænse os til én "asfalteret vej" og var nødt til konstant at bygge nye måder at fremme vores teknologier på. For at holde omkostningerne nede, begrænsede vi centraliseret support og fokuserede på JVM, nye noder og Docker. Vi prioriterede effektiv effekt, informerede teams om omkostningerne ved deres beslutninger og opfordrede dem til at lede efter måder at genbruge de højeffektive løsninger, de allerede havde udviklet. Vi brugte denne tilgang, da vi oversatte tjenesten til fremmedsprog for at levere produktet til internationale kunder. Som eksempler kan nævnes relativt simple klientbiblioteker, der kan genereres automatisk, så det er ret nemt at lave en Python-version, en Ruby-version, en Java-version osv.
Vi ledte konstant efter muligheder for at bruge gennemprøvede teknologier, der havde bevist sig selv ét sted og i andre lignende situationer.
Lad os tale om det sidste element - ændringer eller variationer. Se hvordan forbruget af vores produkt varierer ujævnt efter ugedag og timetal i løbet af dagen. Man kan sige, at kl. 9 er den sværeste tid for Netflix, når belastningen på systemet når sit maksimum.
Hvordan kan vi opnå høj hastighed for implementering af softwareinnovationer, det vil sige konstant at foretage nye ændringer i systemet, uden at forårsage afbrydelser i serviceleveringen og uden at skabe gener for vores kunder? Netflix opnåede dette gennem brugen af Spinnaker, en ny global cloud-baseret administration og kontinuerlig levering (CD) platform.
Kritisk er Spinnaker designet til at integrere vores bedste praksis, så vi, når vi implementerer komponenter i produktionen, kan integrere output direkte i vores medieleveringsteknologi.
Vi har været i stand til at inkorporere to teknologier i vores leveringspipeline, som vi værdsætter højt: automatiseret kanariefugleanalyse og trinvis implementering. Kanarisk analyse betyder, at vi dirigerer et snavs af trafik til den nye version af koden, og sender resten af produktionstrafikken gennem den gamle version. Så tjekker vi, hvordan den nye kode klarer opgaven – bedre eller dårligere end den eksisterende.
En forskudt udrulning betyder, at hvis en udrulning i en region har problemer, går vi over til en udrulning i en anden region. I dette tilfælde skal ovennævnte tjekliste indgå i produktionspipelinen. Jeg vil spare dig lidt tid og anbefaler, at du tjekker mit tidligere foredrag, Engineering Global Netflix Operations in the Cloud, hvis du er interesseret i at dykke dybere ned i dette emne. Videooptagelsen af talen kan ses ved at følge linket i bunden af diaset.
I slutningen af foredraget vil jeg kort fortælle om organisationen og arkitekturen af Netflix. Allerede i begyndelsen havde vi en ordning kaldet Electronic Delivery, som var den første version af NRDP 1.x mediestreaming. Udtrykket "backstream" kan bruges her, fordi brugeren i første omgang kun kunne downloade indhold til senere afspilning på enheden. Netflix' allerførste digitale leveringsplatform, tilbage i 2009, så nogenlunde sådan ud.
Brugerenheden indeholdt Netflix-applikationen, som bestod af en UI-grænseflade, sikkerhedsmoduler, tjenesteaktivering og afspilning, baseret på NRDP-platformen - Netflix Ready Device Platform.
På det tidspunkt var brugergrænsefladen meget enkel. Den indeholdt, hvad der blev kaldt en Queque-læser, og brugeren ville gå til webstedet for at tilføje noget til Queque og derefter se det tilføjede indhold på deres enhed. Det positive var, at front-end-teamet og back-end-teamet tilhørte den samme elektroniske leveringsorganisation og havde et tæt samarbejde. Nyttelasten blev oprettet baseret på XML. Samtidig blev Netflix API til DVD-virksomheden skabt, som tilskyndede tredjepartsapplikationer til at dirigere trafik til vores tjeneste.
Netflix API var dog godt forberedt til at hjælpe os med en innovativ brugergrænseflade, indeholdende metadata af alt indhold, information om hvilke film der var tilgængelige, hvilket skabte muligheden for at generere overvågningslister. Det havde en generisk REST API baseret på JSON-skemaet, HTTP Response Code, den samme som bruges i moderne arkitektur, og en OAuth-sikkerhedsmodel, som var det, der krævedes på det tidspunkt for en front-end-applikation. Dette gjorde det muligt at gå fra en offentlig model for levering af streaming af indhold til en privat.
Problemet med overgangen var fragmentering, da vores system nu drev to tjenester baseret på helt forskellige driftsprincipper - den ene på Rest, JSON og OAuth, den anden på RPC, XML og en brugersikkerhedsmekanisme baseret på NTBA-tokensystemet. Dette var den første hybride arkitektur.
Der var i det væsentlige en firewall mellem vores to teams, fordi API'et oprindeligt ikke skaleres særlig godt med NCCP, og dette førte til friktion mellem holdene. Forskellene var i tjenester, protokoller, kredsløb, sikkerhedsmoduler, og udviklere skulle ofte skifte mellem helt forskellige kontekster.
I den forbindelse havde jeg en samtale med en af virksomhedens senioringeniører, til hvem jeg stillede spørgsmålet: "Hvad skal være den rigtige langsigtede arkitektur?" og han stillede modspørgsmålet: "Du er nok mere bekymret. om de organisatoriske konsekvenser – hvad sker der, hvis vi integrerer disse ting, og de bryder det, vi har lært at gøre godt? Denne tilgang er meget relevant for Conways lov: "Organisationer, der designer systemer er begrænset af et design, der replikerer kommunikationsstrukturen i den pågældende organisation." Dette er en meget abstrakt definition, så jeg foretrækker en mere specifik: "Ethvert stykke software afspejler den organisatoriske struktur, der skabte det." Her er mit yndlingscitat fra Eric Raymond: "Hvis du har fire teams af udviklere, der arbejder på en compiler, vil du ende med en fire-pass compiler." Nå, Netflix har en fire-pass compiler, og det er sådan vi arbejder.
Vi kan sige, at i dette tilfælde logrer halen med hunden. Vores førsteprioritet er ikke løsningen, men organisationen; det er organisationen, der driver den arkitektur, vi har. Efterhånden, fra en mængde tjenester, flyttede vi til en arkitektur, som vi kaldte Blade Runner, fordi vi her taler om edge-tjenester og NCCP's evne til at blive adskilt og integreret direkte i Zuul-proxyen, API-gatewayen og den tilsvarende funktionelle "pieces" er blevet omdannet til nye mikrotjenester med mere avanceret sikkerhed, genafspilning, datasortering osv. funktioner.
Man kan således sige, at afdelingsstrukturer og virksomhedsdynamik spiller en vigtig rolle i udformningen af systemdesign og er en faktor, der fremmer eller hæmmer forandring. Microservices arkitektur er kompleks og organisk, og dens sundhed er baseret på disciplin og indført kaos.
Lidt reklame
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com