Josh Evans praat oor die chaotiese en kleurvolle wêreld van Netflix-mikrodienste, wat begin met die heel basiese beginsels – die anatomie van mikrodienste, die uitdagings wat met verspreide stelsels geassosieer word, en die voordele daarvan. Deur op hierdie grondslag te bou, ondersoek hy die kulturele, argitektoniese en operasionele praktyke wat lei tot mikrodiensbemeestering.
Anders as operasionele drywing, is die bekendstelling van nuwe tale vir diensinternasionalisering en nuwe tegnologieë soos houers bewuste besluite om nuwe kompleksiteit tot die omgewing te voeg. My bedryfspan het gestandaardiseer op die beste tegnologie-padkaart vir Netflix, wat gebak is in voorafbepaalde beste praktyke gebaseer op Java en EC2, maar soos die besigheid gegroei het, het ontwikkelaars nuwe komponente soos Python, Ruby, Node-JS en Docker begin byvoeg.
Ek is baie trots daarop dat ons die eerste was wat gepleit het dat ons produk uitstekend werk sonder om te wag vir klanteklagtes. Dit het alles eenvoudig genoeg begin - ons het bedryfsprogramme in Python gehad en 'n paar back-office toepassings in Ruby, maar dinge het baie interessanter geword toe ons webontwikkelaars aangekondig het dat hulle die JVM gaan laat vaar en die web gaan skuif toepassing op die Node-sagtewareplatform. js. Na die bekendstelling van Docker het dinge baie meer kompleks geword. Ons het logika gevolg en die tegnologieë waarmee ons vorendag gekom het, het werklikheid geword toe ons dit vir kliënte geïmplementeer het, want dit het baie sin gemaak. Ek sal jou vertel hoekom dit so is.
API Gateway het eintlik die vermoë om wonderlike skrifte te integreer wat as eindpunte vir UI-ontwikkelaars kan dien. Hulle het elkeen van hierdie skrifte op so 'n manier omgeskakel dat hulle, nadat hulle veranderinge aangebring het, dit na produksie en dan na gebruikerstoestelle kon ontplooi, en al hierdie veranderinge is gesinchroniseer met eindpunte wat in die API-poort loop.
Dit het egter die probleem herhaal om 'n nuwe monoliet te skep waar die API-diens oorlaai is met kode op so 'n manier dat verskeie mislukkingscenario's plaasgevind het. Sommige eindpunte is byvoorbeeld verwyder, of skrifte het ewekansig soveel weergawes van iets gegenereer dat die weergawes al die beskikbare geheue van die API-diens opgeneem het.
Dit was logies om hierdie eindpunte te neem en hulle uit die API-diens te trek. Om dit te doen, het ons Node.js-komponente geskep wat as klein toepassings in Docker-houers geloop het. Dit het ons in staat gestel om enige probleme en ineenstortings wat deur hierdie nodus-toepassings veroorsaak word, te isoleer.
Die koste van hierdie veranderinge is redelik groot en bestaan uit die volgende faktore:
- Produktiwiteit gereedskap. Die bestuur van nuwe tegnologieë het nuwe nutsmiddels vereis omdat die UI-span, wat baie goeie skrifte gebruik het om 'n doeltreffende model te skep, nie veel tyd hoef te bestee aan die bestuur van die infrastruktuur nie, hulle moes net skrifte skryf en hul funksionaliteit nagaan.
Geleentheid-insig en -sortering - 'n Sleutelvoorbeeld is die nuwe gereedskap wat nodig is om inligting oor prestasiebestuurder te ontbloot. Dit was nodig om te weet hoeveel die verwerker beset is, hoe geheue gebruik word, en om hierdie inligting in te samel, het verskillende gereedskap vereis. - Fragmentasie van basisbeelde - die eenvoudige basis-AMI het meer gefragmenteerd en gespesialiseerd geword.
- Nodus bestuur. Daar is geen van die rak argitektuur of tegnologie beskikbaar wat jou toelaat om nodusse in die wolk te bestuur nie, daarom het ons Titus gebou, 'n houerbestuurplatform wat skaalbare en betroubare houerontplooiing en wolkintegrasie met Amazon AWS bied.
- Duplisering van 'n biblioteek of platform. Om nuwe tegnologieë met dieselfde kernfunksionaliteit van die platform te verskaf, moes dit in wolkgebaseerde Node.js-ontwikkelaarnutsgoed gedupliseer word.
- Leerkurwe en industriële ervaring. Die bekendstelling van nuwe tegnologieë skep onvermydelik nuwe uitdagings wat oorkom moet word en waaruit geleer moet word.
Ons kon ons dus nie tot een “geplaveide pad” beperk nie en moes voortdurend nuwe maniere bou om ons tegnologieë te bevorder. Om koste laag te hou, het ons gesentraliseerde ondersteuning beperk en gefokus op die JVM, nuwe nodusse en Docker. Ons het effektiewe impak geprioritiseer, spanne ingelig oor die koste van hul besluite en hulle aangemoedig om maniere te soek om die hoë-impakoplossings wat hulle reeds ontwikkel het, te hergebruik. Ons het hierdie benadering gebruik toe ons die diens in vreemde tale vertaal het om die produk aan internasionale kliënte te lewer. Voorbeelde sluit in relatief eenvoudige kliëntbiblioteke wat outomaties gegenereer kan word, sodat dit redelik maklik is om 'n Python-weergawe, 'n Ruby-weergawe, 'n Java-weergawe, ens.
Ons was voortdurend op soek na geleenthede om bewese tegnologieë te gebruik wat hulself op een plek en in ander soortgelyke situasies bewys het.
Kom ons praat oor die laaste element - veranderinge, of variasies. Kyk hoe wissel die verbruik van ons produk oneweredig volgens dag van die week en per uur deur die dag. Jy kan sê dat 9:XNUMX die moeilikste tyd vir Netflix is, wanneer die las op die stelsel sy maksimum bereik.
Hoe kan ons 'n hoë spoed van implementering van sagteware-innovasies bereik, dit wil sê, voortdurend nuwe veranderinge aan die stelsel maak, sonder om onderbrekings in dienslewering te veroorsaak en sonder om ongerief vir ons kliënte te skep? Netflix het dit bereik deur die gebruik van Spinnaker, 'n nuwe wêreldwye wolk-gebaseerde bestuur en deurlopende aflewering (CD) platform.
Krities, Spinnaker is ontwerp om ons beste praktyke te integreer sodat ons, terwyl ons komponente in produksie ontplooi, die uitset direk in ons media-afleweringstegnologie kan integreer.
Ons kon twee tegnologieë in ons afleweringspyplyn inkorporeer wat ons baie waardeer: outomatiese kanarie-analise en gefaseerde ontplooiing. Kanarie-analise beteken dat ons 'n druppel verkeer na die nuwe weergawe van die kode lei, en die res van die produksieverkeer deur die ou weergawe stuur. Dan kyk ons hoe die nuwe kode die taak hanteer - beter of slegter as die bestaande een.
'n Verspreide ontplooiing beteken dat as 'n ontplooiing in een streek probleme het, ons na 'n ontplooiing in 'n ander streek beweeg. In hierdie geval moet die bogenoemde kontrolelys by die produksiepyplyn ingesluit word. Ek sal jou tyd spaar en aanbeveel dat jy na my vorige praatjie, Engineering Global Netflix Operations in the Cloud, kyk as jy belangstel om dieper in hierdie onderwerp te duik. Die video-opname van die toespraak kan bekyk word deur die skakel onderaan die skyfie te volg.
Aan die einde van die praatjie sal ek kortliks praat oor die organisasie en argitektuur van Netflix. Heel aan die begin het ons 'n skema genaamd Electronic Delivery gehad, wat die eerste weergawe van NRDP 1.x mediastroom was. Die term "terugstroom" kan hier gebruik word omdat die gebruiker aanvanklik slegs inhoud kon aflaai vir latere afspeel op die toestel. Netflix se heel eerste digitale afleweringsplatform, terug in 2009, het so gelyk.
Die gebruikertoestel het die Netflix-toepassing bevat, wat bestaan het uit 'n UI-koppelvlak, sekuriteitsmodules, diensaktivering en terugspeel, gebaseer op die NRDP-platform - Netflix Ready Device Platform.
Op daardie tydstip was die gebruikerskoppelvlak baie eenvoudig. Dit bevat wat 'n Queque-leser genoem word, en die gebruiker sal na die webwerf gaan om iets by Queque te voeg en dan die bygevoegde inhoud op hul toestel te bekyk. Die positiewe was dat die voorkantspan en die agterkantspan aan dieselfde Elektroniese Afleweringsorganisasie behoort het en 'n noue werksverhouding gehad het. Die loonvrag is geskep op grond van XML. Terselfdertyd is die Netflix API vir die DVD-besigheid geskep, wat derdeparty-toepassings aangemoedig het om verkeer na ons diens te lei.
Die Netflix API was egter goed voorberei om ons te help met 'n innoverende gebruikerskoppelvlak, wat metadata van alle inhoud bevat, inligting oor watter flieks beskikbaar was, wat die vermoë geskep het om kyklyste te genereer. Dit het 'n generiese REST API gehad gebaseer op die JSON-skema, HTTP-reaksiekode, dieselfde een wat in moderne argitektuur gebruik word, en 'n OAuth-sekuriteitsmodel, wat destyds nodig was vir 'n front-end-toepassing. Dit het dit moontlik gemaak om van 'n publieke model van stroominhoudlewering na 'n private een te beweeg.
Die probleem met die oorgang was fragmentasie, want nou het ons stelsel twee dienste bedryf wat gebaseer is op heeltemal verskillende werkingsbeginsels - een op Rest, JSON en OAuth, die ander op RPC, XML en 'n gebruikersekuriteitsmeganisme gebaseer op die NTBA-tokenstelsel. Dit was die eerste hibriede argitektuur.
Daar was in wese 'n firewall tussen ons twee spanne, want aanvanklik het die API nie baie goed met NCCP geskaal nie en dit het tot wrywing tussen die spanne gelei. Die verskille was in dienste, protokolle, stroombane, sekuriteitsmodules, en ontwikkelaars moes dikwels tussen heeltemal verskillende kontekste wissel.
In hierdie verband het ek 'n gesprek gehad met een van die senior ingenieurs van die maatskappy, aan wie ek die vraag gevra het: "Wat moet die regte langtermyn-argitektuur wees?" en hy het die teenvraag gevra: "Jy is waarskynlik meer bekommerd. oor die organisatoriese gevolge - wat gebeur as ons hierdie dinge integreer, en hulle breek wat ons geleer het om goed te doen? Hierdie benadering is baie relevant vir Conway se wet: "Organisasies wat stelsels ontwerp word beperk deur 'n ontwerp wat die kommunikasiestruktuur van daardie organisasie herhaal." Dit is 'n baie abstrakte definisie, so ek verkies 'n meer spesifieke een: "Enige stuk sagteware weerspieël die organisatoriese struktuur wat dit geskep het." Hier is my gunsteling aanhaling van Eric Raymond: "As jy vier spanne ontwikkelaars het wat aan 'n samesteller werk, sal jy eindig met 'n viergangsamesteller." Wel, Netflix het 'n viergangsamesteller, en dit is hoe ons werk.
Ons kan sê dat in hierdie geval die stert die hond waai. Ons eerste prioriteit is nie die oplossing nie, maar die organisasie; dit is die organisasie wat die argitektuur wat ons het dryf. Geleidelik, van 'n mengelmoes dienste, het ons oorbeweeg na 'n argitektuur wat ons Blade Runner genoem het, want hier praat ons van randdienste en die vermoë van NCCP om direk geskei en geïntegreer te word in die Zuul-instaanbediener, API-poort, en die ooreenstemmende funksionele "stukke" is omskep in nuwe mikrodienste met meer gevorderde sekuriteit, herhaling, datasortering, ens.-kenmerke.
Daar kan dus gesê word dat departementele strukture en maatskappydinamika 'n belangrike rol speel in die vorming van stelselontwerp en 'n faktor is wat verandering bevorder of belemmer. Mikrodienste-argitektuur is kompleks en organies, en die gesondheid daarvan is gebaseer op dissipline en ingevoerde chaos.
Bietjie advertensie
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com