java - Hystrix: Interruptor personalizado y lógica de recuperación

fault-tolerance

Question

Acabo de leer la guía de Hystrix y estoy tratando de comprender cómo funcionan los interruptores de circuito y el período de recuperación predeterminados, y cómo personalizar su comportamiento.

Obviamente, si el circuito se desconecta, Hystrix llamará automáticamente al método getFallBack() del comando; Esto lo entiendo mucho. Pero, ¿qué criterios van a hacer que el circuito se dispare en primer lugar? Idealmente, me gustaría intentar golpear un servicio de respaldo varias veces (por ejemplo, un máximo de 3 intentos) antes de que consideremos que el servicio está fuera de línea / no es saludable y dispara el interruptor automático. ¿Cómo podría implementar esto, y dónde?

Pero me imagino que si anulo el interruptor automático predeterminado, también debo anular cualquier mecanismo que maneje el período de recuperación predeterminado. Si un servicio de respaldo falla, podría ser por cualquiera de varias razones:

• Hay una interrupción de la red entre el cliente y el servidor
• El servicio se implementó con un error que lo hace incapaz de devolver respuestas válidas al cliente
• El cliente se implementó con un error que lo hace incapaz de enviar solicitudes válidas al servidor
• Algunos contratiempos extraños y momentáneos (quizás el servicio está haciendo una gran recolección de basura, etc.)
• etc.

En la mayoría de estos casos, no es suficiente tener un período de recuperación que simplemente espere N segundos y luego vuelva a intentarlo. Si el servicio tiene un error, o si alguien extrajo algunos cables de red en el centro de datos, siempre obtendremos fallas en este servicio. Solo en un pequeño número de casos, el servicio al cliente se curará automáticamente sin ninguna interacción humana.

Entonces, supongo que mi siguiente pregunta es parcialmente " ¿Cómo personalizo la estrategia predeterminada del período de recuperación? ", Pero creo que es principalmente: " ¿Cómo uso Hystrix para notificar a los devops cuando un servicio está inactivo y requiere intervención manual? "

Answer 1

Básicamente, existen cuatro razones por las que Hystrix llama al método de reserva : una excepción, un tiempo de espera, demasiadas solicitudes paralelas o demasiadas excepciones en las llamadas anteriores.

Es posible que desee hacer un reintento en su método run () si el código de retorno o la excepción que recibe de su servicio indican que un reintento tiene sentido.

En su método de respaldo del comando, puede volver a intentarlo cuando hubo un tiempo de espera: cuando hay demasiadas solicitudes paralelas o demasiadas excepciones, por lo general no tiene sentido volver a llamar al mismo servicio.

También se le preguntó cómo notificar a los devops : debe conectar un sistema de monitoreo a Hystrix que evalúe el estado del interruptor y la proporción de llamadas exitosas y no exitosas. Puede utilizar los editores de métricas proporcionados, JMX, o escribir su propio adaptador utilizando la API de Hystrix. Escribí dos adaptadores para Riemann y Zabbix en un tutorial que preparé ; Vas a tener muy pocas líneas de código para eso.

El tutorial también tiene una aplicación de ejemplo y un controlador de carga para probar algunos escenarios.

Br, Alexander.