Josh Evans hovoří o chaotickém a barevném světě mikroslužeb Netflix, počínaje úplnými základy – anatomií mikroslužeb, výzvami spojenými s distribuovanými systémy a jejich výhodami. V návaznosti na tento základ zkoumá kulturní, architektonické a provozní postupy, které vedou k mistrovství v mikroslužbách.
Na rozdíl od provozního posunu je zavádění nových jazyků pro internacionalizaci služeb a nových technologií, jako jsou kontejnery, vědomými rozhodnutími, jak přidat do prostředí novou složitost. Můj provozní tým se standardizoval podle nejlepší technologické mapy pro Netflix, která byla zapečena do předem definovaných osvědčených postupů založených na Javě a EC2, ale jak se podnikání rozrůstalo, vývojáři začali přidávat nové komponenty, jako jsou Python, Ruby, Node-JS a Docker.
Jsem velmi hrdý na to, že jsme byli první, kdo se zasadil o to, aby náš produkt fungoval skvěle bez čekání na stížnosti zákazníků. Všechno to začalo docela jednoduše – měli jsme operační programy v Pythonu a několik back-office aplikací v Ruby, ale věci se staly mnohem zajímavějšími, když naši weboví vývojáři oznámili, že se zbaví JVM a chystají se přesunout web. aplikace na softwarovou platformu Node js. Po zavedení Dockeru se věci staly mnohem složitějšími. Řídili jsme se logikou a technologie, se kterými jsme přišli, se staly realitou, když jsme je implementovali pro zákazníky, protože dávaly velký smysl. Řeknu vám, proč tomu tak je.
API Gateway má ve skutečnosti schopnost integrovat skvělé skripty, které mohou fungovat jako koncové body pro vývojáře uživatelského rozhraní. Převedli každý z těchto skriptů takovým způsobem, že po provedení změn je mohli nasadit do produkčního a poté do uživatelských zařízení a všechny tyto změny byly synchronizovány s koncovými body, které běžely v bráně API.
Tím se však opakoval problém s vytvořením nového monolitu, kde byla služba API přetížena kódem tak, že docházelo k různým scénářům selhání. Například byly odstraněny některé koncové body nebo skripty náhodně vygenerovaly tolik verzí něčeho, že verze zabraly veškerou dostupnou paměť služby API.
Bylo logické vzít tyto koncové body a vytáhnout je ze služby API. Za tímto účelem jsme vytvořili komponenty Node.js, které běžely jako malé aplikace v kontejnerech Docker. To nám umožnilo izolovat jakékoli problémy a pády způsobené těmito aplikacemi uzlů.
Náklady na tyto změny jsou poměrně vysoké a sestávají z následujících faktorů:
- Nástroje produktivity. Správa nových technologií vyžadovala nové nástroje, protože tým uživatelského rozhraní, využívající velmi dobré skripty k vytvoření efektivního modelu, nemusel trávit mnoho času správou infrastruktury, musel pouze psát skripty a kontrolovat jejich funkčnost.
Příležitosti Insight and Sorting – Klíčovým příkladem jsou nové nástroje potřebné k odhalení informací o ovladači výkonu. Bylo nutné vědět, jak moc je procesor vytížen, jak se využívá paměť, a sběr těchto informací vyžadoval různé nástroje. - Fragmentace základních obrazů – jednoduchá základní AMI se stala fragmentovanější a specializovanější.
- Správa uzlů. Není k dispozici žádná standardní architektura ani technologie, které by vám umožnily spravovat uzly v cloudu, a proto jsme vytvořili Titus, platformu pro správu kontejnerů, která poskytuje škálovatelné a spolehlivé nasazení kontejnerů a integraci cloudu s Amazon AWS.
- Duplikace knihovny nebo platformy. Poskytování nových technologií se stejnou základní funkcí platformy vyžadovalo její duplikaci do cloudových vývojářských nástrojů Node.js.
- Křivka učení a průmyslové zkušenosti. Zavádění nových technologií nevyhnutelně vytváří nové výzvy, které je třeba překonat a poučit se z nich.
Nemohli jsme se tedy omezit na jednu „dlážděnou cestu“ a museli jsme neustále budovat nové způsoby, jak naše technologie posouvat dál. Abychom udrželi nízké náklady, omezili jsme centralizovanou podporu a zaměřili jsme se na JVM, nové uzly a Docker. Upřednostnili jsme efektivní dopad, informovali týmy o nákladech na jejich rozhodnutí a povzbuzovali jsme je, aby hledaly způsoby, jak znovu použít vysoce účinná řešení, která již vyvinuli. Tento přístup jsme použili při překladu služby do cizích jazyků k dodání produktu mezinárodním klientům. Příklady zahrnují relativně jednoduché klientské knihovny, které lze generovat automaticky, takže je poměrně snadné vytvořit verzi Python, verzi Ruby, verzi Java atd.
Neustále jsme hledali možnosti využití osvědčených technologií, které se osvědčily na jednom místě a v dalších podobných situacích.
Pojďme se bavit o posledním prvku – změnách, neboli variacích. Podívejte se, jak se spotřeba našeho produktu nerovnoměrně mění podle dne v týdnu a po hodině během dne. Dalo by se říci, že pro Netflix je nejtěžší 9 hodin ráno, kdy zatížení systému dosahuje maxima.
Jak můžeme dosáhnout vysoké rychlosti implementace softwarových inovací, tedy neustálého provádění nových změn v systému, aniž bychom způsobovali přerušení dodávky služeb a nezpůsobovali nepříjemnosti našim zákazníkům? Netflix toho dosáhl pomocí Spinnakeru, nové globální cloudové platformy pro správu a nepřetržité doručování (CD).
Důležité je, že Spinnaker byl navržen tak, aby integroval naše osvědčené postupy, takže když nasazujeme komponenty do výroby, můžeme výstup integrovat přímo do naší technologie doručování médií.
Do našeho zásobovacího kanálu jsme dokázali začlenit dvě technologie, kterých si velmi ceníme: automatizovanou analýzu kanárků a postupné nasazení. Canary analýza znamená, že nasměrujeme pramínek provozu na novou verzi kódu a zbytek produkčního provozu přeneseme přes starou verzi. Poté zkontrolujeme, jak se nový kód vypořádá s úkolem - lépe nebo hůře než ten stávající.
Postupné zavádění znamená, že pokud má zavádění v jedné oblasti problémy, přejdeme k zavádění v jiné oblasti. V tomto případě musí být výše uvedený kontrolní seznam zahrnut do výrobního procesu. Ušetřím vám čas a doporučím vám, abyste se podívali na mou předchozí přednášku Engineering Global Netflix Operations in the Cloud, pokud máte zájem ponořit se hlouběji do tohoto tématu. Videozáznam projevu si můžete prohlédnout kliknutím na odkaz ve spodní části snímku.
Na konci povídání krátce pohovořím o organizaci a architektuře Netflixu. Na úplném začátku jsme měli schéma nazvané Electronic Delivery, což byla první verze streamování médií NRDP 1.x. Zde lze použít termín „backstream“, protože zpočátku mohl uživatel pouze stahovat obsah pro pozdější přehrávání na zařízení. Úplně první platforma pro digitální doručování Netflixu v roce 2009 vypadala nějak takto.
Uživatelské zařízení obsahovalo aplikaci Netflix, která se skládala z UI rozhraní, bezpečnostních modulů, aktivace a přehrávání služeb, založené na platformě NRDP – Netflix Ready Device Platform.
V té době bylo uživatelské rozhraní velmi jednoduché. Obsahoval to, co se nazývalo Queque Reader, a uživatel šel na web, aby něco přidal do Queque a pak si prohlížel přidaný obsah na svém zařízení. Pozitivní bylo, že přední a zadní tým patřili ke stejné organizaci pro elektronické doručování a měli úzký pracovní vztah. Užitná zátěž byla vytvořena na základě XML. Zároveň bylo vytvořeno rozhraní Netflix API pro obchod s DVD, které povzbudilo aplikace třetích stran, aby směrovaly provoz na naši službu.
Netflix API však bylo dobře připraveno, aby nám pomohlo s inovativním uživatelským rozhraním, obsahujícím metadata veškerého obsahu, informace o tom, jaké filmy byly k dispozici, což vytvořilo možnost generovat seznamy sledovaných. Měl generické REST API založené na schématu JSON, HTTP Response Code, stejný, jaký se používá v moderní architektuře, a model zabezpečení OAuth, což bylo v té době vyžadováno pro front-endovou aplikaci. To umožnilo přejít od veřejného modelu doručování streamovaného obsahu k soukromému.
Problémem přechodu byla fragmentace, protože nyní náš systém provozoval dvě služby založené na zcela odlišných principech fungování – jednu na Rest, JSON a OAuth, druhou na RPC, XML a uživatelském bezpečnostním mechanismu založeném na systému tokenů NTBA. Jednalo se o první hybridní architekturu.
Mezi našimi dvěma týmy byl v podstatě firewall, protože zpočátku se rozhraní API s NCCP příliš neškálovalo, což vedlo k třenicím mezi týmy. Rozdíly byly ve službách, protokolech, okruzích, bezpečnostních modulech a vývojáři museli často přecházet mezi zcela odlišnými kontexty.
V tomto ohledu jsem vedl rozhovor s jedním ze starších inženýrů společnosti, kterému jsem položil otázku: „Jaká by měla být správná dlouhodobá architektura?“ a on položil protiotázku: „Pravděpodobně vás více znepokojuje o organizačních důsledcích – co se stane, když tyto věci integrujeme a poruší to, co jsme se naučili dělat dobře? Tento přístup je velmi relevantní pro Conwayův zákon: "Organizace, které navrhují systémy, jsou omezeny návrhem, který kopíruje komunikační strukturu dané organizace." Toto je velmi abstraktní definice, takže preferuji konkrétnější: „Jakýkoli software odráží organizační strukturu, která jej vytvořila.“ Zde je můj oblíbený citát od Erica Raymonda: "Pokud máte čtyři týmy vývojářů pracující na kompilátoru, skončíte se čtyřprůchodovým kompilátorem." Netflix má čtyřprůchodový kompilátor a tak pracujeme.
Dá se říci, že v tomto případě pes vrtí ocasem. Naší první prioritou není řešení, ale organizace; je to organizace, která řídí architekturu, kterou máme. Postupně jsme z houfem služeb přešli na architekturu, kterou jsme nazvali Blade Runner, protože zde mluvíme o okrajových službách a schopnosti NCCP být odděleny a integrovány přímo do Zuul proxy, API brány a odpovídající funkční „kousky“ se změnily v nové mikroslužby s pokročilejšími funkcemi zabezpečení, přehrávání, třídění dat atd.
Dá se tedy říci, že struktury oddělení a dynamika společnosti hrají důležitou roli při utváření návrhu systému a jsou faktorem, který podporuje nebo brzdí změny. Architektura mikroslužeb je komplexní a organická a její zdraví je založeno na disciplíně a zavedeném chaosu.
Trochu reklamy
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com