Esu tikras, kad antraštė sukėlė sveiką reakciją – „na, vėl prasidėjo...“ Bet leiskite patraukti jūsų dėmesį 5-10 minučių ir pasistengsiu nenuvilti jūsų lūkesčių.
Straipsnio struktūra bus tokia: imamasi stereotipinio teiginio ir atskleidžiama šio stereotipo atsiradimo „pobūdis“. Tikiuosi, kad tai leis jums nauju kampu pažvelgti į duomenų mainų paradigmos pasirinkimą jūsų projektuose.
Kad būtų aišku, kas yra RPC, siūlau apsvarstyti standartą . Su REST nėra aiškumo. Ir taip neturėtų būti. Viskas, ką reikia žinoti apie REST – tai niekuo neišsiskiria .
RPC užklausos yra greitesnės ir efektyvesnės, nes leidžia pateikti paketines užklausas.
Esmė ta, kad RPC vienu prašymu galite iškviesti kelias procedūras vienu metu. Pavyzdžiui, sukurkite vartotoją, pridėkite jam avatarą ir toje pačioje užklausoje užsiprenumeruokite kai kurias temas. Tik vienas prašymas, ir kiek naudos!
Iš tiesų, jei turite tik vieną užpakalinį mazgą, tai atrodys greičiau su paketine užklausa. Kadangi trims REST užklausoms užmegzti ryšius reikės tris kartus daugiau išteklių iš vieno mazgo.
Atminkite, kad pirmoji užklausa REST atveju turi grąžinti vartotojo ID, kad būtų galima pateikti vėlesnes užklausas. Tai taip pat neigiamai veikia bendrą rezultatą.
Tačiau tokią infrastruktūrą galima rasti tik vidiniuose sprendimuose ir įmonėje. Kraštutiniu atveju – mažuose WEB projektuose. Tačiau visaverčių WEB sprendimų ir net tų, kurie vadinami HighLoad, kurti neverta. Jų infrastruktūra turi atitikti didelio prieinamumo ir apkrovos kriterijus. Ir vaizdas keičiasi.
Infrastruktūros veiklos kanalai pagal tą patį scenarijų pažymėti žalia spalva. Atkreipkite dėmesį, kaip RPC elgiasi dabar. Užklausa naudoja infrastruktūrą tik vienoje atkarpoje nuo balansyro iki galinės dalies. Nors REST vis tiek pralaimi pirmoje užklausoje, ji kompensuoja prarastą laiką naudodama visą infrastruktūrą.
Užtenka į scenarijų įvesti ne du praturtėjimo prašymus, o, tarkime, penkis ar dešimt... ir atsakyti į klausimą „kas dabar laimės? tampa neaišku.
Siūlau į problemą pažvelgti dar plačiau. Diagramoje parodyta, kaip naudojami infrastruktūros kanalai, tačiau infrastruktūra neapsiriboja tik kanalais. Svarbi didelės apkrovos infrastruktūros dalis yra talpyklos. Dabar gaukime tam tikrą vartotojo artefaktą. Pakartotinai. Tarkime, 32 kartus.
Pažiūrėkite, kaip RPC infrastruktūra žymiai pagerėjo, kad atitiktų didelės apkrovos poreikius. Reikalas tas, kad REST naudoja visą HTTP protokolo galią, skirtingai nei RPC. Aukščiau pateiktoje diagramoje ši galia realizuojama naudojant užklausos metodą - GET.
HTTP metodai, be kita ko, turi talpyklos strategijas. Juos galite rasti dokumentacijoje adresu . RPC naudojamos POST užklausos, kurios nėra laikomos idempotentiškomis, tai yra, pasikartojant tų pačių POST užklausų rezultatai gali būti skirtingi (pavyzdžiui, po kiekvieno komentaro išsiuntimo atsiras kita šio komentaro kopija) ().
Todėl RPC negali efektyviai naudoti infrastruktūros talpyklų. Dėl to reikia „importuoti“ programinės įrangos talpyklas. Diagramoje pavaizduotas Redis šiame vaidmenyje. Programinės įrangos talpykla savo ruožtu reikalauja, kad kūrėjas pridėtų papildomą kodo sluoksnį ir pastebimus architektūros pakeitimus.
Dabar suskaičiuokime, kiek užklausų REST ir RPC „pagimdė“ nagrinėjamoje infrastruktūroje?
Paklausimai
Gautieji
į užnugarį
į DBVS
į minkštąją talpyklą („Redis“)
IŠ VISO
POILSIO
1 / 32 *
1
1
0
3 / 35
RSC
32
32
1
31
96
Palyginti su pirmąja schema, skirtumas yra ryškus. Dabar REST nauda aiškėja. Bet siūlau tuo nesustoti. Sukurta infrastruktūra apima CDN. Dažnai tai taip pat išsprendžia kovos su DDoS ir DoS atakomis problemą. Mes gauname:
Čia RPC reikalai tampa labai blogi. RPC tiesiog negali deleguoti darbo krūvio CDN. Galime pasikliauti tik sistemomis, kurios kovoja su atakomis.
Ar čia galima baigti? Ir vėl ne. HTTP metodai, kaip minėta aukščiau, turi savo „stebuklingumą“. Ir ne be reikalo GET metodas plačiai naudojamas internete. Atminkite, kad šis metodas gali pasiekti turinio dalį, gali nustatyti sąlygas, kurias infrastruktūros elementai gali interpretuoti prieš perduodant valdymą jūsų kodui ir pan. Visa tai leidžia sukurti lanksčią, valdomą infrastruktūrą, kuri gali apdoroti tikrai didelius užklausų srautus. Tačiau RPC šis metodas... yra ignoruojamas.
Taigi kodėl mitas, kad paketinės užklausos (RPC) yra greitesnės, yra toks nuolatinis? Man asmeniškai atrodo, kad dauguma projektų tiesiog nepasiekia tokio išsivystymo lygio, kad REST galėtų parodyti savo jėgą. Be to, mažuose projektuose jis labiau nori parodyti savo silpnybes.
REST arba RPC pasirinkimas nėra savanoriškas asmens pasirinkimas projekte. Šis pasirinkimas turi atitikti projekto reikalavimus. Jei projektas sugeba iš REST išspausti viską, ką iš tikrųjų gali, ir jam to tikrai reikia, REST bus puikus pasirinkimas.
Bet jei, norint gauti visus REST privalumus, projektui reikia samdyti devops specialistus, kurie greitai padidins infrastruktūrą, administratorius, kurie valdys infrastruktūrą, architektą, kuris suprojektuotų visus WEB paslaugos sluoksnius... ir projektą. , tuo pačiu parduoda tris pakuotes margarino per dieną... Aš pasilikčiau prie RPC, nes... šis protokolas yra labiau utilitarinis. Tai nereikės gilių žinių apie tai, kaip veikia talpyklos ir infrastruktūra, o sutelks kūrėją į paprastus ir suprantamus jam reikalingų procedūrų iškvietimus. Verslas bus laimingas.
RPC užklausos yra patikimesnės, nes jos gali vykdyti paketines užklausas per vieną operaciją
Ši RPC savybė yra neabejotinas pranašumas, nes Lengva išlaikyti duomenų bazės nuoseklumą. Tačiau su REST viskas darosi vis sudėtingiau. Užklausos gali gauti nenuosekliai į skirtingus galinius mazgus.
Šis REST „trūkumas“ yra atvirkštinė aukščiau aprašyto pranašumo pusė – galimybė efektyviai panaudoti visus infrastruktūros išteklius. Jei infrastruktūra yra blogai suprojektuota, o juo labiau, jei projekto architektūra ir ypač duomenų bazė yra prastai suprojektuota, tai tikrai yra didelis skausmas.
Tačiau ar paketinės užklausos yra tokios patikimos, kaip atrodo? Pažiūrėkime į atvejį: sukuriame vartotoją, praturtiname jo profilį kokiu nors aprašymu ir išsiunčiame jam SMS žinutę su paslaptimi, kad užbaigtume registraciją. Tie. trys skambučiai vienoje paketinėje užklausoje.
Pažiūrėkime į diagramą. Jame pristatoma infrastruktūra su aukšto prieinamumo elementais. Yra du nepriklausomi ryšio kanalai su SMS vartais. Bet... ką mes matome? Siunčiant SMS įvyksta klaida 503 – paslauga laikinai nepasiekiama. Nes SMS siuntimas supakuotas į paketinę užklausą, tada visa užklausa turi būti atšaukta. Veiksmai DBVS atšaukiami. Klientas gauna klaidą.
Kitas bandymas – loterija. Arba užklausa vėl pasieks tą patį mazgą ir vėl grąžins klaidą, arba jums pasiseks ir ji bus įvykdyta. Bet svarbiausia, kad bent kartą mūsų infrastruktūra jau dirbo veltui. Krūvis buvo, bet pelno nebuvo.
Gerai, įsivaizduokime, kad persitempėme (!) ir apgalvojome variantą, kada užklausa gali būti iš dalies sėkmingai įvykdyta. O likusią dalį vėl bandysime užbaigti po tam tikro laiko tarpo (kuris? Ar sprendžia frontas?). Tačiau loterija liko ta pati. Prašymas išsiųsti SMS turi 50/50 tikimybę, kad vėl nepavyks.
Sutikite, iš kliento pusės paslauga neatrodo tokia patikima, kaip norėtume... o kaip REST?
REST vėl naudoja HTTP magiją, bet dabar su atsakymo kodais. Kai SMS šliuze įvyksta klaida 503, užpakalinė programa perduoda šią klaidą balansuotojui. Balansuotojas gauna šią klaidą ir nenutraukdamas ryšio su klientu siunčia užklausą į kitą mazgą, kuris sėkmingai apdoroja užklausą. Tie. klientas gauna laukiamą rezultatą, o infrastruktūra patvirtina aukštą „labai prieinamos“ titulą. Vartotojas laimingas.
Ir vėl tai dar ne viskas. Balansuotojas gavo ne tik atsakymo kodą 503. Atsakant, pagal standartą, patartina šį kodą pateikti su antrašte „Retry-After“. Antraštė balansuotojui aiškiai parodo, kad šio maršruto mazgo tam tikrą laiką trikdyti neverta. O kitos užklausos siųsti SMS bus siunčiamos tiesiai į mazgą, kuris neturi problemų su SMS šliuzu.
Kaip matome, JSON-RPC patikimumas yra pervertintas. Iš tiesų, lengviau organizuoti duomenų bazės nuoseklumą. Tačiau auka šiuo atveju bus visos sistemos patikimumas.
Išvada iš esmės panaši į ankstesnę. Kai infrastruktūra paprasta, JSON-RPC akivaizdumas tikrai yra pliusas. Jei projektas susijęs su dideliu prieinamumu ir didele apkrova, REST atrodo kaip teisingesnis, nors ir sudėtingesnis sprendimas.
Įėjimo į REST slenkstis yra žemesnis
Manau, kad aukščiau pateikta analizė, griaunanti nusistovėjusius stereotipus apie RPC, aiškiai parodė, kad įstojimo į REST slenkstis neabejotinai yra aukštesnis nei į RPC. Taip yra dėl to, kad reikia giliai suprasti, kaip veikia HTTP, taip pat būtinybė turėti pakankamai žinių apie esamus infrastruktūros elementus, kurie gali ir turėtų būti naudojami WEB projektuose.
Tad kodėl daugelis mano, kad REST bus paprastesnis? Mano asmeninė nuomonė yra ta, kad šis akivaizdus paprastumas kyla iš REST pasireiškimų. Tie. REST yra ne protokolas, o sąvoka... REST neturi standarto, yra tam tikros gairės... REST nėra sudėtingesnis už HTTP. Tariama laisvė ir anarchija traukia „laisvuosius menininkus“.
Žinoma, REST nėra sudėtingesnis už HTTP. Tačiau pats HTTP yra gerai suprojektuotas protokolas, kuris įrodė savo vertę per dešimtmečius. Jei nėra gilaus supratimo apie patį HTTP, REST negalima vertinti.
Bet apie RPC – galite. Pakanka atsižvelgti į jo specifikaciją. Taigi ar reikia ? O gal vis dar sudėtingas REST? Tu nuspręsk.
Nuoširdžiai tikiuosi, kad nešvaisčiau jūsų laiko.
Šaltinis: www.habr.com