Traditioneel kan een systeem dat een miljard transacties per dag afhandelt honderden VM's vereisen, PayPal doet dit allemaal met slechts 8 VM's en levert een snelle respons bij 90% CPU-verbruik, een transactiedichtheid die PayPal nog nooit eerder heeft bereikt, en het proces kost 1/10 van de tijd om het proces te realiseren, waardoor de organisatie kan bijblijven groeien zonder de computerinfrastructuur op te schalen en de kosten te verlagen. Hoe doe je dit?
PayPal heeft zijn systeem gemigreerd naar Akka-gebaseerde Actor-modus. In het artikel Squbs: PayPal hanteert een nieuwe reactieve benadering bij het bouwen van apps (De hyperlink-login is zichtbaar.PayPal legt de ins en outs van het proces uit. Ze hebben nu Squbs open-source gemaakt en gepubliceerd op GitHub (De hyperlink-login is zichtbaar.)。
Wanneer een project een hands-on aanpak moet hanteren, krijgt het stateful service-model nog steeds niet genoeg aandacht. Om meer te weten te komen over stateful services, raden we aan de redenen te lezen om nu door te gaan met het bouwen van schaalbare stateful services (De hyperlink-login is zichtbaar.), dit artikel is gebaseerd op een toespraak van Caitie McCaffrey. Als dit artikel je niet overtuigt, is er ook WhatsApp dat Akka's concurrent Erlang gebruikt voor extreem hoge doorvoer: Facebooks WhatsApp-architectuur van $19 miljard (De hyperlink-login is zichtbaar.)。
De reden om het bovenstaande artikel aan te bevelen is dat PayPal geen gedetailleerde introductie tot de architectuur biedt, maar meer tijd besteedt aan de redenen waarom ze voor Akka hebben gekozen en de voordelen van migreren naar Akka. Maar dit artikel biedt nog steeds waardevolle aanmoediging en demonstratie voor de praktijk van "buiten de gebaande paden gaan".
Wat is er mis met het gebruik van een groot aantal virtuele machines voor een service?
- Draai de service met zeer laag-doorvoer, extreem kleine virtuele machines. Het grootste voordeel van actor-gebaseerde reactieve systemen is dat ze efficiënter gebruik kunnen maken van rekenkrachten, wat de grootte van het systeem aanzienlijk kan verkleinen en de "eenvoudige en ruwe" autoscaling van traditionele praktijken kan vermijden.
- Het legt veel druk op je netwerk en routeringsinfrastructuur. Omdat diensten doorgaans meer met elkaar verbonden zijn, moeten verzoeken mogelijk via een groot aantal netwerkhops, wat de latentie verhoogt en de gebruikerservaring verslechtert.
- Hoe groter het is, hoe duurder het is. Diensten met honderden virtuele machines hebben hoge inherente kosten op het gebied van beheer, monitoring en ineffectieve caching.
- Hoe kleiner het is, hoe wendbaarder het is. Het uitrollen van diensten naar honderden virtuele machines is een tijdrovend proces.
- Haal meer uit meer CPU op elke virtuele machine. Omdat CPU's niet verder kunnen worden versneld, moet de infrastructuur efficiënter gebruik kunnen maken van meer CPU's op elke virtuele machine.
- Microservices moeten worden gebouwd met losjes gekoppelde NanoServices die gemakkelijk te onderhouden en snel te bouwen zijn. Niemand wil met een complex systeem met veel lagen te maken hebben, en je hebt meer inzicht nodig in de rol van verschillende services zonder diep in codelagen te hoeven duiken.
Met deze factoren in gedachten wilde PayPal een systeem bouwen dat:
- Schaalbaar, niet alleen om horizontaal te schalen naar honderden nodes, maar ook om op te schalen naar meer processors om het doel te bereiken om miljarden verzoeken per dag te verwerken.
- Lage latentie en kan worden geregeld met extreem fijne granulariteit.
- Wees veerkrachtig in het aangezicht van mislukkingen.
- Flexibele aanpassing van dienstgrenzen.
- Bevorder schaalbaarheid en eenvoud door programmeermodellen en cultuur, evenals eenvoudigere mechanismen voor fout- en foutafhandeling.
Er is geen twijfel dat PayPal een dunnere stack wil gebruiken, en ze willen niet dat hun stack veel technologie en bewegende onderdelen op verschillende niveaus bevat. Over het algemeen zijn Akka- en toestandgebaseerde systemen goed geschikt voor deze behoefte, waardoor de stapel van grote componenten kan worden "opgesplitst" tot één technologie. PayPal koos voor Akka boven Erlang omdat ze meer ervaring hebben met Java, dat bovenop Java draait. Voor veel mensen is het niet realistisch om Erlang vanaf nul te leren.
Met Akka kunnen ze:
- Schrijf code die makkelijker uit te leggen is
- Schrijf code die makkelijker te testen is
- Fout- en faalscenario's worden natuurlijker behandeld dan traditionele modi met de JVM
- Schrijf snellere, veerkrachtiger en eenvoudigere code om fouten vloeiender te behandelen en het aantal bugs te verminderen
PayPal schreef meteen een eigen framework gebaseerd op Akka, genaamd Squbs, dat werd gebruikt om te rijmen met "Cubes". Dit stelt je in staat om een modulaire technologielaag te creëren voor het bouwen van een NanoService, genaamd een "Cube". De kubussen zijn symmetrisch, en de afhankelijkheden tussen verschillende kubussen zijn ook symmetrisch en los, waardoor alleen de berichtinterfaces worden blootgesteld die Akka al aanbiedt.
Het beschrijft ook de moeilijkheden die programmeurs kunnen ondervinden bij het adopteren van AKKA-code, omdat je mogelijk ook iemand moet inhuren die getraind is in Akka/Scala.
Aangezien de meeste services vergelijkbare doelen hebben: verzoeken ontvangen, databases aanroepen en lezen en schrijven, andere services oproepen, regel-engines oproepen, data uit caches halen, naar caches schrijven... Als gevolg hiervan kunnen services worden geabstraheerd via patronen zoals Orchestrator Pattern en Perpetual Stream.
Squbs is een standaardpraktijk geworden voor PayPal om reactieve applicaties te bouwen op basis van Akka. Als je team nog geen stateful systemen heeft overwogen, is het waarschijnlijk de moeite waard om het te proberen, want het werkt goed bij PayPal, Facebook, Uber en Microsoft.
|
Geplaatst op 25-09-2019 16:11:58
|
|
|
|
