Biztos vagyok benne, hogy a főcím egészséges reakciót váltott ki – „na, újra kezdődött...” De hadd ragadjam le a figyelmedet 5-10 percre, és igyekszem nem csalódni az elvárásaidban.
A cikk felépítése a következő lesz: egy sztereotip állítást veszünk, és feltárjuk e sztereotípia kialakulásának „természetét”. Remélem, ez lehetővé teszi, hogy új szemszögből tekintse meg projektjei során az adatcsere-paradigma megválasztását.
Annak érdekében, hogy egyértelmű legyen, mi az RPC, javaslom, hogy fontolja meg a szabványt . A REST-nél nincs egyértelműség. És nem szabadna. Minden, amit a REST-ről tudni kell – megkülönböztethetetlen tőle .
Az RPC-kérések gyorsabbak és hatékonyabbak, mert lehetővé teszik a kötegelt kérések elkészítését.
A lényeg az, hogy az RPC-ben egyszerre több eljárást is meghívhat egy kérelemben. Például hozzon létre egy felhasználót, adjon hozzá egy avatart, és ugyanabban a kérelemben iratkozzon fel neki bizonyos témákra. Csak egy kérés, és mennyi haszon!
Valójában, ha csak egy háttér-csomópontja van, akkor a kötegelt kéréssel gyorsabbnak tűnik. Mert három REST kérés háromszor több erőforrást igényel egy csomóponttól a kapcsolatok létrehozásához.
Vegye figyelembe, hogy REST esetén az első kérésnek vissza kell adnia a felhasználói azonosítót a további kérésekhez. Ami szintén negatívan befolyásolja az általános eredményt.
De ilyen infrastruktúrák csak a házon belüli megoldásokban és az Enterprise-ban találhatók meg. Legvégső esetben kis WEB projektekben. De a teljes értékű WEB megoldásokat, sőt a HighLoad nevűeket sem érdemes építeni. Infrastruktúrájuknak meg kell felelnie a magas rendelkezésre állás és terhelés kritériumainak. És a kép változik.
Az azonos forgatókönyv szerinti infrastruktúra-tevékenységi csatornák zölddel vannak jelölve. Figyelje meg, hogyan viselkedik most az RPC. A kérés csak egy lábon használja az infrastruktúrát a kiegyenlítőtől a háttérig. Míg a REST még mindig veszít az első kérésben, a teljes infrastruktúra használatával pótolja az elveszett időt.
Elég, ha nem két gazdagítási kérelmet ír be a forgatókönyvbe, hanem mondjuk ötöt vagy tízet... és a „ki nyer most?” kérdésre a válasz. homályossá válik.
Azt javaslom, hogy még szélesebb körben vizsgáljuk meg a problémát. A diagram bemutatja, hogyan használják az infrastruktúra csatornáit, de az infrastruktúra nem korlátozódik a csatornákra. A nagy terhelésű infrastruktúra fontos eleme a gyorsítótárak. Lássunk most valamilyen felhasználói műterméket. Többször. Mondjuk 32-szer.
Tekintse meg, hogyan fejlődött jelentősen az RPC infrastruktúra, hogy megfeleljen a nagy terhelés követelményeinek. A helyzet az, hogy a REST a HTTP protokoll teljes erejét használja, ellentétben az RPC-vel. A fenti diagramon ez a teljesítmény a kérési módszerrel - GET - valósul meg.
A HTTP metódusok többek között gyorsítótárazási stratégiákkal rendelkeznek. Megtalálható a dokumentációban a címen . Az RPC esetében POST kéréseket használnak, amelyek nem tekinthetők idempotensnek, azaz ugyanazon POST kérések ismétlődő ismétlése eltérő eredményeket adhat (például minden megjegyzés elküldése után ennek a megjegyzésnek egy másik példánya jelenik meg) ().
Következésképpen az RPC nem tudja hatékonyan használni az infrastruktúra gyorsítótárait. Ez szükségessé teszi a szoftver gyorsítótárak „importálását”. Az ábrán Redis látható ebben a szerepkörben. A szoftver-gyorsítótár viszont megköveteli a fejlesztőtől, hogy egy további kódréteget adjon hozzá, és észrevehető változtatásokat kell végrehajtania az architektúrában.
Most számoljuk meg, hány kérést „született” a REST és az RPC a vizsgált infrastruktúrában?
kérelmek
Inbox
háttérbe állítani
a DBMS-hez
lágy gyorsítótárba (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Az első sémához képest szembetűnő a különbség. Most már világossá válik a REST előnyei. De azt javaslom, hogy ne álljunk meg itt. A kifejlesztett infrastruktúra CDN-t tartalmaz. Gyakran megoldja a DDoS és DoS támadások elleni küzdelmet is. Kapunk:
Ez az, ahol a dolgok nagyon rosszak az RPC számára. Az RPC egyszerűen nem képes a munkaterhelést egy CDN-re delegálni. A támadások ellen csak rendszerekre támaszkodhatunk.
Lehet itt véget érni? És megint nem. A HTTP-metódusoknak, mint fentebb említettük, megvan a maguk „varázslata”. És nem ok nélkül használják a GET módszert széles körben az interneten. Vegye figyelembe, hogy ez a módszer képes hozzáférni egy tartalomhoz, beállíthat olyan feltételeket, amelyeket az infrastruktúra elemei értelmezhetnek, mielőtt a vezérlést átadják a kódnak, és így tovább. Mindez lehetővé teszi olyan rugalmas, kezelhető infrastruktúrák létrehozását, amelyek képesek igazán nagy kérések kezelésére. De az RPC-ben ezt a módszert... figyelmen kívül hagyják.
Tehát miért olyan tartós az a mítosz, hogy a kötegelt kérések (RPC) gyorsabbak? Személy szerint nekem úgy tűnik, hogy a legtöbb projekt egyszerűen nem éri el azt a fejlettségi szintet, hogy a REST meg tudja mutatni erejét. Sőt, kis projektekben szívesebben mutatja meg gyengeségeit.
A REST vagy az RPC választása nem a projektben részt vevő egyén akaratlagos választása. Ennek a választásnak meg kell felelnie a projekt követelményeinek. Ha egy projekt mindent ki tud kicsikarni a REST-ből, amit csak tud, és valóban szüksége van rá, akkor a REST kiváló választás lesz.
De ha a REST minden előnyének kihasználásához devops-szakembereket kell felvennie a projekthez az infrastruktúra gyors méretezéséhez, adminisztrátorokat az infrastruktúra kezeléséhez, egy építészt a WEB szolgáltatás minden rétegének megtervezéséhez... és a projekthez. , ugyanakkor napi három csomag margarint ad el... Én maradnék az RPC-nél, mert... ez a protokoll inkább haszonelvű. Ez nem igényel mély ismereteket a gyorsítótárak és az infrastruktúra működéséről, hanem a fejlesztőt a szükséges eljárások egyszerű és érthető hívásaira összpontosítja. Az üzlet boldog lesz.
Az RPC-kérelmek megbízhatóbbak, mivel egyetlen tranzakción belül képesek kötegelt kéréseket végrehajtani
Az RPC ezen tulajdonsága határozott előny, mert Könnyű az adatbázis konzisztenciáját tartani. De a REST-nél ez egyre bonyolultabbá válik. A kérések következetlenül érkezhetnek a különböző háttér-csomópontokhoz.
A REST ezen „hátránya” a fent leírt előnyének a másik oldala – az infrastruktúra összes erőforrásának hatékony felhasználása. Ha az infrastruktúra rosszul van megtervezve, és még inkább, ha a projekt architektúrája és különösen az adatbázis rosszul van megtervezve, akkor ez valóban nagy fájdalom.
De vajon a kötegelt kérések olyan megbízhatóak, mint amilyennek látszanak? Nézzünk egy esetet: létrehozunk egy felhasználót, gazdagítjuk a profilját némi leírással és SMS-t küldünk neki egy titokkal a regisztráció befejezéséhez. Azok. három hívás egy kötegelt kérésben.
Nézzük a diagramot. Magas rendelkezésre állású elemekkel rendelkező infrastruktúrát mutat be. Két független kommunikációs csatorna van SMS-átjárókkal. De... mit látunk? SMS küldésekor 503-as hiba történik - a szolgáltatás átmenetileg nem érhető el. Mert Az SMS küldés kötegelt kérésbe van csomagolva, majd a teljes kérést vissza kell görgetni. A DBMS-ben végrehajtott műveletek megszakadnak. Az ügyfél hibaüzenetet kap.
A következő próbálkozás a lottó. Vagy a kérés újra és újra ugyanazt a csomópontot éri el, vagy hibaüzenetet ad vissza, vagy szerencsés lesz, és végrehajtásra kerül. De a lényeg, hogy legalább egyszer már hiába működött az infrastruktúránk. Volt terhelés, de semmi nyereség.
Oké, képzeljük el, hogy megfeszítettük magunkat (!) és végiggondoltuk azt a lehetőséget, amikor a kérés részben sikeresen teljesíthető. A többit pedig egy időintervallum után újra megpróbáljuk teljesíteni (Melyik? A front dönti el?). De a lottó ugyanaz maradt. Az SMS küldésére vonatkozó kérés 50/50 esélye van annak, hogy ismét meghiúsul.
Egyetértek, az ügyfél oldaláról nézve 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 válaszkódokkal. Ha 503-as hiba lép fel az SMS-átjárón, a háttérrendszer továbbítja ezt a hibát a kiegyenlítőnek. Az egyensúlyozó megkapja ezt a hibát, és anélkül, hogy megszakítaná a kapcsolatot az ügyféllel, elküldi a kérést egy másik csomópontnak, amely sikeresen feldolgozza a kérést. Azok. az ügyfél megkapja a várt eredményt, az infrastruktúra pedig megerősíti magas szintű „nagyon hozzáférhető” címét. A felhasználó boldog.
És ez megint nem minden. A kiegyenlítő nem csak 503-as válaszkódot kapott. Válaszadáskor a szabvány szerint célszerű ezt a kódot a „Retry-After” fejléccel ellátni. A fejléc egyértelművé teszi a kiegyenlítő számára, hogy ezen az útvonalon ezt a csomópontot nem érdemes meghatározott ideig megzavarni. A következő SMS-küldési kéréseket pedig közvetlenül egy olyan csomópontra küldjük, amelynek nincs problémája az SMS-átjáróval.
Amint látjuk, a JSON-RPC megbízhatósága túlértékelt. Valójában könnyebb megszervezni a konzisztenciát az adatbázisban. De az áldozat ebben az esetben a rendszer egészének megbízhatósága lesz.
A következtetés nagyjából hasonló az előzőhöz. Ha az infrastruktúra egyszerű, a JSON-RPC nyilvánvalósága mindenképpen előny. Ha a projekt magas rendelkezésre állást és nagy terhelést foglal magában, a REST helyesebb, bár összetettebb megoldásnak tűnik.
A REST belépési küszöbe alacsonyabb
Úgy gondolom, hogy a fenti, az RPC-vel kapcsolatban kialakult sztereotípiákat leromboló elemzés egyértelműen megmutatta, hogy a REST-be való belépés küszöbe kétségtelenül magasabb, mint az RPC-be. Ez annak köszönhető, hogy mélyen meg kell érteni a HTTP működését, valamint kellő ismeretekkel kell rendelkezni azokról a meglévő infrastruktúraelemekről, amelyeket lehet és kell használni a WEB projektekben.
Akkor miért gondolják sokan, hogy a REST egyszerűbb lesz? Személyes véleményem az, hogy ez a látszólagos egyszerűség a REST megnyilvánulásaiból fakad. Azok. A REST nem protokoll, hanem fogalom... A REST-nek nincs szabványa, van néhány irányelv... A REST nem bonyolultabb, mint a HTTP. A látszólagos szabadság és anarchia vonzza a „szabad művészeket”.
Természetesen a REST nem bonyolultabb, mint a HTTP. De maga a HTTP egy jól megtervezett protokoll, amely évtizedek óta bevált. Ha magának a HTTP-nek nincs mély megértése, akkor a REST nem ítélhető meg.
De az RPC-ről - megteheti. Elég, ha figyelembe vesszük a specifikációját. Tehát kell-e ? Vagy még mindig trükkös REST? Te döntesz.
Őszintén remélem, hogy nem pazaroltam az idejét.
Forrás: will.com