|
|
Opublikowano 25.09.2019 16:11:58
|
|
|
|
Tradycyjnie system obsługujący miliard transakcji dziennie mógł wymagać setek maszyn wirtualnych, PayPal robi to wszystko za pomocą zaledwie 8 maszyn wirtualnych, zapewnia szybką reakcję przy 90% użyciu CPU – gęstość transakcji, której PayPal nigdy wcześniej nie osiągnął, a proces zajmuje 1/10 czasu, co pomaga organizacji nadążyć za rozwojem bez konieczności skalowania infrastruktury obliczeniowej i obniżając koszty. Jak to się robi?
PayPal przeniósł swój system do trybu aktora opartego na Akka. W artykule Squbs: PayPal podejmuje nowe, reaktywne podejście do tworzenia aplikacji (Logowanie do linku jest widoczne.PayPal wyjaśnia szczegóły całego procesu. Teraz udostępnili Squbs jako open source i opublikowali je na GitHubie (Logowanie do linku jest widoczne.)。
Gdy projekt wymaga podejścia praktycznego, model usług stanowych nadal nie otrzymuje wystarczającej uwagi. Aby dowiedzieć się więcej o usługach stanowych, zalecamy przeczytanie powodów, dla których warto kontynuować budowanie skalowalnych usług stanowych już teraz (Logowanie do linku jest widoczne.), artykuł opiera się na przemówieniu Caitie McCaffrey. Jeśli ten artykuł Cię nie przekona, jest też WhatsApp, który wykorzystuje konkurenta Akka, Erlang, do bardzo wysokiej przepustowości: architekturę WhatsApp Facebooka wartą 19 miliardów dolarów (Logowanie do linku jest widoczne.)。
Powodem polecania powyższego artykułu jest to, że PayPal nie przedstawia szczegółowego wprowadzenia do architektury, lecz poświęca więcej uwagi na powody, dla których wybrano Akka oraz korzyści płynące z migracji do Akka. Mimo to ten artykuł wciąż dostarcza cennych zachęt i dowodów na praktykę "odchodzenia od utartych szlaków".
Co jest złego w używaniu dużej liczby maszyn wirtualnych dla usługi?
- Uruchom usługę na bardzo niskiej przepustowości, bardzo małych maszynach wirtualnych. Największą zaletą systemów reaktywnych opartych na aktorach jest to, że mogą one efektywniej wykorzystać zasoby obliczeniowe, co znacznie zmniejsza rozmiar systemu i pozwala uniknąć "prostego i prymitywnego" automatycznego skalowania tradycyjnych praktyk.
- To bardzo obciąża twoją sieć i infrastrukturę routingową. Ponieważ usługi są zwykle bardziej połączone, żądania mogą wymagać przejścia przez dużą liczbę przeskoków sieciowych, co zwiększa opóźnienia i pogarsza doświadczenie użytkownika.
- Im większy, tym droższy. Usługi z setkami maszyn wirtualnych mają wysokie koszty związane z zarządzaniem, monitorowaniem oraz nieefektywnym buforowaniem.
- Im mniejszy, tym bardziej zwinny jest. Wdrażanie usług na setkach maszyn wirtualnych to proces czasochłonny.
- Wykorzystaj więcej CPU na każdej maszynie wirtualnej. Ponieważ procesorów nie można jeszcze bardziej przyspieszyć, infrastruktura musi być w stanie efektywniej wykorzystać więcej procesorów na każdej maszynie wirtualnej.
- Mikroserwisy muszą być budowane z luźno powiązanych nanoserwisów, które są łatwe w utrzymaniu i szybkie w budowie. Nikt nie chce mieć do czynienia z złożonym systemem z wieloma warstwami, a potrzebujesz większej przejrzystości roli różnych usług bez konieczności zagłębiania się w warstwy kodu.
Mając na uwadze te czynniki, PayPal chciał zbudować system, które:
- Skalowalny, nie tylko do skalowania poziomego do setek węzłów, ale także do większej liczby procesorów, by osiągnąć cel przetwarzania miliardów żądań dziennie.
- Niskie opóźnienia i można nim sterować z bardzo precyzyjną granulacją.
- Bądź odporny na porażki.
- Elastyczne dostosowanie granic usług.
- Promuj skalowalność i prostotę poprzez modele i kulturę programowania, a także prostsze mechanizmy obsługi błędów i błędów.
Nie ma wątpliwości, że PayPal chce używać bardziej "cienkiego" stosu i nie chce, aby jego stos zawierał dużo technologii i ruchomych elementów na różnych poziomach. Ogólnie rzecz biorąc, systemy Akka i stanowe są dobrze przystosowane do tych potrzeb, co pozwala na "rozbicie" stosu dużych komponentów na jedną technologię. PayPal wybrał Akka zamiast Erlang, ponieważ mają większe doświadczenie z Javą, która działa na Javie. Dla wielu osób nauka Erlanga od podstaw nie jest realistyczna.
Dzięki Akce mogą:
- Napisz kod łatwiejszy do wyjaśnienia
- Napisz kod łatwiejszy do testowania
- Scenariusze błędów i awarii są obsługiwane bardziej naturalnie niż w tradycyjnych trybach przy użyciu JVM
- Pisz szybszy, bardziej odporny i prostszy kod, aby płynniej radzić sobie z błędami i zmniejszyć liczbę błędów
PayPal natychmiast stworzył własny framework oparty na Akka, który nazwał się Squbs, rymując się z "Cubes". Pozwala to stworzyć modułową warstwę technologiczną do budowy NanoService, zwaną "Cube". Kostki są symetryczne, a zależności między różnymi kostkami również symetryczne i luźne, ujawniając jedynie interfejsy komunikatów, które już oferuje Akka.
Opisuje także trudności, z jakimi mogą się spotkać programiści przy wdrażaniu kodu AKKA, ponieważ może być konieczne zatrudnienie osoby przeszkolonej w Akka/Scala.
Ponieważ większość usług ma podobne cele: odbieranie żądań, wywoływanie oraz odczyt i zapis baz danych, wywoływanie innych usług, wywoływanie silników reguł, pobieranie danych z pamięci podręcznej, zapis do cache... W rezultacie usługi mogą być abstrahowane za pomocą wzorców takich jak Wzorzec Orchestratora i Strumień Wieczny.
Squbs stał się standardową praktyką PayPal w budowaniu reaktywnych aplikacji opartych na Akka. Jeśli Twój zespół jeszcze nie rozważał systemów stanowych, warto spróbować, bo dobrze sprawdzają się w PayPal, Facebooku, Uberze i Microsoftzie.
|
Poprzedni:Trzy czynniki, które sprawiają, że odrzucam ChromeNastępny:vs utwórz folder, a podczas generowania rozwiązania nikt nie ma nikogo pod plikiem bin.
|
