Vyvinutá jednotná platforma GraphQL na Netflixu

V tomto článku popíšeme naši cestu k jednotné architektuře GraphQL. Konkrétně budeme hovořit o platformě GraphQL, kterou jsme vytvořili a která se skládá z rámce Domain Graph Services (DGS) pro implementaci služeb GraphQL v Javě pomocí Spring Boot, graphql-java a nástrojů pro vývoj schémat. Popíšeme také, jak se ekosystém vyvíjel v různých fázích přijetí.

Proč GraphQL Federation?

Netflix v posledních několika letech rozrůstá svou nabídku originálního obsahu. Mnoho týmů v rámci studiové organizace pracuje na aplikacích a službách pro usnadnění produkce, jako je řízení talentů, rozpočtování a postprodukce.

V několika případech týmy nezávisle vytvořily svá vlastní API pomocí gRPC, REST a dokonce i GraphQL. Zákazníci budou muset mluvit s jednou nebo více back-end službami, aby získali data, která potřebují. Implementace nebyla konzistentní a měli jsme příliš mnoho způsobů, jak získat stejná data, což mělo za následek více zdrojů pravdy. Abychom tento problém vyřešili, vytvořili jsme jednotné GraphQL API poháněné monolitem. Zákaznické týmy pak mohly přistupovat ke všem požadovaným datům prostřednictvím tohoto jednotného API a potřebovaly pouze mluvit s jedinou back-endovou službou. Monolit zase udělá veškerou práci při komunikaci se všemi backendy potřebnými k načtení a vrácení dat v jediné odpovědi GraphQL.

Tento modul se však neškáloval, protože více týmů přidalo svá data do jednotného rozhraní GraphQL API. Vyžadovalo znalosti domény, aby bylo možné určit, jak převést příchozí požadavky na odpovídající volání pro různé služby. To způsobilo údržbu a provozní zátěž pro tým údržby tohoto grafu. Kromě toho vývoj schématu také nebyl ve vlastnictví produktových týmů primárně odpovědných za data, což mělo za následek špatně navržená rozhraní API pro zákazníky.

Chtěli jsme prozkoumat jiný model vlastnictví, aby týmy, které vlastní data, mohly být také zodpovědné za své vlastní GraphQL API a zároveň zachovat jednotné GraphQL API, se kterým mohou vývojáři zákazníků komunikovat (viz obrázek 1).

[Click on the image to view full-size]

Obrázek 1: Jednotné vlastnictví grafu

V roce 2019 byl propuštěn Apollo Specifikace unie, což týmům umožňuje mít podgrafy a přitom být součástí jednoho grafu. Jinými slovy, vlastnictví grafů lze konsolidovat napříč více týmy rozdělením různých resolverů, které zpracovávají příchozí požadavky GraphQL. Namísto monolitu nyní můžeme použít jednoduchou bránu pro směrování požadavků na backendy GraphQL, nazývané Domain Graph Services, které obsluhují podgraf. Každý DGS získá data z odpovídajících backendů vlastněných stejným týmem (viz obrázek 2). Začali jsme pilotovat vlastní implementaci brány Federated GraphQL a začali jsme pracovat s několika týmy na přechodu na tuto novou architekturu.

[Click on the image to view full-size]

Obrázek 2: Sjednocená architektura GraphQL

O dva roky později máme nyní přes 150 služeb, které jsou součástí tohoto grafu. Nejen, že jsme rozšířili graf studia, ale vytvořili jsme další grafy pro další oblasti, jako jsou naše interní nástroje platformy a další také pro migraci streamovacích API.

Fáze rané adopce

Když jsme s migrací začínali, měli jsme asi 40 týmů, které již byly součástí federovaného grafu obsluhovaného naším monolitem GraphQL. Požádali jsme všechny tyto týmy, aby přešly na zcela novou architekturu, která vyžadovala znalost Federated GraphQL – zcela nového konceptu i pro nás. Poskytování skvělých vývojářských zkušeností bylo klíčem k úspěchu přijetí v tomto měřítku.

Zpočátku se do nové struktury rozhodlo připojit jen několik týmů. Setkali jsme se s vývojáři v týmu, abychom lépe porozuměli vývojářským pracovním postupům, mezerám a nástrojům potřebným k překlenutí mezery ve znalostech a usnadnění procesu migrace.

Naším cílem bylo co nejvíce usnadnit implementaci nové služby GraphQL a začlenit ji do jednotného grafu. Postupně jsme začali budovat platformu GraphQL sestávající z několika nástrojů a rámců a nadále jsme se vyvíjeli v různých fázích přijetí.

Náš špičkový ekosystém GraphQL

a Rámec Domain Graph Services (DGS). Je to knihovna Spring Boot založená na graphql-java, která umožňuje vývojářům snadno zapojit řešiče GraphQL do jejich grafu. Původně jsme vytvořili tento rámec s cílem poskytovat integrace specifické pro Netflix pro zabezpečení, metriky a sledování pro vývojáře v Netflixu. Navíc jsme chtěli eliminovat ruční připojování resolverů, což bychom mohli vylepšit použitím vlastních anotací DGS jako součásti jádra. Obrázek 3 ukazuje modulární architekturu rámce s několika funkcemi předplatného, ​​ze kterých si vývojáři mohou vybrat.

[Click on the image to view full-size]

Obrázek 3: Rámcová struktura DGS

Při používání frameworku DGS se vývojáři mohou jednoduše soustředit na logiku obchodní domény a méně se soustředit na učení se všem spletitým a oddechovým úskalím GraphQL. Kromě toho jsme vytvořili plugin Gradle pro generování kódu pro generování tříd Java nebo Kotlin, které představují schéma. Tím odpadá ruční vytváření těchto tříd.

Postupem času jsme přidali další funkce, které byly obecně užitečné i pro vývojáře služeb mimo Netflix. Rozhodli jsme se pro open source Rámeček DGS A Plugin pro generování kódu DGS Začátkem roku 2021 a pokračovat v jeho vývoji. Také jsme tvořili plugin DGS IntelliJ Který poskytuje navigaci od schématu k implementaci modulů pro rozlišení dat a úryvků pro dokončení kódu pro vaši implementaci DGS.

Po zvládnutí implementace služby GraphQL byla dalším krokem registrace DGS, aby mohla být součástí federovaného grafu. Implementovali jsme službu registrace schémat pro mapování schémat na jejich odpovídající služby. Unified Gateway používá registr schémat k určení, ke kterým službám bude přistupovat, na základě příchozího dotazu. Pro tuto službu registrace schémat jsme také implementovali samoobslužné uživatelské rozhraní, které vývojářům pomáhá spravovat jejich systémy DGS a jednotné zjišťování schémat.

Nakonec jsme optimalizovali naše stávající monitorovací nástroje pro GraphQL. Náš nástroj pro distribuované sledování umožňuje snadné ladění problémů s výkonem a chyb požadavků tím, že poskytuje komplexní pohled na graf hovorů a také možnost zobrazit související protokoly.

Rozšiřte jednotnou platformu GraphQL

S tímto úsilím jsme začali na začátku roku 2019 a od té doby se do Unified Graph zapojilo více než 200 týmů. Přijetí jednotné architektury GraphQL bylo tak úspěšné, že jsme kromě našeho vlastního Graph Studia nakonec vytvořili další grafy pro další domény. Nyní máme jeden pro naše interní nástroje platformy, které nazýváme Enterprise Graph, a další pro naše streamovací API.

Po představení nového podnikového grafu jsme si rychle uvědomili, že týmy mají zájem vystavit stejné DGS jako součást svých podnikových a studiových grafů. Stejně tak měli zákazníci zájem získat data z obou grafů. Poté jsme spojili grafy Studio a Enterprise do jednoho většího grafu. To pro nás vytvořilo jinou sadu výzev, pokud jde o měření grafu velikostí a počtu vývojářů.

Větší graf ztěžoval škálování našeho procesu kontroly grafu, protože byl většinou ručně moderován členy naší skupiny pro kontrolu grafů (viz obrázek 4). Potřebovali jsme vytvořit více nástrojů pro automatizaci některých těchto procesů. Vytvořili jsme nástroj nazvaný GraphDoctor, který kontroluje schéma a automaticky komentuje změny schématu související s PR pro všechny registrované služby. Abychom pomohli při spolupráci schémat, vytvořili jsme GraphLabs, které nastaví izolované prostředí pro testování změn schématu, aniž by to ovlivnilo ostatní části grafu. To umožňuje vývojářům front-endu a back-endu rychleji spolupracovat na změnách schématu (viz obrázek 4).

[Click on the image to view full-size]

Obrázek 4: Pracovní postup pro vývoj schématu

Formulář podpory pro vývojáře

Platformu GraphQL jsme postavili, abychom usnadnili implementaci služeb doménového grafu a práci s grafem. To však samo o sobě nestačilo. Potřebovali jsme doplnit zkušenosti dobrou vývojářskou podporou. Zpočátku jsme poskytovali zkušenost s migrací v bílých rukavicích tím, že jsme se hemžili týmy a dělali jsme spoustu migrační práce za ně. To poskytlo mnoho informací o tom, co jsme potřebovali vytvořit, abychom zlepšili vývojářskou zkušenost. Identifikovali jsme mezery ve stávajících řešeních, které mohou pomoci urychlit implementaci tím, že vývojářům umožní soustředit se na obchodní logiku a eliminovat opakované nastavování kódu.

Jakmile jsme měli poměrně stabilní platformu, byli jsme schopni nalodit mnoho týmů rychlým tempem. Také jsme hodně investovali do poskytování dobré dokumentace a návodů na federaci a koncepty GraphQL našim vývojářům, aby se mohli snadno samoobslužně obsluhovat. Nadále nabízíme vývojářskou podporu na našich interních komunikačních kanálech přes Slack během pracovní doby, abychom vám pomohli zodpovědět jakékoli otázky a řešit problémy, jakmile se vyskytnou.

Vývojářský efekt

Platforma GraphQL poskytuje plně dlážděnou cestu pro celý pracovní postup, od návrhu schématu, implementaci schématu ve službě GraphQL, registraci služby jako součást federovaného grafu a její spuštění po nasazení. To pomohlo více týmům přijmout architekturu, díky níž je GraphQL populárnější než tradiční REST API Netflixu. Konkrétně Federated GraphQL výrazně zjednodušuje přístup k datům pro front-end vývojáře a umožňuje týmům rychle přejít na jejich výstupy.

naučili jsme se

Díky velkým investicím do zkušeností pro vývojáře jsme byli schopni zajistit přijetí mnohem rychleji, než bychom to udělali jinak. Začali jsme v malém s využitím nástrojů komunity. To nám pomohlo identifikovat mezery a místa, kde jsme potřebovali vlastní funkčnost. Vybudovali jsme rámec DGS a ekosystém nástrojů, jako je plugin pro generování kódu a dokonce i software pro správu základních schémat.

Po vyřešení základního pracovního postupu můžeme zaměřit své úsilí na komplexnější nástroje pracovního postupu grafů. S rostoucím přijetím jsme byli schopni identifikovat problémy, přizpůsobit platformu tak, aby fungovala s většími grafy, a škálovat ji pro stále větší počet vývojářů. Část procesu kontroly grafů jsme zautomatizovali, což usnadňuje práci s většími grafy. Stále vidíme, jak se objevují nové případy použití a vyvíjíme naši platformu, abychom pro ně poskytovali řešení pro zpevněné cesty.

Co je před námi?

Dosud jsme migrovali naši architekturu Studio na Unified GraphQL a integrovali nový graf pro týmy interní platformy se Studio Graph, abychom vytvořili větší makrograf. Nyní migrujeme rozhraní API pro streamování Netflix, která umožňují objevování v uživatelském rozhraní Netflix, na stejný model. Tento nový graf přichází s jinou sadou výzev. Streamovací služba Netflix je podporována na více zařízeních a uživatelské rozhraní se na každé platformě zobrazuje jinak. Uspořádání by mělo být dobře navrženo tak, aby vyhovovalo různým případům použití.

Dalším důležitým rozdílem je, že streamovací služby musí zvládnout mnohem vyšší RPS, na rozdíl od jiných grafů. Identifikujeme úzká místa výkonu v rámci a nástrojích, aby byly naše služby GraphQL výkonnější. Souběžně také vylepšujeme naše monitorovací nástroje, abychom zajistili, že tyto služby můžeme provozovat ve velkém měřítku.