Microservicios: compensa la falla del servicio con la cola

Estamos utilizando algún tipo de enfoque de microservicios en nuestra aplicación (aunque en realidad no se cumple).

Cuando un servicio está inactivo o lanzando una excepción, el enfoque es ponerlo en una cola (ActiveMQ) y volver a intentarlo cuando el servicio vuelva a estar activo.

¿Es esta una solución "estándar"? ¿O debería evitarse por alguna razón?

¿O hay una solución mejor o alternativa a este problema?

microservices message-queue

— usuario140547
fuente

¿Cuál es el problema con la solución actual? La mejor / mejor solución es la que se ajusta totalmente a sus requisitos. Hazlo el actual?

— Laiv

@Laiv: No hay ningún problema per se, pero como no tengo tanta experiencia con esa arquitectura, solo preguntaba si hay algún problema o limitación potencial de este enfoque que deba considerarse.

— user140547

¿Qué pasa si la cola está baja?

— Jon Raynor

@ JonRaynor: ríndete y devuelve un error, ya que probablemente sería excesivo implementar un segundo mecanismo alternativo ...

— user140547

Respuestas:

Suponiendo que puede hacer que sus llamadas sean asíncronas (no necesita obtener una respuesta del servicio para continuar), hacerlo es a menudo una buena idea.

Permite que el servicio de llamadas continúe funcionando sin la demora (o error absoluto) causado al llamar al otro servicio. Le permite tener una lógica de reintento más compleja y distribuir la carga de manera más uniforme con el tiempo.

En muchos casos, puede aprovecharlo aún más renunciando a las garantías de pedido proporcionadas por las colas y cambiando a Kafka u otro agente de mensajes asíncrono. Hermes proporciona una API REST más conveniente además de Kafka.

— Michał Kosmulski
fuente

Voto esta respuesta asumiendo que el contexto es que estamos hablando del cliente. Esta no es realmente una pregunta de microservicios. Es una decisión de diseño del cliente. Si el servicio es síncrono o no y está activo o no. No está claramente explicado en la pregunta, pero en realidad solo tiene sentido si estamos hablando de un cliente.

— JimmyJames

Este es un mal enfoque en mi opinión. deberías

Siempre comunique ver una cola: su aplicación no debe esperar una respuesta inmediata y, por lo tanto, el proceso de trabajo no tiene que estar 100% disponible
Utilice siempre las comunicaciones de estilo RPC. Solicitudes de equilibrio de carga en varias instancias de servicio: si un servicio es defectuoso, otro responderá a la solicitud, por lo que tiene un tiempo de actividad del 100%

Tener el flujo, llamar al servicio, obtener un error, colocarlo en la cola, recuerde verificar en la cola las respuestas a algunos de mis mensajes pero no a todos. Es demasiado complicado.

editar: demasiado complicado porque tienes que programar tanto el estilo de comunicación sincronizado como el asíncrono en lugar de solo uno u otro.

— Ewan
fuente

Estoy de acuerdo con esto. Es mas complicado. Es difícil evaluar si es demasiado complicado sin comprender la arquitectura más grande. El problema con ir 100% basado en colas es que agrega un nuevo punto único de falla y crea algunos otros desafíos. Por ejemplo si el proceso se está abrumado con las tareas, escribiendo a la cola es generalmente muy rápido por lo que no hay ningún problema aparente en el lado de entrada hasta el auge de la cola se llena. Si el origen de las solicitudes no se puede limitar, puede tener un gran problema. No es insuperable, pero agrega su propia complejidad.

— JimmyJames

Si puedo, sugiero volver a redactar la última oración. 'Recordar' no es realmente un problema aquí, una vez que el código está escrito para leer desde la cola, no hay nada que recordar. Es simplemente un código adicional para escribir y mantener, pero no debería verse muy diferente de lo que tendría si siempre leyera desde la cola.

— JimmyJames

en los únicos errores goto queue senario Y desea respuestas, tiene que escribir tanto la verificación de la cola Y el manejo inmediato de la respuesta. Así que tienes que 'recordar' esas llamadas erradas y no las inmediatas

— Ewan

@ Jimmy tienes esos problemas con cualquier solución. hacer cola siempre, hacer cola a veces o todo RPC.

— Ewan

Realmente no tiene algunos de estos problemas cuando los productores esperan a los consumidores. Por ejemplo, si recibe un máximo de 1000 solicitudes por segundo, y la capacidad interna de sus procesos cae a 100 por segundo, sus productores serán bloqueados en un enfoque directo. Serán limitados también. Si simplemente inserta una cola en el medio, los productores generalmente no se verán afectados por la caída de la capacidad y continuarán a su ritmo máximo. La cola se llenará hasta que alcance su límite de capacidad y las escrituras comiencen a fallar (a 1000 fallas por segundo)

— JimmyJames