Josh Evans snakker om den kaotiske og fargerike verdenen til Netflix-mikrotjenester, og starter med det helt grunnleggende - mikrotjenesters anatomi, utfordringene knyttet til distribuerte systemer og fordelene deres. Ved å bygge på dette grunnlaget utforsker han de kulturelle, arkitektoniske og operasjonelle praksisene som fører til mestring av mikrotjenester.
I motsetning til operasjonell drift, er introduksjonen av nye språk for internasjonalisering av tjenester og nye teknologier som containere bevisste beslutninger for å legge til ny kompleksitet til miljøet. Driftsteamet mitt standardiserte det beste teknologiske veikartet for Netflix, som ble bakt inn i forhåndsdefinerte beste praksis basert på Java og EC2, men etter hvert som virksomheten vokste, begynte utviklere å legge til nye komponenter som Python, Ruby, Node-JS og Docker.
Jeg er veldig stolt over at vi var de første som gikk inn for at produktet vårt skulle fungere utmerket uten å vente på kundeklager. Det hele startet enkelt nok - vi hadde driftsprogrammer i Python og noen få backoffice-applikasjoner i Ruby, men ting ble mye mer interessant da nettutviklerne våre annonserte at de skulle droppe JVM og skulle flytte nettet applikasjon til Node-programvareplattformen. js. Etter introduksjonen av Docker ble ting mye mer komplekse. Vi fulgte logikken og teknologiene vi kom opp med ble virkelighet da vi implementerte dem for kunder fordi de ga mye mening. Jeg skal fortelle deg hvorfor det er slik.
API Gateway har faktisk muligheten til å integrere flotte skript som kan fungere som endepunkter for UI-utviklere. De konverterte hvert av disse skriptene på en slik måte at de etter å ha gjort endringer kunne distribuere dem til produksjon og deretter til brukerenheter, og alle disse endringene ble synkronisert med endepunkter som kjørte i API-porten.
Dette gjentok imidlertid problemet med å lage en ny monolitt der API-tjenesten ble overbelastet med kode på en slik måte at ulike feilscenarier oppstod. For eksempel ble noen endepunkter fjernet, eller skript genererte tilfeldig så mange versjoner av noe at versjonene tok opp alt tilgjengelig minne til API-tjenesten.
Det var logisk å ta disse endepunktene og trekke dem ut av API-tjenesten. For å gjøre dette opprettet vi Node.js-komponenter som kjørte som små applikasjoner i Docker-beholdere. Dette tillot oss å isolere eventuelle problemer og krasj forårsaket av disse nodeapplikasjonene.
Kostnaden for disse endringene er ganske store og består av følgende faktorer:
- Produktivitetsverktøy. Å administrere nye teknologier krevde nye verktøy fordi UI-teamet, som brukte veldig gode skript for å lage en effektiv modell, ikke trengte å bruke mye tid på å administrere infrastrukturen, de måtte bare skrive skript og sjekke funksjonaliteten.
Mulighetsinnsikt og sortering – Et sentralt eksempel er de nye verktøyene som trengs for å avdekke informasjon om ytelsesdrivere. Det var nødvendig å vite hvor mye prosessoren var opptatt, hvordan minnet ble brukt, og å samle inn denne informasjonen krevde forskjellige verktøy. - Fragmentering av basebilder - den enkle base AMI har blitt mer fragmentert og spesialisert.
- Nodestyring. Det er ingen hyllearkitektur eller teknologi tilgjengelig som lar deg administrere noder i skyen, så vi bygde Titus, en containeradministrasjonsplattform som gir skalerbar og pålitelig containerdistribusjon og skyintegrasjon med Amazon AWS.
- Duplisering av et bibliotek eller en plattform. Å tilby nye teknologier med den samme kjernefunksjonaliteten til plattformen krevde å duplisere den til skybaserte Node.js-utviklerverktøy.
- Læringskurve og industriell erfaring. Innføringen av ny teknologi skaper uunngåelig nye utfordringer som må overvinnes og læres av.
Dermed kunne vi ikke begrense oss til én "asfaltert vei" og måtte hele tiden bygge nye måter å fremme teknologiene våre på. For å holde kostnadene nede begrenset vi sentralisert støtte og fokuserte på JVM, nye noder og Docker. Vi prioriterte effektiv effekt, informerte teamene om kostnadene ved beslutningene deres, og oppfordret dem til å se etter måter å gjenbruke de effektfulle løsningene de allerede hadde utviklet. Vi brukte denne tilnærmingen når vi oversatte tjenesten til fremmedspråk for å levere produktet til internasjonale kunder. Eksempler inkluderer relativt enkle klientbiblioteker som kan genereres automatisk, slik at det er ganske enkelt å lage en Python-versjon, en Ruby-versjon, en Java-versjon osv.
Vi var hele tiden på utkikk etter muligheter for å bruke utprøvde teknologier som hadde bevist seg på ett sted og i andre lignende situasjoner.
La oss snakke om det siste elementet - endringer eller variasjoner. Se hvordan forbruket av produktet vårt varierer ujevnt etter ukedag og time i løpet av dagen. Du kan si at klokken 9 er den vanskeligste tiden for Netflix, når belastningen på systemet når sitt maksimum.
Hvordan kan vi oppnå høy hastighet på implementering av programvareinnovasjoner, det vil si hele tiden å gjøre nye endringer i systemet, uten å forårsake avbrudd i tjenesteleveransen og uten å skape ulemper for våre kunder? Netflix oppnådde dette gjennom bruk av Spinnaker, en ny global skybasert plattform for administrasjon og kontinuerlig levering (CD).
Kritisk er Spinnaker designet for å integrere våre beste praksiser slik at når vi distribuerer komponenter i produksjonen, kan vi integrere produksjonen direkte i vår medieleveringsteknologi.
Vi har vært i stand til å inkorporere to teknologier i leveransepipeline vår som vi setter stor pris på: automatisert kanariøyneanalyse og trinnvis distribusjon. Kanarieanalyse betyr at vi dirigerer en drypp av trafikk til den nye versjonen av koden, og sender resten av produksjonstrafikken gjennom den gamle versjonen. Deretter sjekker vi hvordan den nye koden takler oppgaven – bedre eller dårligere enn den eksisterende.
En forskjøvet utrulling betyr at hvis en utrulling i en region har problemer, går vi over til en utrulling i en annen region. I dette tilfellet må ovennevnte sjekkliste inkluderes i produksjonsrørledningen. Jeg vil spare deg for litt tid og anbefaler deg å sjekke ut min forrige foredrag, Engineering Global Netflix Operations in the Cloud, hvis du er interessert i å dykke dypere inn i dette emnet. Videoopptaket av talen kan sees ved å følge lenken nederst på lysbildet.
På slutten av foredraget vil jeg kort snakke om organisasjonen og arkitekturen til Netflix. Helt i begynnelsen hadde vi et opplegg kalt Electronic Delivery, som var den første versjonen av NRDP 1.x mediestrømming. Begrepet "backstream" kan brukes her fordi brukeren i utgangspunktet kun kunne laste ned innhold for senere avspilling på enheten. Netflix sin aller første digitale leveringsplattform, tilbake i 2009, så omtrent slik ut.
Brukerenheten inneholdt Netflix-applikasjonen, som besto av et UI-grensesnitt, sikkerhetsmoduler, tjenesteaktivering og avspilling, basert på NRDP-plattformen – Netflix Ready Device Platform.
På den tiden var brukergrensesnittet veldig enkelt. Den inneholdt det som ble kalt en Queque-leser, og brukeren ville gå til nettstedet for å legge til noe i Queque og deretter se det tilførte innholdet på enheten sin. Det positive var at front-end-teamet og back-end-teamet tilhørte samme elektroniske leveringsorganisasjon og hadde et nært samarbeid. Nyttelasten ble opprettet basert på XML. Samtidig ble Netflix API for DVD-virksomheten opprettet, som oppmuntret tredjepartsapplikasjoner til å dirigere trafikk til tjenesten vår.
Netflix API var imidlertid godt forberedt for å hjelpe oss med et innovativt brukergrensesnitt, som inneholder metadata for alt innhold, informasjon om hvilke filmer som var tilgjengelige, noe som skapte muligheten til å generere overvåkningslister. Den hadde en generisk REST API basert på JSON-skjemaet, HTTP Response Code, den samme som brukes i moderne arkitektur, og en OAuth-sikkerhetsmodell, som var det som var nødvendig på den tiden for en front-end-applikasjon. Dette gjorde det mulig å gå fra en offentlig modell for levering av strømmeinnhold til en privat modell.
Problemet med overgangen var fragmentering, siden systemet vårt nå opererte to tjenester basert på helt forskjellige operasjonsprinsipper - en på Rest, JSON og OAuth, den andre på RPC, XML og en brukersikkerhetsmekanisme basert på NTBA-tokensystemet. Dette var den første hybridarkitekturen.
Det var i hovedsak en brannmur mellom de to lagene våre, fordi API-en i utgangspunktet ikke skalert særlig godt med NCCP, og dette førte til friksjon mellom lagene. Forskjellene var i tjenester, protokoller, kretser, sikkerhetsmoduler, og utviklere måtte ofte bytte mellom helt andre kontekster.
I denne forbindelse hadde jeg en samtale med en av senioringeniørene i selskapet, som jeg stilte spørsmålet til: "Hva burde være den riktige langsiktige arkitekturen?" og han stilte motspørsmålet: "Du er sannsynligvis mer bekymret om de organisatoriske konsekvensene – hva skjer hvis vi integrerer disse tingene, og de bryter det vi har lært å gjøre bra? Denne tilnærmingen er svært relevant for Conways lov: "Organisasjoner som designer systemer er begrenset av et design som gjenskaper kommunikasjonsstrukturen til den organisasjonen." Dette er en veldig abstrakt definisjon, så jeg foretrekker en mer spesifikk: "Enhver programvare gjenspeiler organisasjonsstrukturen som skapte den." Her er mitt favorittsitat fra Eric Raymond: "Hvis du har fire team av utviklere som jobber med en kompilator, vil du ende opp med en kompilator med fire pass." Vel, Netflix har en kompilator med fire pass, og det er slik vi jobber.
Vi kan si at i dette tilfellet logrer halen med hunden. Vår første prioritet er ikke løsningen, men organisasjonen; det er organisasjonen som driver arkitekturen vi har. Gradvis, fra en mengde tjenester, flyttet vi til en arkitektur som vi kalte Blade Runner, fordi vi her snakker om edge-tjenester og muligheten til NCCP å separeres og integreres direkte i Zuul-proxyen, API-gatewayen og den tilsvarende funksjonelle «brikker» har blitt omgjort til nye mikrotjenester med mer avanserte funksjoner for sikkerhet, replay, datasortering osv.
Dermed kan man si at avdelingsstrukturer og bedriftsdynamikk spiller en viktig rolle i utformingen av systemdesign og er en faktor som fremmer eller hindrer endring. Mikrotjenesters arkitektur er kompleks og organisk, og dens helse er basert på disiplin og innført kaos.
Litt reklame
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com