Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Comunicación asíncrona
Por el contrario, en la comunicación asíncrona, el cliente envía una solicitud a un servicio, pero no recibe una respuesta inmediata. En este caso, el cliente suele recibir solo un acuse de recibo de que la solicitud ha sido aceptada.
Los beneficios de la comunicación asíncrona incluyen:
-
Soporte de arquitectura basada en eventos: ideal para los patrones de generación de eventos y de división de responsabilidades por consultas de comandos (CQRS).
-
Mejor gestión de los recursos: capacidad de los servicios para procesar las solicitudes en función de su capacidad.
-
Aislamiento de errores mejorado: disociación de los servicios, lo que evita los fallos en cascada.
-
Gestión de los picos de carga: mejor gestión de los picos de tráfico mediante la puesta en cola de mensajes.
Entre los inconvenientes se incluye la complejidad. Por ejemplo:
-
Si el cliente requiere el resultado de la operación asíncrona, implementar un mecanismo para obtener o recibir ese resultado requiere más esfuerzo.
-
Puede resultar más difícil solucionar los problemas de las operaciones asíncronas, ya que la solución de problemas requiere examinar los registros de varios sistemas.
-
Puede resultar más difícil probar las operaciones asíncronas, ya que las pruebas requieren la coordinación entre varios sistemas y servicios.
Entre los enfoques de la comunicación asíncrona se incluyen la comunicación “de disparo y olvido”, verificación de reclamaciones, devolución de llamadas y comunicación bidireccional.
Disparo y olvido
En el patrón de disparo y olvido, un cliente envía una solicitud al servidor y recibe de forma sincronizada un acuse de recibo que indica que el servidor ha recibido el mensaje y lo procesará. Sin embargo, el procesamiento real aún no se ha realizado y el cliente no sabe cuándo o cómo se realizará. El siguiente diagrama ilustra este patrón.
En este caso, el servicio no debería enviar el acuse de recibo hasta que el objeto haya persistido de forma duradera. Esta persistencia podría implementarse como una operación de escritura en una base de datos o al colocar un elemento en una cola.
Consideraciones adicionales:
-
Implemente la idempotencia para gestionar los mensajes duplicados. Es decir, cada mensaje debe procesarse solo una vez.
-
Tenga en cuenta las colas de mensajes fallidos
en caso de errores de procesamiento. -
Monitoree las tasas de éxito del procesamiento de mensajes.
Verificación de reclamación
Si un cliente necesita el resultado de una llamada de servicio, se puede crear el servicio para emitir una verificación de reclamación cuando reciba una solicitud. El siguiente diagrama ilustra este patrón. La verificación de reclamación se implementa como un identificador que el servicio devuelve en su acuse de recibo. El cliente puede usar este identificador más adelante para comprobar el estado de la solicitud y recuperar el resultado cuando se complete la solicitud.
Los clientes deben implementar un mecanismo para sondear los resultados. Esto podría automatizarse (por ejemplo, se puede realizar una verificación cada n minutos) o implementarse de manera manual, en el caso de que la verificación se realice en respuesta a otro evento o acción del usuario. Los servicios que implementan el patrón de verificación de reclamaciones deben especificar explícitamente el período de validez de una verificación de reclamaciones.
Prácticas recomendadas:
-
Implemente un retroceso exponencial en las votaciones.
-
Establezca un tiempo de vida (time to live, TTL) adecuado para la verificación de las reclamaciones.
-
Proporcione puntos de conexión de estado para el seguimiento del progreso.
Devolución de llamada
En el patrón de devolución de llamadas, un cliente emite una solicitud a un servicio y proporciona una ubicación para que el servicio se ponga en contacto con él cuando se complete el procesamiento. El cliente no espera el resultado y el procesamiento continúa. El servicio es responsable de ponerse en contacto con la ubicación una vez finalizado el procesamiento y de proporcionar el resultado. Los tipos comunes de ubicaciones para las respuestas son REST APIs o colas. En el siguiente diagrama, se ilustra el patrón de devolución de llamada.
Implementación:
-
Implemente mecanismos de reintento para las devoluciones de llamada fallidas.
-
Proteja la ubicación de la devolución de la llamada como lo haría con otros servicios.
-
Gestione los tiempos de espera de las devoluciones de llamadas.
Comunicación bidireccional
Para implementar la comunicación bidireccional, debe crear una conexión con estado entre un cliente y un servicio, que permita que tanto el cliente como el servicio envíen y procesen mensajes. Esto se explica en el siguiente diagrama. Aunque la comunicación es asíncrona, el servicio debe poder admitir una conexión abierta para cada cliente.
Consideraciones de implementación:
-
Ordenación de los mensajes
-
Números de secuencia
-
Estrategias de partición
-
Ordenación de los mensajes
-
-
Administración de estados
-
Patrón de abastecimiento de eventos
-
Reconciliación de estado
-
Modelos de coherencia
-
-
Gestión de errores
-
Políticas de reintentos
-
Estrategias alternativas
-
Supervisión y observabilidad
-
Correlación IDs
-
Seguimiento de mensajes
-
Métricas de desempeño
-
Indicadores de estado del sistema
-
