|
|
Objavljeno na 25. 09. 2019 16:11:58
|
|
|
|
Tradicionalno bi sistem, ki obdeluje milijardo transakcij na dan, zahteval na stotine VM-jev, PayPal pa vse to počne z le 8 VM-ji in zagotavlja hiter odziv pri 90 % porabi procesorja, kar je gostota transakcij, ki je PayPal še nikoli ni dosegel, postopek pa traja 1/10 časa, kar organizaciji pomaga slediti rasti brez potrebe po razširitvi računalniške infrastrukture in hkrati zmanjšati stroške. Kako se to naredi?
PayPal je svoj sistem preusmeril v način igralcev, ki temelji na Akka. V članku Squbs: PayPal uporablja nov reaktiven pristop k izdelavi aplikacij (Prijava do hiperpovezave je vidna.PayPal razloži vse podrobnosti postopka. Zdaj so objavili odprtokodne Squbs in jih objavili na GitHubu (Prijava do hiperpovezave je vidna.)。
Ko projekt potrebuje praktičen pristop, model storitev s statusom še vedno ne dobi dovolj pozornosti. Za več informacij o storitvah s statusom priporočamo, da preberete razloge za nadaljevanje gradnje razširljivih storitev s statusom zdaj (Prijava do hiperpovezave je vidna.), ta članek temelji na govoru Caitie McCaffrey. Če vas ta članek ne prepriča, obstaja tudi WhatsApp, ki uporablja Akkinega konkurenta Erlang za izjemno visoko prepustnost: Facebookovo 19 milijard dolarjev vredno arhitekturo WhatsApp (Prijava do hiperpovezave je vidna.)。
Razlog za priporočilo zgornjega članka je, da PayPal ne ponuja podrobnega uvoda v arhitekturo, temveč se bolj posveti razlogom, zakaj so izbrali Akka in prednostim migracije na Akka. A ta članek še vedno ponuja dragoceno spodbudo in demonstracijo prakse »odhoda s uhojenih poti«.
Kaj je narobe z uporabo velikega števila virtualnih strojev za storitev?
- Poganjajte storitev z zelo nizko prepustnostjo in izjemno majhnimi virtualnimi stroji. Največja prednost reaktivnih sistemov, ki temeljijo na akterjih, je, da lahko učinkoviteje izkoristijo računalniške vire, kar močno zmanjša velikost sistema in se izogne "preprostemu in grobemu" samodejnemu skaliranju tradicionalnih praks.
- To močno obremenjuje vaše omrežje in usmerjevalno infrastrukturo. Ker so storitve običajno bolj medsebojno povezane, morajo zahteve pogosto preiti skozi veliko število omrežnih skokov, kar povečuje zakasnitev in poslabša uporabniško izkušnjo.
- Večja kot je, dražja je. Storitve s stotinami virtualnih strojev imajo visoke inherentne stroške glede upravljanja, spremljanja in neučinkovitega predpomnjenja.
- Manjše kot je, bolj je agilno. Nameščanje storitev na stotine virtualnih strojev je zamuden proces.
- Izkoristite več procesorja na vsakem virtualnem stroju. Ker procesorjev ni mogoče dodatno pospešiti, mora infrastruktura omogočati učinkovitejšo uporabo več procesorjev na vsakem virtualnem stroju.
- Mikroservisi morajo biti zgrajeni z ohlapno povezanimi nanoservisi, ki so enostavni za vzdrževanje in hitro za gradnjo. Nihče noče delati s kompleksnim sistemom z veliko plastmi, zato potrebuješ več vpogleda v vlogo različnih storitev, ne da bi se moral poglabljati v plasti kode.
Ob upoštevanju teh dejavnikov je PayPal želel zgraditi sistem, ki:
- Razširljiv, ne le za horizontalno skaliranje na stotine vozlišč, ampak tudi za povečanje števila procesorjev, da se doseže cilj obdelave milijard zahtevkov na dan.
- Nizka zakasnitev in jo je mogoče nadzorovati z izjemno natančno granularnostjo.
- Bodite odporni na neuspehe.
- Prilagodljiva prilagoditev meja storitev.
- Spodbujajte razširljivost in preprostost s programskimi modeli in kulturo ter enostavnejše mehanizme za obravnavo napak in napak.
Ni dvoma, da PayPal želi uporabiti bolj "tanek" sklad in ne želi, da bi njegov sklad vseboval veliko tehnologije in gibljivih delov na različnih ravneh. Na splošno so Akka in sistemi, ki temeljijo na stanju, dobro primerni za to potrebo, saj omogočajo, da se sklad velikih komponent "razdeli" v eno samo tehnologijo. PayPal je izbral Akka namesto Erlanga, ker imajo več izkušenj z Javo, ki deluje na Javi. Za mnoge ljudi učenje Erlanga iz nič ni realno.
Z Akko lahko:
- Napiši kodo, ki jo je lažje razložiti
- Napiši kodo, ki jo je lažje testirati
- Scenariji napak in okvar se obravnavajo bolj naravno kot tradicionalni načini z uporabo JVM
- Napišite hitrejšo, bolj odporno in preprostejšo kodo za tekoče obravnavo napak in zmanjšanje števila hroščev
PayPal je takoj napisal svoj okvir, ki temelji na Akki, imenovan Squbs, kar se je rima z "Cubes". To vam omogoča ustvarjanje modularne tehnološke plasti za gradnjo NanoService, imenovane "Cube". Kocke so simetrične, odvisnosti med različnimi kockami pa so prav tako simetrične in ohlapne, razkrivajo le vmesnike za sporočila, ki jih Akka že ponuja.
Prav tako opisuje težave, s katerimi se programerji lahko srečajo pri uvajanju AKKA kode, saj boste morda morali najeti nekoga, usposobljenega za Akka/.
Ker ima večina storitev podobne namene: prejemanje zahtev, klicanje ter branje in pisanje podatkovnih baz, klic drugih storitev, klic pogonov pravil, pridobivanje podatkov iz predpomnilnikov, pisanje v predpomnilnike... Zaradi tega je mogoče storitve abstrahirati z vzorci, kot sta vzorec orkestratorja in večni tok.
Squbs je postal standardna praksa, da PayPal gradi reaktivne aplikacije na osnovi Akka. Če vaša ekipa še ni razmišljala o sistemih s stanjem, je verjetno vredno poskusiti, saj dobro deluje pri PayPal, Facebooku, Uberju in Microsoftu.
|
Prejšnji:Trije dejavniki, zaradi katerih odrivam ChromeNaslednji:vs ustvari mapo, in ko generiramo rešitev, pod datoteko za zaboj ni nikogar
|
