Hablando de la ruptura del circuito de SpringCloud me recuerda a la ruptura del circuito en el mercado de valores el año pasado. Me he dado cuenta de muchos momentos dolorosos. El impacto de la ruptura del circuito aleatorio en todo el sistema es desastroso. Bueno, hablemos de los asuntos serios a continuación.
Fusible
Efecto de avalancha
En las arquitecturas de microservicio, generalmente hay múltiples capas de servicio para llamar. La falla del servicio subyacente puede conducir a fallas en cascada, lo que a su vez hace que todo el sistema no esté disponible. Este fenómeno se llama efecto de avalancha de servicio. El efecto Avalanche Service es un proceso en el que la falta de disponibilidad del "proveedor de servicios" conduce a la falta de disponibilidad de los "consumidores de servicios" y amplifica gradualmente la falta de disponibilidad.
Si la figura a continuación muestra: A es el proveedor de servicios, B es el consumidor de servicios de A, y C y D son los consumidores de servicios de B. La falta de disponibilidad de A causa la falta de disponibilidad de B y cuando la falta de disponibilidad se amplía a C y D como una bola de nieve, el efecto avalanche se forma.
Interruptor de circuito
El principio de un fusible es muy simple, como un protector de sobrecarga de energía. Puede lograr una falla rápida. Si detecta muchos errores similares durante un período de tiempo, obligará a sus llamadas posteriores a fallar rápidamente y ya no accederá al servidor remoto, evitando así que la aplicación intente constantemente realizar posibles operaciones de falla, lo que hace que la aplicación continúe ejecutando sin esperar la corrección del error, o perder el tiempo de CPU para esperar hasta que ocurra un tiempo de espera largo. El fusible también puede habilitar la aplicación para diagnosticar si el error se ha solucionado y si se ha solucionado, la aplicación intentará volver a llamar a la operación.
El modo de fusible es como un proxy que puede conducir fácilmente a operaciones incorrectas. Este proxy puede registrar el número de errores que ocurrieron en la llamada más reciente, y luego decidir usar la operación permitida para continuar, o devolver el error de inmediato.
La lógica de la conversión mutua de los interruptores de fusibles es la siguiente:
Los fusibles son la última línea de defensa para proteger la alta disponibilidad de servicios.
Características de Hystrix
1. Mecanismo del interruptor de circuito
El disyuntor es fácil de entender. Cuando el comando Hystrix solicita fallas de servicio de fondo excede una cierta proporción (predeterminado 50%), el interruptor de circuito cambiará al estado abierto (abierto). En este momento, todas las solicitudes fallarán directamente sin enviar al servicio de fondo. Después de que el interruptor de circuito permanece en estado abierto por un período de tiempo (predeterminado 5 segundos), cambiará automáticamente al estado medio abierto (medio abierto). En este momento, se juzgará el estado de devolución de la próxima solicitud. Si la solicitud es exitosa, el interruptor de circuito volverá al estado de circuito cerrado (cerrado), de lo contrario, cambiará al estado abierto (abierto). El disyuntor de Hystrix es como un fusible en nuestro circuito de origen. Una vez que el servicio de back-end no esté disponible, el interruptor de circuito cortará directamente el enlace de solicitud para evitar enviar una gran cantidad de solicitudes no válidas para afectar el rendimiento del sistema. El disyuntor tiene la capacidad de autodetección y recuperarse.
2.
El respaldo es equivalente a una operación de rebaja. Para las operaciones de consulta, podemos implementar un método de respaldo. Cuando se produce una excepción en un servicio posterior solicitado, se puede utilizar el valor devuelto por el método de retroceso. El valor de retorno del método alternativo generalmente se establece por el valor predeterminado o proviene del caché.
3. Aislamiento de recursos
En Hystrix, el aislamiento de recursos se logra principalmente a través de grupos de subprocesos. Por lo general, cuando lo usamos, dividimos múltiples grupos de hilos de acuerdo con el servicio remoto que llamamos. Por ejemplo, el comando que llama a los servicios de productos se coloca en un grupo de subprocesos, y el comando que llama a los servicios de cuentas se coloca en B Pool de subprocesos. La principal ventaja de esto es que el entorno en ejecución está aislado. De esta manera, incluso si el código que llama el servicio está molesto o el grupo de subprocesos que se consume debido a otras razones, no afectará a otros servicios del sistema. Sin embargo, el costo es que mantener múltiples grupos de subprocesos traerá una sobrecarga de rendimiento adicional al sistema. Si tiene requisitos de rendimiento estrictos y está seguro de que no habrá problemas con el código del cliente que llame al servicio, puede usar el modo de señal de Hystrix (semáforos) para aislar los recursos.
Feign Hystrix
Debido a que el interruptor de circuito solo funciona en el extremo de llamadas de servicio, solo necesitamos cambiar el código relevante del proyecto Spring-Cloud-Consumer en función del código de ejemplo en el artículo anterior. Debido a que Feign ya depende de Hystrix, no es necesario hacer ningún cambio en la configuración de Maven.
1. Archivo de configuración
Agregue esto a Application.Properties:
Feign.hystrix.enabled = True
2. Cree una clase de devolución de llamada
Crear herencia de clase HelloremoteHystrix y Helloremote para implementar devoluciones de llamada
@ComponentPublic Class HelloremoteHyStrix implementa Helloremote {@Override public String Hello (@RequestParam (valor = "Nombre") Nombre de cadena) {return "Hello" +Name +", este mensaje envía fallado"; }}3. Agregar atributo de retroceso
Agregue la clase de retroceso especificada a la clase Helloremote y devuelva el contenido en la clase de respaldo cuando el servicio esté circuito.
@FeignClient (name = "Spring-Cloud-Producer", Fallback = HelloreMoteHystrix.Class) Interfaz pública HelloreMote {@RequestMapping (value = "/Hello") Public String Hello (@RequestParam (valor = "Nombre") Nombre de cadena);}Este es el punto de cambio, es muy simple.
4. Prueba
Luego, lo pruebemos para ver el efecto.
Comience los tres proyectos Spring-Cloud-eureka, Spring-Cloud-Producer y Spring-Cloud-Consumer.
Ingrese en el navegador: http: // localhost: 9001/hello/neo
Regreso: Hola Neo, este es el primer mensaje
Significa que después de agregar información relacionada con el interruptor del circuito, no afectará el acceso normal. A continuación, detenemos manualmente el proyecto Spring-Cloud-Producer y lo probamos nuevamente:
Ingrese en el navegador: http: // localhost: 9001/hello/neo
Regreso: Hola Neo, este mensaje envía fallado
Según el resultado de retorno, el disyuntor se indicó con éxito.
Código de muestra
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.