Estoy seguro de que el titular provocó una reacción saludable: "bueno, ha comenzado de nuevo..." Pero déjame captar tu atención durante 5 a 10 minutos e intentaré no decepcionar tus expectativas.
La estructura del artículo será la siguiente: se toma una declaración estereotipada y se revela la "naturaleza" del surgimiento de este estereotipo. Espero que esto le permita ver la elección del paradigma de intercambio de datos en sus proyectos desde un nuevo ángulo.
Para tener claro qué es RPC, propongo considerar el estándar . Con REST no hay claridad. Y no debería ser así. Todo lo que necesita saber sobre REST: es indistinguible de .
Las solicitudes RPC son más rápidas y eficientes porque le permiten realizar solicitudes por lotes.
El caso es que en RPC puedes llamar a varios procedimientos a la vez en una sola solicitud. Por ejemplo, crear un usuario, agregarle un avatar y, en la misma solicitud, suscríbelo a algunos temas. ¡Solo una petición y cuánto beneficio!
De hecho, si solo tiene un nodo backend, parecerá más rápido con una solicitud por lotes. Porque tres solicitudes REST requerirán tres veces más recursos de un nodo para establecer conexiones.
Tenga en cuenta que la primera solicitud en el caso de REST debe devolver el ID de usuario para que se puedan realizar solicitudes posteriores. Lo que también afecta negativamente al resultado general.
Pero este tipo de infraestructuras sólo se pueden encontrar en soluciones internas y empresariales. Como último recurso, en pequeños proyectos WEB. Pero no vale la pena construir soluciones WEB completas, e incluso aquellas llamadas HighLoad. Su infraestructura debe cumplir con criterios de alta disponibilidad y carga. Y el panorama está cambiando.
Los canales de actividad de infraestructura bajo el mismo escenario están marcados en verde. Observe cómo se comporta RPC ahora. La solicitud utiliza la infraestructura en un solo tramo desde el equilibrador hasta el backend. Si bien REST aún pierde en la primera solicitud, compensa el tiempo perdido utilizando toda la infraestructura.
Basta con introducir en el guión no dos solicitudes de enriquecimiento, sino, digamos, cinco o diez... y la respuesta a la pregunta "¿quién gana ahora?" se vuelve confuso.
Propongo dar una mirada aún más amplia al problema. El diagrama muestra cómo se utilizan los canales de infraestructura, pero la infraestructura no se limita a los canales. Un componente importante de una infraestructura de alta carga son los cachés. Ahora obtengamos algún tipo de artefacto de usuario. Repetidamente. Digamos 32 veces.
Vea cómo la infraestructura RPC ha mejorado significativamente para satisfacer las demandas de carga elevada. El caso es que REST utiliza toda la potencia del protocolo HTTP, a diferencia de RPC. En el diagrama anterior, este poder se realiza mediante el método de solicitud: GET.
Los métodos HTTP, entre otras cosas, tienen estrategias de almacenamiento en caché. Puede encontrarlos en la documentación en . Para RPC, se utilizan solicitudes POST, que no se consideran idempotentes, es decir, las repeticiones repetidas de las mismas solicitudes POST pueden devolver resultados diferentes (por ejemplo, después de enviar cada comentario, aparecerá otra copia de este comentario) ().
En consecuencia, RPC no puede utilizar eficazmente las cachés de infraestructura. Esto lleva a la necesidad de "importar" cachés de software. El diagrama muestra a Redis en esta función. La caché de software, a su vez, requiere que el desarrollador agregue una capa adicional de código y cambios notables en la arquitectura.
Contemos ahora cuántas solicitudes REST y RPC "dieron a luz" en la infraestructura en consideración.
solicitudes
Bandeja de entrada
para respaldar
al DBMS
a caché suave (Redis)
Total
RESTO
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
En comparación con el primer esquema, la diferencia es sorprendente. Ahora el beneficio de REST queda claro. Pero sugiero no detenerse ahí. La infraestructura desarrollada incluye una CDN. A menudo, también resuelve el problema de contrarrestar los ataques DDoS y DoS. Obtenemos:
Aquí es donde las cosas se ponen realmente mal para RPC. RPC simplemente no es capaz de delegar la carga de trabajo a una CDN. Sólo podemos confiar en los sistemas para contrarrestar los ataques.
¿Es posible terminar aquí? Y de nuevo, no. Los métodos HTTP, como se mencionó anteriormente, tienen su propia "magia". Y no en vano el método GET se utiliza mucho en Internet. Tenga en cuenta que este método puede acceder a una parte del contenido, puede establecer condiciones que los elementos de la infraestructura pueden interpretar antes de que el control se transfiera a su código, etc. Todo esto le permite crear infraestructuras flexibles y manejables que pueden manejar flujos de solicitudes realmente grandes. Pero en RPC este método... se ignora.
Entonces, ¿por qué es tan persistente el mito de que las solicitudes por lotes (RPC) son más rápidas? Personalmente, me parece que la mayoría de los proyectos simplemente no alcanzan un nivel de desarrollo en el que REST pueda mostrar su fuerza. Además, en proyectos pequeños está más dispuesto a mostrar sus debilidades.
La elección de REST o RPC no es una elección voluntaria de un individuo en un proyecto. Esta elección debe cumplir con los requisitos del proyecto. Si un proyecto es capaz de exprimir todo lo que realmente puede de REST y realmente lo necesita, entonces REST será una excelente opción.
Pero si para obtener todos los beneficios de REST necesitas contratar especialistas en devops para que el proyecto escale rápidamente la infraestructura, administradores para gestionar la infraestructura, un arquitecto para diseñar todas las capas del servicio WEB... y el proyecto , al mismo tiempo, vende tres paquetes de margarina al día... Yo me quedaría con RPC, porque... este protocolo es más utilitario. No requerirá un conocimiento profundo de cómo funcionan las cachés y la infraestructura, pero centrará al desarrollador en llamadas simples y comprensibles a los procedimientos que necesita. Los negocios estarán felices.
Las solicitudes RPC son más confiables porque pueden ejecutar solicitudes por lotes dentro de una sola transacción.
Esta propiedad de RPC es una ventaja definitiva, porque Es fácil mantener la coherencia de la base de datos. Pero con REST se vuelve cada vez más complicado. Las solicitudes pueden llegar de manera inconsistente a diferentes nodos de backend.
Esta "desventaja" de REST es la otra cara de la ventaja descrita anteriormente: la capacidad de utilizar de manera eficiente todos los recursos de la infraestructura. Si la infraestructura está mal diseñada, y más aún si la arquitectura del proyecto y la base de datos en particular están mal diseñadas, entonces esto es realmente un gran problema.
Pero, ¿son las solicitudes por lotes tan fiables como parecen? Veamos un caso: creamos un usuario, enriquecemos su perfil con alguna descripción y le enviamos un SMS con un secreto para completar el registro. Aquellos. tres llamadas en una solicitud por lotes.
Miremos el diagrama. Presenta una infraestructura con elementos de alta disponibilidad. Hay dos canales de comunicación independientes con pasarelas SMS. Pero… ¿qué vemos? Al enviar un SMS, aparece el error 503: el servicio no está disponible temporalmente. Porque El envío de SMS se empaqueta en una solicitud por lotes, luego se debe revertir toda la solicitud. Se cancelan las acciones en el DBMS. El cliente recibe un error.
El próximo intento es la lotería. O la solicitud llegará al mismo nodo una y otra vez y devolverá un error, o tendrá suerte y se ejecutará. Pero lo principal es que al menos una vez nuestra infraestructura ya ha funcionado en vano. Hubo una carga, pero no hubo ganancias.
Bien, imaginemos que nos hemos esforzado (!) y pensado en la opción en la que la solicitud se puede completar parcialmente con éxito. E intentaremos completar el resto nuevamente después de algún intervalo de tiempo (¿Cuál? ¿Decide el frente?). Pero la lotería siguió siendo la misma. La solicitud de envío de SMS tiene un 50/50 de posibilidades de volver a fallar.
De acuerdo, desde el lado del cliente, el servicio no parece tan confiable como nos gustaría... ¿qué pasa con REST?
REST vuelve a utilizar la magia de HTTP, pero ahora con códigos de respuesta. Cuando se produce un error 503 en la puerta de enlace SMS, el backend transmite este error al equilibrador. El equilibrador recibe este error y, sin interrumpir la conexión con el cliente, envía la solicitud a otro nodo, que procesa la solicitud con éxito. Aquellos. el cliente recibe el resultado esperado y la infraestructura confirma su alto título de “altamente accesible”. El usuario está contento.
Y nuevamente eso no es todo. El equilibrador no solo recibió el código de respuesta 503. Al responder, según el estándar, es recomendable proporcionar este código con el encabezado "Reintentar después". El encabezado deja claro al equilibrador que no vale la pena perturbar este nodo en esta ruta durante un tiempo específico. Y las próximas solicitudes de envío de SMS se enviarán directamente a un nodo que no tenga problemas con la puerta de enlace SMS.
Como podemos ver, la confiabilidad de JSON-RPC está sobrevalorada. De hecho, es más fácil organizar la coherencia en la base de datos. Pero el sacrificio, en este caso, será la fiabilidad del sistema en su conjunto.
La conclusión es en gran medida similar a la anterior. Cuando la infraestructura es simple, la obviedad de JSON-RPC es definitivamente una ventaja. Si el proyecto implica alta disponibilidad con una carga elevada, REST parece una solución más correcta, aunque más compleja.
El umbral de entrada a REST es menor
Creo que el análisis anterior, que desacredita los estereotipos establecidos sobre RPC, mostró claramente que el umbral para ingresar a REST es sin duda más alto que a RPC. Esto se debe a la necesidad de un conocimiento profundo de cómo funciona HTTP, así como a la necesidad de tener suficiente conocimiento sobre los elementos de infraestructura existentes que pueden y deben usarse en proyectos WEB.
Entonces, ¿por qué mucha gente piensa que REST será más sencillo? Mi opinión personal es que esta aparente sencillez proviene de las manifestaciones del DESCANSO. Aquellos. REST no es un protocolo sino un concepto... REST no tiene un estándar, hay algunas pautas... REST no es más complicado que HTTP. La aparente libertad y anarquía atraen a los “artistas libres”.
Por supuesto, REST no es más complicado que HTTP. Pero HTTP en sí es un protocolo bien diseñado que ha demostrado su valía durante décadas. Si no hay un conocimiento profundo de HTTP en sí, entonces no se puede juzgar REST.
Pero sobre RPC, puedes hacerlo. Basta con tomar su especificación. Entonces ¿necesitas ? ¿O sigue siendo complicado el DESCANSO? Tú decides.
Espero sinceramente no haberte hecho perder el tiempo.
Fuente: habr.com