Josh Evans puhuu Netflixin mikropalvelujen kaoottisesta ja värikkäästä maailmasta alkaen aivan perusasioista - mikropalvelujen anatomiasta, hajautettujen järjestelmien haasteista ja niiden eduista. Tämän perustan pohjalta hän tutkii kulttuurisia, arkkitehtonisia ja toiminnallisia käytäntöjä, jotka johtavat mikropalvelujen hallintaan.
Toisin kuin toiminnallinen ajautuminen, uusien kielten käyttöönotto palveluiden kansainvälistymistä varten ja uudet teknologiat, kuten kontit, ovat tietoisia päätöksiä lisätä ympäristöön uutta monimutkaisuutta. Toimintatiimini standardisoi Netflixin parhaan teknologian tiekartan, joka tiivistettiin ennalta määritellyiksi parhaiksi käytännöiksi Javaan ja EC2:een perustuen, mutta liiketoiminnan kasvaessa kehittäjät alkoivat lisätä uusia komponentteja, kuten Python, Ruby, Node-JS ja Docker.
Olen erittäin ylpeä siitä, että olimme ensimmäiset, jotka puolustivat tuotteemme toimimista erinomaisesti odottamatta asiakkaiden valituksia. Kaikki alkoi riittävän yksinkertaiselta - meillä oli toimintaohjelmat Pythonissa ja muutama taustasovellus Rubyssa, mutta asiat muuttuivat paljon mielenkiintoisemmiksi, kun verkkokehittäjämme ilmoittivat luopuvansa JVM:stä ja siirtävänsä verkkoa. sovellus Node-ohjelmistoalustaan. Dockerin käyttöönoton jälkeen asiat muuttuivat paljon monimutkaisemmiksi. Seurasimme logiikkaa ja keksimämme teknologiat tulivat todeksi, kun otimme ne käyttöön asiakkaille, koska niissä oli paljon järkeä. Kerron sinulle miksi näin on.
API-yhdyskäytävällä on itse asiassa kyky integroida upeita komentosarjoja, jotka voivat toimia käyttöliittymäkehittäjien päätepisteinä. He muunsivat kaikki nämä skriptit siten, että muutosten tekemisen jälkeen he voivat ottaa ne käyttöön tuotantoon ja sitten käyttäjän laitteisiin, ja kaikki nämä muutokset synkronoitiin API-yhdyskäytävässä suoritettujen päätepisteiden kanssa.
Tämä kuitenkin toisti ongelman luoda uusi monoliitti, jossa API-palvelu oli ylikuormitettu koodilla siten, että esiintyi erilaisia vikatilanteita. Esimerkiksi joitain päätepisteitä poistettiin tai komentosarjat loivat satunnaisesti niin monta versiota jostakin, että versiot veivät koko API-palvelun käytettävissä olevan muistin.
Oli loogista ottaa nämä päätepisteet ja vetää ne pois API-palvelusta. Tätä varten loimme Node.js-komponentteja, jotka toimivat pieninä sovelluksina Docker-säiliöissä. Tämän ansiosta pystyimme eristämään näiden solmusovellusten aiheuttamat ongelmat ja kaatumiset.
Näiden muutosten kustannukset ovat melko suuret ja koostuvat seuraavista tekijöistä:
- Tuottavuuden työkalut. Uusien teknologioiden hallinta vaati uusia työkaluja, koska käyttöliittymätiimin, joka käytti erittäin hyviä skriptejä tehokkaan mallin luomiseen, ei tarvinnut käyttää paljon aikaa infrastruktuurin hallintaan, he pitivät vain kirjoittaa komentosarjoja ja tarkistaa niiden toimivuus.
Opportunity Insight and Sorting - Tärkeä esimerkki ovat uudet työkalut, joita tarvitaan suorituskykyohjaintietojen paljastamiseen. Oli tarpeen tietää kuinka paljon prosessori oli varattu, kuinka muistia käytettiin, ja tämän tiedon kerääminen vaati erilaisia työkaluja. - Peruskuvien pirstoutuminen - yksinkertainen perus-AMI on pirstoutunut ja erikoistunut.
- Solmun hallinta. Ei ole saatavilla valmista arkkitehtuuria tai teknologiaa, jonka avulla voit hallita solmuja pilvessä, joten rakensimme Tituksen, kontinhallintaalustan, joka tarjoaa skaalautuvan ja luotettavan kontin käyttöönoton ja pilviintegroinnin Amazon AWS:n kanssa.
- Kirjaston tai alustan kopiointi. Uusien teknologioiden tarjoaminen alustan samoilla ydintoiminnoilla vaati sen monistamista pilvipohjaisiin Node.js-kehittäjätyökaluihin.
- Oppimiskäyrä ja teollinen kokemus. Uusien teknologioiden käyttöönotto luo väistämättä uusia haasteita, jotka on voitettava ja joista on opittava.
Näin ollen emme voineet rajoittua yhteen "päällystettyyn tietä" ja meidän piti jatkuvasti rakentaa uusia tapoja kehittää teknologioitamme. Kustannusten pitämiseksi kurissa rajoitimme keskitettyä tukea ja keskityimme JVM:ään, uusiin solmuihin ja Dockeriin. Priorisoimme tehokkaan vaikutuksen, informoimme tiimejä päätöstensä kustannuksista ja rohkaisimme heitä etsimään tapoja käyttää uudelleen jo kehittämiään vaikuttavia ratkaisuja. Käytimme tätä lähestymistapaa kääntäessämme palvelua vieraille kielille toimittaaksemme tuotteen kansainvälisille asiakkaille. Esimerkkejä ovat suhteellisen yksinkertaiset asiakaskirjastot, jotka voidaan luoda automaattisesti, joten Python-version, Ruby-version, Java-version jne. luominen on melko helppoa.
Etsimme jatkuvasti mahdollisuuksia käyttää hyväksi todettuja teknologioita, jotka ovat osoittautuneet yhdessä paikassa ja muissa vastaavissa tilanteissa.
Puhutaanpa viimeisestä elementistä - muutoksista tai muunnelmista. Katso kuinka tuotteemme kulutus vaihtelee epätasaisesti viikonpäivittäin ja tunneittain pitkin päivää. Voidaan sanoa, että klo 9 on Netflixille vaikeinta aikaa, jolloin järjestelmän kuormitus saavuttaa maksiminsa.
Kuinka voimme saavuttaa ohjelmistoinnovaatioiden nopean käyttöönoton eli jatkuvan uusien muutosten tekemisen järjestelmään aiheuttamatta keskeytyksiä palveluiden toimittamisessa ja aiheuttamatta haittaa asiakkaillemme? Netflix saavutti tämän käyttämällä Spinnakeria, uutta globaalia pilvipohjaista hallinta- ja jatkuvatoimitusalustaa (CD).
Kriittisesti Spinnaker on suunniteltu integroimaan parhaat käytäntömme niin, että kun otamme komponentteja käyttöön tuotantoon, voimme integroida tuotoksen suoraan median toimitustekniikkaamme.
Olemme voineet sisällyttää toimitusketjuumme kaksi teknologiaa, joita arvostamme suuresti: automatisoitu kanarian analyysi ja vaiheittainen käyttöönotto. Canary-analyysi tarkoittaa, että ohjaamme liikennevirrat koodin uuteen versioon ja välitämme muun tuotantoliikenteen vanhan version kautta. Sitten tarkistamme, kuinka uusi koodi selviää tehtävästä - paremmin tai huonommin kuin nykyinen.
Porrastettu käyttöönotto tarkoittaa, että jos yhden alueen käyttöönotossa on ongelmia, siirrymme käyttöönottoon toisella alueella. Tässä tapauksessa edellä mainittu tarkistuslista on sisällytettävä tuotantoputkeen. Säästän aikaa ja suosittelen, että katsot edellisen puheeni, Engineering Global Netflix Operations in the Cloud, jos olet kiinnostunut sukeltamaan syvemmälle tähän aiheeseen. Puheen videotallenne on katsottavissa dian alareunassa olevasta linkistä.
Puheen lopussa kerron lyhyesti Netflixin organisaatiosta ja arkkitehtuurista. Heti alussa meillä oli sähköinen toimitus, joka oli ensimmäinen versio NRDP 1.x -median suoratoistosta. Termiä "backstream" voidaan käyttää tässä, koska alun perin käyttäjä pystyi vain lataamaan sisältöä myöhempää toistoa varten laitteella. Netflixin ensimmäinen digitaalinen jakelualusta vuonna 2009 näytti suunnilleen tältä.
Käyttäjälaite sisälsi Netflix-sovelluksen, joka koostui käyttöliittymästä, suojausmoduuleista, palvelun aktivoinnista ja toistosta, perustuen NRDP-alustaan - Netflix Ready Device Platform.
Tuolloin käyttöliittymä oli hyvin yksinkertainen. Se sisälsi niin sanotun Queque Readerin, ja käyttäjä meni sivustolle lisäämään jotain Quequeen ja katsomaan sitten lisättyä sisältöä laitteellaan. Positiivista oli, että front end -tiimi ja back end -tiimi kuuluivat samaan Electronic Delivery -organisaatioon ja niillä oli läheinen työsuhde. Hyötykuorma luotiin XML:n perusteella. Samalla luotiin DVD-liiketoiminnan Netflix API, joka kannusti kolmannen osapuolen sovelluksia ohjaamaan liikennettä palveluumme.
Netflix API oli kuitenkin hyvin valmistautunut auttamaan meitä innovatiivisella käyttöliittymällä, joka sisälsi metatiedot kaikesta sisällöstä, tietoa saatavilla olevista elokuvista, mikä loi mahdollisuuden luoda katselulistoja. Siinä oli yleinen REST API, joka perustui JSON-skeemaan, HTTP-vastauskoodi, sama, jota käytetään nykyaikaisessa arkkitehtuurissa, ja OAuth-suojausmalli, jota edellytettiin tuolloin käyttöliittymäsovellukselta. Tämä mahdollisti siirtymisen julkisesta suoratoistosisällön toimitusmallista yksityiseen.
Siirron ongelmana oli pirstoutuminen, koska nyt järjestelmämme toimi kahdella täysin eri toimintaperiaatteilla pohjautuvilla palveluilla - yksi Rest, JSON ja OAuth, toinen RPC, XML ja NTBA-token-järjestelmään perustuva käyttäjäturvamekanismi. Tämä oli ensimmäinen hybridiarkkitehtuuri.
Kahden tiimimme välillä oli pohjimmiltaan palomuuri, koska alun perin API ei skaalautunut kovin hyvin NCCP:n kanssa ja tämä johti kitkaa joukkueiden välille. Erot olivat palveluissa, protokollissa, piireissä, suojausmoduuleissa, ja kehittäjien oli usein vaihdettava täysin erilaisten kontekstien välillä.
Tältä osin kävin keskustelun yrityksen yhden vanhemman insinöörin kanssa, jolle esitin kysymyksen: "Millainen pitäisi olla oikea pitkän aikavälin arkkitehtuuri?" ja hän esitti vastakysymyksen: "Olet luultavasti enemmän huolissasi organisaation seurauksista - mitä tapahtuu, jos integroimme nämä asiat ja ne rikkovat sen, mitä olemme oppineet tekemään hyvin? Tämä lähestymistapa on erittäin tärkeä Conwayn lain kannalta: "Organisaatioita, jotka suunnittelevat järjestelmiä, rajoittaa suunnittelu, joka jäljittelee kyseisen organisaation viestintärakennetta." Tämä on hyvin abstrakti määritelmä, joten pidän parempana tarkempaa: "Jokainen ohjelmisto heijastaa organisaatiorakennetta, joka loi sen." Tässä on suosikkilainaukseni Eric Raymondilta: "Jos sinulla on neljä kehittäjäryhmää, jotka työskentelevät kääntäjän parissa, päädyt nelivaiheiseen kääntäjään." No, Netflixillä on nelivaiheinen kääntäjä, ja niin me toimimme.
Voimme sanoa, että tässä tapauksessa häntä heiluttaa koiraa. Ensimmäinen prioriteettimme ei ole ratkaisu, vaan organisaatio; se on organisaatio, joka ohjaa olemassa olevaa arkkitehtuuria. Vähitellen siirryimme palvelujoukosta arkkitehtuuriin, jota kutsuimme Blade Runneriksi, koska tässä puhutaan reunapalveluista ja NCCP:n kyvystä erottaa ja integroida suoraan Zuul-välityspalvelimeen, API-yhdyskäytävään ja vastaavaan toimintoon. ”kappaleista” on tehty uusia mikropalveluita, joissa on edistyneemmät suojaus-, toisto-, tiedonlajittelu- jne. ominaisuudet.
Voidaan siis sanoa, että osastorakenteet ja yritysdynamiikka ovat tärkeässä roolissa järjestelmäsuunnittelun muovaamisessa ja ovat muutosta edistävä tai estävä tekijä. Mikropalveluarkkitehtuuri on monimutkaista ja orgaanista, ja sen terveys perustuu kurinalaisuuteen ja tuotuun kaaokseen.
Jotain mainontaa
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com