JSON-RPC? Kasutage nutikat REST-i

Olen kindel, et pealkiri kutsus esile terve reaktsiooni - "noh, nüüd on see jälle alanud...". Kuid lubage mul haarata teie tähelepanu 5-10 minutiks ja ma püüan mitte petta teie ootusi.

Artikli struktuur näeb välja järgmine: vaadatakse stereotüüpset väidet ja paljastatakse selle stereotüübi „loomuse“ taga. Loodetavasti võimaldab see teil vaadata andmevahetuse paradigma valikut oma projektides uue nurga alt.

Kuna on vajalik selgus selles, mis on RPC, soovitan arvesse võtta standardit JSON-RPC 2.0. REST ei paku selgust. Ja ei peakski. Kõik, mida vajate RESTist teadmiseks, on, et see ei eristu HTTP.

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

Ehkki RPC võimaldab ühes päringus korraga kutsuda mitut protseduuri. Näiteks luua kasutaja, lisada talle avatar ja samas päringus liituda mõne teema jälgimisega. Ainult üks päring, kuid kui palju kasu!

Tõepoolest, kui teil on ainult üks backend sõlm, tundub batch-päringu puhul see kiirem. Sest kolm REST-päringut vajavad ühelt sõlmelt kolme korda rohkem ressursse ühenduste loomiseks.

Pange tähele, et esimeses päringus REST-iga tuleb tagastada kasutaja ID, et edasisi päringuid teha. See mõjutab negatiivselt kogu tulemust.

Kuid selliseid infrastruktuure võib leida ainult siseringi lahendustes ja ettevõtete tasemel. Viimase abinõuna väikeses veebiprojektis. Kuid täielikke veebilahendusi, mis on nimetatud HighLoad, ei tohiks nii ehitada. Nende infrastruktuur peab vastama kõrge kättesaadavuse ja koormuse kriteeriumidele. Ning pilt muutub.

Roheliselt on märgitud infrastruktuuri aktiivsuse kanalid sama stsenaariumi puhul. Pange tähele, kuidas RPC nüüd käitub. Päring kasutab infrastruktuuri ainult ühe haru võrra koormaja ja backend vahel. Samal ajal, kui REST jätkuvalt kaotab esimeses päringus, korrigeerib see puuduvaid ressursse, kasutades kogu infrastruktuuri.

Piisab, kui stsenaariumisse tuua mitte kaks, vaid näiteks viis või kümme päringut… ja küsimusele „kes nüüd võidab?“ pole enam selget vastust.

Pakun vaadata probleemi veel laiemalt. Skeemil on näha, kuidas infrastruktuuri kanaleid kasutatakse, kuid infrastruktuur ei piirdu kanalitega. Kõrge koormusega infrastruktuuri oluline komponent on vahemäed. Saatkem nüüd mõni kasutaja artefakt. Korduvalt. Ütleme 32 korda.

Vaadake, kui oluliselt on infrastruktuur RPC puhul „paranenud“, et vastata kõrge koormuse nõudmistele. Asi on selles, et REST kasutab HTTP protokolli kõiki võimeid, erinevalt RPC-st. Antud skeemil realizeerub see võime päringu meetodi kaudu - GET.

HTTP meetoditel on lisaks ka vahemälu strateegiad. Nendega tutvuda saab dokumentatsioonis HTTP. RPC kasutab POST päringuid, mida ei peeta idempotentseteks, see tähendab, et sama POST päringu korduv saatmine võib anda erinevaid tulemusi (näiteks iga kommentaari saatmise järel ilmub uus koopia sellest kommentaarist) (allikas).

Seega ei suuda RPC tõhusalt kasutada infrastruktuuri vahemälu. See toob kaasa vajaduse „importida“ tarkvaralisi vahemälusid. Skeemil on selles rollis esindatud Redis. Tarkvaraline vahemälu nõuab omakorda arendajalt täiendavat koodikihti ja märkimisväärseid muudatusi arhitektuuris.

Arvutame nüüd, kui palju päringuid „toodab“ REST ja RPC käsitletavas infrastruktuuris?

Päringud
Sisse tulevad
backendile
andmebaasile
tarkvahemällu (Redis)
KOKKU

REST
1/32*
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] parima stsenaariumi korral (kui lokaalne vahemälu on kasutusel) 1 päring (ainult üks!), halvimal juhul 32 sissetulevat päringut.

Esimese skeemiga võrreldes on erinevus üüratu. Nüüd on selge, et REST võidab. Kuid pakun mitte peatuda saavutatud tulemuste juures. Arenenud infrastruktuur sisaldab ka CDN-i. Sageli lahendab see ka DDoS ja DoS rünnakute vastase võitluse küsimuse. Saame:

Siin muutub RPC olukord täiesti nutuseks. RPC lihtsalt ei suuda delegeerida CDN-i koormusega töötamist. Jäetakse lootma vaid rünnakute vastaseid süsteeme.

Kas on võimalik sellega lõpetada? Ja jälle, ei. HTTP meetoditel, nagu eelnevalt mainitud, on oma "maagia". Ja pole juhus, et GET meetodit kasutatakse Internetis ülimalt laialdaselt. Pange tähele, et see meetod suudab pöörduda osa sisu poole, suudab seada tingimusi, mida infrastruktuuri elemendid suudavad tõlgendada juba enne teie koodi täitmist jne. Kõik see võimaldab luua paindlikke, hallatavaid infrastruktuure, mis suudavad tõeliselt suuri päringute vooge töödelda. Ja RPC-s see meetod... ignoreeritakse.

Nii et miks on müüt batch-päringute (RPC) kiiretest olemisest nii püsiv? Isiklikult tundub mulle, et enamus projekte ei saavuta lihtsalt sellist arengutaset, kus REST suudab oma jõudlust näidata. Veelgi enam, väikestes projektides näitab see pigem oma nõrkusi.

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

Kuid kui REST-i kõigi eeliste saavutamiseks peate projekti palkama DevOps'e, et kiiresti infrastruktuuri skaleerida, administraatoreid infrastruktuuri haldamiseks, arhitekti kõigi WEB teenuse kihtide projekteerimiseks... ja projekt müüb samal ajal kolme pakki võid päevas... siis ma peatuksin RPC-l, kuna see protokoll on praktilisem. See ei nõua sügavaid teadmisi vahemäludest ja infrastruktuurist, vaid keskendub arendajatele lihtsatele ja arusaadavatele vajalike protseduuride kutsumisele. Äri on rahul.

RPC-päringud on usaldusväärsemad, sest need suudavad teostada batch-päringuid ühe tehingu raames.

See omadus on RPC puhul kahtlemata eelis, kuna andmebaasi hoiab kergemini kooskõlvses seisundis. Kuid RESTi puhul on see keerulisem. Päringud võivad järk-järgult saabuda erinevatele backend'il olevatele sõlmedele.

See "puudus" REST-is on vastand ülaltoodud eelisele - võime tõhusalt kasutada kõiki infrastruktuuri ressursse. Kui infrastruktuur on valesti projekteeritud, ja veelgi enam, kui ka projekti arhitektuur ja eriti andmebaas on valesti projekteeritud, siis see on tõeliselt suur valu.

Aga kas batch-päringud on tõeliselt nii usaldusväärsed kui tunduvad? Vaadakem juhtumit: loome kasutaja, rikastame tema profiili mingi kirjeldusega ja saadame talle SMS-i salajasega registreerimise lõpetamiseks. Ehk kolm kutsumist ühes batch-päringus.

Vaadakem skeemi. Sellel on infrastruktuur, kus on kõrge kättesaadavuse elemendid. On kaks iseseisvat ühendust SMS-i gateway'ga. Kuid... mida me näeme? SMS-i saatmisel ilmneb tõrge 503 - teenus on ajutiselt mitteaktiivne. Kuna SMS-i saatmine on pakitud batch-päringusse, siis kogu päring tuleb tagasi kerida. TEGUDETAKSE andmebaasis. Klient saab vea.

Järgmine katse on loterii. Kas päring jõuab uuesti samale sõlmele ja toob uuesti vea või on õnne ja see täidetakse. Peamine on see, et vähemalt korra on meie infrastruktuur juba asjatult vaeva näinud. Koormus oli, kuid kasu pole.

Hästi, kujutame ette, et pingutasime (!) ja mõtlesime välja variandi, kus päringut oleks võimalik osaliselt edukalt täita. Ja ülejäänud, proovime uuesti teatud aja pärast (Milline? Otsustab frontend?). Kuid loterii jäi. SMS-i saatmise päring ebaõnnestub tõenäosusega 50/50 uuesti.

Nõustuge, et kliendi silmis ei tundu teenus nii usaldusväärne kui sooviksime... aga kuidas on REST-iga?

REST kasutab jälle HTTP "maagiat", kuid nüüd koos vastuse koodidega. Kui SMS-i gateway'l tekib tõrge 503, edastab backend selle vea koormuse tasakaalustajale. Koormuse tasakaalustaja, saades selle vea ja katkestamata kliendiga ühendust, suunab päringu teisele sõlmele, mis täidab päringu edukalt. Ehk klient saab ootuspärase tulemuse, ja infrastruktuur tõestab end kõrge kättesaadavuse tasemel. Kasutaja on õnnelik.

Ja see pole veel kõik. Koormuse tasakaalustaja ei saanud lihtsalt vastuskoodi 503. Selle koodi vastuses on soovitatav varustada "Retry-After" päringuga. Pealkiri annab tasakaalustajale teada, et selle sõlmega seda marsruuti ei maksaks mingil määral koormata. Ja järgmised päringud SMS-i saatmiseks suunatakse kohe sõlmele, kus pole mingeid probleeme SMS-i gateway'ga.

Nagu näeme, on JSON-RPC usaldusväärsuse ülehindamine. Tõepoolest, andmebaasi kooskõlvsuse korraldamine on lihtsam. Kuid sel juhul on süsteemi usaldusväärsus tervikuna ohvriks.

Väljund on suuresti sarnane eelnevale. Kui infrastruktuur on lihtne, siis JSON-RPC ilmselt on see pluss. Kui projekt annab võimaluse kõrge kättesaadavuse ja kõrge koormuse jaoks, siis REST tundub kindlasti õigema, kuigi keerulisema lahendusena.

REST-i sisenemisbarjäär on madalam

Arvan, et eelnevalt toodud analüüs, mis lükkab ümber väljakujunenud stereotüüpe RPC kohta, näitas selgelt, et REST-i sisenemisbarjäär on kindlasti kõrgem kui RPC-l. See on seotud vajadusega sügavalt mõista HTTP-d ning piisava teadlikkusega olemasolevatest infrastruktuuri elementidest, mida saab ja tuleks rakendada veebi projektides.

Aga miks arvavad paljud, et REST on lihtsam? Minu isiklik arvamus on see, et see näiliselt lihtsus tuleneb REST-i manifestidest. Ning REST ei ole protokoll, vaid kontseptsioon… REST-il ei ole standardit, on vaid mõned soovitused… REST ei ole keerulisem kui HTTP. Näiliselt vaba ja anarhiline tõmbab “vabu kunstnikke”.

Ilmselgelt ei ole REST keerulisem kui HTTP. Kuid HTTP on hästi läbimõeldud protokoll, mis on tõestanud oma väärtust aastakümnete jooksul. Kui puudub sügav arusaam HTTP-st, siis ei saa rääkida ka REST-ist.

RPC-d aga saab. Piisab, kui võtta tema spetsifikatsioon. Kas see on vajalik? tavaline JSON-RPC? Или все же хитрый REST? Решать вам.

Loodan siiralt, et ma ei raisanud teie aega asjata.

Allikas: habr.com