|
|
Zveřejněno 25.09.2019 16:11:58
|
|
|
|
Tradičně by systém, který zvládne miliardu transakcí denně, vyžadoval stovky virtuálních strojů, PayPal to zvládá s pouhými 8 VM a poskytuje rychlou odezvu při 90% využití CPU, což je hustota transakcí, které PayPal dosud nikdy nedosáhl, a proces trvá 1/10 času, což pomáhá organizaci držet krok s růstem bez nutnosti škálovat svou výpočetní infrastrukturu a zároveň snižovat náklady. Jak se to dělá?
PayPal převedl svůj systém do režimu Akka založeného na akka. V článku Squbs: PayPal zaujímá nový reaktivní přístup k tvorbě aplikací (Přihlášení k hypertextovému odkazu je viditelné.PayPal vysvětluje všechny detaily procesu. Nyní mají open-source Squbs a publikovali je na GitHubu (Přihlášení k hypertextovému odkazu je viditelné.)。
Když projekt potřebuje přístup do praxe, model stavové služby stále nedostává dostatečnou pozornost. Chcete-li se dozvědět více o stavových službách, doporučujeme si přečíst důvody, proč pokračovat ve vytváření škálovatelných stavových služeb nyní :(Přihlášení k hypertextovému odkazu je viditelné.), tento článek je založen na projevu Caitie McCaffreyové. Pokud vás tento článek nepřesvědčí, existuje také WhatsApp, který využívá konkurenta Akky Erlang pro extrémně vysokou propustnost: Facebookovu architekturu WhatsApp za 19 miliard dolarů (Přihlášení k hypertextovému odkazu je viditelné.)。
Důvodem doporučení výše uvedeného článku je, že PayPal neposkytuje podrobný úvod do architektury, ale spíše věnuje více času důvodům, proč si vybrali Akka, a výhodám migrace na Akka. Přesto tento článek stále poskytuje cenné povzbuzení a ukázku praxe "odbočování z vyšlapané cesty".
Co je špatného na používání velkého množství virtuálních strojů pro službu?
- Spusť službu s velmi nízkopropustnými, extrémně malými virtuálními stroji. Největší výhodou reaktivních systémů založených na akcích je, že mohou efektivněji využívat výpočetní zdroje, což výrazně snižuje velikost systému a zabraňuje "jednoduchému a hrubému" automatickému škálování tradičních postupů.
- To hodně zatěžuje vaši síť a směrovací infrastrukturu. Protože služby bývají více propojené, mohou požadavky muset projít velkým množstvím síťových skoků, což zvyšuje latenci a zhoršuje uživatelský zážitek.
- Čím větší, tím dražší. Služby se stovkami virtuálních strojů mají vysoké inherentní náklady na správu, monitorování a neefektivní cache.
- Čím menší je, tím je obratnější. Nasazování služeb na stovky virtuálních strojů je časově náročný proces.
- Získejte více CPU na každém virtuálním stroji. Protože CPU nelze dále zrychlovat, infrastruktura musí být schopna efektivněji využívat více CPU na každém virtuálním stroji.
- Mikroslužby je třeba stavět s volně propojenými nanoservisy, které jsou snadné na údržbu a rychlé na vybudování. Nikdo nechce pracovat se složitým systémem s mnoha vrstvami a potřebujete větší přehled o roli různých služeb, aniž byste museli jít do hloubky vrstev kódu.
S ohledem na tyto faktory chtěl PayPal vybudovat systém, který:
- Škálovatelný nejen horizontálně na stovky uzlů, ale také pro rozšíření na více procesorů, aby se dosáhlo cíle zpracovávat miliardy požadavků denně.
- Nízká latence a lze ji ovládat extrémně jemnou granularitou.
- Buďte odolní tváří v tvář neúspěchům.
- Flexibilní úprava hranic služeb.
- Podporovat škálovatelnost a jednoduchost prostřednictvím programovacích modelů a kultury, stejně jako jednodušší mechanismy pro řešení chyb a chyb.
Není pochyb o tom, že PayPal chce používat více "tenčí" stack a nechce, aby jeho stack obsahoval mnoho technologií a pohyblivých částí na různých úrovních. Obecně jsou Akka a systémy založené na stavech pro tuto potřebu velmi vhodné, což umožňuje "rozložit" zásobník velkých komponent do jedné technologie. PayPal si vybral Akku místo Erlangu, protože má více zkušeností s Javou, která běží na Javě. Pro mnoho lidí není realistické učit se Erlang od nuly.
S Akkou mohou:
- Piš kód, který se lépe vysvětluje
- Piš kód, který se lépe testuje
- Chybové a selhání scénáře jsou řešeny přirozeněji než tradiční režimy pomocí JVM
- Pište rychlejší, odolnější a jednodušší kód, který umožňuje plynulejší zpracování chyb a snížení počtu chyb
PayPal okamžitě napsal vlastní framework založený na Akce, který se jmenoval Squbs, což se rýmovalo s "Cubes". To vám umožní vytvořit modulární technologickou vrstvu pro sestavení NanoService nazvanou "Cube". Krychle jsou symetrické a závislosti mezi různými kostkami jsou také symetrické a volné, takže jsou odhalovány pouze rozhraní zpráv, která už Akka nabízí.
Popisuje také obtíže, se kterými se programátoři mohou setkat při zavádění kódu AKKA, protože možná budete muset najmout někoho vyškoleného v Akka/Scala.
Protože většina služeb má podobné účely: přijímat požadavky, volat a číst a zapisovat databáze, volat jiné služby, volat pravidlové enginy, získávat data z cache, zapisovat do cache... Díky tomu lze služby abstrahovat pomocí vzorů jako Orchestrator Pattern a Perpetual Stream.
Squbs se stal standardní praxí pro PayPal při vytváření reaktivních aplikací založených na Akka. Pokud váš tým ještě neuvažoval o stavových systémech, pravděpodobně to stojí za zkoušku, protože dobře funguje u PayPal, Facebooku, Uberu a Microsoftu.
|
Předchozí:Tři faktory, kvůli kterým Chrome odsuzujiDalší:vs Vytvořte složku, a při generování řešení není pod souborem nikdo
|
