|
|
Postat pe 25.09.2019 16:11:58
|
|
|
|
În mod tradițional, un sistem care gestionează un miliard de tranzacții pe zi ar putea necesita sute de mașini virtuale, PayPal face toate acestea cu doar 8 VM-uri și oferă un răspuns rapid cu 90% utilizare a procesorului, o densitate a tranzacțiilor pe care PayPal nu a mai atins-o niciodată, iar procesul durează 1/10 din timp, ajutând organizația să țină pasul cu creșterea fără a fi nevoită să-și extindă infrastructura de calcul, reducând în același timp costurile. Cum se face asta?
PayPal și-a migrat sistemul în modul Actor bazat pe Akka. În articolul Squbs: PayPal adoptă o nouă abordare reactivă în construirea aplicațiilor (Autentificarea cu hyperlink este vizibilă.PayPal explică toate detaliile procesului. Acum au făcut open source Squbs și l-au publicat pe GitHub (Autentificarea cu hyperlink este vizibilă.)。
Când un proiect trebuie să adopte o abordare directă, modelul de serviciu cu stare tot nu primește suficientă atenție. Pentru a afla mai multe despre serviciile cu star, vă recomandăm să citiți motivele pentru a continua să construiți servicii cu stare scalabile acum (Autentificarea cu hyperlink este vizibilă.), acest articol se bazează pe un discurs al lui Caitie McCaffrey. Dacă acest articol nu te convinge, există și WhatsApp, care folosește concurentul lui Akka, Erlang, pentru un debit extrem de mare: arhitectura WhatsApp de 19 miliarde de dolari a Facebook (Autentificarea cu hyperlink este vizibilă.)。
Motivul recomandării articolului de mai sus este că PayPal nu oferă o introducere detaliată a arhitecturii, ci dedică mai mult timp motivelor pentru care au ales Akka și beneficiile migrării către Akka. Dar acest articol oferă totuși încurajare valoroasă și demonstrație pentru practica de a "ieși de pe drumul bătut".
Ce este rău în a folosi un număr mare de mașini virtuale pentru un serviciu?
- Rulează serviciul cu mașini virtuale foarte mici, extrem de mici. Cel mai mare avantaj al sistemelor reactive bazate pe actori este că pot folosi mai eficient resursele de calcul, ceea ce poate reduce semnificativ dimensiunea sistemului și poate evita autoscalarea "simplă și rudimentară" a practicilor tradiționale.
- Pune multă presiune pe rețeaua și infrastructura de rutare. Deoarece serviciile tind să fie mai interconectate, cererile pot fi nevoite să treacă printr-un număr mare de sărituri în rețea, ceea ce crește latența și degradează experiența utilizatorului.
- Cu cât este mai mare, cu atât este mai scump. Serviciile cu sute de mașini virtuale au costuri inerente ridicate în ceea ce privește managementul, monitorizarea și cache-ul ineficient.
- Cu cât este mai mic, cu atât este mai agil. Implementarea serviciilor către sute de mașini virtuale este un proces consumator de timp.
- Obține mai mult din mai mult CPU pe fiecare mașină virtuală. Deoarece procesoarele nu pot fi accelerate suplimentar, infrastructura trebuie să poată folosi mai eficient mai multe procesoare pe fiecare mașină virtuală.
- Microserviciile trebuie construite cu NanoServices slab cuplate, ușor de întreținut și rapid de construit. Nimeni nu vrea să se ocupe de un sistem complex cu multe straturi, iar ai nevoie de mai multă vizibilitate asupra rolului diferitelor servicii fără să intri în detalii în straturi de cod.
Având în vedere acești factori, PayPal a dorit să construiască un sistem care:
- Scalabil, nu doar pentru a se scala orizontal la sute de noduri, ci și pentru a crește la mai mulți procesoare pentru a atinge obiectivul de a procesa miliarde de cereri pe zi.
- Latență scăzută și poate fi controlată cu o granularitate extrem de fină.
- Fii rezilient în fața eșecurilor.
- Ajustare flexibilă a limitelor serviciilor.
- Promovați scalabilitatea și simplitatea prin modele și cultură de programare, precum și mecanisme mai simple de gestionare a erorilor.
Nu există nicio îndoială că PayPal dorește să folosească un stack mai "subțire" și nu vor ca stack-ul lor să conțină multă tehnologie și componente mobile la diferite niveluri. În general, sistemele Akka și cele bazate pe state sunt bine adaptate acestei nevoi, ceea ce permite ca stivul de componente mari să fie "descompus" într-o singură tehnologie. PayPal a ales Akka în locul lui Erlang pentru că au mai multă experiență cu Java, care rulează peste Java. Pentru mulți oameni, să învețe Erlang de la zero nu este realist.
Cu Akka pot:
- Scrie cod mai ușor de explicat
- Scrie cod mai ușor de testat
- Scenariile de eroare și eșec sunt gestionate mai natural decât modurile tradiționale folosind JVM-ul
- Scrie cod mai rapid, mai rezistent și mai simplu pentru a gestiona erorile mai fluent și a reduce numărul de erori
PayPal a scris imediat propriul său cadru bazat pe Akka, numit Squbs, folosit pentru a rima cu "Cubes". Acest lucru îți permite să creezi un strat tehnologic modular pentru construirea unui NanoService numit "Cub". Cuburile sunt simetrice, iar dependențele dintre diferite cuburi sunt de asemenea simetrice și lejere, expunând doar interfețele de mesaje pe care Akka le oferă deja.
De asemenea, descrie dificultățile cu care se pot confrunta programatorii atunci când adoptă codul AKKA, deoarece este posibil să fie nevoie să angajezi pe cineva instruit în Akka/Scala.
Deoarece majoritatea serviciilor au scopuri similare: primesc cereri, apelează și citesc și scriu baze de date, apelează alte servicii, apelează motoare de reguli, obțin date din cache-uri, scriu în cache-uri... Ca urmare, serviciile pot fi abstractizate prin modele precum Orchestrator Pattern și Perpetual Stream.
Squbs a devenit o practică standard pentru PayPal de a construi aplicații reactive bazate pe Akka. Dacă echipa ta nu a luat încă în considerare sistemele stateful, probabil merită încercat, deoarece funcționează bine la PayPal, Facebook, Uber și Microsoft.
|
Precedent:Trei factori care mă fac să renunț la ChromeUrmător:vs Creează un folder, iar la generarea soluției, nu există nimeni sub fișierul bin
|
