Som si istý, že nadpis vyvolal zdravú reakciu – „no, už to zase začalo...“ Ale dovoľte mi na 5-10 minút upútať vašu pozornosť a pokúsim sa nesklamať vaše očakávania.
Štruktúra článku bude nasledovná: vezme sa stereotypné vyhlásenie a odhalí sa „povaha“ vzniku tohto stereotypu. Dúfam, že vám to umožní pozrieť sa na výber paradigmy výmeny údajov vo vašich projektoch z nového uhla.
Aby bolo jasné, čo je RPC, navrhujem zvážiť štandard . S REST nie je žiadna jasnosť. A to by nemalo byť. Všetko, čo potrebujete vedieť o REST - je na nerozoznanie .
Požiadavky RPC sú rýchlejšie a efektívnejšie, pretože vám umožňujú vytvárať dávkové požiadavky.
Ide o to, že v RPC môžete v jednej požiadavke volať niekoľko procedúr naraz. Napríklad vytvorte používateľa, pridajte k nemu avatara a v rovnakej požiadavke ho prihláste na odber niektorých tém. Len jedna žiadosť a koľko výhod!
V skutočnosti, ak máte iba jeden backendový uzol, bude to vyzerať rýchlejšie s dávkovou požiadavkou. Pretože tri požiadavky REST budú vyžadovať trikrát viac zdrojov z jedného uzla na vytvorenie spojenia.
Všimnite si, že prvá požiadavka v prípade REST musí vrátiť ID užívateľa, aby bolo možné vykonať ďalšie požiadavky. Čo negatívne ovplyvňuje aj celkový výsledok.
Takéto infraštruktúry však možno nájsť iba v interných riešeniach a podnikoch. Ako posledná možnosť v malých WEB projektoch. Ale plnohodnotné WEB riešenia a dokonca ani tie s názvom HighLoad sa neoplatí stavať. Ich infraštruktúra musí spĺňať kritériá vysokej dostupnosti a zaťaženia. A obraz sa mení.
Kanály aktivity infraštruktúry v rámci rovnakého scenára sú označené zelenou farbou. Všimnite si, ako sa teraz správa RPC. Požiadavka využíva infraštruktúru len na jednej vetve od balancera po backend. Zatiaľ čo REST stále stráca pri prvej požiadavke, doháňa stratený čas pomocou celej infraštruktúry.
Do scenára stačí zadať nie dve žiadosti o obohatenie, ale povedzme päť alebo desať... a odpoveď na otázku „kto teraz vyhrá?“ sa stáva nejasným.
Navrhujem, aby sme sa na problém pozreli ešte širšie. Diagram ukazuje, ako sa používajú kanály infraštruktúry, ale infraštruktúra nie je obmedzená na kanály. Dôležitou súčasťou vysoko zaťaženej infraštruktúry sú vyrovnávacie pamäte. Poďme teraz získať nejaký druh používateľského artefaktu. Opakovane. Povedzme 32-krát.
Pozrite sa, ako sa infraštruktúra RPC výrazne zlepšila, aby splnila požiadavky vysokého zaťaženia. Ide o to, že REST využíva plný výkon protokolu HTTP, na rozdiel od RPC. Vo vyššie uvedenom diagrame je tento výkon realizovaný prostredníctvom metódy požiadavky - GET.
Metódy HTTP majú okrem iného stratégie ukladania do vyrovnávacej pamäte. Nájdete ich v dokumentácii na adrese . Pre RPC sa používajú požiadavky POST, ktoré sa nepovažujú za idempotentné, to znamená, že opakované opakovania tých istých požiadaviek POST môžu vrátiť rôzne výsledky (napríklad po odoslaní každého komentára sa objaví ďalšia kópia tohto komentára) ().
V dôsledku toho RPC nedokáže efektívne využívať vyrovnávacie pamäte infraštruktúry. To vedie k potrebe „importovať“ vyrovnávaciu pamäť softvéru. Diagram ukazuje Redis v tejto úlohe. Softvérová vyrovnávacia pamäť zase vyžaduje, aby vývojár pridal ďalšiu vrstvu kódu a viditeľné zmeny v architektúre.
Poďme teraz spočítať, koľko požiadaviek REST a RPC „zrodili“ v posudzovanej infraštruktúre?
žiadosti
Doručená pošta
na backend
do DBMS
do mäkkej vyrovnávacej pamäte (Redis)
CELKOM
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
V porovnaní s prvou schémou je rozdiel markantný. Teraz je výhoda REST-u jasná. Ale navrhujem nezastavovať sa tam. Vybudovaná infraštruktúra zahŕňa CDN. Často tiež rieši problém boja proti DDoS a DoS útokom. Dostaneme:
To je miesto, kde sa veci pre RPC naozaj zhoršujú. RPC jednoducho nedokáže delegovať pracovné zaťaženie na CDN. Môžeme sa spoliehať len na systémy, ktoré dokážu čeliť útokom.
Dá sa tu skončiť? A opäť nie. Metódy HTTP, ako je uvedené vyššie, majú svoje vlastné „kúzlo“. A nie nadarmo je metóda GET na internete široko používaná. Všimnite si, že táto metóda je schopná pristupovať k časti obsahu, je schopná nastaviť podmienky, ktoré môžu prvky infraštruktúry interpretovať pred prenosom kontroly do vášho kódu atď. To všetko vám umožňuje vytvárať flexibilné, spravovateľné infraštruktúry, ktoré dokážu spracovať skutočne veľké toky požiadaviek. Ale v RPC sa táto metóda... ignoruje.
Prečo je teda mýtus, že dávkové požiadavky (RPC) sú rýchlejšie, taký trvalý? Osobne sa mi zdá, že väčšina projektov jednoducho nedosahuje úroveň rozvoja, kde je REST schopný ukázať svoju silu. Navyše v malých projektoch ochotnejšie ukazuje svoje slabé stránky.
Voľba REST alebo RPC nie je dobrovoľnou voľbou jednotlivca v projekte. Táto voľba musí spĺňať požiadavky projektu. Ak projekt dokáže z RESTu vyžmýkať všetko, čo skutočne môže, a skutočne to potrebuje, potom bude REST vynikajúcou voľbou.
Ak však na získanie všetkých výhod REST potrebujete na projekt najať devops špecialistov na rýchle škálovanie infraštruktúry, administrátorov na správu infraštruktúry, architekta, ktorý navrhne všetky vrstvy WEB služby... a projekt , zároveň predáva tri balenia margarínu denne... Zostal by som pri RPC, pretože... tento protokol je viac utilitárny. Nebude si to vyžadovať hlboké znalosti o tom, ako fungujú cache a infraštruktúra, ale zameria vývojára na jednoduché a zrozumiteľné volania procedúr, ktoré potrebuje. Obchod bude šťastný.
Požiadavky RPC sú spoľahlivejšie, pretože môžu vykonávať dávkové požiadavky v rámci jednej transakcie
Táto vlastnosť RPC je jednoznačnou výhodou, pretože Je ľahké udržiavať databázu konzistentnú. Ale s RESTom je to čoraz komplikovanejšie. Požiadavky môžu do rôznych koncových uzlov doraziť nekonzistentne.
Táto „nevýhoda“ REST je odvrátenou stranou jeho vyššie opísanej výhody – schopnosti efektívne využívať všetky zdroje infraštruktúry. Ak je zle navrhnutá infraštruktúra a o to viac, ak je zle navrhnutá najmä architektúra projektu a databáza, tak je to naozaj veľká bolesť.
Sú však dávkové požiadavky také spoľahlivé, ako sa zdajú? Pozrime sa na prípad: vytvoríme používateľa, obohatíme jeho profil o nejaký popis a pošleme mu SMS s tajničkou na dokončenie registrácie. Tie. tri hovory v jednej hromadnej žiadosti.
Pozrime sa na diagram. Predstavuje infraštruktúru s prvkami vysokej dostupnosti. K dispozícii sú dva nezávislé komunikačné kanály s SMS bránami. Ale... čo vidíme? Pri odosielaní SMS sa objaví chyba 503 - služba je dočasne nedostupná. Pretože Odoslanie SMS je zabalené do dávkovej požiadavky, potom je potrebné celú požiadavku vrátiť späť. Akcie v DBMS sú zrušené. Klient dostane chybu.
Ďalším pokusom je lotéria. Buď požiadavka zasiahne ten istý uzol znova a znova vráti chybu, alebo budete mať šťastie a bude vykonaná. Ale hlavné je, že aspoň raz naša infraštruktúra už fungovala márne. Bol náklad, ale žiadny zisk.
Dobre, predstavme si, že sme sa namáhali (!) a premýšľali nad možnosťou, kedy by mohla byť požiadavka čiastočne úspešne dokončená. A zvyšok sa pokúsime po nejakom časovom intervale opäť doplniť (Ktorý? Rozhoduje predok?). Ale lotéria zostala rovnaká. Požiadavka na odoslanie SMS má 50/50 šancu, že znova zlyhá.
Súhlasíte, zo strany klienta sa služba nezdá taká spoľahlivá, ako by sme chceli... čo REST?
REST opäť využíva kúzlo HTTP, ale teraz s kódmi odozvy. Keď sa na SMS bráne vyskytne chyba 503, backend odošle túto chybu do balancéra. Balancer dostane túto chybu a bez prerušenia spojenia s klientom odošle požiadavku inému uzlu, ktorý požiadavku úspešne spracuje. Tie. klient dostane očakávaný výsledok a infraštruktúra potvrdí svoj vysoký titul „vysoko dostupné“. Používateľ je spokojný.
A to opäť nie je všetko. Balancer nedostal len kód odpovede 503. Pri odpovedi je podľa normy vhodné uviesť tento kód s hlavičkou „Retry-After“. Hlavička dáva vyvažovačovi jasne najavo, že tento uzol na tejto trase by nemal rušiť počas stanoveného času. A ďalšie požiadavky na odoslanie SMS budú odoslané priamo uzlu, ktorý nemá problémy s SMS bránou.
Ako vidíme, spoľahlivosť JSON-RPC je preceňovaná. V skutočnosti je jednoduchšie organizovať konzistenciu v databáze. Obetou však v tomto prípade bude spoľahlivosť systému ako celku.
Záver je do značnej miery podobný predchádzajúcemu. Keď je infraštruktúra jednoduchá, samozrejmosť JSON-RPC je určite plus. Ak projekt zahŕňa vysokú dostupnosť s vysokým zaťažením, REST vyzerá ako správnejšie, aj keď zložitejšie riešenie.
Vstupný prah do REST je nižší
Myslím si, že vyššie uvedená analýza, vyvracajúca zaužívané stereotypy o RPC, jasne ukázala, že prah pre vstup do REST je nepochybne vyšší ako do RPC. Je to spôsobené potrebou hlbokého pochopenia toho, ako HTTP funguje, ako aj potrebou mať dostatočné znalosti o existujúcich prvkoch infraštruktúry, ktoré môžu a mali by byť použité vo WEB projektoch.
Prečo si teda veľa ľudí myslí, že REST bude jednoduchší? Môj osobný názor je, že táto zdanlivá jednoduchosť pochádza z prejavov OSTATNÉHO. Tie. REST nie je protokol, ale koncept... REST nemá štandard, existujú nejaké usmernenia... REST nie je o nič komplikovanejší ako HTTP. Zdanlivá sloboda a anarchia priťahujú „slobodných umelcov“.
REST samozrejme nie je o nič zložitejší ako HTTP. Samotný HTTP je však dobre navrhnutý protokol, ktorý sa osvedčil v priebehu desaťročí. Ak neexistuje hlboké pochopenie samotného HTTP, potom REST nemožno posudzovať.
Ale o RPC - môžete. Stačí si vziať jeho špecifikáciu. Takže potrebujete ? Alebo je to stále ošemetný REST? Ty rozhodni.
Úprimne dúfam, že som nestratil váš čas.
Zdroj: hab.com