Josh Evans govori o kaotičnem in barvitem svetu mikrostoritev Netflix, začenši s samimi osnovami – anatomijo mikrostoritev, izzivi, povezanimi s porazdeljenimi sistemi, in njihovimi prednostmi. Na tej podlagi raziskuje kulturne, arhitekturne in operativne prakse, ki vodijo do obvladovanja mikrostoritev.
Za razliko od operativnega premika so uvedba novih jezikov za internacionalizacijo storitev in novih tehnologij, kot so zabojniki, zavestna odločitev za dodajanje nove kompleksnosti okolju. Moja operativna ekipa je standardizirala najboljši tehnološki načrt za Netflix, ki je bil vključen v vnaprej določene najboljše prakse, ki temeljijo na Javi in EC2, a ko je posel rasel, so razvijalci začeli dodajati nove komponente, kot so Python, Ruby, Node-JS in Docker.
Zelo sem ponosen, da smo bili prvi, ki smo zagovarjali, da bi naš izdelek deloval odlično, ne da bi čakali na pritožbe strank. Vse se je začelo precej preprosto – imeli smo operacijske programe v Pythonu in nekaj zalednih aplikacij v Rubyju, vendar so stvari postale veliko bolj zanimive, ko so naši spletni razvijalci objavili, da bodo opustili JVM in preselili splet aplikacija za programsko platformo Node. js. Po uvedbi Dockerja so stvari postale veliko bolj zapletene. Sledili smo logiki in tehnologije, ki smo jih izumili, so postale resničnost, ko smo jih implementirali za stranke, ker so bile zelo smiselne. Povedal vam bom, zakaj je tako.
API Gateway dejansko lahko integrira odlične skripte, ki lahko delujejo kot končne točke za razvijalce uporabniškega vmesnika. Vsakega od teh skriptov so pretvorili tako, da so jih po opravljenih spremembah lahko uvedli v proizvodnjo in nato v uporabniške naprave, vse te spremembe pa so bile sinhronizirane s končnimi točkami, ki so se izvajale v prehodu API.
Vendar se je s tem ponovil problem ustvarjanja novega monolita, kjer je bila storitev API preobremenjena s kodo na tak način, da so se pojavili različni scenariji napak. Na primer, nekatere končne točke so bile odstranjene ali pa so skripti naključno ustvarili toliko različic nečesa, da so te različice zavzele ves razpoložljivi pomnilnik storitve API.
Logično je bilo vzeti te končne točke in jih umakniti iz storitve API. Da bi to naredili, smo ustvarili komponente Node.js, ki so delovale kot majhne aplikacije v vsebnikih Docker. To nam je omogočilo izolacijo morebitnih težav in zrušitev, ki jih povzročajo te aplikacije vozlišč.
Stroški teh sprememb so precej visoki in so sestavljeni iz naslednjih dejavnikov:
- Orodja za produktivnost. Upravljanje novih tehnologij je zahtevalo nova orodja, saj ekipi uporabniškega vmesnika z zelo dobrimi skripti za izdelavo učinkovitega modela ni bilo treba porabiti veliko časa za upravljanje infrastrukture, morali so le napisati skripte in preveriti njihovo funkcionalnost.
Vpogled v priložnosti in razvrščanje – ključni primer so nova orodja, potrebna za odkrivanje informacij o gonilniku zmogljivosti. Vedeti je bilo treba, koliko je procesor zaseden, kako se uporablja pomnilnik, zbiranje teh informacij pa je zahtevalo različna orodja. - Fragmentacija osnovnih slik - preprost osnovni AMI je postal bolj fragmentiran in specializiran.
- Upravljanje vozlišč. Na voljo ni standardne arhitekture ali tehnologije, ki bi omogočala upravljanje vozlišč v oblaku, zato smo zgradili Titus, platformo za upravljanje vsebnikov, ki zagotavlja razširljivo in zanesljivo uvajanje vsebnikov in integracijo v oblak z Amazon AWS.
- Podvajanje knjižnice ali platforme. Zagotavljanje novih tehnologij z isto osnovno funkcionalnostjo platforme je zahtevalo njeno podvajanje v orodja za razvijalce Node.js v oblaku.
- Krivulja učenja in industrijske izkušnje. Uvajanje novih tehnologij neizogibno ustvarja nove izzive, ki jih je treba premagati in se iz njih učiti.
Tako se nismo mogli omejiti na eno »tlakovano cesto« in smo morali nenehno graditi nove načine za napredek naših tehnologij. Da bi zmanjšali stroške, smo omejili centralizirano podporo in se osredotočili na JVM, nova vozlišča in Docker. Dali smo prednost učinkovitemu učinku, ekipe obvestili o stroških njihovih odločitev in jih spodbudili k iskanju načinov za ponovno uporabo zelo učinkovitih rešitev, ki so jih že razvili. Ta pristop smo uporabili pri prevajanju storitve v tuje jezike za dostavo izdelka mednarodnim strankam. Primeri vključujejo razmeroma preproste odjemalske knjižnice, ki jih je mogoče ustvariti samodejno, tako da je dokaj enostavno ustvariti različico Python, različico Ruby, različico Java itd.
Nenehno smo iskali možnosti za uporabo preverjenih tehnologij, ki so se izkazale na enem mestu in v drugih podobnih situacijah.
Pogovorimo se o zadnjem elementu – spremembah ali variacijah. Poglejte, kako se poraba našega izdelka neenakomerno spreminja po dnevih v tednu in po urah čez dan. Lahko bi rekli, da je za Netflix najtežji čas ob 9. uri, ko je obremenitev sistema največja.
Kako lahko dosežemo visoko hitrost uvajanja novosti programske opreme, torej nenehno vnašanje novih sprememb v sistem, ne da bi pri tem povzročali prekinitve pri izvajanju storitev in ne povzročali nevšečnosti našim strankam? Netflix je to dosegel z uporabo Spinnakerja, nove globalne platforme za upravljanje in neprekinjeno dostavo (CD), ki temelji na oblaku.
Kar je kritično, je bil Spinnaker zasnovan za integracijo naših najboljših praks, tako da lahko, ko uvajamo komponente v proizvodnjo, integriramo izhod neposredno v našo tehnologijo dostave medijev.
V naš cevovod dostave smo lahko vključili dve tehnologiji, ki ju zelo cenimo: avtomatizirano kanarsko analizo in postopno uvajanje. Canary analiza pomeni, da del prometa usmerimo na novo različico kode, preostali produkcijski promet pa prenesemo skozi staro različico. Nato preverimo, kako je nova koda kos nalogi – bolje ali slabše od obstoječe.
Postopno uvajanje pomeni, da če ima uvajanje v eni regiji težave, se premaknemo na uvajanje v drugi regiji. V tem primeru mora biti zgoraj omenjeni kontrolni seznam vključen v proizvodni načrt. Prihranil vam bom nekaj časa in priporočam, da si ogledate moj prejšnji govor, Inženiring globalnih operacij Netflix v oblaku, če se želite poglobiti v to temo. Videoposnetek govora si lahko ogledate na povezavi na dnu prosojnice.
Na koncu predavanja bom na kratko spregovoril o organizaciji in arhitekturi Netflixa. Na samem začetku smo imeli shemo, imenovano Electronic Delivery, ki je bila prva različica pretakanja medijev NRDP 1.x. Tukaj lahko uporabimo izraz "povratni tok", ker je uporabnik na začetku lahko samo prenesel vsebino za kasnejše predvajanje v napravi. Netflixova prva platforma za digitalno dostavo je bila leta 2009 videti nekako takole.
Uporabniška naprava je vsebovala aplikacijo Netflix, ki je bila sestavljena iz UI vmesnika, varnostnih modulov, aktivacije storitve in predvajanja, ki temelji na platformi NRDP - Netflix Ready Device Platform.
Takrat je bil uporabniški vmesnik zelo preprost. Vseboval je nekaj, kar se je imenovalo Queque Reader, in uporabnik je šel na spletno mesto, da bi dodal nekaj v Queque in si nato ogledal dodano vsebino v svoji napravi. Pozitivno je bilo, da sta sprednja in zadnja ekipa pripadali isti organizaciji za elektronsko dostavo in tesno sodelovali. Tovor je bil ustvarjen na podlagi XML. Istočasno je bil ustvarjen Netflix API za poslovanje z DVD-ji, ki je spodbudil aplikacije tretjih oseb k usmerjanju prometa na našo storitev.
Kljub temu je bil Netflix API dobro pripravljen, da nam pomaga z inovativnim uporabniškim vmesnikom, ki vsebuje metapodatke vseh vsebin, informacije o tem, kateri filmi so na voljo, kar je ustvarilo možnost ustvarjanja seznamov za ogled. Imel je generični API REST, ki je temeljil na shemi JSON, odzivno kodo HTTP, enako tisti, ki se uporablja v sodobni arhitekturi, in varnostni model OAuth, kar je bilo takrat zahtevano za sprednjo aplikacijo. To je omogočilo prehod iz javnega modela dostave pretočnih vsebin na zasebnega.
Težava pri prehodu je bila razdrobljenost, saj je sedaj naš sistem deloval z dvema storitvama, ki temeljita na popolnoma različnih principih delovanja - ena na Rest, JSON in OAuth, druga na RPC, XML in varnostni mehanizem uporabnika, ki temelji na sistemu žetonov NTBA. To je bila prva hibridna arhitektura.
Med našima ekipama je v bistvu obstajal požarni zid, ker se API sprva ni dobro prilagajal NCCP, kar je povzročilo trenja med ekipama. Razlike so bile v storitvah, protokolih, vezjih, varnostnih modulih, razvijalci pa so morali pogosto preklapljati med povsem različnimi konteksti.
V zvezi s tem sem imel pogovor z enim od višjih inženirjev podjetja, ki sem mu zastavil vprašanje: »Kakšna bi morala biti prava dolgoročna arhitektura?« in postavil je nasprotno vprašanje: »Verjetno vas bolj skrbi o organizacijskih posledicah – kaj se zgodi, če te stvari integriramo in pokvarijo tisto, kar smo se naučili delati dobro? Ta pristop je zelo pomemben za Conwayjev zakon: "Organizacije, ki načrtujejo sisteme, so omejene z zasnovo, ki posnema komunikacijsko strukturo te organizacije." To je zelo abstraktna definicija, zato imam raje bolj specifično: "Vsak kos programske opreme odraža organizacijsko strukturo, ki jo je ustvarila." Tukaj je moj najljubši citat Erica Raymonda: "Če imate štiri ekipe razvijalcev, ki delajo na prevajalniku, boste na koncu imeli štiriprehodni prevajalnik." No, Netflix ima štiristopenjski prevajalnik in tako delamo.
Lahko rečemo, da v tem primeru pes maha z repom. Naša prva prednostna naloga ni rešitev, ampak organizacija; organizacija je tista, ki poganja arhitekturo, ki jo imamo. Postopoma smo iz mešanice storitev prešli na arhitekturo, ki smo jo poimenovali Blade Runner, ker tukaj govorimo o robnih storitvah in zmožnosti NCCP, da se loči in integrira neposredno v proxy Zuul, prehod API in ustrezne funkcije »kosi« so bili spremenjeni v nove mikrostoritve z naprednejšo varnostjo, funkcijami predvajanja, razvrščanja podatkov itd.
Tako lahko rečemo, da imajo strukture oddelkov in dinamika podjetja pomembno vlogo pri oblikovanju sistemske zasnove in so dejavnik, ki spodbuja ali zavira spremembe. Arhitektura mikrostoritev je zapletena in organska, njeno zdravje pa temelji na disciplini in vnesenem kaosu.
Malo reklame
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com