|
|
Zverejnené 25. 9. 2019 16:11:58
|
|
|
|
Tradične by systém, ktorý spracováva miliardu transakcií denne, mohol vyžadovať stovky VM, PayPal to zvláda len s 8 VM a poskytuje rýchlu reakciu pri 90 % využití CPU, čo je hustota transakcií, ktorú PayPal doteraz nikdy nedosiahol, a proces trvá 1/10 času, čo pomáha organizácii držať krok s rastom bez nutnosti škálovať výpočtovú infraštruktúru a zároveň znižovať náklady. Ako sa to robí?
PayPal migroval svoj systém do režimu aktora založeného na Akka. V článku Squbs: PayPal zvolil nový reaktívny prístup k tvorbe aplikácií (Prihlásenie na hypertextový odkaz je viditeľné.PayPal vysvetľuje všetky detaily procesu. Teraz sprístupnili Squbs ako open source a publikovali ho na GitHube (Prihlásenie na hypertextový odkaz je viditeľné.)。
Keď projekt potrebuje pristupovať prakticky, model štátnej služby stále nedostáva dostatočnú pozornosť. Ak sa chcete dozvedieť viac o štátnych službách, odporúčame prečítať si dôvody, prečo pokračovať vo vytváraní škálovateľných štátnych služieb už teraz :(Prihlásenie na hypertextový odkaz je viditeľné.), tento článok je založený na prejave Caitie McCaffrey. Ak vás tento článok nepresvedčí, existuje aj WhatsApp, ktorý využíva konkurenta Akky Erlang pre extrémne vysokú priepustnosť: Facebookovu architektúru WhatsApp za 19 miliárd dolárov (Prihlásenie na hypertextový odkaz je viditeľné.)。
Dôvodom odporúčania vyššie uvedeného článku je, že PayPal neposkytuje podrobný úvod do architektúry, ale venuje viac času dôvodom, prečo si vybral Akka a výhodám migrácie na Akka. Napriek tomu tento článok stále poskytuje cenné povzbudenie a ukážku praxe "odbočovania z vyšliapaných ciest".
Čo je zlé na používaní veľkého množstva virtuálnych strojov pre službu?
- Spúšťajte službu s veľmi nízkopriepustnými, extrémne malými virtuálnymi strojmi. Najväčšou výhodou reaktívnych systémov založených na aktoroch je, že dokážu efektívnejšie využívať výpočtové zdroje, čo môže výrazne znížiť veľkosť systému a vyhnúť sa "jednoduchému a hrubému" automatickému škálovaniu tradičných postupov.
- To zaťažuje vašu sieť a infraštruktúru smerovania. Keďže služby majú tendenciu byť viac prepojené, požiadavky môžu musieť prejsť veľkým počtom sieťových skokov, čo zvyšuje latenciu a zhoršuje používateľský zážitok.
- Čím je väčší, tým je drahší. Služby so stovkami virtuálnych strojov majú vysoké inherentné náklady na správu, monitorovanie a neefektívne cacheovanie.
- Čím je menšia, tým je obratnejšia. Nasadzovanie služieb na stovky virtuálnych strojov je časovo náročný proces.
- Získaj viac CPU na každom virtuálnom stroji. Keďže CPU sa nedajú ďalej zrýchľovať, infraštruktúra musí byť schopná efektívnejšie využívať viac CPU na každom virtuálnom stroji.
- Mikroslužby musia byť vytvorené s voľne prepojenými nanoslužbami, ktoré sa ľahko udržiavajú a rýchlo budujú. Nikto nechce pracovať so zložitým systémom s množstvom vrstiev a potrebujete lepší prehľad o úlohe rôznych služieb bez toho, aby ste museli ísť hlboko do vrstiev kódu.
S ohľadom na tieto faktory chcel PayPal vybudovať systém, ktorý:
- Škálovateľné, nielen na horizontálne škálovanie na stovky uzlov, ale aj na rozšírenie na viac procesorov s cieľom spracovať miliardy požiadaviek denne.
- Nízka latencia a dá sa ovládať extrémne jemnou granularitou.
- Buďte odolní tvárou v tvár neúspechom.
- Flexibilné prispôsobenie hraníc služieb.
- Podporujte škálovateľnosť a jednoduchosť prostredníctvom programovacích modelov a kultúry, ako aj jednoduchších mechanizmov riešenia chýb a chýb.
Niet pochýb o tom, že PayPal chce používať "tenší" stack a nechce, aby jeho stack obsahoval veľa technológií a pohyblivých častí na rôznych úrovniach. Vo všeobecnosti sú Akka a systémy založené na stavoch dobre prispôsobené tejto potrebe, čo umožňuje "rozložiť" zásobník veľkých komponentov do jednej technológie. PayPal si vybral Akka namiesto Erlangu, pretože má viac skúseností s Javou, ktorá beží na Jave. Pre mnohých ľudí nie je realistické učiť sa Erlang od nuly.
S Akkou môžu:
- Napíšte kód, ktorý sa ľahšie vysvetľuje
- Napíšte kód, ktorý sa ľahšie testuje
- Scenáre chýb a zlyhaní sa riešia prirodzenejšie než tradičné režimy pomocou JVM
- Píšte rýchlejší, odolnejší a jednoduchší kód na plynulejšie spracovanie chýb a zníženie počtu chýb
PayPal okamžite napísal vlastný rámec založený na Akka, ktorý sa volal Squbs, ktorý sa rýmoval s "Cubes". To vám umožňuje vytvoriť modulárnu technologickú vrstvu pre zostavenie NanoService, nazývanú "Cube". Kocky sú symetrické a závislosti medzi rôznymi kockami sú tiež symetrické a voľné, odhaľujúc len rozhrania správ, ktoré už poskytuje Akka.
Popisuje tiež ťažkosti, s ktorými sa môžu programátori stretnúť pri prijímaní kódu AKKA, keďže možno budete musieť najať niekoho vyškoleného v Akka/Scala.
Keďže väčšina služieb má podobné účely: prijímať požiadavky, volať a čítať a zapisovať databázy, volať iné služby, volať riadiace enginy, získavať dáta z cache, zapisovať do cache... V dôsledku toho je možné služby abstrahovať prostredníctvom vzorov ako Orchestrator Pattern a Perpetual Stream.
Squbs sa stal štandardnou praxou pre PayPal pri vytváraní reaktívnych aplikácií založených na Akka. Ak váš tím ešte neuvažoval o stavových systémoch, pravdepodobne to stojí za vyskúšanie, pretože dobre fungujú vo PayPal, Facebooku, Uberi a Microsofte.
|
Predchádzajúci:Tri faktory, ktoré ma nútia Chrome odsudzovaťBudúci:vs vytvoriť priečinok, a pri generovaní riešenia nie je nikto pod súborom
|
