JSON-RPC? Kasutage nutikat REST-i.

Ma olen kindel, et pealkiri tekitas terve reaktsiooni – "oh mitte jälle...". Kuid lubage mul haarata teie tähelepanu 5-10 minutiks ning ma püüan mitte petta teie ootusi.

Artikli struktuur on järgmine: tuuakse välja stereotüüpne väide ja paljastatakse selle stereotüübi tekkimise "lood". Loodan, et see võimaldab vaadata oma projektide andmevahetusparadigmat uue nurga alt.

Selleks, et oleks selge, mis on RPC, soovitan vaadata standardit JSON-RPC 2.0. RESTi puhul ei ole selgust. Ja see ei pea olema. Kõik, mida RESTi kohta teada on, on see, et see on eristamatu HTTP.

RPC päringud on kiiremad ja tõhusamad, kuna nad võimaldavad teha batch-päringuid.

Küsimus on selles, et RPC-s saab ühes päringus teha mitme protseduuri kutse. Näiteks luua kasutaja, lisada talle avatar ja samas päringus tellida ta mõnele teemale. Ainult üks päring, kuid kui palju kasu!

Tõepoolest, kui teil on ainult üks backend'i sõlm, võib see tunduda kiirem batch-päringu korral. Kuna kolm REST päringut nõuavad ühest sõlmest ühenduse loomisel kolm korda rohkem ressurssi.

Pange tähele, et esimene päring RESTi puhul peab tagastama kasutaja identifikaatori järgmiste päringute täitmiseks. See mõjutab ka üleüldiselt negatiivselt tulemust.

Kuid selliseid infrastruktuure võib leida vaid, juhul, kui need on in-house lahendustes ja ettevõtetes. Äärmuslikel juhtudel väikestes veebiprojektides. Kuid täisväärtuslikke veebilahendusi, veelgi enam nimetatuna HighLoad, ei tohiks nii ehitada. Nende infrastruktuur peab vastama kõrge kättesaadavuse ja koormusnõuetele. Siis muutub olukord.

Roheline näitab infrastruktuuri aktiivsuskanaleid sama stsenaariumi puhul. Pange tähele, kuidas RPC nüüd käitub. Päring kasutab infrastruktuuri ainult ühe liini ulatuses tasakaalustajast backendini. Samas, kui REST ikka veel kaotab esimeses päringus, kuid jookseb mööda, kasutades kogu infrastruktuuri.

Piisab, kui stsenaariumi tuuakse mitte kaks rikastamis päringut, vaid näiteks viis või kümme… ja vastus küsimusele "kes nüüd võidab?" muutub ebaselgeks.

Pakun vaatama probleemi veelgi laiemalt. Skeemilt on näha, kuidas infrastruktuuri kanaleid kasutatakse, kuid infrastruktuur ei piirdu kanalitega. Oluline osa kõrgekoormuslikust infrastruktuurist on vahemälud. Vaatame nüüd, kuidas kasutaja artefaktide genereerimine välja näeb. Korrake seda mitu korda. Ütleme 32 korda.

Vaadake, kuidas on RPC infrastruktuur selgelt "paranenud", et tulla toime kõrge koormuse nõudmistega. Asi on selles, et REST kasutab kogu HTTP protokolli võimsust, erinevalt RPC-st. Antud skeemil on see võime realiseeritud päringu meetodi kaudu — GET.

HTTP meetoditel on lisaks muule ka vahemälustrateegiad. Nendega saab tutvuda dokumentatsioonis aadressil HTTP. RPCs kasutatakse POST päringuid, mis ei ole idempotentsed, st korduv samade POST päringute tegemine võib anda erinevaid tulemusi (näiteks iga kord, kui kommentaari saadetakse, tekib uus koopia sellest kommentaarist) (allikas).

Seega ei suuda RPC tõhusalt kasutada infrastruktuuri vahemälusid. See tähendab, et tuleb "tuua sisse" tarkvara vahemälud. Skeemil esindab neid Redis. Tarkvara vahemälu, omakorda, nõuab arendajalt täiendavat koodikihti ja olulisi muudatusi arhitektuuris.

Arvutame nüüd, kui palju päringuid on REST ja RPC eelkõige infrastruktuuris genereerinud?

Päringud
Sissetulevad
backendile
andmebaasile
tarkvahemälule (Redis)
KOKKU

REST
1/32*
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] parimal juhul (kui kohalikku vahemälus kasutatakse) 1 päring (ainult üks!), halvemal juhul 32 sisenevat päringut.

Esimese skeemiga võrreldes on erinevus silmatorkav. Nüüd on selge, et REST-il on eelised. Kuid ma pakun, et ei tasu sellele peatuda. Arenenud infrastruktuur hõlmab CDN-i. Sageli lahendab see ka DDoS ja DoS rünnakute vastased probleemid. Saame:

Siin muutuvad asjad RPC jaoks tõeliselt murettekitavaks. RPC ei suuda lihtsalt CDN koormuse haldamist delegeerida. Jääb loota vaid rünnakute vastu suunatud süsteemidele.

Kas sellel saab lõppeda? Ja jälle, ei. HTTP meetodid, nagu eelnevalt mainitud, omavad oma „maagiat“. Ja pole juhus, et GET meetod on Internetis kõige enam kasutatav. Pange tähele, et see meetod suudab pöörduda sisu osade poole, suudab seada tingimusi, mida infrastruktuurielemendid saavad tõlgendada veel enne, kui kontroll teie koodi üle antakse jne. Kõik see võimaldab luua painduvaid, hallatavaid infrastruktuure, mis suudavad tõeliselt suuri päringute vooge seedida. Ja RPC puhul jäetakse see meetod... tähelepanuta.

Nii et miks on müüt, et batch-päringud (RPC) on kiiremad, nii püha? Isiklikult tundub mulle, et enamik projekte ei jõua lihtsalt sellisele arengutasemele, et REST suudaks oma tõeliselt head külge näidata. Veelgi enam, väikestes projektides näitab see pigem oma nõrkusi.

REST või RPC valik ei ole ühe inimese isiklik valik projektis. See valik peab vastama projekti nõudmistele. Kui projekt suudab RESTist kõik välja pressida, mida ta tõeliselt suudab, ja see on tõeliselt vajalik, siis on REST suurepärane valik.

Aga kui RESTi kõigi eeliste saamiseks tuleb palgata projektis devOps'e infrastruktuuri operatiivseks skaleerimiseks, administraatoreid infrastruktuuri haldamiseks, arhitekte kõigi WEB teenuse kihtide projekteerimiseks... ja projekt toob samal ajal müüki kolm pakki margariini päevas... jääksin RPC juurde, kuna see protokoll on utilitaarselt sõbralikum. See ei nõua sügavat arusaama vahemäcache ja infrastruktuuri tööst, vaid suunab arendajat lihtsatele ja arusaadavatele vajalike protseduuride kutsetele. Äri on rahul.

RPC päringud on usaldusväärsemad, kuna nad suudavad läbi viia batch-päringud ühe tehingu raames.

See RPC omadus on kahtlemata pluss, kuna andmebaasi on lihtsam hoida järjepidevas seisundis. RESTiga on see keerulisem. Päringud võivad jõuda mitteseotud järjekorras erinevatele backend node'idele.

See RESTi „puudus“ on vastand eelpool mainitud eelistele — võime tõhusalt kasutada kogu infrastruktuuri ressursse. Kui infrastruktuur on halvasti projekteeritud, ja veelgi enam, kui projekti arhitektuur ja andmebaas on halvad, on see tõeliselt suur nuhtlus.

Aga kas batch-päringud on tõeliselt nii usaldusväärsed nagu nad paistavad? Uurime näidet: loome kasutaja, rikastame tema profiili millegi kirjeldusega ja saadame talle SMS-i registreerimise lõpetamiseks vajaliku saladusega. See tähendab, et teeme kolm kutset ühe batch-päringu raames.

Uurime skeemi. See näitab infrastruktuuri, kus on kõrge kättesaadavuse elemendid. Seal on kaks sõltumatut sidekanalit SMS-gateway’idega. Kuid... mida me näeme? SMS-i saatmisel ilmneb viga 503 - teenus on ajutiselt saadaval. Kuna SMS-i saatmine on pakitud batch-päringusse, peab kogu päring tagastama. Tegevused andmebaasis tühistatakse. Klient saab vea.

järgmine katse - loterii. Kas päring satub taas sama sõlme ja tagastab jälle vea, või läheb meil hästi ja see täidetakse. Kuid peamine on, et meie infrastruktuur on juba vähemalt korra tööle asunud asjatult. Koormus oli, kuid kasu pole.

Oleme nõus, et kujutame ette, et pingutasime (!) ja mõtlesime välja variandi, kuidas päringut võiks osaliselt edukalt täita. Ja ülejäänu püüame uuesti mõne aja pärast täita (Millisest ajast? Otsustab front?). Kuid loterii jäi endiseks. SMS-i saatmise päring ebaõnnestub tõenäosusega 50/50 uuesti.

Nõus, kliendi seisukohalt ei tundu teenus nii usaldusväärne kui tahaksime ... ent kuidas on REST-iga?

REST kasutab jälle HTTP "maagiat", kuid nüüd koos vastuskoodidega. Kui SMS-gateway'l ilmneb viga 503, edastab backend selle vea laadijale. Laadija, saades selle vea, ei katkesta ühendust kliendiga, vaid suunab päringu teise sõlme, mis täidab päringu edukalt. Seega saab klient oodatud tulemuse ja infrastruktuur kinnitab oma kõrget pealkirja "kõrge kättesaadavus". Kasutaja on rahul.

Ja see pole veel kõik. Laadija ei saanud lihtsalt vastuskoodi 503. Selle koodi puhul on soovitatav vastusele lisada pealkiri "Retry-After". Pealkiri annab teada laadijale, et ei tasu seda sõlme selle marsruudi kaudu teatud aja jooksul häirida. Järgmised päringud SMS-i saatmiseks suunatakse kohe sõlmele, kus ei esine probleeme SMS-gateway'ga.

Kuidas me näeme, on JSON-RPC usaldusväärsus üle hinnatud. Tõepoolest, andmebaasi konsistentsi korraldamine on lihtsam. Kuid nende juhtumite ohvriks langeb süsteemi usaldusväärsus tervikuna.

Väljund on suuresti sarnane eelnevale. Kui infrastruktuur on lihtne, on JSON-RPC ilmselgelt selle pluss. Kui projekt nõuab kõrget saadavust ja suurt koormust, näib REST olema õigem, ehkki ka keerulisem lahendus.

REST-i sisenemislävi on madalam.

Lugesin, et ülaltoodud analüüs, mis lükkab ümber kehtivad stereotüübid RPC kohta, näitab ilmekalt, et sisenemislävi REST-i on kindlasti kõrgem kui RPC-l. See tuleneb vajadusest sügavalt mõista HTTP toimimist ning omada piisavalt teadmisi olemasolevatest infrastruktuuri elementidest, mida saab ja tuleb rakendada veebiprojektides.

Kuid miks paljud arvavad, et REST on lihtsam? Isiklikult arvan, et see näiliselt lihtsus tuleneb REST-i manifestidest. Nimelt, REST ei ole protokoll, vaid kontseptsioon... REST-il ei ole standardit, on vaid mõned soovitused... REST ei ole keerulisem kui HTTP. Näiline vabadus ja anarhia meelitavad 'vabu kunstnikke'.

Ilmselgelt ei ole REST keerulisem kui HTTP. Kuid HTTP ise on hästi läbi mõeldud protokoll, mis on juba aastakümneid tõestanud oma tõhusust. Kui ei ole sügavat arusaamist HTTP-st, siis ei saa hinnata ka REST-i.

Aga RPC kohta saab küll. Piisab, kui võtta tema spetsifikatsioon. Kas teil on siis vaja karm JSON-RPC?? Или все же хитрый REST? Решать вам.

Loodan siiralt, et ma ei raisanud teie aega asjatult.

Allikas: habr.com