Estic segur que el titular va provocar una reacció saludable: "bé, ha tornat a començar..." Però permeteu-me captar la vostra atenció durant 5-10 minuts, i intentaré no decebre les vostres expectatives.
L'estructura de l'article serà la següent: es pren una declaració estereotipada i es revela la "naturalesa" de l'aparició d'aquest estereotip. Espero que això us permeti mirar l'elecció del paradigma d'intercanvi de dades en els vostres projectes des d'un nou angle.
Per tenir clar què és RPC, proposo considerar l'estàndard . Amb REST no hi ha claredat. I no hauria de ser. Tot el que necessites saber sobre REST: no es pot distingir .
Les sol·licituds RPC són més ràpides i eficients perquè us permeten fer sol·licituds per lots.
La qüestió és que a RPC podeu trucar a diversos tràmits alhora en una sol·licitud. Per exemple, creeu un usuari, afegiu-li un avatar i, en la mateixa sol·licitud, subscriviu-lo a alguns temes. Només una sol·licitud i quants beneficis!
De fet, si només teniu un node de fons, semblarà més ràpid amb una sol·licitud per lots. Perquè tres sol·licituds REST requeriran tres vegades més recursos d'un node per establir connexions.
Tingueu en compte que la primera sol·licitud en el cas de REST ha de retornar l'identificador d'usuari per tal que es puguin fer les peticions posteriors. La qual cosa també afecta negativament el resultat global.
Però aquestes infraestructures només es poden trobar en solucions internes i Enterprise. Com a últim recurs, en petits projectes WEB. Però les solucions WEB completes, i fins i tot les anomenades HighLoad, no valen la pena construir-se. La seva infraestructura ha de complir els criteris d'alta disponibilitat i càrrega. I la imatge està canviant.
Els canals d'activitat d'infraestructura sota el mateix escenari estan marcats en verd. Observeu com es comporta ara RPC. La sol·licitud utilitza la infraestructura en una sola part des de l'equilibrador fins al backend. Tot i que REST encara perd en la primera sol·licitud, compensa el temps perdut utilitzant tota la infraestructura.
N'hi ha prou amb entrar al guió no dues peticions d'enriquiment, sinó, per exemple, cinc o deu... i la resposta a la pregunta "qui guanya ara?" queda poc clar.
Proposo fer una visió encara més àmplia del problema. El diagrama mostra com s'utilitzen els canals d'infraestructura, però la infraestructura no es limita als canals. Un component important d'una infraestructura d'alta càrrega són les memòria cau. Ara anem a obtenir algun tipus d'artefacte d'usuari. Repetidament. Diguem 32 vegades.
Vegeu com la infraestructura RPC ha millorat significativament per satisfer les demandes d'alta càrrega. El cas és que REST utilitza tota la potència del protocol HTTP, a diferència de RPC. Al diagrama anterior, aquesta potència es realitza mitjançant el mètode de sol·licitud - GET.
Els mètodes HTTP, entre altres coses, tenen estratègies de memòria cau. Els trobareu a la documentació a . Per a RPC, s'utilitzen peticions POST, que no es consideren idempotents, és a dir, repeticions repetides de les mateixes peticions POST poden retornar resultats diferents (per exemple, després d'enviar cada comentari, apareixerà una altra còpia d'aquest comentari) ().
En conseqüència, RPC no pot utilitzar de manera eficaç les memòria cau d'infraestructura. Això comporta la necessitat d'"importar" memòria cau de programari. El diagrama mostra a Redis en aquest paper. La memòria cau del programari, al seu torn, requereix que el desenvolupador afegeixi una capa addicional de codi i canvis notables en l'arquitectura.
Comptem ara quantes sol·licituds REST i RPC "han donat a llum" a la infraestructura que s'està considerant?
Sol·licituds
Safata d’entrada
al backend
al SGBD
a la memòria cau suau (Redis)
TOTAL
RESTA
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
En comparació amb el primer esquema, la diferència és sorprenent. Ara es fa evident el benefici de REST. Però suggereixo no aturar-se aquí. La infraestructura desenvolupada inclou un CDN. Sovint també resol el problema de contrarestar els atacs DDoS i DoS. Obtenim:
Aquí és on les coses es posen molt malament per a RPC. RPC simplement no és capaç de delegar la càrrega de treball a un CDN. Només podem confiar en sistemes per contrarestar els atacs.
És possible acabar aquí? I de nou, no. Els mètodes HTTP, com s'ha esmentat anteriorment, tenen la seva pròpia "màgia". I no és sense raó que el mètode GET s'utilitza àmpliament a Internet. Tingueu en compte que aquest mètode és capaç d'accedir a un contingut, és capaç d'establir condicions que els elements de la infraestructura poden interpretar abans que el control es transfereixi al vostre codi, i així successivament. Tot això us permet crear infraestructures flexibles i manejables que poden gestionar fluxos de peticions molt grans. Però a RPC aquest mètode... s'ignora.
Aleshores, per què és tan persistent el mite que les sol·licituds per lots (RPC) són més ràpides? Personalment, em sembla que la majoria de projectes simplement no arriben a un nivell de desenvolupament on REST sigui capaç de mostrar la seva força. A més, en petits projectes, està més disposat a mostrar les seves debilitats.
L'elecció de REST o RPC no és una elecció voluntària d'un individu en un projecte. Aquesta elecció ha de complir els requisits del projecte. Si un projecte és capaç d'extreure tot el que realment pot de REST, i realment ho necessita, llavors REST serà una opció excel·lent.
Però si, per tal d'aconseguir tots els avantatges de REST, cal contractar especialistes devops per al projecte per escalar ràpidament la infraestructura, administradors per gestionar la infraestructura, un arquitecte per dissenyar totes les capes del servei WEB... i el projecte , al mateix temps, ven tres paquets de margarina al dia... Jo em quedaria amb RPC, perquè... aquest protocol és més utilitari. No requerirà un coneixement profund del funcionament de la memòria cau i la infraestructura, però centrarà el desenvolupador en trucades senzilles i entenedores als procediments que necessita. El negoci serà feliç.
Les sol·licituds RPC són més fiables perquè poden executar sol·licituds per lots en una sola transacció
Aquesta propietat de RPC és un avantatge definitiu, perquè És fàcil mantenir la base de dades coherent. Però amb REST es fa cada cop més complicat. Les sol·licituds poden arribar de manera inconsistent a diferents nodes de backend.
Aquest "desavantatge" de REST és l'altra cara del seu avantatge descrit anteriorment: la capacitat d'utilitzar de manera eficient tots els recursos de la infraestructura. Si la infraestructura està mal dissenyada, i encara més si l'arquitectura del projecte i la base de dades en particular estan mal dissenyades, això és realment un gran dolor.
Però les sol·licituds per lots són tan fiables com semblen? Vegem un cas: creem un usuari, enriquim el seu perfil amb alguna descripció i li enviem un SMS amb un secret per completar el registre. Aquells. tres trucades en una sol·licitud per lot.
Mirem el diagrama. Presenta una infraestructura amb elements d'alta disponibilitat. Hi ha dos canals de comunicació independents amb passarel·les SMS. Però... què veiem? Quan s'envia un SMS, es produeix un error 503: el servei no està disponible temporalment. Perquè L'enviament d'SMS s'empaqueta en una sol·licitud per lots, després s'ha de revertir tota la sol·licitud. Les accions al SGBD es cancel·len. El client rep un error.
El següent intent és la loteria. O la sol·licitud colpejarà el mateix node una vegada i una altra i retornarà un error, o tindreu sort i s'executarà. Però el més important és que almenys una vegada la nostra infraestructura ja ha funcionat en va. Hi havia una càrrega, però cap benefici.
D'acord, imaginem que ens hem esforçat (!) i hem pensat en l'opció quan la sol·licitud es podria completar parcialment amb èxit. I intentarem tornar a completar la resta després d'un interval de temps (Quin? El front decideix?). Però la loteria es va mantenir igual. La sol·licitud per enviar SMS té un 50/50 de possibilitats de fallar de nou.
D'acord, des del costat del client, el servei no sembla tan fiable com voldríem... què passa amb REST?
REST torna a utilitzar la màgia de l'HTTP, però ara amb codis de resposta. Quan es produeix un error 503 a la passarel·la SMS, el backend transmet aquest error a l'equilibrador. L'equilibrador rep aquest error i sense trencar la connexió amb el client, envia la sol·licitud a un altre node, que processa correctament la sol·licitud. Aquells. el client rep el resultat esperat, i la infraestructura confirma el seu alt títol de "altament accessible". L'usuari està content.
I de nou, això no és tot. L'equilibrador no només va rebre un codi de resposta de 503. Quan respongui, segons l'estàndard, és recomanable proporcionar aquest codi amb l'encapçalament "Retry-After". La capçalera deixa clar a l'equilibrador que no hauria de molestar aquest node d'aquesta ruta durant un temps especificat. I les properes sol·licituds per enviar SMS s'enviaran directament a un node que no tingui problemes amb la passarel·la d'SMS.
Com podem veure, la fiabilitat de JSON-RPC està sobrevalorada. De fet, és més fàcil organitzar la coherència a la base de dades. Però el sacrifici, en aquest cas, serà la fiabilitat del sistema en conjunt.
La conclusió és molt semblant a l'anterior. Quan la infraestructura és senzilla, l'obvietat de JSON-RPC és sens dubte un avantatge. Si el projecte implica una alta disponibilitat amb una càrrega elevada, REST sembla una solució més correcta, encara que més complexa.
El llindar d'entrada a REST és més baix
Crec que l'anàlisi anterior, desmentint els estereotips establerts sobre RPC, va mostrar clarament que el llindar d'entrada a REST és sens dubte més alt que a RPC. Això es deu a la necessitat d'una comprensió profunda de com funciona HTTP, així com a la necessitat de tenir un coneixement suficient sobre els elements d'infraestructura existents que poden i s'han d'utilitzar en projectes WEB.
Aleshores, per què molta gent pensa que REST serà més senzill? La meva opinió personal és que aquesta aparent senzillesa prové de les manifestacions REST. Aquells. REST no és un protocol sinó un concepte... REST no té un estàndard, hi ha unes pautes... REST no és més complicat que HTTP. La llibertat i l'anarquia aparent atrauen "artistes lliures".
Per descomptat, REST no és més complicat que HTTP. Però HTTP en si és un protocol ben dissenyat que ha demostrat el seu valor durant dècades. Si no hi ha una comprensió profunda del propi HTTP, no es pot jutjar REST.
Però sobre RPC: pots. N'hi ha prou amb prendre la seva especificació. Així que ho necessites ? O encara és complicat REST? Tu decideixes.
Espero sincerament no haver-vos perdut el temps.
Font: www.habr.com