|
|
Publicerad på 2019-09-25 16:11:58
|
|
|
|
Traditionellt kan ett system som hanterar en miljard transaktioner per dag kräva hundratals virtuella maskiner, PayPal gör allt med bara 8 virtuella maskiner och levererar snabb respons vid 90 % CPU-användning, en transaktionstäthet som PayPal aldrig tidigare uppnått, och processen tar en tiondel av tiden att uppnå processen, vilket hjälper organisationen att hänga med i tillväxten utan att behöva skala upp sin datorinfrastruktur samtidigt som kostnaderna minskas. Hur görs detta?
PayPal har migrerat sitt system till Akka-baserat Actor-läge. I artikeln Squbs: PayPal tar ett nytt reaktivt grepp om att bygga appar (Inloggningen med hyperlänken är synlig.PayPal förklarar processens detaljer. De har nu öppnat källkod för Squbs och publicerat det på GitHub (Inloggningen med hyperlänken är synlig.)。
När ett projekt behöver ta ett praktiskt grepp får den statliga tjänstemodellen ändå inte tillräcklig uppmärksamhet. För att lära dig mer om stateful services rekommenderar vi att du läser anledningarna till att fortsätta bygga skalbara stateful services nu (Inloggningen med hyperlänken är synlig.), denna artikel baseras på ett tal av Caitie McCaffrey. Om den här artikeln inte övertygar dig, finns det också WhatsApp som använder Akkas konkurrent Erlang för extremt hög genomströmning: Facebooks WhatsApp-arkitektur värd 19 miljarder dollar (Inloggningen med hyperlänken är synlig.)。
Anledningen till att rekommendera ovanstående artikel är att PayPal inte ger en detaljerad introduktion till arkitekturen, utan istället ägnar mer tid åt varför de valde Akka och fördelarna med att migrera till Akka. Men denna artikel ger ändå värdefull uppmuntran och demonstration för praktiken att "gå utanför allfartsvägarna".
Vad är fel med att använda ett stort antal virtuella maskiner för en tjänst?
- Kör tjänsten med mycket låg genomströmning, extremt små virtuella maskiner. Den största fördelen med aktörbaserade reaktiva system är att de kan använda datorresurser mer effektivt, vilket kan minska systemets storlek avsevärt och undvika den "enkla och grova" autoskalningen som traditionella metoder innebär.
- Det belastar ditt nätverk och din routinginfrastruktur mycket. Eftersom tjänster tenderar att vara mer sammankopplade kan förfrågningar behöva gå genom ett stort antal nätverkshopp, vilket ökar latensen och försämrar användarupplevelsen.
- Ju större den är, desto dyrare är den. Tjänster med hundratals virtuella maskiner har höga inneboende kostnader vad gäller hantering, övervakning och ineffektiv cache.
- Ju mindre den är, desto mer smidig är den. Att distribuera tjänster till hundratals virtuella maskiner är en tidskrävande process.
- Få ut mer av mer CPU på varje virtuell maskin. Eftersom CPU:er inte kan snabbas upp ytterligare måste infrastrukturen kunna använda fler CPU:er på varje virtuell maskin mer effektivt.
- Mikrotjänster måste byggas med löst kopplade NanoServices som är lätta att underhålla och snabba att bygga. Ingen vill hantera ett komplext system med många lager, och du behöver mer insyn i olika tjänsters roll utan att behöva gå djupt in i lager av kod.
Med dessa faktorer i åtanke ville PayPal bygga ett system som:
- Skalbart, inte bara för att skalas horisontellt till hundratals noder, utan också för att skala upp till fler processorer för att uppnå målet att bearbeta miljarder förfrågningar per dag.
- Låg latens och kan kontrolleras med extremt fin granularitet.
- Var motståndskraftig inför misslyckanden.
- Flexibel justering av tjänstegränser.
- Främja skalbarhet och enkelhet genom programmeringsmodeller och kultur, samt enklare fel- och felhanteringsmekanismer.
Det råder ingen tvekan om att PayPal vill använda en mer "tunn" stack, och de vill inte att deras stack ska innehålla mycket teknik och rörliga delar på olika nivåer. Generellt är Akka och tillståndsbaserade system väl lämpade för detta behov, vilket gör det möjligt att "bryta ner stapeln av stora komponenter" till en enda teknik. PayPal valde Akka framför Erlang eftersom de har mer erfarenhet av Java, som körs ovanpå Java. För många är det inte realistiskt att lära sig Erlang från grunden.
Med Akka kan de:
- Skriv kod som är lättare att förklara
- Skriv kod som är lättare att testa
- Fel- och felscenarier hanteras mer naturligt än i traditionella lägen som använder JVM
- Skriv snabbare, mer motståndskraftig och enklare kod för att hantera fel mer smidigt och minska antalet buggar
PayPal skrev omedelbart sitt eget ramverk baserat på Akka, som kallades Squbs, vilket användes för att rimma på "Cubes". Detta gör att du kan skapa ett modulärt teknologilager för att bygga en NanoService kallad "Cube". Kuberna är symmetriska, och beroendena mellan olika kuber är också symmetriska och lösa, vilket endast exponerar de meddelandegränssnitt som Akka redan tillhandahåller.
Den beskriver också de svårigheter som programmerare kan stöta på när de använder AKKA-kod, eftersom du också kan behöva anlita någon utbildad i Akka/Scala.
Eftersom de flesta tjänster har liknande syften: ta emot förfrågningar, anropa och läsa och skriva databaser, anropa andra tjänster, anropa regelmotorer, hämta data från cacheminnen, skriva till cacher... Som ett resultat kan tjänster abstraheras genom mönster som Orchestrator Pattern och Perpetual Stream.
Squbs har blivit en standardpraxis för PayPal att bygga reaktiva applikationer baserade på Akka. Om ditt team ännu inte har övervägt tillståndsbundna system är det nog värt ett försök, eftersom det fungerar bra på PayPal, Facebook, Uber och Microsoft.
|
Föregående:Tre faktorer som gör att jag avskaffar ChromeNästa:vs skapa en mapp, och när lösningen genereras finns det ingen under bin-filen
|
