Estou seguro de que o título causou unha reacción saudable: "ben, comezou de novo..." Pero permíteme captar a túa atención durante 5-10 minutos e intentarei non defraudar as túas expectativas.
A estrutura do artigo será a seguinte: tómase unha declaración estereotipada e revélase a "natureza" da aparición deste estereotipo. Espero que isto che permita ver a elección do paradigma de intercambio de datos nos teus proxectos desde un novo ángulo.
Para ter claro o que é RPC, propoño considerar o estándar . Con REST non hai claridade. E non debería ser. Todo o que necesitas saber sobre REST: non se pode distinguir .
As solicitudes RPC son máis rápidas e eficientes porque permiten facer solicitudes por lotes.
A cuestión é que en RPC pode chamar varios procedementos á vez nunha solicitude. Por exemplo, crea un usuario, engádelle un avatar e, na mesma solicitude, subscríbeo a algúns temas. Só unha solicitude e cantos beneficios!
De feito, se só tes un nodo de backend, parecerá máis rápido cunha solicitude por lotes. Porque tres solicitudes REST requirirán tres veces máis recursos dun nodo para establecer conexións.
Teña en conta que a primeira solicitude no caso de REST debe devolver o ID de usuario para que se realicen solicitudes posteriores. O que tamén afecta negativamente ao resultado global.
Pero tales infraestruturas só se poden atopar en solucións internas e Enterprise. Como último recurso, en pequenos proxectos WEB. Pero as solucións WEB completas, e mesmo as chamadas HighLoad, non valen a pena construír. A súa infraestrutura debe cumprir os criterios de alta dispoñibilidade e carga. E a imaxe está cambiando.
As canles de actividade de infraestrutura no mesmo escenario están marcadas en verde. Observe como se comporta RPC agora. A solicitude usa a infraestrutura só nunha pata desde o equilibrador ata o backend. Aínda que REST aínda perde na primeira solicitude, compensa o tempo perdido usando toda a infraestrutura.
Abonda con entrar no guión non dúas peticións de enriquecemento, senón, digamos, cinco ou dez... e a resposta á pregunta "quen gaña agora?" queda pouco claro.
Propoño darlle unha ollada aínda máis ampla ao problema. O diagrama mostra como se utilizan as canles de infraestrutura, pero a infraestrutura non se limita ás canles. Un compoñente importante dunha infraestrutura de alta carga son as cachés. Agora imos obter algún tipo de artefacto de usuario. Reiteradamente. Digamos 32 veces.
Vexa como a infraestrutura RPC mellorou significativamente para satisfacer as demandas de alta carga. O caso é que REST usa toda a potencia do protocolo HTTP, a diferenza de RPC. No diagrama anterior, este poder realízase mediante o método de solicitude - GET.
Os métodos HTTP, entre outras cousas, teñen estratexias de almacenamento en caché. Podes atopalos na documentación en . Para RPC, utilízanse solicitudes POST, que non se consideran idempotentes, é dicir, as repeticións repetidas das mesmas solicitudes POST poden devolver resultados diferentes (por exemplo, despois de enviar cada comentario, aparecerá outra copia deste comentario) ().
En consecuencia, RPC non pode utilizar eficazmente as cachés de infraestrutura. Isto leva á necesidade de "importar" cachés de software. O diagrama mostra a Redis neste papel. A caché do software, pola súa banda, require que o programador engada unha capa adicional de código e cambios notables na arquitectura.
Contemos agora cantas solicitudes REST e RPC "deron a luz" na infraestrutura en consideración?
Solicitudes
caixa de entrada
ao backend
ao DBMS
a caché suave (Redis)
TOTAL
DESCANSO
1 / 32 *
1
1
0
3 / 35
CPR
32
32
1
31
96
En comparación co primeiro esquema, a diferenza é sorprendente. Agora queda claro o beneficio de REST. Pero suxiro non parar aí. A infraestrutura desenvolvida inclúe unha CDN. Moitas veces tamén resolve o problema de contrarrestar os ataques DDoS e DoS. Obtemos:
Aquí é onde as cousas están moi mal para RPC. RPC simplemente non é capaz de delegar a carga de traballo nun CDN. Só podemos confiar nos sistemas para contrarrestar os ataques.
É posible rematar aquí? E de novo, non. Os métodos HTTP, como se mencionou anteriormente, teñen a súa propia "maxia". E non é sen razón que o método GET é amplamente utilizado en Internet. Teña en conta que este método pode acceder a un contido, pode establecer condicións que os elementos da infraestrutura poden interpretar antes de que o control se transfira ao seu código, etc. Todo isto permítelle crear infraestruturas flexibles e manexables que poden xestionar fluxos de solicitudes realmente grandes. Pero en RPC este método... é ignorado.
Entón, por que é tan persistente o mito de que as solicitudes por lotes (RPC) son máis rápidas? Persoalmente, paréceme que a maioría dos proxectos simplemente non alcanzan un nivel de desenvolvemento onde REST sexa capaz de mostrar a súa forza. Ademais, en pequenos proxectos, está máis disposto a mostrar as súas debilidades.
A elección de REST ou RPC non é unha elección voluntaria dun individuo nun proxecto. Esta elección debe cumprir os requisitos do proxecto. Se un proxecto é capaz de espremer todo o que realmente pode de REST, e realmente o necesita, entón REST será unha excelente opción.
Pero se, para obter todos os beneficios de REST, necesitas contratar especialistas en devops para que o proxecto escale rapidamente a infraestrutura, administradores para xestionar a infraestrutura, un arquitecto para deseñar todas as capas do servizo WEB... e o proxecto. , ao mesmo tempo, vende tres paquetes de margarina ao día... Eu quedaríame con RPC, porque... este protocolo é máis utilitario. Non requirirá un coñecemento profundo de como funcionan as cachés e a infraestrutura, pero centrará o programador en chamadas sinxelas e comprensibles aos procedementos que precisa. Os negocios serán felices.
As solicitudes RPC son máis fiables porque poden executar solicitudes por lotes nunha única transacción
Esta propiedade de RPC é unha vantaxe definitiva, porque É doado manter a base de datos consistente. Pero con REST complícase cada vez máis. As solicitudes poden chegar de forma inconsistente a distintos nodos de backend.
Esta "desvantaxe" de REST é a outra cara da súa vantaxe descrita anteriormente: a capacidade de utilizar de forma eficiente todos os recursos da infraestrutura. Se a infraestrutura está mal deseñada, e aínda máis se a arquitectura do proxecto e a base de datos en particular están mal deseñadas, entón isto é realmente unha gran dor.
Pero as solicitudes por lotes son tan fiables como parecen? Vexamos un caso: creamos un usuario, enriquecemos o seu perfil con algunha descrición e enviámoslle unha SMS cun segredo para completar o rexistro. Eses. tres chamadas nunha solicitude por lotes.
Vexamos o diagrama. Presenta unha infraestrutura con elementos de alta dispoñibilidade. Hai dúas canles de comunicación independentes con pasarelas SMS. Pero... que vemos? Ao enviar unha SMS, prodúcese un erro 503: o servizo non está dispoñible temporalmente. Porque O envío de SMS está empaquetado nunha solicitude por lotes, entón toda a solicitude debe ser revertida. As accións no DBMS son canceladas. O cliente recibe un erro.
O seguinte intento é a lotería. Ou a solicitude golpeará o mesmo nodo unha e outra vez devolverá un erro, ou terás sorte e executarase. Pero o principal é que polo menos unha vez a nosa infraestrutura xa funcionou en balde. Había unha carga, pero sen beneficio.
Vale, imaxinemos que esforzámonos (!) e pensamos na opción cando a solicitude pode completarse parcialmente con éxito. E tentaremos completar o resto de novo despois dun intervalo de tempo (Cal? ¿Decide a fronte?). Pero a lotería seguiu igual. A solicitude para enviar SMS ten un 50/50 de posibilidades de fallar de novo.
De acordo, dende o lado do cliente, o servizo non parece tan fiable como nos gustaría... e REST?
REST usa de novo a maxia de HTTP, pero agora con códigos de resposta. Cando se produce un erro 503 na pasarela de SMS, o backend envía este erro ao equilibrador. O equilibrador recibe este erro e sen romper a conexión co cliente, envía a solicitude a outro nodo, que procesa a solicitude con éxito. Eses. o cliente recibe o resultado esperado e a infraestrutura confirma o seu alto título de "altamente accesible". O usuario está contento.
E de novo iso non é todo. O equilibrador non acaba de recibir un código de resposta de 503. Ao responder, segundo o estándar, é recomendable proporcionar este código coa cabeceira "Retry-After". A cabeceira deixa claro ao equilibrador que non debe perturbar este nodo nesta ruta durante un tempo especificado. E as seguintes solicitudes para enviar SMS enviaranse directamente a un nodo que non teña problemas coa pasarela de SMS.
Como podemos ver, a fiabilidade de JSON-RPC está sobrevalorada. De feito, é máis doado organizar a coherencia na base de datos. Pero o sacrificio, neste caso, será a fiabilidade do sistema no seu conxunto.
A conclusión é moi similar á anterior. Cando a infraestrutura é sinxela, a obviedade de JSON-RPC é definitivamente unha vantaxe. Se o proxecto implica unha alta dispoñibilidade cunha carga elevada, REST parece unha solución máis correcta, aínda que máis complexa.
O limiar de entrada a REST é menor
Creo que a análise anterior, desmentindo os estereotipos establecidos sobre RPC, mostrou claramente que o limiar para entrar en REST é, sen dúbida, maior que en RPC. Isto débese á necesidade dunha comprensión profunda de como funciona HTTP, así como á necesidade de ter coñecemento suficiente sobre os elementos de infraestrutura existentes que poden e deben ser utilizados en proxectos WEB.
Entón, por que moita xente pensa que REST será máis sinxelo? A miña opinión persoal é que esta aparente sinxeleza provén das manifestacións REST. Eses. REST non é un protocolo senón un concepto... REST non ten un estándar, hai unhas pautas... REST non é máis complicado que HTTP. A aparente liberdade e anarquía atraen aos "artistas libres".
Por suposto, REST non é máis complicado que HTTP. Pero o propio HTTP é un protocolo ben deseñado que demostrou a súa valía durante décadas. Se non hai unha comprensión profunda do propio HTTP, non se pode xulgar REST.
Pero sobre RPC - podes. Basta con tomar a súa especificación. Entón necesitas ? Ou aínda é complicado REST? Ti decides.
Sinceramente espero non perder o seu tempo.
Fonte: www.habr.com