Josh Evans govori o kaotičnom i šarenom svijetu Netflixovih mikroservisa, počevši od samih osnova - anatomije mikroservisa, izazova povezanih s distribuiranim sustavima i njihovih prednosti. Nadovezujući se na te temelje, istražuje kulturne, arhitektonske i operativne prakse koje dovode do ovladavanja mikroservisima.
Za razliku od operativnog kretanja, uvođenje novih jezika za internacionalizaciju usluga i novih tehnologija kao što su spremnici svjesne su odluke za dodavanje nove složenosti okruženju. Moj operativni tim standardizirao se prema najboljem tehnološkom planu za Netflix, koji je uklopljen u unaprijed definirane najbolje prakse temeljene na Javi i EC2, ali kako je posao rastao, programeri su počeli dodavati nove komponente kao što su Python, Ruby, Node-JS i Docker.
Jako sam ponosan što smo prvi zagovarali da naš proizvod radi odlično bez čekanja na pritužbe kupaca. Sve je počelo prilično jednostavno - imali smo operativne programe u Pythonu i nekoliko pozadinskih aplikacija u Rubyju, ali stvari su postale puno zanimljivije kada su naši web programeri najavili da će odbaciti JVM i premjestiti web aplikacija na softversku platformu Node. js. Nakon uvođenja Dockera stvari su postale mnogo složenije. Slijedili smo logiku i tehnologije koje smo smislili postale su stvarnost kada smo ih implementirali za kupce jer su imale puno smisla. Reći ću vam zašto je to tako.
API Gateway zapravo ima mogućnost integriranja sjajnih skripti koje mogu djelovati kao krajnje točke za UI programere. Konvertirali su svaku od tih skripti na takav način da su ih nakon unošenja promjena mogli implementirati u produkciju, a zatim na korisničke uređaje, a sve su te promjene sinkronizirane s krajnjim točkama koje su se izvodile u API pristupniku.
Međutim, ovo je ponovio problem stvaranja novog monolita gdje je API usluga bila preopterećena kodom na takav način da su se dogodili različiti scenariji kvarova. Na primjer, neke su krajnje točke uklonjene ili su skripte nasumično generirale toliko verzija nečega da su verzije zauzele svu dostupnu memoriju API usluge.
Bilo je logično uzeti te krajnje točke i povući ih iz API usluge. Da bismo to učinili, stvorili smo Node.js komponente koje su se izvodile kao male aplikacije u Docker spremnicima. To nam je omogućilo da izoliramo sve probleme i padove uzrokovane ovim aplikacijama čvorova.
Cijena ovih promjena prilično je velika i sastoji se od sljedećih čimbenika:
- Alati za produktivnost. Upravljanje novim tehnologijama zahtijevalo je nove alate jer UI tim, koristeći vrlo dobre skripte za izradu učinkovitog modela, nije morao trošiti puno vremena na upravljanje infrastrukturom, samo je trebalo napisati skripte i provjeriti njihovu funkcionalnost.
Uvid u mogućnosti i sortiranje - ključni primjer su novi alati potrebni za otkrivanje informacija o pokretaču performansi. Trebalo je znati koliko je procesor zauzet, kako se koristi memorija, a prikupljanje tih informacija zahtijevalo je različite alate. - Fragmentacija osnovnih slika - jednostavni osnovni AMI postao je fragmentiraniji i specijaliziraniji.
- Upravljanje čvorom. Ne postoji dostupna gotova arhitektura ili tehnologija koja vam omogućuje upravljanje čvorovima u oblaku, pa smo izgradili Titus, platformu za upravljanje spremnicima koja pruža skalabilnu i pouzdanu implementaciju spremnika i integraciju u oblak s Amazon AWS-om.
- Dupliciranje knjižnice ili platforme. Pružanje novih tehnologija s istom osnovnom funkcionalnošću platforme zahtijevalo je njeno dupliciranje u alate za razvojne programere Node.js temeljene na oblaku.
- Krivulja učenja i industrijsko iskustvo. Uvođenje novih tehnologija neminovno stvara nove izazove koje treba prevladati i iz kojih treba učiti.
Stoga se nismo mogli ograničiti na jednu "asfaltiranu cestu" i morali smo stalno graditi nove načine za unapređenje naših tehnologija. Kako bismo smanjili troškove, ograničili smo centraliziranu podršku i usredotočili se na JVM, nove čvorove i Docker. Dali smo prioritet učinkovitom učinku, informirali timove o cijeni njihovih odluka i potaknuli ih da traže načine za ponovnu upotrebu visokoučinkovitih rješenja koja su već razvili. Koristili smo ovaj pristup prilikom prevođenja usluge na strane jezike kako bismo isporučili proizvod međunarodnim klijentima. Primjeri uključuju relativno jednostavne klijentske biblioteke koje se mogu generirati automatski, tako da je prilično lako stvoriti Python verziju, Ruby verziju, Java verziju itd.
Stalno smo tražili mogućnosti korištenja provjerenih tehnologija koje su se dokazale na jednom mjestu iu drugim sličnim situacijama.
Razgovarajmo o posljednjem elementu – promjenama, odnosno varijacijama. Pogledajte kako potrošnja našeg proizvoda neravnomjerno varira po danima u tjednu i po satu tijekom dana. Moglo bi se reći da je 9 ujutro najteže vrijeme za Netflix, kada je opterećenje sustava maksimalno.
Kako postići veliku brzinu implementacije softverskih inovacija, odnosno konstantno unositi nove promjene u sustav, a da pritom ne dođe do prekida u pružanju usluga i ne stvaramo neugodnosti našim korisnicima? Netflix je to postigao upotrebom Spinnakera, nove globalne platforme za upravljanje i kontinuiranu isporuku (CD) koja se temelji na oblaku.
Ono što je kritično, Spinnaker je osmišljen kako bi integrirao naše najbolje prakse tako da dok implementiramo komponente u proizvodnju, možemo integrirati izlaz izravno u našu tehnologiju isporuke medija.
Uspjeli smo uključiti dvije tehnologije u naš cjevovod isporuke koje iznimno cijenimo: automatiziranu analizu Canarya i postupnu implementaciju. Canary analiza znači da dio prometa usmjeravamo na novu verziju koda, a ostatak proizvodnog prometa propuštamo kroz staru verziju. Zatim provjeravamo kako se novi kod nosi sa zadatkom - bolje ili lošije od postojećeg.
Postepeno uvođenje znači da ako uvođenje u jednoj regiji ima problema, prelazimo na uvođenje u drugoj regiji. U tom slučaju, gore spomenuti kontrolni popis mora biti uključen u proizvodni proces. Uštedjet ću vam malo vremena i preporučiti vam da pogledate moj prethodni govor, Inženjering globalnih Netflix operacija u oblaku, ako ste zainteresirani dublje zaroniti u ovu temu. Video snimku govora možete pogledati klikom na poveznicu na dnu slajda.
Na kraju predavanja ukratko ću govoriti o organizaciji i arhitekturi Netflixa. Na samom početku imali smo shemu pod nazivom Electronic Delivery, koja je bila prva verzija NRDP 1.x media streaminga. Ovdje se može koristiti izraz "backstream" jer je u početku korisnik mogao samo preuzeti sadržaj za kasniju reprodukciju na uređaju. Netflixova prva platforma za digitalnu isporuku, još 2009., izgledala je otprilike ovako.
Korisnički uređaj sadržavao je Netflix aplikaciju koja se sastojala od UI sučelja, sigurnosnih modula, aktivacije usluge i reprodukcije, bazirane na NRDP platformi - Netflix Ready Device Platform.
U to je vrijeme korisničko sučelje bilo vrlo jednostavno. Sadržao je ono što se nazivalo Queque Reader, a korisnik bi otišao na stranicu kako bi dodao nešto u Queque i zatim pogledao dodani sadržaj na svom uređaju. Pozitivno je bilo to što su front end tim i back end tim pripadali istoj organizaciji Electronic Delivery i imali blisku suradnju. Korisni teret je kreiran na temelju XML-a. Istodobno je kreiran Netflix API za DVD poslovanje, koji je potaknuo aplikacije trećih strana da usmjere promet na našu uslugu.
Međutim, Netflix API bio je dobro pripremljen da nam pomogne s inovativnim korisničkim sučeljem, koje sadrži metapodatke o svim sadržajima, informacije o tome koji su filmovi dostupni, što je stvorilo mogućnost generiranja popisa za gledanje. Imao je generički REST API temeljen na JSON shemi, HTTP Response Code, isti onaj koji se koristi u modernoj arhitekturi, i OAuth sigurnosni model, što je bilo ono što je bilo potrebno u to vrijeme za front-end aplikaciju. Time je omogućen prelazak s javnog modela isporuke streaming sadržaja na privatni.
Problem prijelaza bila je fragmentiranost, budući da je sada naš sustav radio s dvije usluge temeljene na potpuno različitim principima rada – jedna na Rest, JSON i OAuth, druga na RPC, XML i korisničkom sigurnosnom mehanizmu baziranom na NTBA token sustavu. Ovo je bila prva hibridna arhitektura.
U biti je postojao vatrozid između naša dva tima jer se u početku API nije dobro mjerio s NCCP-om i to je dovelo do trvenja između timova. Razlike su bile u uslugama, protokolima, sklopovima, sigurnosnim modulima, a programeri su se često morali prebacivati između potpuno različitih konteksta.
S tim u vezi, imao sam razgovor s jednim od starijih inženjera tvrtke, kojem sam postavio pitanje: “Kakva bi trebala biti prava dugoročna arhitektura?”, a on je postavio kontra pitanje: “Vjerojatno ste više zabrinuti o organizacijskim posljedicama - što se događa ako integriramo te stvari, a one pokvare ono što smo naučili raditi dobro? Ovaj je pristup vrlo relevantan za Conwayev zakon: "Organizacije koje dizajniraju sustave ograničene su dizajnom koji replicira komunikacijsku strukturu te organizacije." Ovo je vrlo apstraktna definicija, pa mi je draža preciznija: "Svaki dio softvera odražava organizacijsku strukturu koja ga je stvorila." Evo mog omiljenog citata Erica Raymonda: "Ako imate četiri tima programera koji rade na kompajleru, završit ćete s kompajlerom u četiri prolaza." Pa, Netflix ima kompajler s četiri prolaza i tako radimo.
Možemo reći da u ovom slučaju pas maše repom. Naš prvi prioritet nije rješenje, već organizacija; organizacija je ta koja pokreće arhitekturu koju imamo. Postupno, od gomile usluga, prešli smo na arhitekturu koju smo nazvali Blade Runner, jer ovdje govorimo o rubnim uslugama i mogućnosti da se NCCP odvoji i integrira izravno u Zuul proxy, API pristupnik i odgovarajuću funkcionalnost “komadi” su pretvoreni u nove mikroservise s naprednijom sigurnošću, replayom, sortiranjem podataka itd. značajkama.
Stoga se može reći da strukture odjela i dinamika poduzeća igraju važnu ulogu u oblikovanju dizajna sustava te su čimbenik koji potiče ili sprječava promjene. Arhitektura mikroservisa je složena i organska, a njeno zdravlje se temelji na disciplini i uvedenom kaosu.
Malo reklame
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com