Įvadas į „Vert.x“, greičiausią „Java“ sistemą šiandien

Jei neseniai „Google“ žiniatinklyje ieškojote „geriausios žiniatinklio sistemos“, galbūt patekote į „Techempower“ etalonus, kur reitinguojama daugiau nei trys šimtai sistemų. Ten galbūt pastebėjote, kad „Vert.x“ yra vienas iš geriausiai vertinamų, jei ne pirmas pagal tam tikras priemones.

Taigi pakalbėkime apie tai.

„Vert.x“ yra daugialypė žiniatinklio sistema, turinti bendras palaikomų kalbų „Java“, „Kotlin“, „Scala“, „Ruby“ ir „Javascript“ funkcijas. Nepaisant kalbos, „Vert.x“ veikia „Java“ virtualioje mašinoje (JVM). Būdamas modulinis ir lengvas, jis yra orientuotas į mikropaslaugų plėtrą.

„Techempower“ etalonai matuoja duomenų atnaujinimo, gavimo ir pateikimo iš duomenų bazės našumą. Kuo daugiau prašymų pateikiama per sekundę, tuo geriau. Tokiame IO scenarijuje, kai skaičiuojama nedaug, bet kuri neužblokuojanti sistema turėtų pranašumų. Pastaraisiais metais tokia paradigma yra beveik neatsiejama nuo „Node.js“, kuri ją išpopuliarino savo vieno sriegio įvykių kilpa.

„Vert.x“, kaip ir „Node“, valdo vieną įvykių ciklą. Tačiau „Vert.x“ taip pat naudojasi JVM. Nors mazgas veikia viename branduolyje, „Vert.x“ palaiko siūlų grupę, kurios dydis gali atitikti galimų branduolių skaičių. Su didesniu lygiagretumo palaikymu „Vert.x“ tinka ne tik IO, bet ir sunkiems procesoriams, kuriems reikalingas lygiagretus kompiuteris.

Tačiau įvykių kilpos yra pusė istorijos. Kita pusė mažai susijusi su „Vert.x“.

Norint prisijungti prie duomenų bazės, klientui reikalinga jungties tvarkyklė. „Java“ srityje labiausiai paplitusi „Sql“ tvarkyklė yra JDBC. Problema ta, kad šis tvarkyklė blokuoja. Tai blokuoja lizdo lygyje. Siūlas visada įstrigs ten, kol grįš su atsakymu.

Nereikia nė sakyti, kad vairuotojas buvo kliūtis įgyvendinant visiškai neužblokuojančią programą. Laimei, buvo padaryta pažanga (nors ir neoficiali) naudojant asinchroninį tvarkyklę su keliomis aktyviomis šakėmis, tarp jų:

  • //github.com/jasync-sql/jasync-sql (skirta „Postgres“ ir „MySql“)
  • //github.com/reactiverse/reactive-pg-client („Postgres“)

Auksinė taisyklė

„Vert.x“ yra gana paprasta dirbti, o http serverį galima iškelti su keliomis kodo eilutėmis.

Metodas requestHandler yra vieta, kur įvykio ciklas pateikia užklausos įvykį. Kadangi „Vert.x“ nėra nuomonės, jo tvarkymas yra laisvo stiliaus. Tačiau nepamirškite vienos svarbios neužblokuojančių gijų taisyklės: jos neužblokuokite.

Dirbdami lygiagrečiai galime pasinaudoti tiek daug šiandien galimų variantų, kaip „Promise“, „Future“, „Rx“, taip pat „Vert.x“ idiomatiniu būdu. Tačiau augant programos sudėtingumui, vien tik asinchroninio funkcionalumo nepakanka. Mums taip pat reikia lengvai koordinuoti ir susieti skambučius, vengiant skambučių pragaro ir grakščiai perduoti bet kokią klaidą.

„Scala Future“ tenkina visas aukščiau pateiktas sąlygas ir turi papildomą pranašumą, nes remiasi funkciniais programavimo principais. Nors šiame straipsnyje „Scala Future“ nėra gilinamasi, galime jį išbandyti naudodami paprastą programą. Tarkime, kad programa yra API paslauga, skirta rasti vartotoją su jo ID:

Atliekamos trys operacijos: užklausos parametro tikrinimas, ID tinkamumo tikrinimas ir duomenų gavimas. Kiekvieną iš šių operacijų apimsime ateityje ir koordinuosime vykdymą struktūroje „supratimui“.

  • Pirmas žingsnis - suderinti užklausą su paslauga. „Scala“ turi galingą raštų derinimo funkciją, kurią galime naudoti šiam tikslui. Čia mes perimame bet kokį „/ user“ paminėjimą ir perduodame jį į savo tarnybą.
  • Kitas yra šios paslaugos pagrindas, kai mūsų ateitis yra išdėstyta nuosekliai supratimui. Pirmasis būsimas „ f1“ patikrina parametrų patikrą. Mes konkrečiai norime gauti ID iš užklausos gauti ir perkelti jį į int. („Scala“ nereikalauja aiškaus grąžinimo, jei grąžinimo vertė yra paskutinė metodo eilutė.) Kaip matote, ši operacija gali sukelti išimtį, nes ID gali būti ne int arba jo nėra, bet kol kas tai gerai .
  • Antroji būsima f2 tikrina id pagrįstumą. Mes blokuojame bet kokį ID, mažesnį nei 100, aiškiai paskambinę į Future.failand with our own CustomException. Priešingu atveju mes praleidžiame tuščią Ateitį Future.unit forma kaip sėkmingą patvirtinimą.
  • Paskutinė būsima f3 gauna vartotoją su ID, kurį pateikia f1. Kadangi tai tik pavyzdys, mes tikrai neprisijungiame prie duomenų bazės. Mes tiesiog grąžiname kažkokią imitacinę stygą.
  • Žemėlapis vykdo išdėstymą, kuris pateikia vartotojo duomenis iš f3, tada juos atspausdina atsakyme.
  • Dabar, jei kurioje nors sekos dalyje įvyksta klaida, „Throwable“ perduodama, kad būtų atkurta . Čia galime suderinti jo tipą su tinkama atkūrimo strategija. Žvelgdami atgal į savo kodą, numatėme keletą galimų gedimų, tokių kaip trūkstamas ID arba ID, kuris nebuvo int arba negaliojantis ir dėl kurio atsiras konkrečių išimčių. Kiekvieną iš jų tvarkome „handException“, perduodami klientui klaidos pranešimą.

Ši tvarka suteikia ne tik asinchroninį srautą nuo pradžios iki pabaigos, bet ir švarų požiūrį į klaidų tvarkymą. Kadangi tai supaprastinta visiems tvarkytojams, galime sutelkti dėmesį į svarbius dalykus, pvz., Duomenų bazės užklausą.

Vertikalės, renginių autobusas ir kitos gagos

„Vert.x“ taip pat siūlo lygiagretumo modelį, vadinamą vertikale, panašų į „Actor“ sistemą. (Jei norite sužinoti daugiau, pereikite prie mano „Akka Actor“ vadovo.) „Verticle“ izoliuoja savo būseną ir elgesį, kad būtų sukurta saugi aplinka. Vienintelis būdas su juo bendrauti yra per renginių autobusą.

Tačiau „Vert.x“ įvykių magistralė reikalauja, kad jos pranešimai būtų „String“ arba „JSON“. Dėl to sunku perduoti savavališkus ne POJO objektus. Didelio našumo sistemoje JSON konversija yra nepageidautina, nes tai reikalauja tam tikrų skaičiavimo išlaidų. Jei kuriate IO programas, jums gali būti geriau nenaudoti nei vertikalės, nei įvykių magistralės, nes tokioms programoms mažai reikia vietos valstybės.

Darbas su kai kuriais „Vert.x“ komponentais taip pat gali būti gana sudėtingas. Galite pastebėti dokumentų trūkumą, netikėtą elgesį ir net neveikimą. „Vert.x“ gali būti kenčia nuo savo ambicijų, nes norint sukurti naujus komponentus reikėtų perkelti daugeliu kalbų. Tai sunkus užsiėmimas. Dėl šios priežasties būtų geriausia laikytis pagrindo.

Jei kuriate viešąją API, tada turėtų pakakti „vertx-core“. Jei tai yra žiniatinklio programa, galite pridėti „vertx-web“, kuris teikia http parametrų valdymą ir JWT / sesijos autentifikavimą. Šiaip ar taip, dominavo etalonai. Kai kuriuose „vertx-web“ bandymuose šiek tiek sumažėja našumas, tačiau, atrodo, kad tai kilo dėl optimizavimo, jis gali būti pašalintas vėlesniuose leidimuose.