|
|
Postitatud 25.09.2019 16:11:58
|
|
|
|
Traditsiooniliselt võib süsteem, mis haldab miljard tehingut päevas, vajada sadu VM-e, PayPal teeb seda kõike vaid 8 VM-iga ning pakub kiiret reageerimist 90% protsessori kasutusega, tehingutihedusega, mida PayPal pole varem saavutanud, ning protsess võtab 1/10 ajast, aidates organisatsioonil kasvuga sammu pidada ilma arvutitaristut suurendamata ja kulusid vähendada. Kuidas seda tehakse?
PayPal on oma süsteemi üle viinud Akka-põhisele Actor režiimile. Artiklis Squbs: PayPal rakendab rakenduste loomisel uut reaktiivset lähenemist (Hüperlingi sisselogimine on nähtav.PayPal selgitab protsessi kõiki nüansse. Nad on nüüd avatud lähtekoodiga Squbs'i avaldanud ja avaldanud selle GitHubis (Hüperlingi sisselogimine on nähtav.)。
Kui projekt vajab praktilist lähenemist, ei saa seisunditeenuse mudel ikkagi piisavalt tähelepanu. Stateful teenuste kohta lisateabe saamiseks soovitame lugeda põhjuseid, miks jätkata skaleeritavate olekuteenuste ehitamist juba praegu (Hüperlingi sisselogimine on nähtav.), see artikkel põhineb Caitie McCaffrey kõnel. Kui see artikkel sind ei veena, siis on olemas ka WhatsApp, mis kasutab Akka konkurendi Erlangi äärmiselt suure läbilaskevõime jaoks: Facebooki 19 miljardi dollari suurune WhatsAppi arhitektuur (Hüperlingi sisselogimine on nähtav.)。
Eelneva artikli soovitamise põhjus on see, et PayPal ei anna arhitektuuri üksikasjalikku sissejuhatust, vaid pühendab rohkem aega põhjustele, miks nad valisid Akka ja millised on Akka kolimise eelised. Kuid see artikkel annab siiski väärtuslikku julgustust ja demonstratsiooni "tavapärasest rajast kõrvale kaldumise" praktikaks.
Mis on halba kasutada suurt hulka virtuaalmasinaid teenuse jaoks?
- Käivita teenust väga madala läbilaskevõimega, äärmiselt väikeste virtuaalmasinatega. Aktoripõhiste reaktiivsete süsteemide suurim eelis on see, et nad suudavad arvutusressursse tõhusamalt kasutada, mis võib oluliselt vähendada süsteemi suurust ja vältida traditsiooniliste tavade "lihtsat ja lihtsat" automaatset skaleerimist.
- See paneb palju koormust sinu võrgule ja marsruutimisinfrastruktuurile. Kuna teenused kipuvad olema rohkem omavahel ühendatud, võivad päringud läbida suure hulga võrguhüppeid, mis suurendab latentsust ja halvendab kasutajakogemust.
- Mida suurem see on, seda kallim see on. Teenustel, kus on sadu virtuaalmasinaid, on kõrged kaasasündinud kulud halduse, jälgimise ja ebaefektiivse vahemällu salvestamise osas.
- Mida väiksem see on, seda osavam see on. Teenuste juurutamine sadadele virtuaalmasinatele on aeganõudev protsess.
- Saad rohkem kasu rohkem, kui iga virtuaalmasina protsessor on rohkem. Kuna protsessoreid ei saa enam kiirendada, peab infrastruktuur suutma tõhusamalt kasutada rohkem protsessoreid igal virtuaalmasinal.
- Mikroteenuseid tuleb ehitada lõdvalt seotud NanoServices'iga, mis on lihtsasti hooldatavad ja kiired ehitada. Keegi ei taha tegeleda keeruka süsteemiga, kus on palju kihte, ja sul on vaja rohkem ülevaadet erinevate teenuste rollist, ilma et peaksid süvitsi koodikihtidesse minema.
Neid tegureid silmas pidades soovis PayPal luua süsteemi, mis:
- Skaleeritav, mitte ainult horisontaalselt skaleerumiseks sadadele sõlmedele, vaid ka selleks, et skaleerida rohkemate protsessorite suunas, et saavutada eesmärk töödelda miljardeid päringuid päevas.
- Madal latentsus ja seda saab kontrollida äärmiselt peene teravusega.
- Ole vastupidav ebaõnnestumiste ees.
- Teenuse piiride paindlik kohandamine.
- Edendada skaleeritavust ja lihtsust programmeerimismudelite ja kultuuri kaudu ning lihtsamate rikete ja veahaldusmehhanismide kaudu.
Kahtlemata soovib PayPal kasutada "õhemat" virna ning nad ei taha, et nende virn sisaldaks palju tehnoloogiat ja liikuvaid osi erinevatel tasanditel. Üldiselt sobivad Akka ja olekupõhised süsteemid selleks vajaduseks hästi, võimaldades suurte komponentide virna "lagundada" üheks tehnoloogiaks. PayPal valis Akka Erlangi asemel, sest neil on rohkem kogemusi Javaga, mis töötab Java peal. Paljudele inimestele ei ole Erlangi nullist õppimine realistlik.
Akka abil saavad nad:
- Kirjuta koodi, mida on lihtsam seletada
- Kirjuta koodi, mida on lihtsam testida
- Vea- ja rikete stsenaariumid lahendatakse loomulikumalt kui traditsioonilistes JVM-režiimides
- Kirjuta kiirem, vastupidavam ja lihtsam koodi, et vigu sujuvamalt käsitleda ja vigade arvu vähendada
PayPal kirjutas kohe oma raamistiku Akka põhjal, mida hakati kasutama riimina sõnaga "Cubes". See võimaldab luua modulaarse tehnoloogiakihi NanoService'i ehitamiseks, mida nimetatakse "kuubiks". Kuubikud on sümmeetrilised ning erinevate kuubikute sõltuvused on samuti sümmeetrilised ja lahtised, paljastades ainult Akka juba pakutud sõnumiliidesed.
Samuti kirjeldatakse raskusi, millega programmeerijad võivad AKKA koodi omaks võtmisel kokku puutuda, kuna võib olla vaja palgata keegi, kes on Akka/Scala koolitatud.
Kuna enamikul teenustel on sarnased eesmärgid: taotluste vastuvõtt, andmebaaside lugemine ja kirjutamine, teiste teenuste kutsumine, reeglimootorite kutsumine, andmete saamine vahemäludest, vahemäludesse kirjutamine... Selle tulemusena saab teenuseid abstraktseks teha mustrite kaudu, nagu Orkestraatormuster ja Igavene voog.
Squbs on saanud PayPal-i jaoks tavapäraseks praktikaks reaktiivsete rakenduste loomiseks Akka põhjal. Kui teie meeskond pole veel olekuga süsteeme kaalunud, tasub seda proovida, sest see töötab hästi PayPal'is, Facebookis, Uberis ja Microsoftis.
|
Eelmine:Kolm tegurit, mis panevad mind Chrome'i maha võtmaJärgmine:vs loo kausta, ja lahenduse genereerimisel pole kastifaili all kedagi
|
