Callback en multi instancia k8s.
Tengo una aplicación de microservicios (A) que se ejecuta en varias instancias en K8S. Cuando recibo una solicitud (1) del cliente, envía otra solicitud (2) a otra aplicación (B) para ejecutar una tarea larga.
(2) retornará inmediatamente si la solicitud de empuje a (B) tiene éxito, mientras que
(1) esperará hasta que B termine de ejecutar.
1 2
Cliente ------> microservicio A ------> microservicio B
Mi aplicación proporciona un método de devolución de llamada a B y B lo llamará cuando termine de ejecutar la tarea.
El problema aquí es que, debido a que la aplicación se ejecuta en varias instancias, la llamada de devolución de llamada puede ir a un nodo diferente al nodo emisor original.
¿Existe alguna forma de que la solicitud a A sepa cuándo B ha terminado la tarea?
davy.ai
Hay varias formas de resolver este problema:
Utilizar un sistema de mensajería como Kafka o RabbitMQ para desacoplar la comunicación entre los microservicios A y B. Cuando A envía una solicitud a B, puede publicar un mensaje en un tema, y B puede suscribirse a ese tema y procesar la solicitud. Una vez que B termina la tarea, puede publicar otro mensaje en un tema diferente indicando que la tarea está completa. El microservicio A puede suscribirse a ese tema y recibir una notificación cuando la tarea esté completa, sin importar en qué nodo se recibió el mensaje.
Almacenar la información de devolución de llamada en un almacén de datos centralizado como Redis o una base de datos. Cuando A envía la solicitud a B, puede almacenar la información de devolución de llamada en Redis o la base de datos junto con un identificador único para la solicitud. Cuando B finaliza la tarea, puede actualizar el estado de la solicitud en Redis o la base de datos. El microservicio A puede verificar periódicamente el estado de la solicitud y saber cuándo la tarea esté completa, sin importar en qué nodo se procesó la solicitud.
Utilizar StatefulSets de Kubernetes en lugar de Deployments para el microservicio A. StatefulSets proporciona identidades de red estables y almacenamiento persistente para cada pod, por lo que se puede garantizar que las solicitudes siempre se envíen al mismo pod y las devoluciones de llamada siempre sean recibidas por el mismo pod. Sin embargo, este enfoque requiere más configuración y puede no ser adecuado para todos los casos de uso.