Josh Evans vorbește despre lumea haotică și plină de culoare a microserviciilor Netflix, începând cu elementele de bază - anatomia microserviciilor, provocările asociate sistemelor distribuite și beneficiile acestora. Pe această bază, el explorează practicile culturale, arhitecturale și operaționale care duc la stăpânirea microserviciilor.
Spre deosebire de deriva operațională, introducerea de noi limbi pentru internaționalizarea serviciilor și noile tehnologii precum containerele sunt decizii conștiente pentru a adăuga o nouă complexitate mediului. Echipa mea de operațiuni a standardizat cea mai bună foaie de parcurs tehnologică pentru Netflix, care a fost integrată în cele mai bune practici predefinite bazate pe Java și EC2, dar pe măsură ce afacerea a crescut, dezvoltatorii au început să adauge noi componente precum Python, Ruby, Node-JS și Docker.
Sunt foarte mândru că am fost primii care au susținut ca produsul nostru să funcționeze excelent fără a aștepta plângerile clienților. Totul a început destul de simplu - aveam programe de operare în Python și câteva aplicații de back-office în Ruby, dar lucrurile au devenit mult mai interesante când dezvoltatorii noștri web au anunțat că vor renunța la JVM și vor muta web-ul. aplicație pe platforma software Node.js. După introducerea Docker, lucrurile au devenit mult mai complexe. Am urmat logica și tehnologiile cu care am venit au devenit realitate atunci când le-am implementat pentru clienți pentru că aveau mult sens. Îți voi spune de ce este așa.
API Gateway are de fapt capacitatea de a integra scripturi grozave care pot acționa ca puncte finale pentru dezvoltatorii de UI. Ei au convertit fiecare dintre aceste scripturi în așa fel încât, după ce au făcut modificări, să le poată implementa în producție și apoi pe dispozitivele utilizatorului, iar toate aceste modificări au fost sincronizate cu punctele finale care rulau în gateway-ul API.
Cu toate acestea, acest lucru a repetat problema creării unui nou monolit în care serviciul API a fost supraîncărcat cu cod, astfel încât să apară diverse scenarii de eșec. De exemplu, unele puncte finale au fost eliminate sau scripturile au generat aleatoriu atât de multe versiuni ale ceva, încât versiunile au ocupat toată memoria disponibilă a serviciului API.
Era logic să luăm aceste puncte finale și să le scoatem din serviciul API. Pentru a face acest lucru, am creat componente Node.js care rulau ca aplicații mici în containerele Docker. Acest lucru ne-a permis să izolăm orice probleme și blocări cauzate de aceste aplicații nod.
Costul acestor modificări este destul de mare și constă din următorii factori:
- Instrumente de productivitate. Gestionarea noilor tehnologii a necesitat noi instrumente deoarece echipa UI, folosind scripturi foarte bune pentru a crea un model eficient, nu a trebuit să petreacă mult timp gestionând infrastructura, trebuia doar să scrie scripturi și să le verifice funcționalitatea.
Perspectiva și sortarea oportunităților - Un exemplu cheie îl reprezintă noile instrumente necesare pentru a descoperi informații despre driverul de performanță. Era necesar să se știe cât de mult era ocupat procesorul, cum era folosită memoria, iar colectarea acestor informații necesita instrumente diferite. - Fragmentarea imaginilor de bază - AMI-ul de bază simplu a devenit mai fragmentat și specializat.
- Managementul nodurilor. Nu există nicio arhitectură sau tehnologie disponibilă care să vă permită să gestionați nodurile în cloud, așa că am construit Titus, o platformă de gestionare a containerelor care oferă implementare scalabilă și fiabilă a containerelor și integrare în cloud cu Amazon AWS.
- Duplicarea unei biblioteci sau platforme. Furnizarea de noi tehnologii cu aceeași funcționalitate de bază a platformei a necesitat duplicarea acesteia în instrumentele de dezvoltare Node.js bazate pe cloud.
- Curba de învățare și experiență industrială. Introducerea noilor tehnologii creează inevitabil noi provocări care trebuie depășite și din care trebuie învățate.
Astfel, nu ne-am putut limita la un singur „drum asfaltat” și a trebuit să construim constant noi modalități de a avansa tehnologiile noastre. Pentru a reduce costurile, am limitat suportul centralizat și ne-am concentrat pe JVM, noduri noi și Docker. Am prioritizat impactul eficient, am informat echipele despre costul deciziilor lor și le-am încurajat să caute modalități de a reutiliza soluțiile de mare impact pe care le-au dezvoltat deja. Am folosit această abordare atunci când traducem serviciul în limbi străine pentru a livra produsul clienților internaționali. Exemplele includ biblioteci client relativ simple care pot fi generate automat, astfel încât este destul de ușor să creați o versiune Python, o versiune Ruby, o versiune Java etc.
Căutăm constant oportunități de a folosi tehnologii dovedite care s-au dovedit într-un loc și în alte situații similare.
Să vorbim despre ultimul element - modificări sau variații. Uitați-vă cum consumul produsului nostru variază inegal în funcție de ziua săptămânii și de oră pe parcursul zilei. Ați putea spune că ora 9 a.m. este cea mai grea oră pentru Netflix, când încărcarea sistemului atinge maximul.
Cum putem obține o viteză mare de implementare a inovațiilor software, adică să facem în mod constant noi modificări în sistem, fără a provoca întreruperi în furnizarea serviciilor și fără a crea neplăceri clienților noștri? Netflix a realizat acest lucru prin utilizarea Spinnaker, o nouă platformă globală de management și livrare continuă (CD) bazată pe cloud.
În mod esențial, Spinnaker a fost conceput pentru a ne integra cele mai bune practici, astfel încât, pe măsură ce implementăm componente în producție, să putem integra rezultatele direct în tehnologia noastră de livrare media.
Am reușit să încorporăm două tehnologii în pipeline-ul nostru de livrare pe care le prețuim foarte mult: analiza automată Canary și implementarea în etape. Analiza Canary înseamnă că direcționăm un filtru de trafic către noua versiune a codului și trecem restul traficului de producție prin versiunea veche. Apoi verificăm modul în care noul cod face față sarcinii - mai bine sau mai rău decât cel existent.
O lansare eșalonată înseamnă că, dacă o lansare într-o regiune are probleme, trecem la o lansare într-o altă regiune. În acest caz, lista de verificare menționată mai sus trebuie inclusă în conducta de producție. Vă voi economisi ceva timp și vă recomand să consultați discuția mea anterioară, Engineering Global Netflix Operations in the Cloud, dacă sunteți interesat să aprofundați acest subiect. Înregistrarea video a discursului poate fi vizionată urmând linkul din partea de jos a slide-ului.
La finalul discuției, voi vorbi pe scurt despre organizarea și arhitectura Netflix. La început am avut o schemă numită Electronic Delivery, care a fost prima versiune de streaming media NRDP 1.x. Termenul „backstream” poate fi folosit aici, deoarece inițial utilizatorul putea descărca conținut doar pentru redare ulterioară pe dispozitiv. Prima platformă de livrare digitală a Netflix, din 2009, arăta cam așa.
Dispozitivul utilizatorului conținea aplicația Netflix, care consta dintr-o interfață UI, module de securitate, activare și redare a serviciului, bazată pe platforma NRDP - Netflix Ready Device Platform.
La acea vreme interfața cu utilizatorul era foarte simplă. Conținea ceea ce se numea un Queque Reader, iar utilizatorul mergea pe site pentru a adăuga ceva la Queque și apoi vedea conținutul adăugat pe dispozitivul său. Aspectul pozitiv a fost că echipa front-end și echipa back-end aparțineau aceleiași organizații Electronic Delivery și aveau o relație de lucru strânsă. Sarcina utilă a fost creată pe baza XML. În același timp, a fost creat API-ul Netflix pentru afacerea DVD, care a încurajat aplicațiile terțe să direcționeze traficul către serviciul nostru.
Cu toate acestea, API-ul Netflix a fost bine pregătit pentru a ne ajuta cu o interfață de utilizator inovatoare, care conține metadate ale întregului conținut, informații despre ce filme erau disponibile, ceea ce a creat posibilitatea de a genera liste de urmărire. Avea un API REST generic bazat pe schema JSON, codul de răspuns HTTP, același folosit în arhitectura modernă și un model de securitate OAuth, care era ceea ce era necesar la acea vreme pentru o aplicație front-end. Acest lucru a făcut posibilă trecerea de la un model public de livrare de conținut în flux la unul privat.
Problema tranziției a fost fragmentarea, deoarece acum sistemul nostru opera două servicii bazate pe principii de funcționare complet diferite - unul pe Rest, JSON și OAuth, celălalt pe RPC, XML și un mecanism de securitate a utilizatorului bazat pe sistemul de token NTBA. Aceasta a fost prima arhitectură hibridă.
În esență, a existat un firewall între cele două echipe ale noastre, deoarece inițial API-ul nu s-a scalat foarte bine cu NCCP și acest lucru a dus la fricțiuni între echipe. Diferențele au fost în servicii, protocoale, circuite, module de securitate, iar dezvoltatorii au trebuit adesea să comute între contexte complet diferite.
În acest sens, am avut o conversație cu unul dintre inginerii seniori ai companiei, căruia i-am pus întrebarea: „Care ar trebui să fie arhitectura potrivită pe termen lung?” și a pus contra întrebarea: „Probabil că ești mai îngrijorat. despre consecințele organizaționale - ce se întâmplă dacă integrăm aceste lucruri și ele sparg ceea ce am învățat să facem bine? Această abordare este foarte relevantă pentru Legea lui Conway: „Organizațiile care proiectează sisteme sunt constrânse de un design care reproduce structura de comunicare a acelei organizații”. Aceasta este o definiție foarte abstractă, așa că prefer una mai specifică: „Orice bucată de software reflectă structura organizațională care a creat-o”. Iată citatul meu preferat din Eric Raymond: „Dacă aveți patru echipe de dezvoltatori care lucrează la un compilator, veți ajunge cu un compilator cu patru treceri”. Ei bine, Netflix are un compilator cu patru treceri și așa lucrăm.
Putem spune că în acest caz coada dă din câine. Prima noastră prioritate nu este soluția, ci organizația; organizația este cea care conduce arhitectura pe care o avem. Treptat, dintr-un amestec de servicii, am trecut la o arhitectură pe care am numit-o Blade Runner, pentru că aici vorbim despre serviciile edge și despre capacitatea NCCP de a fi separat și integrat direct în proxy-ul Zuul, gateway-ul API și funcționalul corespunzător. „piesele” au fost transformate în noi microservicii cu caracteristici mai avansate de securitate, reluare, sortare a datelor etc.
Astfel, se poate spune că structurile departamentale și dinamica companiei joacă un rol important în modelarea proiectării sistemului și sunt un factor care promovează sau împiedică schimbarea. Arhitectura microserviciilor este complexă și organică, iar sănătatea sa se bazează pe disciplină și pe haos introdus.
Niște reclame
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com