web-services - que - sqs programa
¿Cola de mensajes frente a servicios web? (5)
¿Bajo qué condiciones se favorecerían las aplicaciones que hablan a través de una cola de mensajes en lugar de a través de servicios web (me refiero a XML o JSON o YAML o lo que sea sobre HTTP aquí, no a ningún tipo en particular)?
Tengo que hablar entre dos aplicaciones en una red local. Una será una aplicación web y tendrá que solicitar comandos en otra aplicación (que se ejecuta en un hardware diferente). Las solicitudes son cosas como crear usuarios, mover archivos y crear directorios. ¿Bajo qué condiciones preferiría los servicios web XML (o TCP directo o algo así) a usar una cola de mensajes?
La aplicación web es Ruby on Rails, pero creo que la pregunta es más amplia que eso.
Creo que, en general, querría un servicio web para una tarea de bloqueo (esta tarea debe completarse antes de que ejecutemos más código) y una cola de mensajes para una tarea de no bloqueo (podría llevar bastante tiempo, pero no No hay que esperar por ello).
Cuando usas un servicio web tienes un cliente y un servidor:
- Si el servidor falla, el cliente debe asumir la responsabilidad de manejar el error.
- Cuando el servidor vuelve a funcionar, el cliente es responsable de reenviarlo.
- Si el servidor responde a la llamada y el cliente falla, la operación se pierde.
- No tiene contención, es decir: si millones de clientes llaman a un servicio web en un servidor en un segundo, lo más probable es que su servidor se caiga.
- Puede esperar una respuesta inmediata del servidor, pero también puede manejar llamadas asíncronas.
Cuando utiliza una cola de mensajes como RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, espera resultados diferentes y más tolerantes a errores:
- Si el servidor falla, la cola conserva el mensaje (opcionalmente, incluso si la máquina se apaga).
- Cuando el servidor vuelve a funcionar, recibe el mensaje pendiente.
- Si el servidor responde a la llamada y el cliente falla, si el cliente no reconoce la respuesta, el mensaje persiste.
- Tiene disputa, puede decidir cuántas solicitudes son manejadas por el servidor (en su lugar, llámelo trabajador).
- No espera una respuesta sincrónica inmediata, pero puede implementar / simular llamadas sincrónicas.
Las colas de mensajes tienen muchas más funciones, pero esta es una regla empírica para decidir si desea manejar las condiciones de error o dejarlas en la cola de mensajes.
Ha habido una buena cantidad de investigaciones recientes sobre cómo las llamadas REST HTTP podrían reemplazar el concepto de cola de mensajes.
Si introduce el concepto de un proceso y una tarea como un recurso, la necesidad de una capa de mensajería intermedia comienza a evaporarse.
Ex:
POST /task/name
- Returns a 202 accepted status immediately
- Returns a resource url for the created task: /task/name/X
- Returns a resource url for the started process: /process/Y
GET /process/Y
- Returns status of ongoing process
Una tarea puede tener varios pasos para la inicialización, y un proceso puede devolver el estado cuando se realiza una encuesta o POST a una URL de devolución de llamada cuando se completa.
Esto es muy simple y se vuelve bastante poderoso cuando te das cuenta de que ahora puedes suscribirte a una fuente rss / atom de todos los procesos y tareas en ejecución sin ninguna capa intermedia. Cualquier sistema de colas requerirá algún tipo de interfaz web de todos modos, y este concepto se ha incorporado sin otra capa de código personalizado.
Sus recursos existen hasta que los elimine, lo que significa que puede ver información histórica mucho después de completar el proceso y la tarea.
Ha incorporado el descubrimiento de servicios, incluso para una tarea que tiene varios pasos, sin protocolos adicionales complicados.
GET /task/name
- returns form with required fields
POST (URL provided form''s "action" attribute)
Su descubrimiento de servicios es un formulario HTML, un formato universal y legible por humanos.
El flujo completo se puede usar programáticamente o por un humano, utilizando herramientas universalmente aceptadas. Es un cliente impulsado, y por lo tanto RESTful. Cada herramienta creada para la web puede impulsar sus procesos de negocio. Aún tiene canales de mensajes alternativos mediante la POST de manera asíncrona a una matriz separada de servidores de registro.
Después de considerarlo por un tiempo, siéntese y comience a darse cuenta de que REST puede eliminar la necesidad de una cola de mensajería y un ESB por completo.
Las colas de mensajes son asíncronas y pueden reintentarse varias veces si falla la entrega. Use una cola de mensajes si el solicitante no necesita esperar una respuesta.
La frase "servicios web" me hace pensar en llamadas síncronas a un componente distribuido a través de HTTP. Utilice los servicios web si el solicitante necesita una respuesta.
Las colas de mensajes son ideales para solicitudes que pueden tardar mucho tiempo en procesarse. Las solicitudes se ponen en cola y se pueden procesar fuera de línea sin bloquear el cliente. Si el cliente necesita ser notificado de su finalización, puede proporcionar una forma para que el cliente verifique periódicamente el estado de la solicitud.
Las colas de mensajes también le permiten escalar mejor a lo largo del tiempo. Mejora su capacidad para manejar ráfagas de actividad pesada, porque el procesamiento real puede distribuirse a lo largo del tiempo.
Tenga en cuenta que las colas de mensajes y los servicios web son conceptos ortogonales, es decir, no se excluyen mutuamente. Por ejemplo, puede tener un servicio web basado en XML que actúa como una interfaz para una cola de mensajes. Creo que la distinción que busca es Message Queues versus Request / Response, esta última es cuando la solicitud se procesa de forma síncrona.