|
|
Opslået på 25/09/2019 16.11.58
|
|
|
|
Traditionelt kunne et system, der håndterer en milliard transaktioner om dagen, kræve hundredvis af virtuelle maskiner, PayPal klarer det hele med blot 8 virtuelle maskiner og leverer hurtig respons ved 90 % CPU-forbrug, en transaktionstæthed som PayPal aldrig før har opnået, og processen tager 1/10 af tiden at gennemføre processen, hvilket hjælper organisationen med at følge med væksten uden at skulle skalere sin computerinfrastruktur op, samtidig med at omkostningerne reduceres. Hvordan gør man det?
PayPal har migreret sit system til Akka-baseret Actor-tilstand. I artiklen Squbs: PayPal tager en ny reaktiv tilgang til at bygge apps (Hyperlink-login er synlig.PayPal forklarer processens detaljer. De har nu gjort Squbs open source og udgivet det på GitHub (Hyperlink-login er synlig.)。
Når et projekt skal have en hands-on tilgang, får stateful service-modellen stadig ikke nok opmærksomhed. For at lære mere om statslige tjenester anbefaler vi, at du læser grundene til at fortsætte med at opbygge skalerbare statslige tjenester nu (Hyperlink-login er synlig.), denne artikel er baseret på en tale af Caitie McCaffrey. Hvis denne artikel ikke overbeviser dig, er der også WhatsApp, der bruger Akkas konkurrent Erlang for ekstremt høj gennemstrømning: Facebooks WhatsApp-arkitektur til 19 milliarder dollars (Hyperlink-login er synlig.)。
Grunden til at anbefale ovenstående artikel er, at PayPal ikke giver en detaljeret introduktion til arkitekturen, men i stedet bruger mere tid på årsagerne til, at de valgte Akka, og fordelene ved at migrere til Akka. Men denne artikel giver stadig værdifuld opmuntring og demonstration af praksissen med at "gå uden for alfarvej".
Hvad er der galt i at bruge et stort antal virtuelle maskiner til en service?
- Kør tjenesten med meget lav-gennemløbs, ekstremt små virtuelle maskiner. Den største fordel ved aktørbaserede reaktive systemer er, at de kan udnytte computerressourcerne mere effektivt, hvilket kan reducere systemets størrelse betydeligt og undgå den "simple og primitive" autoskalering, som traditionelle metoder har.
- Det lægger meget pres på dit netværk og din routinginfrastruktur. Da tjenester har tendens til at være mere sammenkoblede, kan forespørgsler være nødt til at gå gennem et stort antal netværkshop, hvilket øger latenstiden og forringer brugeroplevelsen.
- Jo større den er, desto dyrere er den. Tjenester med hundredvis af virtuelle maskiner har høje iboende omkostninger i form af administration, overvågning og ineffektiv caching.
- Jo mindre den er, desto mere adræt er den. At udrulle tjenester til hundredvis af virtuelle maskiner er en tidskrævende proces.
- Få mere ud af mere CPU på hver virtuel maskine. Da CPU'er ikke kan accelereres yderligere, skal infrastrukturen kunne udnytte flere CPU'er mere effektivt på hver virtuel maskine.
- Mikrotjenester skal bygges med løst koblede NanoServices, som er nemme at vedligeholde og hurtige at bygge. Ingen ønsker at håndtere et komplekst system med mange lag, og man har brug for mere overblik over forskellige tjenesters rolle uden at skulle gå dybt ned i lag af kode.
Med disse faktorer in mente ønskede PayPal at bygge et system, der:
- Skalerbar, ikke kun for at skalere horisontalt til hundreder af noder, men også for at skalere op til flere processorer for at opnå målet om at behandle milliarder af forespørgsler om dagen.
- Lav latens og kan kontrolleres med ekstremt fin granularitet.
- Vær modstandsdygtig over for fiaskoer.
- Fleksibel justering af servicegrænser.
- Fremme skalerbarhed og enkelhed gennem programmeringsmodeller og kultur samt enklere fejl- og fejlhåndteringsmekanismer.
Der er ingen tvivl om, at PayPal ønsker at bruge en mere "tynd" stak, og de ønsker ikke, at deres stack skal indeholde for meget teknologi og bevægelige dele på forskellige niveauer. Generelt er Akka og statsbaserede systemer godt egnet til dette behov, hvilket gør det muligt at "nedbryde" stakken af store komponenter til én teknologi. PayPal valgte Akka frem for Erlang, fordi de har mere erfaring med Java, som kører oven på Java. For mange mennesker er det ikke realistisk at lære Erlang fra bunden.
Med Akka kan de:
- Skriv kode, der er nemmere at forklare
- Skriv kode, der er nemmere at teste
- Fejl- og fejlscenarier håndteres mere naturligt end traditionelle tilstande med JVM
- Skriv hurtigere, mere robust og enklere kode for at håndtere fejl mere flydende og reducere antallet af fejl
PayPal skrev straks sit eget framework baseret på Akka, som blev kaldt Squbs, der blev brugt til at rime på "Cubes". Dette gør det muligt at skabe et modulært teknologilag til opbygningen af en NanoService kaldet en "Cube". Kuberne er symmetriske, og afhængighederne mellem forskellige kuber er også symmetriske og løse, hvilket kun eksponerer de beskedgrænseflader, som Akka allerede leverer.
Det beskriver også de vanskeligheder, programmører kan støde på, når de tager AKKA-kode i brug, da du måske også skal hyre en, der er uddannet i Akka/Scala.
Da de fleste tjenester har lignende formål: modtage forespørgsler, kalde og læse og skrive databaser, kalde andre tjenester, kalde regelmotorer, hente data fra caches, skrive til caches... Som følge heraf kan tjenester abstraheres gennem mønstre som Orchestrator Pattern og Perpetual Stream.
Squbs er blevet en standardpraksis for PayPal til at bygge reaktive applikationer baseret på Akka. Hvis dit team endnu ikke har overvejet stateful systemer, er det nok værd at prøve, da det fungerer godt hos PayPal, Facebook, Uber og Microsoft.
|
Tidligere:Tre faktorer, der får mig til at afvikle ChromeNæste:vs Opret en mappe, og når løsningen genereres, er der ingen under bin-filen
|
