Josh Evans hovorí o chaotickom a farebnom svete mikroslužieb Netflix, počnúc úplnými základmi – anatómiou mikroslužieb, výzvami spojenými s distribuovanými systémami a ich výhodami. Na základe tohto základu skúma kultúrne, architektonické a prevádzkové postupy, ktoré vedú k zvládnutiu mikroslužieb.
Na rozdiel od prevádzkového posunu je zavádzanie nových jazykov pre internacionalizáciu služieb a nových technológií, ako sú kontajnery, vedomými rozhodnutiami, ktoré pridávajú do prostredia novú zložitosť. Môj operačný tím sa štandardizoval podľa najlepšieho technologického plánu pre Netflix, ktorý bol zapečatený do vopred definovaných osvedčených postupov založených na Jave a EC2, ale ako sa podnikanie rozrastalo, vývojári začali pridávať nové komponenty, ako sú Python, Ruby, Node-JS a Docker.
Som veľmi hrdý na to, že sme boli prví, ktorí presadzovali, aby náš produkt fungoval skvele bez čakania na sťažnosti zákazníkov. Všetko to začalo dosť jednoducho – mali sme operačné programy v Pythone a niekoľko back-office aplikácií v Ruby, ale veci sa stali oveľa zaujímavejšie, keď naši weboví vývojári oznámili, že sa zbavia JVM a chystajú sa presunúť web. aplikácie na softvérovú platformu Node js. Po zavedení Dockera sa veci stali oveľa zložitejšími. Riadili sme sa logikou a technológie, s ktorými sme prišli, sa stali realitou, keď sme ich implementovali pre zákazníkov, pretože dávali veľký zmysel. Poviem vám, prečo je to tak.
API Gateway má v skutočnosti schopnosť integrovať skvelé skripty, ktoré môžu slúžiť ako koncové body pre vývojárov používateľského rozhrania. Každý z týchto skriptov skonvertovali takým spôsobom, že po vykonaní zmien ich mohli nasadiť do produkcie a následne do používateľských zariadení a všetky tieto zmeny boli synchronizované s koncovými bodmi, ktoré bežali v bráne API.
Zopakoval sa však problém vytvorenia nového monolitu, kde bola služba API preťažená kódom takým spôsobom, že nastali rôzne scenáre zlyhania. Napríklad boli odstránené niektoré koncové body alebo skripty náhodne vygenerovali toľko verzií niečoho, že verzie zaberali všetku dostupnú pamäť služby API.
Bolo logické vziať tieto koncové body a vytiahnuť ich zo služby API. Na tento účel sme vytvorili komponenty Node.js, ktoré sa spúšťali ako malé aplikácie v kontajneroch Docker. To nám umožnilo izolovať akékoľvek problémy a zlyhania spôsobené týmito aplikáciami uzlov.
Náklady na tieto zmeny sú pomerne vysoké a pozostávajú z nasledujúcich faktorov:
- Nástroje produktivity. Riadenie nových technológií si vyžadovalo nové nástroje, pretože tím používateľského rozhrania, využívajúci veľmi dobré skripty na vytvorenie efektívneho modelu, nemusel tráviť veľa času správou infraštruktúry, musel iba písať skripty a kontrolovať ich funkčnosť.
Prehľad a triedenie príležitostí – Kľúčovým príkladom sú nové nástroje potrebné na odhaľovanie informácií o ovládačoch výkonu. Bolo potrebné vedieť, koľko je procesor vyťažený, ako sa využíva pamäť a zber týchto informácií si vyžadoval rôzne nástroje. - Fragmentácia základných obrázkov – jednoduchá základná AMI sa stala fragmentovanejšou a špecializovanejšou.
- Správa uzlov. Nie je k dispozícii žiadna štandardná architektúra ani technológia, ktorá by vám umožnila spravovať uzly v cloude, a preto sme vytvorili Titus, platformu na správu kontajnerov, ktorá poskytuje škálovateľné a spoľahlivé nasadenie kontajnerov a integráciu cloudu s Amazon AWS.
- Duplikácia knižnice alebo platformy. Poskytnutie nových technológií s rovnakou základnou funkcionalitou platformy si vyžadovalo duplikáciu do cloudových vývojárskych nástrojov Node.js.
- Krivka učenia a priemyselné skúsenosti. Zavádzanie nových technológií nevyhnutne vytvára nové výzvy, ktoré treba prekonať a poučiť sa z nich.
Nemohli sme sa teda obmedziť na jednu „spevnenú cestu“ a museli sme neustále budovať nové spôsoby napredovania našich technológií. Aby sme udržali nízke náklady, obmedzili sme centralizovanú podporu a zamerali sme sa na JVM, nové uzly a Docker. Uprednostnili sme efektívny vplyv, informovali tímy o nákladoch na ich rozhodnutia a povzbudili sme ich, aby hľadali spôsoby, ako opätovne použiť riešenia s vysokým dopadom, ktoré už vyvinuli. Tento prístup sme použili pri preklade služby do cudzích jazykov na dodanie produktu medzinárodným klientom. Príklady zahŕňajú relatívne jednoduché klientske knižnice, ktoré je možné generovať automaticky, takže je pomerne jednoduché vytvoriť verziu Pythonu, verziu Ruby, verziu Java atď.
Neustále sme hľadali možnosti využitia overených technológií, ktoré sa osvedčili na jednom mieste a v iných podobných situáciách.
Poďme sa baviť o poslednom prvku – zmenách, alebo variáciách. Pozrite sa, ako sa spotreba nášho produktu mení nerovnomerne podľa dňa v týždni a podľa hodiny počas dňa. Dalo by sa povedať, že 9:XNUMX je pre Netflix najťažší čas, kedy zaťaženie systému dosahuje maximum.
Ako môžeme dosiahnuť vysokú rýchlosť implementácie softvérových inovácií, teda neustále robiť nové zmeny v systéme, bez toho, aby sme spôsobovali prerušenia poskytovania služieb a nespôsobovali nepríjemnosti našim zákazníkom? Netflix to dosiahol pomocou Spinnaker, novej globálnej cloudovej platformy pre správu a nepretržité doručovanie (CD).
Dôležité je, že Spinnaker bol navrhnutý tak, aby integroval naše osvedčené postupy, aby sme pri nasadzovaní komponentov do produkcie mohli integrovať výstup priamo do našej technológie doručovania médií.
Podarilo sa nám začleniť dve technológie do nášho dodávateľského reťazca, ktoré si vysoko ceníme: automatizovanú analýzu kanárikov a postupné nasadenie. Analýza Canary znamená, že nasmerujeme prúd návštevnosti na novú verziu kódu a zvyšok produkčnej návštevnosti prepustíme cez starú verziu. Potom skontrolujeme, ako sa nový kód vyrovná s úlohou - lepšie alebo horšie ako ten existujúci.
Postupné zavádzanie znamená, že ak má zavádzanie v jednom regióne problémy, prejdeme na zavádzanie v inom regióne. V tomto prípade musí byť uvedený kontrolný zoznam zahrnutý do výrobného procesu. Ušetrím vám nejaký čas a odporúčam vám, aby ste si pozreli moju predchádzajúcu prednášku Engineering Global Netflix Operations in the Cloud, ak máte záujem ponoriť sa hlbšie do tejto témy. Videozáznam prejavu si môžete pozrieť kliknutím na odkaz v spodnej časti snímky.
Na konci rozprávania v krátkosti porozprávam o organizácii a architektúre Netflixu. Na samom začiatku sme mali schému s názvom Elektronické doručovanie, čo bola prvá verzia streamovania médií NRDP 1.x. Pojem „spätný tok“ sa tu môže použiť, pretože spočiatku mohol používateľ sťahovať obsah na neskoršie prehrávanie na zariadení. Úplne prvá platforma digitálneho doručovania Netflixu v roku 2009 vyzerala asi takto.
Používateľské zariadenie obsahovalo aplikáciu Netflix, ktorá pozostávala z UI rozhrania, bezpečnostných modulov, aktivácie a prehrávania služieb, založených na platforme NRDP – Netflix Ready Device Platform.
V tom čase bolo používateľské rozhranie veľmi jednoduché. Obsahoval to, čo sa nazývalo Queque Reader, a používateľ mohol ísť na stránku, aby pridal niečo do Queque a potom si prezeral pridaný obsah na svojom zariadení. Pozitívom bolo, že front-end tím a back-end tím patrili do tej istej organizácie elektronického doručovania a mali úzky pracovný vzťah. Užitočné zaťaženie bolo vytvorené na základe XML. Zároveň bolo vytvorené Netflix API pre obchod s DVD, čo povzbudilo aplikácie tretích strán, aby smerovali návštevnosť do našej služby.
Netflix API však bolo dobre pripravené, aby nám pomohlo s inovatívnym používateľským rozhraním, obsahujúcim metadáta všetkého obsahu, informácie o tom, aké filmy boli dostupné, čo vytvorilo možnosť generovať zoznamy sledovaných. Mal generické REST API založené na schéme JSON, kód odpovede HTTP, rovnaký, aký sa používa v modernej architektúre, a bezpečnostný model OAuth, ktorý sa v tom čase vyžadoval pre front-end aplikáciu. To umožnilo prejsť z verejného modelu doručovania streamovaného obsahu na súkromný.
Problémom pri prechode bola fragmentácia, keďže teraz náš systém prevádzkoval dve služby založené na úplne odlišných princípoch fungovania – jednu na Rest, JSON a OAuth, druhú na RPC, XML a používateľskom bezpečnostnom mechanizme založenom na systéme tokenov NTBA. Bola to prvá hybridná architektúra.
Medzi našimi dvoma tímami bol v podstate firewall, pretože spočiatku sa rozhranie API s NCCP veľmi dobre neškálovalo, čo viedlo k nezhodám medzi tímami. Rozdiely boli v službách, protokoloch, okruhoch, bezpečnostných moduloch a vývojári museli často prepínať medzi úplne odlišnými kontextami.
V tejto súvislosti som sa porozprával s jedným zo starších inžinierov spoločnosti, ktorému som položil otázku: „Aká by mala byť správna dlhodobá architektúra?“ a on položil protiotázku: „Asi vás viac znepokojuje o organizačných dôsledkoch – čo sa stane, ak tieto veci integrujeme a porušia to, čo sme sa naučili robiť dobre? Tento prístup je veľmi relevantný pre Conwayov zákon: "Organizácie, ktoré navrhujú systémy, sú obmedzené dizajnom, ktorý kopíruje komunikačnú štruktúru danej organizácie." Toto je veľmi abstraktná definícia, takže uprednostňujem konkrétnejšiu definíciu: „Akýkoľvek softvér odráža organizačnú štruktúru, ktorá ho vytvorila.“ Tu je môj obľúbený citát od Erica Raymonda: "Ak máte štyri tímy vývojárov pracujúcich na kompilátore, skončíte so štvorpriechodovým kompilátorom." Netflix má štvorpriechodový kompilátor a tak fungujeme.
Dá sa povedať, že v tomto prípade chvost vrtí psom. Našou prvou prioritou nie je riešenie, ale organizácia; je to organizácia, ktorá riadi architektúru, ktorú máme. Postupne sme z húštiny služieb prešli na architektúru, ktorú sme nazvali Blade Runner, pretože tu hovoríme o okrajových službách a možnosti NCCP oddeliť a integrovať priamo do Zuul proxy, API brány a zodpovedajúcich funkčných „kúsky“ sa zmenili na nové mikroslužby s pokročilejšími funkciami zabezpečenia, prehrávania, triedenia údajov atď.
Dá sa teda povedať, že štruktúry oddelení a dynamika spoločnosti zohrávajú dôležitú úlohu pri formovaní návrhu systému a sú faktorom, ktorý podporuje alebo bráni zmenám. Architektúra mikroslužieb je komplexná a organická a jej zdravie je založené na disciplíne a zavedenom chaose.
Trochu reklamy
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com