|
|
Julkaistu 25.9.2019 16.11.58
|
|
|
|
Perinteisesti järjestelmä, joka käsittelee miljardin tapahtuman päivittäin, saattoi vaatia satoja virtuaalikoneita, PayPal hoitaa kaiken vain 8 virtuaalikoneella ja tarjoaa nopean vastauksen 90 % prosessorin kulutuksella, mikä on tapahtumatiheys, johon PayPal ei ole aiemmin päässyt, ja prosessi vie kymmenesosan ajasta, auttaen organisaatiota pysymään kasvun mukana ilman, että laskentainfrastruktuuria tarvitsee laajentaa samalla kun kustannukset pienenevät. Miten tämä tehdään?
PayPal on siirtänyt järjestelmänsä Akka-pohjaiseen Actor-tilaan. Artikkelissa Squbs: PayPal ottaa uuden reaktiivisen lähestymistavan sovellusten rakentamiseen (Hyperlinkin kirjautuminen on näkyvissä.PayPal selittää prosessin yksityiskohdat. He ovat nyt julkaisseet avoimen lähdekoodin Squbsin ja julkaisseet sen GitHubissa (Hyperlinkin kirjautuminen on näkyvissä.)。
Kun projekti tarvitsee käytännön lähestymistavan, tilallinen palvelumalli ei silti saa tarpeeksi huomiota. Jos haluat tietää lisää tilapalveluista, suosittelemme lukemaan syyt jatkaa skaalautuvien tilallisten palveluiden rakentamista nyt (Hyperlinkin kirjautuminen on näkyvissä.), tämä artikkeli perustuu Caitie McCaffreyn puheeseen. Jos tämä artikkeli ei vakuuta sinua, on myös WhatsApp, joka käyttää Akkan kilpailijaa Erlangia erittäin suureen läpimenoon: Facebookin 19 miljardin dollarin WhatsApp-arkkitehtuuri (Hyperlinkin kirjautuminen on näkyvissä.)。
Syynä yllä olevan artikkelin suositteluun on se, että PayPal ei tarjoa yksityiskohtaista johdantoa arkkitehtuurista, vaan käyttää enemmän aikaa syihin, miksi he valitsivat Akkan, ja siirtymisen hyötyihin Akkaan. Mutta tämä artikkeli tarjoaa silti arvokasta rohkaisua ja esimerkkiä siitä, miten "poikkeaa polulta".
Mikä on väärin käyttää suurta määrää virtuaalikoneita palvelussa?
- Aja palvelu hyvin matalan läpimenon ja erittäin pienillä virtuaalikoneilla. Toimijapohjaisten reaktiivisten järjestelmien suurin etu on, että ne voivat hyödyntää laskentaresursseja tehokkaammin, mikä voi merkittävästi pienentää järjestelmän kokoa ja välttää perinteisten käytäntöjen "yksinkertaisen ja karkean" automaattisen skaalaamisen.
- Se rasittaa paljon verkkoasi ja reititysinfrastruktuuria. Koska palvelut ovat yleensä enemmän yhteydessä toisiinsa, pyynnöt saattavat joutua kulkemaan suuren määrän verkkohyppyjä, mikä lisää viivettä ja heikentää käyttäjäkokemusta.
- Mitä isompi se on, sitä kalliimpi se on. Palvelut, joissa on satoja virtuaalikoneita, aiheuttavat suuria sisäisiä kustannuksia hallinnan, valvonnan ja tehottoman välimuistin osalta.
- Mitä pienempi se on, sitä ketterämpi se on. Palveluiden käyttöönotto sadoille virtuaalikoneille on aikaa vievä prosessi.
- Saat enemmän irti useammasta prosessorista jokaisella virtuaalikoneella. Koska suorittimia ei voi nopeuttaa enempää, infrastruktuurin täytyy pystyä hyödyntämään tehokkaammin useampia suorittimia jokaisessa virtuaalikoneessa.
- Mikropalvelut täytyy rakentaa löyhästi kytkeytyneillä nanopalveluilla, joita on helppo ylläpitää ja nopeita rakentaa. Kukaan ei halua käsitellä monimutkaista järjestelmää, jossa on paljon kerroksia, ja tarvitset enemmän näkyvyyttä eri palveluiden rooliin ilman, että tarvitsee mennä syvälle koodikerroksiin.
Näiden tekijöiden valossa PayPal halusi rakentaa järjestelmän, joka:
- Skaalautuva, ei vain skaalaamaan vaakasuunnassa satoihin solmuihin, vaan myös skaalaamaan useampiin prosessoreihin, jotta tavoite käsitellä miljardeja pyyntöjä päivässä.
- Alhainen viive ja sitä voidaan hallita erittäin hienolla rakeisuudella.
- Ole sitkeä epäonnistumisia vastaan.
- Palvelurajojen joustava mukauttaminen.
- Edistä skaalautuvuutta ja yksinkertaisuutta ohjelmointimallien ja kulttuurin avulla sekä yksinkertaisempien vikojen ja virheiden käsittelymekanismien avulla.
Ei ole epäilystäkään, etteikö PayPal haluaisi käyttää "ohuempaa" pinoa, eikä se halua pinonsa sisältävän paljon teknologiaa ja liikkuvia osia eri tasoilla. Yleisesti ottaen Akka ja tilapohjaiset järjestelmät soveltuvat tähän tarpeeseen hyvin, mikä mahdollistaa suurten komponenttien pinon "pilkkomisen" yhdeksi teknologiaksi. PayPal valitsi Akkan Erlangin sijaan, koska heillä on enemmän kokemusta Javasta, joka toimii Javan päällä. Monille ihmisille Erlangin oppiminen alusta asti ei ole realistista.
Akkan kanssa he voivat:
- Kirjoita koodia, joka on helpompi selittää
- Kirjoita koodia, jota on helpompi testata
- Virhe- ja vikatilanteet käsitellään luonnollisemmin kuin perinteisissä JVM-tiloissa
- Kirjoita nopeampaa, kestävämpää ja yksinkertaisempaa koodia, jotta virheet voidaan käsitellä sujuvammin ja vähentää bugien määrää
PayPal kirjoitti välittömästi oman kehyksensä Akkan pohjalta, jota kutsuttiin Squbsiksi ja jota käytettiin rimmaamaan sanalla "Cubes". Tämä mahdollistaa modulaarisen teknologiakerroksen luomisen NanoServicen rakentamista varten, nimeltään "Cube". Kuutiot ovat symmetrisiä, ja eri kuutioiden väliset riippuvuudet ovat myös symmetrisiä ja löyhiä, paljastaen vain Akkan jo tarjoamat viestirajapinnat.
Se kuvaa myös vaikeuksia, joita ohjelmoijat kohtaavat AKKA-koodin käyttöönotossa, sillä saatat joutua palkkaamaan myös Akka/Scala-koulutetun henkilön.
Koska useimmilla palveluilla on samankaltaiset tarkoitukset: vastaanottaa pyyntöjä, soittaa ja lukea ja kirjoittaa tietokantoja, kutsua muita palveluita, kutsua sääntömoottoreita, hakea dataa välimuistista, kirjoittaa välimuistiin... Tämän seurauksena palvelut voidaan abstraktoida esimerkiksi Orchestrator Patternin ja Perpetual Streamin kaltaisten kuvioiden kautta.
Squbsista on tullut PayPal-standardi reaktiivisten sovellusten rakentamisessa Akkan pohjalta. Jos tiimisi ei ole vielä harkinnut tilallisia järjestelmiä, se kannattaa kokeilla, sillä se toimii hyvin PayPalilla, Facebookilla, Uberilla ja Microsoftilla.
|
Edellinen:Kolme tekijää, jotka saavat minut vähättelemään ChromeaSeuraava:vs luoda kansio, ja kun generoit ratkaisun, bin-tiedoston alla ei ole ketään
|
