Biztos vagyok benne, hogy a cím egészséges reakciót váltott ki - „már megint kezdődik…” De kérem, engedje, hogy 5-10 percig birtokba vegyem a figyelmét, és megpróbálom nem csalódást okozni az elvárásaiban.
A cikk felépítése a következőképpen alakul: egy sztereotíp állítás kerül bemutatásra, és feltárul a sztereotípus kialakulásának „természete”. Remélem, ez lehetővé teszi, hogy új szögből tekintsünk a projektjeik adatcsere paradigmarendszerére.
Annak érdekében, hogy világos legyen, mi is az RPC, a szabványt javaslom figyelembe venni. . A REST-nek nincs világossága. És nem is kell, hogy legyen. Minden, amit a REST-ről tudni érdemes - nem megkülönböztethető a .
Az RPC-lekérések gyorsabbak és hatékonyabbak, mert lehetővé teszik a batch-kérések végrehajtását.
Arról van szó, hogy az RPC-ben egy kérés keretében több eljárás azonnali meghívására is lehetőség van. Például egy felhasználó létrehozása, az avatár hozzáadása, és ugyanabban a kérésben feliratkozás bizonyos témákra. Csak egy kérés, de mennyi haszon!
Valóban, ha csak egy backend node-ja van, a batch-kérés gyorsabbnak tűnik. Mert három REST kérés háromszor több erőforrást igényel egy node-tól a kapcsolatok létrehozásához.
Vegye figyelembe, hogy a REST esetében az első kérésnek vissza kell adnia a felhasználó azonosítóját a további kérések végrehajtásához. Ez is negatívan befolyásolja az összesítettet.
De az ilyen infrastruktúrák legfeljebb in-house megoldásokban és Enterprise szinten találhatók. Legrosszabb esetben kis WEB projekteknél. De a teljes körű WEB megoldásokat, főleg amelyeket HighLoad-nak neveznek, nem így kell felépíteni. Infrastruktúrájuknak meg kell felelnie a magas rendelkezésre állási és terhelési kritériumoknak. És a helyzet megváltozik.
A zölddel jelölték az infrastruktúra aktivitásának csatornáit ugyanazon forgatókönyv mellett. Figyelje meg, hogy most hogyan viselkedik az RPC. A kérés csak egy lápon használja az infrastruktúrát a terheléselosztótól a backendig. Míg a REST még mindig hátrányban van az első kéréskor, de utána behozza a lemaradást az egész infrastruktúra kihasználásával.
Elég, ha a forgatókönyvbe nem két, hanem mondjuk öt vagy tíz gazdagító kérést írunk… és a kérdésre, hogy „ki nyer most?”, a válasz nem nyilvánvaló.
Nézzük meg a problémát egy szélesebb perspektívából. A diagramban látható, hogyan használják az infrastruktúra csatornáit, de az infrastruktúra nem csak a csatornákból áll. A nagy forgalmú infrastruktúra fontos része a cache. Most pedig nézzük meg, hogy lehet-e valamilyen felhasználói artefaktumot előállítani. Többször. Mondjuk 32-szer.
Nézd meg, mennyire "megnövekedett" az infrastruktúra az RPC-nél, hogy megfeleljen a magas terhelési követelményeknek. Az a tény, hogy a REST kihasználja a HTTP protokoll teljes erejét, ellentétben az RPC-vel. A bemutatott diagramon ez az erő a kérési módszeren keresztül valósul meg — GET.
A HTTP módszereknek, egyebek mellett, van cache-elési stratégiájuk is. Ezen információkat a dokumentációban találhatod a . Az RPC POST kéréseket használ, amelyek nem számítanak idempotensnek, vagyis a POST kérések többszöri megismétlése különböző eredményeket adhat (például minden egyes hozzászólás elküldése után egy újabb példány jelenik meg a hozzászólásból) ().
Ezért az RPC nem képes hatékonyan kihasználni az infrastruktúra cache-eit. Ez oda vezet, hogy szoftveres cache-eket kell "behozni". A diagramon ezen szerepet a Redis tölti be. A szoftveres cache viszont további kód réteget és jelentős változtatásokat igényel az architektúrában a fejlesztőtől.
Most számoljuk meg, hány kérést "generált" a REST és az RPC a vizsgált infrastruktúrában?
Kérések
Bejövő
a backendhez
az adatbázishoz
a szoftveres cache-hez (Redis)
ÖSSZESEN
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] legjobb esetben (ha a helyi cache-t használják) 1 kérés (egy!), legrosszabb esetben 32 bejövő kérés.
Az első diagramhoz képest a különbség szembetűnő. Most már világossá válik a REST előnye. De javaslom, ne álljunk meg itt. A fejlett infrastruktúra magában foglalja a CDN-t is. Gyakran ő oldja meg a DDoS és DoS támadások elleni védekezést is. Nézzük meg:
Itt az RPC számára minden borongósan alakul. Az RPC egyszerűen képtelen a CDN teheráthelyezésének delegálására. Csak a támadások elleni rendszerekben lehet bízni.
Lehet-e ezzel befejezni? És megint nem. A HTTP metódusoknak, ahogy már említettük, van egyfajta "varázsuk". És nem véletlen, hogy a GET metódus a legszélesebb körben használt az Interneten. Vegye figyelembe, hogy ez a módszer képes az előírt tartalom egy részéhez hozzáférni, képes feltételeket állítani, amelyeket az infrastruktúra elemei értelmezhetnek, még azelőtt, hogy átadják az irányítást a kódjának, stb. Mindez lehetővé teszi rugalmas, kezelhető infrastruktúrák létrehozását, amelyek képesek igazán nagy kérések áramlását feldolgozni. RPC esetén ez a módszer... figyelmen kívül marad.
De miért annyira tartós a mítosz arról, hogy a batch kérések (RPC) gyorsabbak? Szerintem az a legtöbb projekt egyszerűen nem éri el azt a fejlettségi szintet, ahol a REST meg tudja mutatni az erejét. Sőt, a kisebb projektek esetében hajlamosabb arra, hogy megmutassa a gyengeségeit.
A REST vagy RPC választása nem egyéni emberi döntés a projektben. Ennek a választásnak meg kell felelnie a projekt követelményeinek. Ha a projekt ki tudja hozni a REST-ből mindazt, amit valójában tud, és ez valóban szükséges, akkor a REST remek választás lesz.
De ha ahhoz, hogy élvezhessük a REST előnyeit, devopsokat kellene felvenni a projektbe az infrastruktúra gyors méretezéséhez, adminokat az infrastruktúra kezelésére, architectet a webszolgáltatás összes rétegének megtervezésére... miközben a projekt naponta három csomag margarint ad el... akkor megállnék az RPC-nél, mert ez a protokoll utilitaristább. Nem igényel mély ismereteket a cache kezeléséről és az infrastruktúra működéséről, és a fejlesztőt a szükséges eljárások egyszerű és érthető hívásaira összpontosítja. Az üzlet elégedett lesz.
Az RPC kérések megbízhatóbbak, mert képesek batch kéréseket végrehajtani egy tranzakción belül.
Ez az RPC tulajdonság kétségtelen előny, mivel könnyen fenntartja az adatbázist konzisztens állapotban. A REST viszont bonyolultabb. A kérések nem következetesen érkeznek a backend különböző node-jaira.
Ez a REST "hátrány" a fentemlített előnyének a visszája — a képesség, hogy hatékonyan kihasználja az infrastruktúra összes erőforrását. Ha az infrastruktúra rosszul van megtervezve, és különösen, ha a projekt architektúrája és az adatbázis megtervezése is gyenge, az valóban nagy fájdalmat okozhat.
De vajon annyira megbízhatók a batch-kérések, mint ahogy tűnnek? Nézzük meg az esetet: létrehozunk egy felhasználót, gazdagítjuk a profilját valamilyen leírással, és SMS-t küldünk neki egy titkos kóddal a regisztráció befejezéséhez. Azaz három hívását végezzük el egy batch-kérésben.
Tekintsük át a diagramot. Ezen az infrastruktúra a magas rendelkezésre állás elemeivel van bemutatva. Két független kommunikációs csatorna létezik az SMS-átjárókhoz. De... mi történik? Az SMS küldésekor 503-as hiba lép fel — a szolgáltatás ideiglenesen nem elérhető. Mivel az SMS küldése egy batch-kérésben van csomagolva, az egész kérésnek vissza kell vonódnia. Az adatbázisban végzett műveletek érvénytelenítve lesznek. Az ügyfél hibát kap.
A következő próbálkozás — lottózás. Vagy a kérés ismét ugyanarra a node-ra kerül és újra hibát ad, vagy szerencsénk lesz és végrehajtódik. De a legfontosabb, hogy legalább egyszer már a mi infrastruktúránk feleslegesen dolgozott. Volt terhelés, de haszon nincs.
Jó, képzeljük el, hogy megfeszítettük magunkat (!) és kigondoltunk egy lehetőséget, hogy a kérés sikeresen végrehajtható részben. A maradékot újra megpróbáljuk végrehajtani egy bizonyos idő elteltével (Melyik? A frontend dönt?). De a lottózás megmaradt. Az SMS küldési kérés 50/50 eséllyel újra megbukik.
Egyetértesz, hogy az ügyfél oldaláról a szolgáltatás nem tűnik olyan megbízhatónak, mint szeretnénk... mi a helyzet a REST-tel?
A REST ismét a HTTP „varázsát” használja, de most már a válaszkódokkal. 503-as hiba esetén az SMS-átjárón a backend ezt a hibát továbbítja a terheléskiegyenlítőnek. A terheléskiegyenlítő, miután megkapta ezt a hibát anélkül, hogy megszakítaná az ügyféllel való kapcsolatot, átirányítja a kérést egy másik node-ra, amely sikeresen végrehajtja a kérést. Azaz az ügyfél megkapja a várt eredményt, és az infrastruktúra megerősíti a „magas rendelkezésre állás” címét. A felhasználó boldog.
És ez még nem minden. A terheléskiegyenlítő nemcsak egy 503-as válaszkódot kapott. Ezt a kódot a válaszban a szabvány szerint kívánatos kiegészíteni egy „Retry-After” fejlécet. Ez a fejléc jelzi a terheléskiegyenlítőnek, hogy ebben az irányban ne zaklassa ezt a node-ot a megadott időn belül. Így a következő SMS küldési kérések közvetlenül olyan node-ra kerülnek, ahol nincsenek problémák az SMS-átjáróval.
Ahogy látjuk, a JSON-RPC megbízhatósága túlértékelt. Valóban, könnyebb konszisztenciát biztosítani az adatbázisban. De ebben az esetben a rendszer megbízhatósága az egészben szenved.
A kimenetel nagymértékben hasonló a korábbihoz. Amikor az infrastruktúra egyszerű, a JSON-RPC nyilvánvalóan előny. Ha a projekt magas rendelkezésre állást és nagy terhelést feltételez, a REST helyesebb megoldásnak tűnik, bár bonyolultabb.
A REST belépési küszöbe alacsonyabb.
Szerintem a fentebb bemutatott elemzés, amely megdönti a RPC-val kapcsolatos megszokott sztereotípiákat, világosan megmutatta, hogy a REST belépési küszöbe kétségtelenül magasabb, mint a RPC-é. Ennek oka a HTTP működésének mély megértésének szükségessége, valamint a meglévő infrastrukturális elemekkel kapcsolatos elegendő tudás, amelyeket alkalmazni és szükség esetén felhasználni lehet a webprojektekben.
De miért gondolják sokan, hogy a REST egyszerűbb lesz? Személyes véleményem szerint ez a látszólagos egyszerűség magából a REST-maniöverekből ered. Vagyis a REST nem protokoll, hanem koncepció… a REST-nek nincs szabványa, vannak bizonyos ajánlások… a REST nem nehezebb, mint a HTTP. A látszólagos szabadság és anarchia vonzza a "szabad művészeket".
Kétségtelen, hogy a REST nem nehezebb, mint a HTTP. De magában a HTTP-ban egy jól megtervezett protokollról van szó, amely évtizedek alatt bizonyította életképességét. Ha nincs mély megértés a HTTP-ról, akkor a REST-ről sem lehet ítélkezni.
A RPC-ról pedig lehet. Elég csak elővenni a specifikációját. Szóval szüksége van egy ? Или все же хитрый REST? Решать вам.
Őszintén remélem, hogy nem pazaroltam el az idejét.
Forrás: habr.com
