JSON-RPC? Získajte rafinovaný REST

Som si istý, že nadpis vyvolal zdravú reakciu – „už zase začína…“ No dajte mi 5-10 minút vášho času a pokúsim sa nesklamať očakávania.

Štruktúra článku bude takáto: vezmeme stereotypné tvrdenie a rozoberieme „povahu“ vzniku tohto stereotypu. Dúfam, že to umožní nahliadnuť na výber paradigmy výmeny údajov vo vašich projektoch z nového uhla.

Aby bolo jasné, čo je to RPC, navrhujem zvážiť štandard JSON-RPC 2.0. V prípade REST jasnosti nie je. A ani by nemala byť. Všetko, čo potrebujete vedieť o REST – je neodlišiteľný od HTTP.

RPC požiadavky sú rýchlejšie a efektívnejšie, pretože umožňujú vykonávať batch-požiadavky.

Ide o to, že v RPC môžete jednou požiadavkou vykonať volanie niekoľkých procedúr. Napríklad vytvoriť používateľa, pridať mu avatar a v tej istej požiadavke ho prihlásiť do niektorých tém. Iba jedna požiadavka, ale koľko prospechu!

Naozaj, ak máte len jednu uzla na backend, bude sa to zdať rýchlejšie pri batch-požiadavke. Pretože tri REST požiadavky si vyžadujú trikrát viac zdrojov z jedného uzla na nadväzovanie pripojení.

Všimnite si, že prvá požiadavka v prípade REST musí vrátiť identifikátor používateľa, aby sa mohli vykonať nasledujúce požiadavky. To tiež negatívne ovplyvňuje celkový výsledok.

Ale také infraštruktúry môžete nájsť len v in-house riešeniach a v rámci podnikov. V najhoršom prípade v malých WEB projektoch. Ale plnohodnotné WEB riešenia, zvlášť nazývané HighLoad, by sa takto budovať nemali. Ich infraštruktúra by mala spĺňať kritériá vysokej dostupnosti a zaťaženia. A situácia sa mení.

Zelenou sú označené kanály aktivity infraštruktúry pri rovnakom scenári. Všimnite si, ako sa teraz správa RPC. Požiadavka využíva infraštruktúru len po jednom ramene od vyrovnávača záťaže k backendu. Zatiaľ čo REST opäť prehráva v prvej požiadavke, ale dobieha stratu využívaním celej infraštruktúry.

Stačí do scenára zaviesť nie dva požiadavky na obohatenie, ale povedzme päť alebo desať… a odpoveď na otázku „kto teraz vyhráva?“ sa stáva nejasnou.

Navrhujem pozrieť sa na problém ešte širšie. Na schéme je vidno, ako sa využívajú kanály infraštruktúry, ale infraštruktúra sa neobmedzuje len na kanály. Dôležitou súčasťou vysokozaťaženej infraštruktúry sú cache. Poďme teraz získať nejaký artefakt používateľa. Niekoľkokrát. Povedzme 32-krát.

Pozrite, ako sa výrazne "zlepšila" infraštruktúra na RPC, aby mohla vyhovieť požiadavkám na vysokú záťaž. Všetko spočíva v tom, že REST využíva celú silu protokolu HTTP, na rozdiel od RPC. Na uvedenej schéme je táto sila implementovaná cez metódu požiadavky — GET.

HTTP metódy majú, okrem iného, aj stratégie cachovania. Spoznáte ich v dokumentácii na HTTP. Pre RPC sa používajú POST požiadavky, ktoré sa nepovažujú za idempotentné, to znamená, že opakované posielanie rovnakých POST požiadaviek môže vracať rôzne výsledky (napríklad, po každom odoslaní komentára sa objaví ďalšia kópia tohto komentára) (zdroj).

Preto RPC nie je schopné efektívne využívať infraštruktúrne cache. To vedie k tomu, že je potrebné "nahradiť" softvérové cache. Na schéme je touto rolou zobrazený Redis. Softvérová cache, na druhej strane, si vyžaduje od vývojára dodatočnú kódovú vrstvu a významné zmeny v architektúre.

Poďme teraz spočítať, koľko požiadaviek "zrodil" REST a RPC v posudzovanej infraštruktúre?

Dotazy
Prichádzajúce
k backendu
k databáze
k soft-cache (Redis)
CELKOM

REST
1/32*
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] v najlepšom prípade (ak sa používa lokálna cache) 1 požiadavka (jedna!), v najhoršom 32 prichádzajúcich požiadaviek.

V porovnaní s prvou schémou je rozdiel výrazný. Teraz je zrejmé, že REST má výhodu. Ale navrhujem nezastavovať sa na dosiahnutom. Rozvinutá infraštruktúra obsahuje CDN. Často tiež rieši otázku protiopatrení proti DDoS a DoS útokom. Získame:

Tu pre RPC všetko vyzerá naozaj tragicky. RPC jednoducho nie je schopné delegovať prácu s záťažou CDN. Zostáva len dúfať v systémy na ochranu proti útokom.

Môže to týmto skončiť? Opäť nie. Metódy HTTP, ako už bolo spomenuté, majú svoju „mágii“. A nie je bezdôvodné, že metóda GET je úplne najpoužívanejšia na internete. Všimnite si, že táto metóda dokáže pristupovať k časti obsahu, dokáže stanoviť podmienky, ktoré môžu interpretovať infrastrukturné prvky ešte pred odovzdaním riadenia vášmu kódu atď. To všetko umožňuje vytvárať flexibilné, spravovateľné infraštruktúry, schopné spracovávať naozaj veľké toky požiadaviek. A v RPC sa táto metóda... ignoruje.

Prečo teda pretrváva mýtus, že batch požiadavky (RPC) sú rýchlejšie? Osobne sa domnievam, že väčšina projektov jednoducho nedosiahne takú úroveň rozvoja, keď REST dokáže ukázať svoju silu. Navyše, v malých projektoch, ochotnejšie ukazuje svoju slabosť.

Výber medzi REST a RPC nie je vôľový výber jednotlivca v projekte. Tento výber by mal zodpovedať požiadavkám projektu. Ak je projekt schopný vyžmýkať z REST všetko, čo naozaj dokáže, a je to naozaj potrebné, tak REST bude skvelou voľbou.

Ale ak na to, aby ste získali všetky výhody REST, potrebujete na projekte najímať devops odborníkov na rýchle škálovanie infraštruktúry, administrátorov na správu infraštruktúry, architekta na navrhnutie všetkých vrstiev WEB služby... a projekt pritom predáva tri balíky margarínu denne... zastavil by som sa na RPC, pretože tento protokol je praktickejší. Nepotiahne si hlboké poznatky o fungovaní cache a infraštruktúry, ale sústredí vývojára na jednoduché a jasné volania potrebných procedúr. Biznis bude spokojný.

RPC požiadavky sú spoľahlivejšie, pretože môžu vykonávať batch požiadavky v rámci jednej transakcie.

Tento vlastnosť RPC je nepochybným plusom, pretože je ľahké udržiavať databázu v konzistentnom stave. A s REST to vychádza komplikovanejšie. Požiadavky môžu prichádzať neposteľne na rôzne nody backendu.

Tento „nedostatok“ REST je opakom jeho výhody popísanej vyššie — schopnosť efektívne využívať všetky zdroje infraštruktúry. Ak je infraštruktúra zle navrhnutá, a keďže architektúra projektu a databázy je navyše zle navrhnutá, môže to byť naozaj veľká bolesť.

Ale sú batch-žiadosťe naozaj také spoľahlivé, ako sa zdajú? Poďme si priblížiť prípad: vytvárame používateľa, obohacujeme jeho profil nejakým popisom a posielame mu SMS s tajomstvom na dokončenie registrácie. T.j. tri volania v jednej batch-žiadosťi.

Pozrime sa na schému. Na nej je zobrazená infraštruktúra s prvkami vysokej dostupnosti. Existujú dva nezávislé komunikačné kanály so SMS bránami. Ale… čo vidíme? Pri odosielaní SMS nastáva chyba 503 — služba je dočasne nedostupná. Keďže odosielanie SMS je zabalené v batch-žiadosťi, celý dopyt sa musí vrátiť. Akcie v DB sa zrušia. Klient dostáva chybu.

Nasledujúci pokus — lotéria. Buď dopyt znova skončí na tej istej nódě a opäť vráti chybu, alebo sa mu bude dariť a úspešne sa vykoná. Ale hlavné je, že aspoň raz už naša infraštruktúra neefektívne pracovala. Záťaž bola, ale zisk žiadny.

Dobre, poďme si predstaviť, že sme sa zamysleli (!) a vymysleli variant, keď dopyt môže byť úspešne vykonaný čiastočne. A zvyšok opäť skúšame vykonať po určitom časovom intervale (Aký? Rozhoduje frontend?). Ale lotéria zostáva. Dopyt na odoslanie SMS má pravdepodobnosť 50/50, že opäť zlyhá.

Súhlasíte, že z pohľadu klienta služba nevyzerá tak spoľahlivo, ako by si želala… a čo REST?

REST opäť využíva „mágiu“ HTTP, ale tentoraz s kódmi odpovedí. Pri výskyte chyby 503 na SMS bráne backend preposiela túto chybu vyvažovaču. Vyvažovač, prijímajúc túto chybovú správu, a nepretrhávajúc spojenie s klientom, presmeruje dopyt na inú nód, ktorá úspešne spracováva dopyt. T.j. klient dostáva očakávaný výsledok a infraštruktúra potvrdzuje svojho vysokého titulu „vysokodostupnej“. Používateľ je šťastný.

A znova, to nie je všetko. Vyvažovač nezískal len kód odpovede 503. Tento kód pri odpovedi by mal byť podľa štandardu obohatený o hlavičku „Retry-After“. Hlavička dáva vyvažovaču najavo, že by nemal obťažovať túto nód cez túto trasu po určitý čas. A ďalšie dopyty na odoslanie SMS budú ihneď smerované na nód, ktorý nemá problémy so SMS bránou.

Ako vidíme, spoľahlivosť JSON-RPC je nadhodnotená. Naozaj, ľahšie je organizovať konzistenciu v DB. Ale obetou sa v takom prípade stane spoľahlivosť systému ako celku.

Výstup je do značnej miery podobný predchádzajúcemu. Keď je infraštruktúra jednoduchá, jasnosť JSON-RPC je nepochybne jej výhodou. Ak projekt predpokladá vysokú dostupnosť s vysokou záťažou, REST sa javí ako správnejšie, hoci zložitejšie riešenie.

Trey pre REST je nižší

Myslím, že vyššie uvedená analýza, ktorá vyvracia ustálené stereotypy o RPC, jasne ukázala, že prahová hodnota pre REST je nepochybne vyššia ako pre RPC. To súvisí s potrebou hlbokého pochopenia fungovania HTTP, ako aj s potrebou mať dostatočné vedomosti o existujúcich infraštruktúrnych prvkoch, ktoré je možné a potrebné aplikovať vo webových projektoch.

Prečo si teda mnohí myslia, že REST bude jednoduchší? Osobne si myslím, že táto zdánlivá jednoduchosť vychádza z manifestov REST. T.j. REST nie je protokol, ale koncept… REST nemá štandard, existujú len niektoré odporúčania… REST nie je zložitejší ako HTTP. Zdánlivá sloboda a anarchia lákajú „voľných umelcov“.

Nepochybne, REST nie je zložitejší ako HTTP. Ale samotné HTTP je dobre premyslený protokol, ktorý sa osvedčil desaťročia. Ak nie je hlboké pochopenie samotného HTTP, tak ani o REST sa nedá spravodlivo súdiť.

O RPC — to je iné. Stačí sa pozrieť na jeho špecifikáciu. Tak potrebujete hlúpy JSON-RPC? Или все же хитрый REST? Решать вам.

Úprimne dúfam, že som vám nezotrhal čas.

Zdroj: habr.com