|
|
Publicēts 25.09.2019 16:11:58
|
|
|
|
Tradicionāli sistēmai, kas apstrādā miljardu darījumu dienā, varētu būt nepieciešami simtiem VM, PayPal to visu dara tikai ar 8 VM un nodrošina ātru reakciju ar 90% CPU lietojumu, darījumu blīvumu, ko PayPal nekad iepriekš nav sasniedzis, un process aizņem 1/10 laika, lai sasniegtu procesu, palīdzot organizācijai sekot līdzi izaugsmei, nepalielinot skaitļošanas infrastruktūru, vienlaikus samazinot izmaksas. Kā tas tiek darīts?
PayPal ir migrējis savu sistēmu uz Akka bāzētu aktiera režīmu. Rakstā Squbs: PayPal izmanto jaunu reaktīvu pieeju lietotņu veidošanai (Hipersaites pieteikšanās ir redzama.PayPal izskaidro procesa nianses. Viņi tagad ir atvērtā koda Squbs un publicējuši to vietnē GitHub (Hipersaites pieteikšanās ir redzama.)。
Ja projektam ir nepieciešama praktiska pieeja, valsts pakalpojumu modelis joprojām nesaņem pietiekami daudz uzmanības. Lai uzzinātu vairāk par valsts pakalpojumiem, iesakām izlasīt iemeslus, kāpēc turpināt veidot mērogojamus stāvokļa pakalpojumus tagad (Hipersaites pieteikšanās ir redzama.), šis raksts ir balstīts uz Caitie McCaffrey runu. Ja šis raksts jūs nepārliecina, ir arī WhatsApp, kas izmanto Akka konkurentu Erlang ārkārtīgi augstai caurlaidspējai: Facebook 19 miljardu ASV dolāru WhatsApp arhitektūra (Hipersaites pieteikšanās ir redzama.)。
Iepriekš minētā raksta ieteikšanas iemesls ir tas, ka PayPal nesniedz detalizētu ievadu arhitektūrā, bet drīzāk velta vairāk laika iemesliem, kāpēc viņi izvēlējās Akka, un migrācijas uz Akka priekšrocībām. Bet šis raksts joprojām sniedz vērtīgu iedrošinājumu un demonstrāciju praksei "iziet no piedzīvotā ceļa".
Kas ir nepareizi, ja pakalpojumam tiek izmantots liels skaits virtuālo mašīnu?
- Palaidiet pakalpojumu ar ļoti zemas caurlaidspējas, ārkārtīgi mazām virtuālajām mašīnām. Uz aktieriem balstītu reaktīvo sistēmu lielākā priekšrocība ir tā, ka tās var efektīvāk izmantot skaitļošanas resursus, kas var ievērojami samazināt sistēmas lielumu un izvairīties no tradicionālās prakses "vienkāršas un rupjas" automātiskās mērogošanas.
- Tas rada lielu slodzi jūsu tīklam un maršrutēšanas infrastruktūrai. Tā kā pakalpojumi mēdz būt vairāk savstarpēji savienoti, pieprasījumiem var būt jāiziet liels skaits tīkla lēcienu, kas palielina latentumu un pasliktina lietotāja pieredzi.
- Jo lielāks tas ir, jo dārgāks tas ir. Pakalpojumiem ar simtiem virtuālo mašīnu ir augstas izmaksas pārvaldības, uzraudzības un neefektīvas kešatmiņas ziņā.
- Jo mazāks tas ir, jo elastīgāks tas ir. Pakalpojumu izvietošana simtiem virtuālo mašīnu ir laikietilpīgs process.
- Iegūstiet vairāk no vairāk CPU katrā virtuālajā mašīnā. Tā kā CPU nevar vēl vairāk paātrināt, infrastruktūrai ir jāspēj efektīvāk izmantot vairāk CPU katrā virtuālajā mašīnā.
- Mikropakalpojumi ir jāveido ar brīvi saistītiem nanopakalpojumiem, kurus ir viegli uzturēt un ātri izveidot. Neviens nevēlas nodarboties ar sarežģītu sistēmu ar daudziem slāņiem, un jums ir nepieciešama lielāka redzamība dažādu pakalpojumu lomā, neiedziļinoties koda slāņos.
Paturot prātā šos faktorus, PayPal vēlējās izveidot sistēmu, kas:
- Mērogojams, ne tikai horizontāli mērogojot simtiem mezglu, bet arī palielinot līdz vairāk procesoru, lai sasniegtu mērķi apstrādāt miljardiem pieprasījumu dienā.
- Zems latentums, un to var kontrolēt ar ļoti smalku detalizāciju.
- Esiet izturīgs pret neveiksmēm.
- Elastīga pakalpojumu robežu pielāgošana.
- Veiciniet mērogojamību un vienkāršību, izmantojot programmēšanas modeļus un kultūru, kā arī vienkāršākus kļūdu un kļūdu apstrādes mehānismus.
Nav šaubu, ka PayPal vēlas izmantot "plānāku" kaudzi, un viņi nevēlas, lai viņu kaudze saturētu daudz tehnoloģiju un kustīgu daļu dažādos līmeņos. Kopumā Akka un valsts sistēmas ir labi piemērotas šai vajadzībai, kas ļauj lielu komponentu kaudzi "sadalīt" vienā tehnoloģijā. PayPal izvēlējās Akka, nevis Erlang, jo viņiem ir lielāka pieredze ar Java, kas darbojas virs Java. Daudziem cilvēkiem Erlang mācīšanās no nulles nav reāla.
Ar Akka viņi var:
- Uzrakstiet kodu, kuru ir vieglāk izskaidrot
- Uzrakstiet kodu, kuru ir vieglāk pārbaudīt
- Kļūdu un kļūmju scenāriji tiek apstrādāti dabiskāk nekā tradicionālie režīmi, izmantojot JVM
- Rakstiet ātrāku, elastīgāku un vienkāršāku kodu, lai efektīvāk apstrādātu kļūdas un samazinātu kļūdu skaitu
PayPal nekavējoties uzrakstīja savu sistēmu, kuras pamatā bija Akka, ko sauca par Squbs, ko izmantoja, lai atskaņotu ar "Cubes". Tas ļauj jums izveidot modulāru tehnoloģiju slāni NanoService izveidei, ko sauc par "Cube". Kubi ir simetriski, un atkarības starp dažādiem kubiem ir arī simetriskas un vaļīgas, atklājot tikai ziņojumu saskarnes, ko Akka jau nodrošina.
Tajā arī aprakstītas grūtības, ar kurām programmētāji var saskarties, pieņemot AKKA kodu, jo jums var būt nepieciešams arī nolīgt kādu, kas apmācīts Akka/Scala.
Tā kā lielākajai daļai pakalpojumu ir līdzīgi mērķi: saņemt pieprasījumus, zvanīt un lasīt un rakstīt datu bāzes, zvanīt citiem pakalpojumiem, zvanīt noteikumu dzinējiem, iegūt datus no kešatmiņām, rakstīt kešatmiņās... Tā rezultātā pakalpojumus var abstrahēt, izmantojot tādus modeļus kā Orchestrator Pattern un Perpetual Stream.
Squbs ir kļuvis par PayPal standarta praksi, lai izveidotu reaktīvas lietojumprogrammas, kuru pamatā ir Akka. Ja jūsu komanda vēl nav apsvērusi stāvokļa sistēmas, iespējams, ir vērts izmēģināt, jo tas labi darbojas PayPal, Facebook, Uber un Microsoft.
|
Iepriekšējo:Trīs faktori, kas liek man novecot pārlūku ChromeNākamo:vs izveidot mapi, un, ģenerējot risinājumu, zem bin faila nav neviena
|
