De París a Berlín: cómo crear disyuntores en Kotlin

1. Introducción se utilizan hoy en día para evitar que se realice una cantidad excesiva de solicitudes a uno u otro servicio que no responde. Cuando, por ejemplo, un servicio se apaga, por cualquier motivo, un disyuntor debería, como indica su nombre, romper el circuito. En otras palabras, en una situación en la que se están realizando 1 millón de solicitudes al mismo tiempo para obtener los resultados de una carrera de caballos, queremos que estas solicitudes se redirijan a otro servicio que pueda manejarlas. Circuit-breakers Este otro servicio puede ser una réplica del anterior o puede utilizarse simplemente para realizar otras operaciones relacionadas con el fallo del servicio original. El objetivo final siempre es interrumpir las llamadas innecesarias y dirigir el flujo a otro lugar. En , llevó el patrón de diseño Circuit Breaker a la vanguardia del diseño de desarrollo de software. Esto se hizo en su publicación Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition. 2017 Michael Nygard El patrón de diseño está inspirado en circuitos electrónicos y eléctricos reales. Sin embargo, en términos de un concepto general, la idea del disyuntor fue inventada en por . Al igual que en esa época, es necesario manejar una corriente desbordante. En términos muy, muy simples, esto es lo que estamos aplicando a la arquitectura de software en este caso. El objetivo principal es asegurarse de que el sistema sea lo suficientemente resistente. Cuán resistente debe ser y cuán debe ser realmente depende de los ingenieros responsables de facilitar la implementación de este patrón. La idea detrás de esto es que bajo ciertas condiciones podemos querer redirigir sin problemas el flujo de una determinada solicitud a otro flujo más disponible detrás del mismo . circuit breaker 1879 Thomas Edison fault-tolerant endpoint Digamos que queremos realizar una solicitud de a De vez en cuando, B falla y siempre está disponible. Si falla aleatoriamente, queremos llegar para que nuestro servicio esté completamente disponible. Sin embargo, para realizar solicitudes de vuelta a , queremos asegurarnos de que no vuelva a fallar con tanta frecuencia. Podemos configurar nuestro sistema para que realice solicitudes aleatorias a B y solo regrese completamente a una vez que la tasa de fallas haya bajado un cierto nivel. A B C B C B B B Es posible que queramos realizar una solicitud C en caso de error, pero también en caso de latencia. Si es muy lento, es posible que queramos volver a enviar todas las solicitudes a Hay muchas otras configuraciones posibles, como intentar llegar a si después de una cantidad definida de intentos, tipos de solicitud, subprocesos simultáneos y muchas otras opciones. Esto también se conoce como y es principalmente un movimiento temporal. B C C short-circuiting Para entender mejor lo que sabemos sobre lo que es realmente un disyuntor, tenemos que entender que un disyuntor funciona como una entidad en nuestra aplicación. Hay tres estados principales para un disyuntor. Puede estar cerrado, abierto o semiabierto. Un estado cerrado significa que los flujos de nuestra aplicación se ejecutan normalmente. Podemos realizar solicitudes de forma segura al servicio A, sabiendo que todas las solicitudes irán al servicio B. Un estado abierto significa que todas las solicitudes al servicio B fallarán. Las reglas que hemos definido para representar un fallo se han cumplido y ya no llegamos al servicio B. En este caso, siempre se devuelve una excepción. Un estado es cuando nuestro disyuntor recibe instrucciones de realizar pruebas en el servicio B para ver si está operativo nuevamente. half-open Cada solicitud exitosa se maneja normalmente, pero continuará realizando solicitudes a C. Si B se comporta como se espera de acuerdo con las reglas de verificación que hemos establecido, nuestro disyuntor volverá a un estado cerrado y el servicio A comenzará a realizar solicitudes exclusivamente al servicio B. En la mayoría de las aplicaciones, un disyuntor sigue el patrón de diseño del decorador. Sin embargo, se puede implementar manualmente y veremos tres formas programáticas de implementar disyuntores y, finalmente, usar una implementación basada en AOP. El código está disponible en . GitHub 2. Controles del vehículo En el último punto de este artículo, analizaremos un juego de carreras de coches. Sin embargo, antes de llegar a ese punto, me gustaría explicarles algunos aspectos de la creación de una aplicación que se ejecute con un . circuit breaker 2.1. Kystrix (de-paris-a-berlin-aplicación-ejecutable-kystrix) , como un pequeño , es una biblioteca sorprendente inventada y creada por . La biblioteca ofrece muchas posibilidades, incluida la integración con Spring y Spring WebFlux. Es interesante echarle un vistazo y jugar un poco con ella: Kystrixs DSL Johan Haleby se.haleby.kystrix kystrix-core se.haleby.kystrix kystrix-spring He creado un ejemplo que se encuentra en el módulo en . Primero, echemos un vistazo al código: from-paris-to-berlin-kystrix-runnable-app GitHub @GetMapping("/{id}") private fun getCars(@PathVariable id: Int): Mono { return if (id == 1) Mono.just(Car("Jaguar")) else { hystrixObservableCommand { groupKey("Test2") commandKey("Test-Command2") monoCommand { webClient.get().uri("/cars/carros/1").retrieve().bodyToMono () .delayElement(Duration.ofSeconds(1)) } commandProperties { withRequestLogEnabled(true) withExecutionTimeoutInMilliseconds(5000) withExecutionTimeoutEnabled(true) withFallbackEnabled(true) withCircuitBreakerEnabled(false) withCircuitBreakerForceClosed(true) } fallback { Observable.just(Car("Tank1")) } }.toMono() } } Este código representa el comando 2 del ejemplo. Verifique el código del comando 1. Lo que sucede aquí es que estamos definiendo el comando que queremos con . Aquí, definimos el método que necesitamos llamar. En , definimos las reglas que hacen que el cambie de estado a abierto. Retrasamos explícitamente nuestra llamada para que dure exactamente 1 segundo. monoCommand commandProperties circuit-breaker Al mismo tiempo, definimos un tiempo de espera de milisegundos. Esto significa que nunca alcanzaremos un tiempo de espera. En este ejemplo, podemos realizar llamadas con un . Dado que esto es solo una prueba, asumimos que , es un de un automóvil, un Jaguar sin necesidad de un . Esto también significa que nunca obtendremos Tank1 como se define en el método de respaldo. Si aún no lo ha notado, observe detenidamente el método de respaldo. Este método utiliza un . Aunque se implementa de acuerdo con el patrón de diseño , no es exactamente un Observable. 5000 Id Id=1 Id circuit-breaker Observable WebFlux Observable Flux Sin embargo, hystrix admite ambos. Ejecute la aplicación y abra su navegador en para confirmarlo. Es importante comprender que si comienza a realizar llamadas muy temprano en el inicio de Spring Boot, es posible que eventualmente reciba un mensaje de Tank1. Esto se debe a que el retraso de inicio puede superar los 5 segundos muy fácilmente según cómo esté ejecutando este proceso. En el segundo ejemplo, vamos a hacer un cortocircuito en nuestro ejemplo con Tank 2: http://localhost:8080/cars/2 @GetMapping("/timeout/{id}") private fun getCarsTimeout(@PathVariable id: Int): Mono { return if (id == 1) Mono.just(Car("Jaguar")) else { hystrixObservableCommand { groupKey("Test3") commandKey("Test-Command3") monoCommand { webClient.get().uri("/cars/carros/1").retrieve().bodyToMono () .delayElement(Duration.ofSeconds(1)) } commandProperties { withRequestLogEnabled(true) withExecutionIsolationThreadInterruptOnTimeout(true) withExecutionTimeoutInMilliseconds(500) withExecutionTimeoutEnabled(true) withFallbackEnabled(true) withCircuitBreakerEnabled(false) withCircuitBreakerForceClosed(true) } fallback { Observable.just(Car("Tank2")) } }.toMono() } } En este ejemplo, nuestro pasará a un estado abierto y devolverá el Tanque 2 como respuesta. Esto se debe a que también estamos provocando un retraso de 1 s aquí, pero especificamos que nuestra condición de disyuntor se activa después de la marca de 500 ms. Si sabes cómo funciona , verás que no es nada diferente en el futuro. Lo que Hystrix no me proporcionó en este momento fue una forma sencilla y sin problemas de proporcionar lo que necesitaba para hacer el juego. parece funcionar en base al cliente. Esto significa que tenemos que declarar nuestro código antes de realizar solicitudes a los servicios detrás de nuestro servicio principal. circuit-breaker hystrix kystrix Kystrix 2.2 Resiliencia4J Muchos consideran que es una implementación muy completa de un disyuntor. Mis primeros ensayos se centraron en explorar algunos aspectos importantes de los disyuntores. En concreto, quería ver un disyuntor que pudiera funcionar en función de los tiempos de espera y la frecuencia de las solicitudes exitosas. permite configurar distintos tipos de módulos . Estos se dividen en categorías diferentes: , , , y . Todos ellos son también nombres de patrones de diseño. El módulo proporciona una implementación completa de este patrón. Resilience4J Resilience4J short-circuiting 6 CircuitBreaker Bulkhead Ratelimiter Retry Timelimiter CircuitBreaker Tenemos muchos parámetros que podemos configurar, pero básicamente, el módulo nos permite configurar qué reconocemos como un fallo, cuántas peticiones permitimos en un estado semiabierto y una ventana deslizante, que puede configurarse por tiempo o por conteo, donde llevamos el conteo de peticiones que ocurren en un estado cerrado. Esto es importante para calcular la frecuencia de errores. Básicamente, podríamos decir que este módulo nos ayudará con la tasa de peticiones, pero eso no es necesariamente cierto. CircuitBreaker CircuitBreaker Depende de cómo lo interpretes. Parece una mejor manera de pensarlo como simplemente una forma de lidiar con fallas. Ya sea que provengan de un tiempo de espera o una excepción, aquí es donde se tratan y cómo las solicitudes se pueden redirigir sin problemas a otro lugar. El módulo está diseñado para lidiar con solicitudes simultáneas. No es un limitador de velocidad. Bulkhead En su lugar, implementa el patrón de diseño , que se utiliza para evitar que se produzca demasiado procesamiento en un único punto final. En este caso, nos permite procesar nuestras solicitudes de forma que se distribuyan entre todos los puntos finales disponibles. El nombre proviene de los diferentes compartimentos sellados que suele tener un gran barco para evitar hundirse en caso de que se produzca un accidente y, como en el caso de los barcos, debemos definir cuántos subprocesos estarán disponibles en el grupo de subprocesos y su tiempo de arrendamiento. Bulkhead Bulkhead Bulkhead El módulo está diseñado para gestionar la tasa de solicitudes. La diferencia entre este y el módulo es que queremos ser tolerantes con las tasas hasta un cierto punto. Esto significa que no necesitamos provocar un fallo para ello. Simplemente decimos, en el diseño, que no toleramos una tasa por encima de un cierto valor. Además, podemos redirigir una solicitud o mantenerla en espera hasta que se conceda el permiso para realizarla. El módulo es probablemente el más fácil de entender, ya que no tiene mucho en común con los otros módulos. RateLimiter Bulkhead Retry Básicamente, declaramos explícitamente la cantidad de reintentos a un punto final determinado, hasta que alcanzamos nuestro umbral definido. El módulo puede verse como una simplificación del módulo , ya que ambos comparten la posibilidad de configurar tiempos de espera. Sin embargo, no depende de otros parámetros como ventanas deslizantes y tampoco tiene un cálculo de umbral de falla integrado. Timelimiter CircuitBreaker Timelimiter Entonces, si estamos puramente interesados en manejar los tiempos de espera al llamar a un determinado servicio y no tenemos en cuenta otras posibles fallas, entonces probablemente estemos mejor con . Timelimiter 2.2.1. Resilience4J con Kotlin y sin el framework Spring (aplicación ejecutable de Resilience4J desde París a Berlín) En este módulo, decidí utilizar solo la biblioteca Kotlin : resilience4j io.github.resilience4j resilience4j-kotlin io.github.resilience4j resilience4j-retry io.github.resilience4j resilience4j-circuitbreaker io.github.resilience4j resilience4j-ratelimiter io.github.resilience4j resilience4j-timelimiter Esta implementación está disponible en el repositorio de GitHub. Primero, veremos el patrón : TimeLimiter var timeLimiterConfig: TimeLimiterConfig = TimeLimiterConfig.custom() .timeoutDuration(Duration.ofMillis(100)) .build() var timeLimiter: TimeLimiter = TimeLimiter.of("backendName", timeLimiterConfig) private suspend fun getPublicCar(): Car { return timeLimiter.decorateSuspendFunction { getPrivateCar() }.let { suspendFunction -> try { suspendFunction() } catch (exception: Exception) { Car("Opel Corsa") } } } private suspend fun getPrivateCar(): Car { delay(10000) return Car("Lancya") } En este caso, decoramos nuestra con la funcionalidad usando la función . Esto provocará un tiempo de espera, si la función que llamamos tarda demasiado obtendremos un Opel Corsa en lugar de un Lancya. Para probar esto, podemos simplemente ejecutar la aplicación y abrir . function getPrivateCar TimeLimiter decorateSuspendFunction http://localhost:8080/cars/timelimiter/normal/1 Si analizamos la implementación, vemos que nunca podemos obtener un . Y esto se debe a que esperamos deliberadamente antes de devolverlo. Nuestro tiene un tiempo de espera mucho menor, por lo que esto nunca funcionará. Un es bastante simple de entender. Un , por otro lado, puede ser una historia diferente. Este es un ejemplo de cómo se puede hacer: Lancya 10s TimeLimiter TimeLimiter CircuitBreaker val circuitBreakerConfig = CircuitBreakerConfig.custom() .failureRateThreshold(20f) .slowCallRateThreshold(50f) .slowCallDurationThreshold(Duration.ofMillis(1000)) .waitDurationInOpenState(Duration.ofMillis(1000)) .maxWaitDurationInHalfOpenState(Duration.ofMillis(1000)) .permittedNumberOfCallsInHalfOpenState(500) .minimumNumberOfCalls(2) .slidingWindowSize(2) .slidingWindowType(COUNT_BASED) .build() val circuitBreaker = CircuitBreakerRegistry.of(circuitBreakerConfig).circuitBreaker("TEST") private suspend fun getPublicCar(id: Long): Car { return circuitBreaker.decorateSuspendFunction { getPrivateCar(id) }.let { suspendFunction -> try { suspendFunction() } catch (exception: Exception) { Car("Opel Corsa") } } } private fun getPrivateCar(id: Long): Car { if (id == 2L) { throw RuntimeException() } return Car("Lancya") } En este caso, estamos diciendo que queremos que nuestro disyuntor cierre el circuito una vez que la tasa de fallas sea inferior al con la propiedad. Las llamadas lentas también tendrán un umbral, pero en este caso será inferior al 50 %. Decimos que una llamada lenta debe durar más de 1 s para ser considerada como tal. También estamos especificando que la duración de un estado semiabierto debe ser de 1 s. Esto significa que, en la práctica, tendremos un estado abierto, un estado semiabierto o un estado cerrado. 20% También decimos que permitimos un máximo de 500 solicitudes de estado semiabierto. Para los cálculos de error, el disyuntor necesita saber en qué marca lo hará. Esto es importante para determinar cuándo cerrar el circuito. Decimos que 2 solicitudes serán mínimamente necesarias para este cálculo, con la propiedad . ¿Recuerda que el estado semiabierto es cuando seguiremos intentando que el circuito se cierre si las solicitudes alcanzan un umbral de falla seguro? minimumNumberOfCalls En esta configuración, significa que necesitamos hacer al menos peticiones, dentro de la ventana deslizante, para calcular la frecuencia de error y determinar si se vuelve a un estado cerrado o no. Esta es la lectura precisa de todas las variables que hemos configurado. En general, lo que esto significa es que nuestra aplicación probablemente hará varias llamadas al servicio alternativo, en caso de que haya alguna, no pasará muy fácilmente de estados abiertos a cerrados dado que la tasa de éxito para hacerlo debe ser del 80% durante los estados semiabiertos y debe haberse agotado el tiempo de espera para el estado abierto. 2 Existen muchas formas de especificar dichos tiempos de espera. En nuestro ejemplo, decimos que es 1 s. Esto significa que nuestro mantendrá el estado abierto, solo si nuestra verificación no satisface la condición de estado cerrado o si este tiempo de espera aún no se ha producido. El comportamiento definido en este puede ser difícil de seguir y predecir, simplemente porque los tiempos de inactividad específicos, las tasas y otras características de las solicitudes simplemente no se pueden replicar exactamente, pero si realizamos varias solicitudes a este punto final, veremos que el comportamiento descrito anteriormente coincide con nuestra experiencia. maxDurationInHalfOpenState CircuitBreaker CircuitBreaker Entonces, intentemos realizar varias solicitudes a los puntos finales: y . Terminar en 1 es el punto final de una recuperación de automóvil exitosa, y terminar en 2 es el punto final de un error en la obtención de un automóvil específico. Mirando el código, vemos que cualquier cosa diferente a 2 significa que obtenemos un como respuesta. Un , significa que inmediatamente lanzamos una excepción de tiempo de ejecución, lo que significa que terminamos obteniendo un como respuesta. http://localhost:8080/cars/circuit/1 http://localhost:8080/cars/circuit/2 Lancya 2 Opel Corsa Si solo hacemos solicitudes al punto final , seguiremos viendo como respuesta. Si el sistema comienza a fallar, es decir, cuando realiza solicitudes al punto final 2, verá que volver a no será una constante después de un tiempo. El informará que está en estado abierto y que no se permiten más solicitudes. 1 Lancya Lancya System 2021-10-20 09:56:50.492 ERROR 34064 --- [ctor-http-nio-2] .fcbrrcCarControllerCircuitBreaker : io.github.resilience4j.circuitbreaker.CallNotPermittedException: CircuitBreaker 'TEST' is OPEN and does not permit further calls Nuestro disyuntor pasará entonces a un estado semiabierto después de una solicitud exitosa, y esto significa que necesitaremos realizar algunas solicitudes de regreso a 1 antes de que se normalice. Cambiaremos de a un par de veces antes de que obtengamos solo nuevamente. Definimos este número como 2. Este es el mínimo para el cálculo de errores. Si solo causamos una falla y seguimos llamando al punto final que no falla, podemos obtener una imagen más clara de lo que está sucediendo: Lancya Opel Corsa Lancya 2021-10-20 11:53:29.058 ERROR 34090 --- [ctor-http-nio-4] .fcbrrcCarControllerCircuitBreaker : java.lang.RuntimeException 2021-10-20 11:53:41.102 ERROR 34090 --- [ctor-http-nio-4] .fcbrrcCarControllerCircuitBreaker : io.github.resilience4j.circuitbreaker.CallNotPermittedException: CircuitBreaker 'TEST' is OPEN and does not permit further calls Este mensaje de estado abierto, si bien es cierto, apareció después de que realicé dos solicitudes al punto final que no presentaba errores. Por eso se dice que el estado está semiabierto. 2.2.2. Resilience4J con Spring Boot y sin AOP (de-paris-a-berlin-resilience4j-spring-app) En el segmento anterior, vimos cómo implementarlo de una manera muy programática, sin el uso de ninguna tecnología Spring. Usamos Spring, pero solo para brindar un tipo de servicio . Además, no cambiamos nada de los servicios en sí. En la siguiente aplicación, exploraremos las siguientes bibliotecas: WebFlux MVC io.github.resilience4j resilience4j-spring-boot2 io.github.resilience4j resilience4j-all io.github.resilience4j resilience4j-reactor Al observar cómo se hace el código, podemos ver una gran diferencia: @RestController @RequestMapping("/cars") class CarController( private val carService: CarService, timeLimiterRegistry: TimeLimiterRegistry, circuitBreakerRegistry: CircuitBreakerRegistry, bulkheadRegistry: BulkheadRegistry ) { private var timeLimiter: TimeLimiter = timeLimiterRegistry.timeLimiter(CARS) private var circuitBreaker = circuitBreakerRegistry.circuitBreaker(CARS) private var bulkhead = bulkheadRegistry.bulkhead(CARS) @GetMapping("/{id}") private fun getCars(@PathVariable id: Int): Mono { return carService.getCar() .transform(TimeLimiterOperator.of(timeLimiter)) .transform(CircuitBreakerOperator.of(circuitBreaker)) .transform(BulkheadOperator.of(bulkhead)) .onErrorResume(TimeoutException::class.java, ::fallback) } @GetMapping("/test/{id}") private fun getCarsTest(@PathVariable id: Int): Mono { return carService.getCar() .transform(TimeLimiterOperator.of(timeLimiter)) .transform(CircuitBreakerOperator.of(circuitBreaker)) .transform(BulkheadOperator.of(bulkhead)) .onErrorResume(TimeoutException::class.java, ::fallback) } @GetMapping("/carros/{id}") private fun getCarros(@PathVariable id: Long): Mono { return Mono.just(Car("Laborghini")) } private fun fallback(ex: Throwable): Mono { return Mono.just(Car("Rolls Royce")) } } En este ejemplo y en el siguiente, nos centraremos principalmente en las propiedades de tiempo de espera. Las complejidades de en sí son menos relevantes porque este es un artículo introductorio. Lo que es importante entender aquí es lo fácil que es implementar esto con los decoradores proporcionados para Spring por . Aunque todavía de forma , podemos decorar fácilmente nuestro editor inicial, el que obtenemos de , con los tipos de que queremos. CircuitBreaker Resilience4J programmatical carService.getCar() short-circuit En este ejemplo, registramos un , un y un . Por último, definimos la función de reserva que se activará una vez que se produzca una TimeoutException. Lo que aún necesitamos ver es cómo se configura todo esto. Configuramos Resilience4J en Spring como cualquier otro módulo configurable. Usamos : TimeLiter BulkHead CircuitBreaker application.yml resilience4j.circuitbreaker: configs: default: registerHealthIndicator: true slidingWindowSize: 10 minimumNumberOfCalls: 5 permittedNumberOfCallsInHalfOpenState: 3 automaticTransitionFromOpenToHalfOpenEnabled: true waitDurationInOpenState: 5s failureRateThreshold: 50 eventConsumerBufferSize: 10 recordExceptions: - org.springframework.web.client.HttpServerErrorException - java.util.concurrent.TimeoutException - java.io.IOException ignoreExceptions: # - io.github.robwin.exception.BusinessException shared: slidingWindowSize: 100 permittedNumberOfCallsInHalfOpenState: 30 waitDurationInOpenState: 1s failureRateThreshold: 50 eventConsumerBufferSize: 10 ignoreExceptions: # - io.github.robwin.exception.BusinessException instances: cars: baseConfig: default roads: registerHealthIndicator: true slidingWindowSize: 10 minimumNumberOfCalls: 10 permittedNumberOfCallsInHalfOpenState: 3 waitDurationInOpenState: 5s failureRateThreshold: 50 eventConsumerBufferSize: 10 # recordFailurePredicate: io.github.robwin.exception.RecordFailurePredicate resilience4j.retry: configs: default: maxAttempts: 3 waitDuration: 100 retryExceptions: - org.springframework.web.client.HttpServerErrorException - java.util.concurrent.TimeoutException - java.io.IOException ignoreExceptions: # - io.github.robwin.exception.BusinessException instances: cars: baseConfig: default roads: baseConfig: default resilience4j.bulkhead: configs: default: maxConcurrentCalls: 100 instances: cars: maxConcurrentCalls: 10 roads: maxWaitDuration: 10ms maxConcurrentCalls: 20 resilience4j.thread-pool-bulkhead: configs: default: maxThreadPoolSize: 4 coreThreadPoolSize: 2 queueCapacity: 2 instances: cars: baseConfig: default roads: maxThreadPoolSize: 1 coreThreadPoolSize: 1 queueCapacity: 1 resilience4j.ratelimiter: configs: default: registerHealthIndicator: false limitForPeriod: 10 limitRefreshPeriod: 1s timeoutDuration: 0 eventConsumerBufferSize: 100 instances: cars: baseConfig: default roads: limitForPeriod: 6 limitRefreshPeriod: 500ms timeoutDuration: 3s resilience4j.timelimiter: configs: default: cancelRunningFuture: false timeoutDuration: 2s instances: cars: baseConfig: default roads: baseConfig: default Este archivo es un archivo de ejemplo tomado de su repositorio y modificado según mi ejemplo. Como hemos visto antes, las instancias de los diferentes tipos de tienen un nombre. El nombre es muy importante si tienes muchos registros diferentes y limitadores diferentes. Para nuestro ejemplo, y tal como se mencionó antes, nos interesa el limitador de tiempo. Podemos ver que está limitado a 2 s. Si observamos la forma en que hemos implementado el servicio, vemos que estamos forzando que se produzca un tiempo de espera: limiters/short-circuit @Component open class CarService { open fun getCar(): Mono { return Mono.just(Car("Fiat")).delayElement(Duration.ofSeconds(10)); } } Iniciemos la aplicación y, en el navegador, vayamos a: . En lugar de obtener un , obtendremos un . Así es como definimos el tiempo de espera. De la misma manera, podemos crear fácilmente un . http://localhost:8080/cars/test/2 Fiat Rolls Royce CircuitBreaker 3. Caso Hasta ahora, hemos visto tres formas esenciales de implementar y limitadores relacionados. Además, veremos mi forma favorita de implementar disyuntores a través de una aplicación que he creado, que es un juego muy simple en el que simplemente hacemos clic en cuadrados para ir de París a Berlín. El juego está hecho para entender cómo implementarlo. No dice mucho sobre dónde implementarlo. Es solo un caso que he diseñado para compartir con ustedes el conocimiento práctico. CircuitBreakers El momento de decidirlo os lo dejo a vosotros más tarde. Básicamente, queremos crear una serie de coches y establecer una ruta hacia Berlín. En diferentes lugares de esta ruta, llegaremos a ciudades en las que, aleatoriamente, crearemos problemas. Nuestros decidirán cuánto tiempo tendremos que esperar antes de que se nos permita seguir adelante. Los demás coches no tienen ningún problema y solo tenemos que elegir la ruta correcta. circuit breakers Se nos permite consultar un horario en el que se registra cuándo ocurrirá un determinado problema en una ciudad en una determinada marca de minutos. La marca de minutos es válida en sus 0 posiciones indexadas. Esto significa que 2 significa que marca de 2, 12, 22, 32, 42, 52 minutos en el reloj será válida para crear este problema. Los problemas serán de 2 tipos: y . Un error le dará un retraso de 20 segundos. every ERROR TIMEOUT Un tiempo de espera te dará un retraso de 50 segundos. Por cada cambio de ciudad, todos tienen que esperar 10 segundos. Sin embargo, antes de esperar, el coche ya está en la entrada de la siguiente ciudad cuando esto se hace en los métodos de respaldo. En este caso, la siguiente ciudad se elige aleatoriamente. 4. Implementación Ya hemos visto antes cómo configurar nuestro registro usando . Una vez hecho esto, veamos algunos ejemplos de cómo decorar nuestras funciones: resilience4j application.yml @TimeLimiter(name = CarService.CARS, fallbackMethod = "reportTimeout") @CircuitBreaker(name = CarService.CARS, fallbackMethod = "reportError") @Bulkhead(name = CarService.CARS) open fun moveToCity(id: Long): Mono { val myCar = roadRace.getMyCar() if (!myCar.isWaiting()) { val destination = myCar.location.forward.find { it.id == id } val blockage = destination?.blockageTimeTable?.find { it.minute.toString().last() == LocalDateTime.now().minute.toString().last() } blockage?.let { roadBlockTime -> when (roadBlockTime.blockageType) { BlockageType.TIMEOUT -> return Mono.just(roadRace).delayElement(Duration.ofSeconds(10)) BlockageType.ERROR -> return Mono.create { it.error(BlockageException()) } BlockageType.UNKNOWN -> return listOf(Mono.create { it.error(BlockageException()) }, Mono.just(roadRace).delayElement(Duration.ofSeconds(10))).random() else -> print("Nothing to do here!") } } destination?.let { myCar.delay(10) myCar.location = it myCar.formerLocations.add(myCar.location) } } return Mono.just(roadRace) } private fun reportError(exception: Exception): Mono { logger.info("---- **** error reported") roadRace.getMyCar().delay(20L) roadRace.getMyCar().randomFw() roadRace.errorReports.add("Error reported! at ${LocalDateTime.now()}") return Mono.create { it.error(BlockageException()) } } private fun reportTimeout(exception: TimeoutException): Mono { logger.info("---- **** timeout reported!") roadRace.getMyCar().delay(50L) roadRace.getMyCar().randomFw() roadRace.errorReports.add("Timeout reported! at ${LocalDateTime.now()}") return Mono.just(roadRace) } Como podemos ver, las llamadas de servicio originales están decoradas directamente mediante anotaciones. Esto solo se puede hacer gracias a la presencia del módulo en el paquete: AOP org.springframework.boot spring-boot-starter-aop , o , es otro paradigma de programación basado en . Se considera un complemento de , y es precisamente así como funcionan muchas anotaciones. Esto permite la activación de otras funciones alrededor, antes o después del método original en puntos de corte precisos. Como se puede ver en el ejemplo, estamos generando tiempos de espera o errores. La , también se genera dentro del método fallback. Esto no representa un problema. Excepto por la respuesta. AOP Aspect Oriented Programming OOP OOP BlockageException Sin embargo, la aplicación se ejecuta en por lo tanto, este error no se verá en la aplicación. Hasta ahora, este era el juego. Implementé esto con el objetivo de mostrar cómo el uso de anotaciones puede hacernos la vida mucho más fácil al implementar una aplicación resistente. No solo hemos implementado CircuitBreakers, sino también otras tecnologías, como , , , , y varias otras. Todo esto se ha hecho para ver cómo se desarrollarían los CircuitBreakers en una aplicación. Si desea jugar con esta aplicación, vaya a la raíz del proyecto y ejecute: WebSockets, WebSockets Spring WebFlux Docker NGINX typescript make docker-clean-build-start Luego ejecute este comando: curl -X POST http://localhost:8080/api/fptb/blockage -H "Content-Type: application/json" --data '{"id":1,"name":"Paris","forward":[{"id":2,"name":"Soissons","forward":[{"id":5,"name":"Aken","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":6,"name":"Heerlen","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":7,"name":"Düren","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":3,"name":"Compiègne","forward":[{"id":5,"name":"Aken","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":6,"name":"Heerlen","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":7,"name":"Düren","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":4,"name":"Reims","forward":[{"id":5,"name":"Aken","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":6,"name":"Heerlen","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]},{"id":7,"name":"Düren","forward":[{"id":8,"name":"Berlin","forward":[],"blockageTimeTable":[]}],"blockageTimeTable":[]}],"blockageTimeTable":[]}],"blockageTimeTable":[]}' La carga útil de esta solicitud se genera utilizando el módulo . Si observas este módulo, verás que es bastante simple de entender y que puedes generar tu propio mapa para el juego. Por último, ve a y tu aplicación debería estar ejecutándose. Ahora, solo debes hacer clic en los cuadrados correctos para jugar. No hagas clic en los rojos si quieres ganar. Sin embargo, si quieres ver el disyuntor en acción, ejecuta los registros de la aplicación: from-paris-to-berlin-city-generator http://localhost:9000 docker logs from_paris_to_berlin_web -f Y haga clic explícitamente en los cuadrados rojos para provocar un fallo. 5. En qué se diferencian Kystrix y Resilience4J es ideal en los casos en los que su aplicación es pequeña y desea asegurarse de mantener el uso del DSL realmente bajo. El único inconveniente es que no ofrece una forma sencilla de decorar los métodos que se verán afectados por un disyuntor. parece ser una gran opción para el trabajo empresarial con disyuntores. Proporciona programación basada en anotaciones, utiliza todos los beneficios de AOP y sus módulos están separados. De alguna manera, también se puede utilizar estratégicamente para puntos críticos de la aplicación. También se puede utilizar como un marco completo para cubrir muchos aspectos de una aplicación. Kystrix Resilience4J 6. Conclusión Independientemente de la marca que elijamos, el objetivo siempre es tener una aplicación resistente. En este artículo, mostré algunos ejemplos de mi experiencia personal en la investigación de disyuntores y mis hallazgos a un nivel muy alto. Esto significa que este artículo está realmente escrito para personas que desean saber qué son los disyuntores y qué pueden hacer los limitadores. Las posibilidades son francamente infinitas cuando pensamos en mejorar nuestras aplicaciones con mecanismos de resiliencia como . Este patrón permite ajustar con precisión una aplicación para hacer un mejor uso de los recursos disponibles que tenemos. Sobre todo en la nube, sigue siendo muy importante optimizar nuestros costos y la cantidad de recursos que realmente necesitamos asignar. circuit breakers Configurar no es una tarea sencilla como lo es para los limitadores, y realmente necesitamos entender todas las posibilidades de configuración para alcanzar niveles óptimos de rendimiento y resiliencia. Esta es la razón por la que no quería entrar en detalles en este artículo introductorio sobre disyuntores. CircuitBreakers se pueden aplicar a muchos tipos diferentes de aplicaciones. La mayoría de las aplicaciones de mensajería y transmisión por secuencias lo necesitarán. Para las aplicaciones que manejan grandes volúmenes de datos que también necesitan estar altamente disponibles, podemos y debemos implementar algún tipo de disyuntor. Las grandes tiendas minoristas en línea necesitan manejar cantidades masivas de datos a diario y, en el pasado, se usaba ampliamente. Actualmente, parece que nos estamos moviendo en la dirección de , que abarca mucho más que esto. Circuit-breakers Hystrix Resilience4J 6. Referencias https://youtu.be/kR2sm1zelI4 https://youtu.be/AiP2_icXpAk Mejora tu código Kotlin con Detekt Demostración de Spring Boot de Resilience 4J Netflix / Hystrix Kystrix: un DSL de Kotlin para Hystrix johanhaleby / kystrix resiliencia4j / resiliencia4j CircuitBreaker: Introducción a la resiliencia4j-circuitbreaker ¡Gracias! ¡Espero que hayas disfrutado de este artículo tanto como yo al crearlo! Deja una reseña, un comentario o cualquier sugerencia que quieras dar en cualquiera de las redes sociales en los enlaces que aparecen a continuación. Te agradecería mucho que me ayudaras a mejorar este artículo. He colocado todo el código fuente de esta aplicación en ¡Gracias por leer! GitHub.