rest - open - rabbitmq vs kafka
RESTful v/s MQ. Diferencias y otras características clave aparte de la entrega garantizada (3)
Ok ... Entonces, comencé a estudiar sobre MQ y su propósito / uso de casos, etc ... Mi aplicación existente (Web realizada utilizando JSP, etc.) utiliza la interfaz RestFUL para comunicarse con un servidor remoto y para publicar / recibir datos del servidor.
A menudo tenemos que lidiar con la conectividad del servidor remoto. El problema de sincronización siempre está ahí.
Mensaje enviado desde nuestro extremo. Pero el servidor remoto se ha caído. O viceversa.
Me encontré con lo de MQ y me pareció confiable cuando se trata de entregar y recibir mensajes del servidor remoto.
Pero nuevamente, usando REST, creo que toda la necesidad de MQ parece ser un poco confusa. Básicamente estoy buscando algunas de las diferencias entre MQ y RestFUL ...
Leí en otra publicación del blog que, con el advenimiento de la creciente investigación en el dominio RestFUL, los MQ perderán ritmo lentamente.
No tengo mucha idea acerca de MQ, así que no comentaré nada, pero seguramente trabajar con RestFUL es divertido.
Agradecería si alguien proporciona diferencias entre el uso de RestFUL y MQ.
Ambos son abstracciones pero en diferentes niveles. Su aplicación puede proporcionar una API REST, pero bajo el capó utilizará varios componentes, entre los cuales se encuentran las colas de mensajes.
Corto y sucio: RESTful declara las mejores prácticas sobre cómo crear aplicaciones o componentes, MQ sirve para la mensajería entre componentes.
Puede confundirse con RPC, pero en un contexto web no es lo mismo que MQ.
Tanto REST como MQ permiten la comunicación entre sistemas remotos (y locales).
En una comunicación REST, el consumidor y el proveedor del servicio REST deben estar ejecutándose para que una comunicación tenga éxito. Es una comunicación punto a punto.
En el modelo MQ, el productor y el consumidor no necesitan estar ejecutando al mismo tiempo. Los productores y consumidores no interactúan directamente. El intermediario de mensajes se encarga de manejar los mensajes, persistir, etc. Se admiten los modelos punto a punto y de publicación / suscripción. En un modelo de suscripción de publicación, más de un consumidor puede consumir un mensaje.
Estos son solo algunos puntos básicos que los diferencian. Hay suficientes publicaciones en SO que hablan de REST y MQ.
Una de las mayores diferencias es que REST implica un procesamiento síncrono, mientras que MQ suele ser asíncrono. Como ya mencionó, MQ es una forma de disociar al productor y al consumidor para que no tengan que estar en línea al mismo tiempo, pero el sistema aún funcionará como un todo. Si su caso de uso implica una respuesta de baja latencia (como un usuario con un navegador), necesita una semántica síncrona y, en este caso, MQ es solo un protocolo diferente. Si la latencia no es una preocupación, o si la mensajería va solo en una dirección, MQ puede ser una alternativa muy viable. Una cosa que MQ proporciona de forma gratuita es el equilibrio de carga (y algún nivel de HA) en el lado del consumidor.
REST es mucho más flexible en términos de compatibilidad cliente / servidor. Puede ejecutar un cliente REST en casi todas las plataformas, lo que no es el caso de MQ. Supongo que esta es la razón por la que algunas personas afirman que MQ se está volviendo obsoleta. Por esta razón, MQ no es bueno para las API públicas. Sin embargo, para la comunicación entre dos sistemas de servidor, MQ sigue siendo una muy buena opción. Una característica única de REST es que le permite imitar completamente el comportamiento WEB de sus recursos (hipermedia), es decir, un recurso contiene una referencia al otro y así sucesivamente. MQ no puede proporcionar nada de eso.
El rendimiento puede ser otra preocupación. No puedo dar cifras exactas, pero MQ tiende a tener un mayor rendimiento.
En algunos casos raros, debido a los requisitos de seguridad, los clientes no pueden conectarse directamente al servidor. En tales casos, MQ es prácticamente la única forma de enviar datos al servidor.
Para resumir, como regla de oro usaría REST
- para APIs públicas o
- donde se necesita procesamiento síncrono
MQ
- cuando solo está involucrada una cantidad limitada de sistemas del lado del servidor y
- El procesamiento asíncrono es aceptable o
- El rendimiento REST no es suficiente