JSON-RPC? Dej si složitý ODPOČINEK

Jsem si jistý, že titulek vyvolal zdravou reakci – „no, už to zase začalo...“ Ale dovolte mi na 5-10 minut upoutat vaši pozornost a pokusím se nezklamat vaše očekávání.

Struktura článku bude následující: vezme se stereotypní tvrzení a odhalí se „povaha“ vzniku tohoto stereotypu. Doufám, že vám to umožní podívat se na výběr paradigmatu výměny dat ve vašich projektech z nového úhlu.

Aby bylo jasné, co je RPC, navrhuji zvážit standard JSON-RPC 2.0. S RESTem není jasno. A to by nemělo být. Vše, co potřebujete vědět o REST - je k nerozeznání HTTP.

Požadavky RPC jsou rychlejší a efektivnější, protože umožňují provádět dávkové požadavky.

Jde o to, že v RPC můžete v jednom požadavku volat více procedur najednou. Vytvořte například uživatele, přidejte k němu avatara a ve stejném požadavku jej přihlaste k odběru některých témat. Jen jedna žádost a jak velký přínos!

Pokud máte pouze jeden backendový uzel, bude se to zdát rychlejší s dávkovým požadavkem. Protože tři požadavky REST budou vyžadovat třikrát více prostředků z jednoho uzlu k navázání spojení.

Všimněte si, že první požadavek v případě REST musí vrátit ID uživatele, aby mohly být provedeny další požadavky. Což také negativně ovlivňuje celkový výsledek.

Ale takové infrastruktury lze nalézt pouze v interních řešeních a Enterprise. Jako poslední možnost v malých WEB projektech. Ale plnohodnotná WEB řešení, a dokonce ani ta s názvem HighLoad, nestojí za to stavět. Jejich infrastruktura musí splňovat kritéria vysoké dostupnosti a zatížení. A obraz se mění.

Kanály aktivit infrastruktury ve stejném scénáři jsou označeny zeleně. Všimněte si, jak se RPC chová nyní. Požadavek využívá infrastrukturu pouze na jedné noze od balanceru po backend. Zatímco REST stále ztrácí v prvním požadavku, dohání ztracený čas pomocí celé infrastruktury.

Stačí do scénáře zadat ne dvě žádosti o obohacení, ale řekněme pět nebo deset... a odpověď na otázku „kdo teď vyhraje?“ se stává nejasným.

Navrhuji podívat se na problém ještě zeširoka. Diagram ukazuje, jak se používají kanály infrastruktury, ale infrastruktura není omezena na kanály. Důležitou součástí vysoce zatěžované infrastruktury jsou mezipaměti. Pojďme nyní získat nějaký druh uživatelského artefaktu. Opakovaně. Řekněme 32krát.

Podívejte se, jak se infrastruktura RPC výrazně zlepšila, aby splnila požadavky vysoké zátěže. Jde o to, že REST využívá plný výkon protokolu HTTP, na rozdíl od RPC. Ve výše uvedeném diagramu je tento výkon realizován prostřednictvím metody požadavku - GET.

Metody HTTP mají mimo jiné strategie ukládání do mezipaměti. Najdete je v dokumentaci na adrese HTTP. Pro RPC se používají požadavky POST, které se nepovažují za idempotentní, to znamená, že opakované opakování stejných požadavků POST může vracet různé výsledky (například po odeslání každého komentáře se objeví další kopie tohoto komentáře) (zdroj).

V důsledku toho RPC není schopno efektivně využívat mezipaměti infrastruktury. To vede k nutnosti „importovat“ softwarové mezipaměti. Diagram ukazuje Redis v této roli. Softwarová mezipaměť zase vyžaduje, aby vývojář přidal další vrstvu kódu a znatelné změny v architektuře.

Pojďme nyní spočítat, kolik požadavků REST a RPC „zrodilo“ v uvažované infrastruktuře?

žádosti
Inbox
do backendu
do DBMS
do měkké mezipaměti (Redis)
CELKEM

REST
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] v nejlepším případě (pokud je použita lokální cache) 1 požadavek (jeden!), v nejhorším případě 32 příchozích požadavků.

Oproti prvnímu schématu je rozdíl markantní. Nyní je výhoda REST jasná. Ale doporučuji nezastavovat se tam. Vybudovaná infrastruktura zahrnuje CDN. Často také řeší problém boje proti DDoS a DoS útokům. Dostaneme:

Tady to s RPC začíná být opravdu špatné. RPC prostě není schopno delegovat pracovní zátěž na CDN. V boji proti útokům se můžeme spolehnout pouze na systémy.

Je možné zde skončit? A znovu, ne. Metody HTTP, jak je uvedeno výše, mají své vlastní „kouzlo“. A ne nadarmo je metoda GET široce používána na internetu. Všimněte si, že tato metoda je schopna přistupovat k části obsahu, je schopna nastavit podmínky, které mohou prvky infrastruktury interpretovat, než se řízení přenese do vašeho kódu a tak dále. To vše vám umožňuje vytvářet flexibilní, spravovatelné infrastruktury, které dokážou zpracovat opravdu velké toky požadavků. Ale v RPC je tato metoda... ignorována.

Proč je tedy mýtus, že dávkové požadavky (RPC) jsou rychlejší, tak trvalý? Osobně se mi zdá, že většina projektů prostě nedosahuje takové úrovně rozvoje, kde je REST schopen ukázat svou sílu. Navíc v malých projektech je ochotnější ukázat své slabiny.

Volba REST nebo RPC není dobrovolnou volbou jednotlivce v projektu. Tato volba musí splňovat požadavky projektu. Pokud projekt dokáže z RESTu vymáčknout vše, co skutečně může, a opravdu to potřebuje, pak bude REST vynikající volbou.

Ale pokud, abyste získali všechny výhody REST, potřebujete na projekt najmout specialisty na vývoj, aby rychle škálovali infrastrukturu, administrátory pro správu infrastruktury, architekta, který navrhne všechny vrstvy WEB služby... a projekt , zároveň prodává tři balení margarínu denně... Zůstal bych u RPC, protože... tento protokol je utilitárnější. Nebude vyžadovat hluboké znalosti o tom, jak fungují cache a infrastruktura, ale zaměří vývojáře na jednoduchá a srozumitelná volání procedur, které potřebuje. Obchod bude šťastný.

Požadavky RPC jsou spolehlivější, protože mohou provádět dávkové požadavky v rámci jedné transakce

Tato vlastnost RPC je jednoznačnou výhodou, protože Je snadné udržovat databázi konzistentní. Ale s RESTem je to čím dál složitější. Požadavky mohou do různých backendových uzlů dorazit nekonzistentně.

Tato „nevýhoda“ REST je odvrácenou stranou jeho výše popsané výhody – schopnosti efektivně využívat veškeré zdroje infrastruktury. Pokud je špatně navržená infrastruktura a tím spíše, pokud je špatně navržena architektura projektu a databáze, tak je to opravdu velká bolest.

Jsou ale dávkové požadavky tak spolehlivé, jak se zdají? Podívejme se na případ: vytvoříme uživatele, obohatíme jeho profil o nějaký popis a pošleme mu SMS s tajenkou pro dokončení registrace. Tito. tři volání v jednom dávkovém požadavku.

Podívejme se na schéma. Představuje infrastrukturu s prvky vysoké dostupnosti. Existují dva nezávislé komunikační kanály s SMS branami. Ale... co vidíme? Při odesílání SMS se objeví chyba 503 - služba je dočasně nedostupná. Protože Odeslání SMS je zabaleno do dávkového požadavku, poté je nutné celý požadavek vrátit zpět. Akce v DBMS jsou zrušeny. Klient obdrží chybu.

Dalším pokusem je loterie. Buď požadavek zasáhne stejný uzel znovu a znovu vrátí chybu, nebo budete mít štěstí a bude proveden. Ale hlavní je, že naše infrastruktura už minimálně jednou fungovala marně. Byl náklad, ale žádný zisk.

Dobře, představme si, že jsme se napjali (!) a promysleli možnost, kdy lze požadavek částečně úspěšně dokončit. A zbytek se pokusíme po nějakém časovém intervalu dokončit znovu (Který? Rozhoduje fronta?). Ale loterie zůstala stejná. Požadavek na odeslání SMS má šanci 50/50, že znovu selže.

Souhlasím, ze strany klienta se služba nezdá tak spolehlivá, jak bychom chtěli... co REST?

REST opět využívá kouzlo HTTP, ale nyní s kódy odpovědí. Když na bráně SMS dojde k chybě 503, backend tuto chybu odešle do balanceru. Balancér obdrží tuto chybu a bez přerušení spojení s klientem odešle požadavek jinému uzlu, který požadavek úspěšně zpracuje. Tito. klient obdrží očekávaný výsledek a infrastruktura potvrdí svůj vysoký titul „vysoce dostupná“. Uživatel je spokojený.

A to opět není vše. Balancér neobdržel pouze kód odezvy 503. Při odpovídání je podle normy vhodné tento kód opatřit hlavičkou „Retry-After“. Hlavička dává balanceru jasně najevo, že nemá cenu tento uzel na této trase po stanovenou dobu rušit. A další požadavky na odeslání SMS budou zasílány přímo na uzel, který nemá problémy s SMS bránou.

Jak vidíme, spolehlivost JSON-RPC je přeceňována. Ve skutečnosti je jednodušší organizovat konzistenci v databázi. Obětí však v tomto případě bude spolehlivost systému jako celku.

Závěr je do značné míry podobný předchozímu. Když je infrastruktura jednoduchá, je samozřejmostí JSON-RPC rozhodně plus. Pokud projekt zahrnuje vysokou dostupnost s vysokou zátěží, REST vypadá jako správnější, i když složitější řešení.

Vstupní práh do REST je nižší

Myslím, že výše uvedená analýza, vyvracející zavedené stereotypy o RPC, jasně ukázala, že práh pro vstup do REST je nepochybně vyšší než do RPC. To je způsobeno potřebou hlubokého porozumění tomu, jak HTTP funguje, a také potřebou mít dostatečné znalosti o existujících prvcích infrastruktury, které mohou a měly by být použity ve WEB projektech.

Proč si tedy mnoho lidí myslí, že REST bude jednodušší? Můj osobní názor je, že tato zdánlivá jednoduchost pochází z projevů REST. Tito. REST není protokol, ale koncept... REST nemá standard, existují nějaké pokyny... REST není o nic složitější než HTTP. Zdánlivá svoboda a anarchie přitahují „svobodné umělce“.

REST samozřejmě není o nic složitější než HTTP. Ale HTTP sám o sobě je dobře navržený protokol, který se po desetiletí osvědčil. Pokud neexistuje hluboké porozumění samotnému HTTP, pak nelze REST posuzovat.

Ale o RPC - můžete. Stačí si vzít jeho specifikaci. Takže potřebujete stupidní JSON-RPC? Nebo je to stále ošemetný REST? Vy rozhodnete.

Upřímně doufám, že jsem neztrácel váš čas.

Zdroj: www.habr.com