|
|
Paskelbta 2019-09-25 16:11:58
|
|
|
|
Tradiciškai sistemai, kuri apdoroja milijardą operacijų per dieną, gali prireikti šimtų VM, "PayPal" viską atlieka tik su 8 VM ir užtikrina greitą atsaką naudojant 90 % procesoriaus – operacijų tankį, kurio "PayPal" niekada anksčiau nepasiekė, o procesas užtrunka 1/10 laiko, padedančio organizacijai neatsilikti nuo augimo nedidinant skaičiavimo infrastruktūros ir mažinant išlaidas. Kaip tai daroma?
"PayPal" perkėlė savo sistemą į "Akka" pagrįstą aktoriaus režimą. Straipsnyje "Squbs: PayPal" taiko naują reaktyvų požiūrį į programų kūrimą (Hipersaito prisijungimas matomas."PayPal" paaiškina proceso subtilybes. Dabar jie turi atvirojo kodo "Squbs" ir paskelbė jį "GitHub" (Hipersaito prisijungimas matomas.)。
Kai projektui reikia praktinio požiūrio, valstybinis paslaugų modelis vis tiek nesulaukia pakankamai dėmesio. Norėdami sužinoti daugiau apie valstybines paslaugas, rekomenduojame perskaityti priežastis, kodėl reikia toliau kurti keičiamo dydžio būsenos paslaugas dabar (Hipersaito prisijungimas matomas.), šis straipsnis yra pagrįstas Caitie McCaffrey kalba. Jei šis straipsnis jūsų neįtikina, taip pat yra "WhatsApp", kuri naudoja "Akka" konkurentą "Erlang" itin dideliam pralaidumui: "Facebook" 19 milijardų dolerių vertės "WhatsApp" architektūra (Hipersaito prisijungimas matomas.)。
Aukščiau pateikto straipsnio rekomendavimo priežastis yra ta, kad "PayPal" nepateikia išsamaus architektūros įvado, o daugiau laiko skiria priežastims, kodėl pasirinko "Akka", ir perėjimo prie "Akka" pranašumams. Tačiau šis straipsnis vis tiek suteikia vertingą padrąsinimą ir demonstraciją praktikai "išeiti iš praminto kelio".
Kas blogo, jei paslaugai naudojama daug virtualių mašinų?
- Paleiskite paslaugą su labai mažo pralaidumo, itin mažomis virtualiomis mašinomis. Didžiausias aktorių reaktyviųjų sistemų privalumas yra tas, kad jos gali efektyviau panaudoti skaičiavimo išteklius, o tai gali labai sumažinti sistemos dydį ir išvengti "paprasto ir primityvaus" tradicinės praktikos automatinio mastelio keitimo.
- Tai labai apkrauna jūsų tinklą ir maršruto parinkimo infrastruktūrą. Kadangi paslaugos paprastai yra labiau tarpusavyje susijusios, užklausoms gali tekti atlikti daug tinklo šuolių, o tai padidina delsą ir pablogina vartotojo patirtį.
- Kuo jis didesnis, tuo brangesnis. Paslaugos, turinčios šimtus virtualių mašinų, turi didelių valdymo, stebėjimo ir neveiksmingo talpyklos išlaidų.
- Kuo jis mažesnis, tuo judresnis. Paslaugų diegimas šimtuose virtualių mašinų yra daug laiko reikalaujantis procesas.
- Gaukite daugiau naudos iš daugiau procesoriaus kiekvienoje virtualioje mašinoje. Kadangi procesorių negalima dar labiau pagreitinti, infrastruktūra turi sugebėti efektyviau išnaudoti daugiau procesorių kiekvienoje virtualioje mašinoje.
- Mikropaslaugos turi būti sukurtos su laisvai susietomis nanopaslaugomis, kurias būtų lengva prižiūrėti ir greitai sukurti. Niekas nenori susidurti su sudėtinga sistema, kurioje yra daug sluoksnių, todėl jums reikia daugiau matomumo apie skirtingų paslaugų vaidmenį, nesigilinant į kodo sluoksnius.
Atsižvelgdama į šiuos veiksnius, "PayPal" norėjo sukurti sistemą, kuri:
- Keičiamo dydžio ne tik horizontaliai iki šimtų mazgų, bet ir iki daugiau procesorių, kad būtų pasiektas tikslas apdoroti milijardus užklausų per dieną.
- Maža delsa ir gali būti valdoma itin smulkiai.
- Būkite atsparūs nesėkmių akivaizdoje.
- Lankstus paslaugų ribų reguliavimas.
- Skatinkite mastelio keitimą ir paprastumą naudodami programavimo modelius ir kultūrą, taip pat paprastesnius gedimų ir klaidų valdymo mechanizmus.
Nėra abejonių, kad PayPal nori naudoti daugiau "plonas" kaminas, ir jie nenori, kad jų kaminas turi daug technologijų ir judančių dalių skirtingais lygiais. Apskritai šiam poreikiui puikiai tinka "Akka" ir valstybinės sistemos, leidžiančios "suskaidyti" didelių komponentų krūvą į vieną technologiją. "PayPal" pasirinko "Akka", o ne "Erlang", nes turi daugiau patirties su "Java", kuri veikia ant "Java". Daugeliui žmonių mokytis Erlang nuo nulio nėra realu.
Su "Akka" jie gali:
- Parašykite kodą, kurį lengviau paaiškinti
- Parašykite kodą, kurį lengviau išbandyti
- Klaidų ir gedimų scenarijai tvarkomi natūraliau nei tradiciniai režimai naudojant JVM
- Rašykite greitesnį, atsparesnį ir paprastesnį kodą, kad galėtumėte sklandžiau tvarkyti klaidas ir sumažinti klaidų skaičių
"PayPal" iš karto parašė savo sistemą, pagrįstą "Akka", kuri vadinosi "Squbs", kuri buvo naudojama rimuotis su "Cubes". Tai leidžia sukurti modulinį technologinį sluoksnį, skirtą "NanoService" kūrimui, vadinamą "kubu". Kubai yra simetriški, o priklausomybės tarp skirtingų kubų taip pat yra simetriškos ir laisvos, atskleidžiant tik pranešimų sąsajas, kurias jau teikia Akka.
Jame taip pat aprašomi sunkumai, su kuriais programuotojai gali susidurti priimdami AKKA kodą, nes taip pat gali tekti samdyti žmogų, apmokytą Akka/Scala.
Kadangi dauguma paslaugų turi panašius tikslus: gauti užklausas, skambinti ir skaityti bei rašyti duomenų bazes, skambinti kitoms tarnyboms, skambinti taisyklių varikliams, gauti duomenis iš talpyklų, rašyti į talpyklas... Dėl to paslaugos gali būti abstrahuojamos naudojant tokius modelius kaip "Orchestrator Pattern" ir "Perpetual Stream".
"Squbs" tapo standartine "PayPal" praktika kurti reaktyvias programas, pagrįstas "Akka". Jei jūsų komanda dar nesvarstė būsenos sistemų, tikriausiai verta pabandyti, nes ji puikiai veikia "PayPal", "Facebook", "Uber" ir "Microsoft".
|
Ankstesnis:Trys veiksniai, dėl kurių nebenaudoju "Chrome"Kitą:vs sukurkite aplanką, o generuojant sprendimą po šiukšliadėžės failu nieko nėra
|
