Hagyományosan egy olyan rendszer, amely naponta milliárd tranzakciót kezel, több száz VM-re van szükség, a PayPal mindezt mindössze 8 VM-vel csinálja, és gyors válaszokat nyújt 90%-os CPU-használattal, ami olyan tranzakciós sűrűséget jelent, amit a PayPal még soha nem ért el, és a folyamat 1/10-ig vesz igénybe az időt, segítve a szervezetet a növekedéssel lépést tartani anélkül, hogy bővítenie kellene a számítástechnikai infrastruktúrát, miközben csökkentené a költségeket. Hogyan csinálják ezt?
A PayPal áthelyezte rendszerét Akka-alapú Actor módra. A Squbs: PayPal új reaktív megközelítést alkalmaz az alkalmazások építésében (A hiperlink bejelentkezés látható.A PayPal elmagyarázza a folyamat részleteit. Most már nyílt forráskódú Squb-okat is közzétettek a GitHubon (A hiperlink bejelentkezés látható.)。
Amikor egy projektnek gyakorlati megközelítésre van szüksége, az állapotos szolgáltatási modell továbbra sem kap elég figyelmet. Ha többet szeretnél megtudni az állapotos szolgáltatásokról, javasoljuk, hogy olvassa el azokat az okokat, amelyek miatt érdemes tovább fejleszteni a skálázható állapotos szolgáltatásokat (A hiperlink bejelentkezés látható.), ez a cikk Caitie McCaffrey beszédén alapul. Ha ez a cikk nem győz meg, van WhatsApp is, amely az Akka versenytársát, az Erlangot használja rendkívül nagy áteresztőképességre: a Facebook 19 milliárd dolláros WhatsApp architektúrája (A hiperlink bejelentkezés látható.)。
A fenti cikk ajánlásának oka az, hogy a PayPal nem ad részletes bevezetést az architektúrába, hanem inkább több időt szentel arra, hogy miért választották az Akkát, és milyen előnyöket jelent az Akka áthelyezés előnyei. De ez a cikk mégis értékes bátorítást és bemutatót ad a "megszokott útról való eltérés" gyakorlásához.
Mi baj van azzal, ha sok virtuális gépet használsz egy szolgáltatáshoz?
- A szolgáltatást nagyon alacsony áteresztőképességű, rendkívül kis virtuális gépeken futtatod. A szereplőalapú reaktív rendszerek legnagyobb előnye, hogy hatékonyabban tudják használni a számítási erőforrásokat, ami jelentősen csökkentheti a rendszer méretét, és elkerülheti a hagyományos gyakorlatok "egyszerű és durva" automatizálódását.
- Nagy terhet ró a hálózatodra és az útvonaltervezési infrastruktúrádra. Mivel a szolgáltatások inkább összekapcsolódnak, a kéréseknek sok hálózati ugráson kell keresztülmenniük, ami növeli a késleltetést és rontja a felhasználói élményt.
- Minél nagyobb, annál drágább. A több száz virtuális gépet tartalmazó szolgáltatások magas költségekkel járnak a menedzsment, a monitorozás és a hatástalan gyorsítótár kialakítása szempontjából.
- Minél kisebb, annál fürgébb. Szolgáltatások telepítése több száz virtuális gépre időigényes folyamat.
- Többet hozz ki több CPU-ból minden virtuális gépen. Mivel a CPU-kat nem lehet tovább gyorsítani, az infrastruktúrának hatékonyabban kell használnia a több CPU-t minden virtuális gépen.
- A mikroszolgáltatásokat lazán összekapcsolt NanoServices-ekkel kell építeni, amelyek könnyen karbantarthatók és gyorsan felépíthetők. Senki sem akar egy összetett rendszerrel foglalkozni, ahol sok réteg van, és nagyobb betekintést kell a különböző szolgáltatások szerepébe anélkül, hogy mélyen a kódrétegekbe kellene menned.
Ezeket a tényezőket szem előtt tartva a PayPal olyan rendszert akart építeni, amely:
- Skálázható, nemcsak hogy vízszintesen több száz csomópontra skálázható, hanem több processzorra is felskálázható, hogy elérje a napi milliárdok kérésének feldolgozását.
- Alacsony késleltetés, és rendkívül finom granularitással szabályozható.
- Légy ellenálló a kudarcok ellen.
- A szolgáltatási határok rugalmas módosítása.
- A skálázhatóságot és az egyszerűséget programozási modelleken és kultúrán, valamint egyszerűbb hibakezelési mechanizmusokon keresztül előmozdítani.
Kétségtelen, hogy a PayPal egy "vékonyabb" stacket szeretne használni, és nem akarja, hogy a stack sok technológiát és mozgó alkatrészt tartalmazzon különböző szinteken. Általánosságban az Akka és az állapotalapú rendszerek jól megfelelnek erre az igényre, amely lehetővé teszi, hogy a nagy komponensekből álló halom egyetlen technológiává "bontsák". A PayPal az Akkát választotta az Erlang helyett, mert több tapasztalatuk van a Java-val, ami a Java fölött fut. Sokak számára az Erlang nulláról való tanulása nem reális.
Akkával a következőket tudnák tenni:
- Írj olyan kódot, amit könnyebb megmagyarázni
- Írj olyan kódot, amit könnyebb tesztelni
- A hiba- és hibahelyzeteket természetesebben kezelik, mint a hagyományos JVM-et használó módok
- Írj gyorsabb, ellenállóbb és egyszerűbb kódot, hogy folyékonyabban kezeld a hibákat, és csökkentsd a hibák számát
A PayPal azonnal saját keretrendszert írt az Akka alapján, amelyet Squbs-nak hívtak, és amelyet a "Cubes" (kockák) rímelésére használtak. Ez lehetővé teszi, hogy moduláris technológiai réteget hozz létre egy NanoService építéséhez, amit "Cube"-nak neveznek. A kockák szimmetrikusak, és a különböző kockák közötti függőségek szintén szimmetrikusak és lazák, csak az Akka által már biztosított üzenetfelületeket tárják fel.
Leírja azokat a nehézségeket is, amelyekkel a programozók szembesülhetnek az AKKA kód alkalmazásakor, mivel előfordulhat, hogy szükség lehet valakit felvenni, aki Akka/Scala nyelven képzett.
Mivel a legtöbb szolgáltatás hasonló célt szolgál: kérések fogadása, hívás, adatbázisok olvasása, írás, más szolgáltatások hívása, szabálymotorok hívása, adatgyűjtés gyorsítótárakból, levélírás... Ennek eredményeként a szolgáltatások absztrakcióba kerülhetnek mintákkal, mint például az Orkestrátor Pattern és az Perpetual Stream.
A Squbs bevált gyakorlatmá vált a PayPal számára, hogy reaktív alkalmazásokat építsen Akka alapján. Ha a csapatod még nem gondolt az állapotos rendszerekre, valószínűleg érdemes kipróbálni, mert jól működik a PayPal-nál, Facebookon, Ubernél és Microsoftnál.
|
Közzétéve 2019. 09. 25. 16:11:58
|
|
|
|
