Joshas Evansas pasakoja apie chaotišką ir spalvingą „Netflix“ mikropaslaugų pasaulį, pradedant nuo pačių pagrindų – mikropaslaugų anatomijos, iššūkių, susijusių su paskirstytomis sistemomis, ir jų teikiama nauda. Remdamasis šiuo pagrindu, jis tyrinėja kultūrinę, architektūrinę ir veiklos praktiką, kuri veda į mikropaslaugų meistriškumą.
Skirtingai nuo veiklos dreifo, naujų paslaugų internacionalizavimo kalbų ir naujų technologijų, pvz., konteinerių, įvedimas yra sąmoningi sprendimai, siekiant suteikti aplinkai naujo sudėtingumo. Mano operacijų komanda standartizavo geriausią „Netflix“ technologijų planą, kuris buvo įtrauktas į iš anksto nustatytą geriausią praktiką, pagrįstą „Java“ ir EC2, tačiau verslui augant kūrėjai pradėjo pridėti naujų komponentų, tokių kaip „Python“, „Ruby“, „Node-JS“ ir „Docker“.
Labai didžiuojuosi, kad mes pirmieji pasisakėme už tai, kad mūsų produktas veiktų puikiai, nelaukiant klientų skundų. Viskas prasidėjo pakankamai paprastai – turėjome veikiančias programas Python ir keletą back-office programų Ruby, bet viskas tapo daug įdomiau, kai mūsų žiniatinklio kūrėjai paskelbė, kad ketina atsisakyti JVM ir ketina perkelti žiniatinklį. taikymas Node programinės įrangos platformai.js. Po Docker įdiegimo viskas tapo daug sudėtingesnė. Vadovavomės logika ir mūsų sugalvotos technologijos tapo realybe, kai jas įdiegėme klientams, nes jos buvo labai prasmingos. Aš jums pasakysiu, kodėl taip yra.
„API Gateway“ iš tikrųjų turi galimybę integruoti puikius scenarijus, kurie gali veikti kaip vartotojo sąsajos kūrėjų galutiniai taškai. Jie konvertavo kiekvieną iš šių scenarijų taip, kad atlikę pakeitimus galėtų juos įdiegti gamybinėje, o vėliau ir vartotojo įrenginiuose, ir visi šie pakeitimai buvo sinchronizuoti su galiniais taškais, kurie veikė API šliuzuose.
Tačiau tai pakartojo naujo monolito kūrimo problemą, kai API paslauga buvo perkrauta kodu taip, kad atsirasdavo įvairių gedimų scenarijų. Pavyzdžiui, kai kurie galiniai taškai buvo pašalinti arba scenarijai atsitiktinai sugeneravo tiek daug kažko versijų, kad versijos užėmė visą turimą API paslaugos atmintį.
Buvo logiška paimti šiuos galinius taškus ir ištraukti juos iš API paslaugos. Norėdami tai padaryti, sukūrėme Node.js komponentus, kurie veikė kaip mažos programos Docker konteineriuose. Tai leido mums išskirti visas šių mazgų programų sukeltas problemas ir gedimus.
Šių pakeitimų kaina yra gana didelė ir susideda iš šių veiksnių:
- Produktyvumo įrankiai. Naujoms technologijoms valdyti prireikė naujų įrankių, nes vartotojo sąsajos komandai, naudojant labai gerus scenarijus efektyviam modeliui sukurti, nereikėjo daug laiko skirti infrastruktūros valdymui, tereikėjo rašyti scenarijus ir patikrinti jų funkcionalumą.
Galimybių įžvalga ir rūšiavimas – pagrindinis pavyzdys yra nauji įrankiai, reikalingi našumo tvarkyklės informacijai atskleisti. Reikėjo žinoti, kiek procesorius užimtas, kaip naudojama atmintis, o šiai informacijai surinkti reikėjo įvairių įrankių. - Bazinių vaizdų suskaidymas – paprastas bazinis AMI tapo labiau suskaidytas ir specializuotas.
- Mazgų valdymas. Nėra paruoštos architektūros ar technologijos, leidžiančios valdyti debesies mazgus, todėl sukūrėme „Titus“ – konteinerių valdymo platformą, kuri užtikrina keičiamo dydžio ir patikimą konteinerių diegimą ir debesų integraciją su „Amazon AWS“.
- Bibliotekos ar platformos kopijavimas. Norint teikti naujas technologijas su tokiomis pačiomis pagrindinėmis platformos funkcijomis, reikėjo jas kopijuoti į debesies pagrindu veikiančius Node.js kūrėjų įrankius.
- Mokymosi kreivė ir pramoninė patirtis. Naujų technologijų diegimas neišvengiamai sukuria naujų iššūkių, kuriuos reikia įveikti ir iš jų pasimokyti.
Taigi negalėjome apsiriboti vienu „asfaltuotu keliu“ ir turėjome nuolat kurti naujus būdus tobulinti savo technologijas. Siekdami sumažinti išlaidas, apribojome centralizuotą palaikymą ir sutelkėme dėmesį į JVM, naujus mazgus ir „Docker“. Pirmenybę teikėme efektyviam poveikiui, informavome komandas apie jų sprendimų kainą ir skatinome jas ieškoti būdų, kaip pakartotinai panaudoti jau sukurtus didelio poveikio sprendimus. Mes naudojome šį metodą versdami paslaugą į užsienio kalbas, kad pristatytume produktą tarptautiniams klientams. Pavyzdžiai apima gana paprastas klientų bibliotekas, kurias galima generuoti automatiškai, kad būtų gana lengva sukurti Python, Ruby, Java ir kt.
Nuolat ieškojome galimybių panaudoti pasiteisinusias technologijas, pasiteisinusias vienoje vietoje ir kitose panašiose situacijose.
Pakalbėkime apie paskutinį elementą – pokyčius, arba variacijas. Pažiūrėkite, kaip mūsų gaminio suvartojimas netolygiai skiriasi priklausomai nuo savaitės dienos ir valandomis visą dieną. Galima sakyti, 9 val. ryto yra pats sunkiausias laikas „Netflix“, kai sistemos apkrova pasiekia maksimumą.
Kaip pasiekti didelį programinių naujovių diegimo greitį, tai yra nuolat daryti naujus sistemos pakeitimus, nesukeliant paslaugų teikimo trikdžių ir nesukeliant nepatogumų savo klientams? „Netflix“ tai pasiekė naudodama „Spinnaker“ – naują pasaulinę debesų valdymo ir nuolatinio pristatymo (CD) platformą.
Svarbiausia, kad „Spinnaker“ buvo sukurta siekiant integruoti mūsų geriausią praktiką, kad gamyboje diegdami komponentus galėtume integruoti išvestį tiesiai į medijos pristatymo technologiją.
Į savo pristatymo sistemą galėjome įtraukti dvi technologijas, kurias labai vertiname: automatinę kanarėlių analizę ir etapinį diegimą. Kanarų analizė reiškia, kad srauto srautą nukreipiame į naują kodo versiją, o likusį gamybinį srautą perduodame per senąją versiją. Tada patikriname, kaip naujasis kodas susidoroja su užduotimi – geriau ar blogiau nei esamas.
Laipsniškas išleidimas reiškia, kad jei išleidimas viename regione turi problemų, pereiname prie išleidimo kitame regione. Tokiu atveju pirmiau minėtas kontrolinis sąrašas turi būti įtrauktas į gamybos vamzdyną. Sutaupysiu jums šiek tiek laiko ir rekomenduosiu perskaityti mano ankstesnį pokalbį „Inžinierių pasaulinės Netflix operacijos debesyje“, jei norite pasinerti į šią temą giliau. Kalbos vaizdo įrašą galima peržiūrėti paspaudus skaidrės apačioje esančią nuorodą.
Pokalbio pabaigoje trumpai papasakosiu apie „Netflix“ organizaciją ir architektūrą. Pačioje pradžioje turėjome schemą pavadinimu Elektroninis pristatymas, kuri buvo pirmoji NRDP 1.x medijos transliacijos versija. Terminas „atgalinis srautas“ gali būti vartojamas čia, nes iš pradžių vartotojas galėjo atsisiųsti turinį, kad vėliau būtų atkurtas įrenginyje. Pati pirmoji „Netflix“ skaitmeninio pristatymo platforma 2009 m. atrodė maždaug taip.
Vartotojo įrenginyje buvo „Netflix“ programa, kurią sudarė vartotojo sąsaja, saugos moduliai, paslaugos aktyvinimas ir atkūrimas, pagrįsta NRDP platforma – „Netflix Ready Device Platform“.
Tuo metu vartotojo sąsaja buvo labai paprasta. Jame buvo vadinama „Ququeque Reader“, o vartotojas eidavo į svetainę, kad pridėtų ką nors prie „Ququeque“, o tada peržiūrėdavo pridėtą turinį savo įrenginyje. Teigiama buvo tai, kad priekinės komandos ir užpakalinės komandos priklausė tai pačiai elektroninio pristatymo organizacijai ir palaikė glaudžius darbinius santykius. Naudingasis krovinys buvo sukurtas remiantis XML. Tuo pačiu metu buvo sukurta Netflix API DVD verslui, kuri paskatino trečiųjų šalių programas nukreipti srautą į mūsų paslaugą.
Tačiau „Netflix“ API buvo gerai paruošta, kad padėtų mums su naujoviška vartotojo sąsaja, kurioje yra viso turinio metaduomenys, informacija apie galimus filmus, o tai suteikė galimybę generuoti žiūrėjimo sąrašus. Jis turėjo bendrą REST API, pagrįstą JSON schema, HTTP atsako kodą, tą patį, kuris naudojamas šiuolaikinėje architektūroje, ir OAuth saugos modelį, kurio tuo metu reikėjo priekinei programai. Tai leido pereiti nuo viešojo srautinio turinio pristatymo modelio prie privataus.
Perėjimo problema buvo susiskaidymas, nes dabar mūsų sistema veikė dvi paslaugas, pagrįstas visiškai skirtingais veikimo principais - vieną Rest, JSON ir OAuth, kitą RPC, XML ir vartotojo saugos mechanizmą, pagrįstą NTBA žetonų sistema. Tai buvo pirmoji hibridinė architektūra.
Iš esmės tarp mūsų dviejų komandų buvo užkarda, nes iš pradžių API nebuvo labai gerai suderinta su NCCP ir tai sukėlė trintį tarp komandų. Skirtumai buvo paslaugose, protokoluose, grandinėse, saugos moduliuose, o kūrėjams dažnai tekdavo perjungti visiškai skirtingus kontekstus.
Šiuo klausimu turėjau pokalbį su vienu iš vyresniųjų įmonės inžinierių, kuriam uždaviau klausimą: „Kokia turėtų būti tinkama ilgalaikė architektūra? apie organizacines pasekmes – kas atsitiks, jei šiuos dalykus integruosime ir jie sulaužys tai, ką išmokome daryti gerai? Šis požiūris labai aktualus Conway dėsniui: „Organizacijos, kurios projektuoja sistemas, yra suvaržytos dizaino, atkartojančio tos organizacijos komunikacijos struktūrą“. Tai labai abstraktus apibrėžimas, todėl man labiau patinka konkretesnis apibrėžimas: „Bet kokia programinė įranga atspindi organizacinę struktūrą, kuri ją sukūrė“. Štai mano mėgstamiausia Erico Raymondo citata: „Jei turite keturias kūrėjų komandas, kurios dirba su kompiliatoriumi, turėsite keturių žingsnių kompiliatorių. Na, „Netflix“ turi keturių žingsnių kompiliatorių, ir taip mes dirbame.
Galima sakyti, kad šiuo atveju uodega vizgina šunį. Mūsų pirmasis prioritetas yra ne sprendimas, o organizacija; tai yra organizacija, kuri vadovauja mūsų turimai architektūrai. Palaipsniui iš daugybės paslaugų perėjome prie architektūros, kurią pavadinome „Blade Runner“, nes čia kalbame apie krašto paslaugas ir NCCP galimybę atskirti ir integruoti tiesiai į „Zuul“ tarpinį serverį, API šliuzą ir atitinkamą funkcinę funkciją. „gabalai“ buvo paversti naujomis mikropaslaugomis su pažangesnėmis saugumo, atkūrimo, duomenų rūšiavimo ir kt.
Taigi galima teigti, kad padalinių struktūros ir įmonės dinamika vaidina svarbų vaidmenį formuojant sistemos dizainą ir yra veiksnys, skatinantis arba stabdantis pokyčius. Mikropaslaugų architektūra yra sudėtinga ir organiška, o jos sveikata pagrįsta disciplina ir įvestu chaosu.
Šiek tiek reklamos
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com