No Parīzes līdz Berlīnei: kā izveidot slēdžus Kotlinā

1. Ievads mūsdienās tiek izmantoti, lai izvairītos no pārmērīga pieprasījumu skaita uz vienu vai otru nereaģējošo pakalpojumu. Ja, piemēram, pakalpojums kāda iemesla dēļ tiek pārtraukts, ķēdes pārtraucējam, kā norāda tā nosaukums, jāpārtrauc ķēde. Citiem vārdiem sakot, situācijā, kad vienlaikus tiek veikts 1 miljons pieprasījumu, lai iegūtu zirgu skriešanās sacensību rezultātus, mēs vēlamies, lai šie pieprasījumi tiktu novirzīti uz citu dienestu, kas to var apstrādāt. Circuit-breakers Šis cits pakalpojums var būt tā kopija, vai arī to var izmantot, lai veiktu citas darbības saistībā ar sākotnējo pakalpojuma kļūmi. Gala mērķis vienmēr ir pārtraukt nevajadzīgus zvanus un vadīt plūsmu kaut kur citur. gadā izvirzīja Circuit Breaker dizaina modeli programmatūras izstrādes dizaina priekšplānā. Tas tika darīts viņa publikācijā Release It!: Design and Deploy Production Ready Software (Pragmatic Programmers) 1st Edition. 2017 Michael Nygard dizaina modelis ir iedvesmots no faktiskajām elektroniskajām un elektriskajām ķēdēm. Tomēr, runājot par vispārīgu koncepciju, ķēdes pārtraucēja ideju gadā izgudroja . Tāpat kā tajā laikā, ir jārīkojas ar pārplūdušo strāvu. Ļoti, ļoti vienkārši izsakoties, šajā gadījumā mēs to attiecinām uz programmatūras arhitektūru. Galvenais mērķis ir pārliecināties, ka sistēma ir pietiekami izturīga. To inženieru acīs, kas ir atbildīgi par šī modeļa ieviešanu, patiešām nosaka, cik tam jābūt izturīgam un cik . Ideja ir tāda, ka noteiktos apstākļos mēs varam nemanāmi novirzīt noteikta pieprasījuma plūsmu uz citu pieejamāku plūsmu aiz tā paša . circuit breaker 1879 Thomas Edison fault-tolerant endpoint Pieņemsim, ka mēs vēlamies izpildīt pieprasījumu no līdz . Ik pa laikam B neizdodas un vienmēr ir pieejams. Ja nejauši neizdodas, mēs vēlamies sasniegt , lai mūsu pakalpojums būtu pilnībā pieejams. Tomēr, lai nosūtītu pieprasījumus atpakaļ uzņēmumam , mēs vēlamies nodrošināt, lai atkārtoti neizdodas. Pēc tam mēs varam konfigurēt savu sistēmu, lai veiktu nejaušus pieprasījumus B un pilnībā atgrieztos pie tikai tad, kad atteices līmenis ir samazinājies par noteiktu līmeni. A B C B C B B B Mēs varētu vēlēties iesniegt pieprasījumu C kļūdas, bet arī latentuma dēļ. Ja darbojas ļoti lēni, mēs, iespējams, vēlēsimies atkārtoti nosūtīt visus pieprasījumus uz . Ir arī daudzas citas iespējamās konfigurācijas, piemēram, mēģinājums sasniegt , ja pēc noteikta mēģinājumu skaita, pieprasījumu veidi, vienlaikus pavedieni un daudzas citas iespējas. To sauc arī par , un tā lielākoties ir īslaicīga kustība. B C C short-circuiting Lai labāk izprastu mūsu zināšanas par to, kas patiesībā ir ķēdes pārtraucējs, mums ir jāsaprot, ka ķēdes pārtraukums mūsu lietojumprogrammā darbojas kā vienība. Slēdžiem ir trīs galvenie statusi. Tas var būt aizvērts, atvērts vai pusatvērts. Statuss aizvērts nozīmē, ka mūsu lietojumprogrammu plūsmas darbojas normāli. Mēs varam droši iesniegt pieprasījumus pakalpojumam A, zinot, ka visi pieprasījumi tiks nosūtīti pakalpojumam B. Atvērts stāvoklis nozīmē, ka visi pieprasījumi pakalpojumam B neizdosies. Noteikumi, ko esam definējuši, lai attēlotu kļūmi, ir notikuši, un mēs vairs nesasniedzam pakalpojumu B. Šajā gadījumā vienmēr tiek atgriezts izņēmums. stāvoklis ir tad, kad mūsu ķēdes pārtraucējam tiek uzdots veikt pakalpojuma B pārbaudes, lai redzētu, vai tas atkal darbojas. half-open Katrs veiksmīgais pieprasījums tiek apstrādāts kā parasti, taču tas turpinās nosūtīt pieprasījumus C. Ja B darbojas, kā paredzēts saskaņā ar mūsu noteiktajiem verifikācijas noteikumiem, mūsu ķēdes pārtraucējs atgriezīsies slēgtā stāvoklī un pakalpojums A sāks veikt. pieprasa tikai pakalpojumam B. Lielākajā daļā lietojumu ķēdes pārtraucējs atbilst dekoratora dizaina shēmai. Tomēr to var ieviest manuāli, un mēs apskatīsim trīs programmatiskus veidus, kā ieviest ķēdes pārtraucējus un visbeidzot izmantot uz AOP balstītu ieviešanu. Kods ir pieejams vietnē . GitHub 2. Automašīnu pārbaudes Šī raksta pēdējā punktā mēs apskatīsim automašīnu sacīkšu spēli. Tomēr, pirms mēs tur nonākam, es vēlos jums sniegt norādījumus par dažiem aspektiem, kā izveidot lietojumprogrammu, kas darbojas ar . circuit breaker 2.1. Kystrix (no Parīzes līdz Berlīnei-kystrix-runnable-app) kā mazs ir pārsteidzoša bibliotēka, ko izgudroja un izveidoja . Bibliotēka sniedz daudz iespēju, tostarp integrāciju ar Spring un Spring WebFlux. Ir interesanti to apskatīt un mazliet paspēlēties: Kystrixs DSL Johan Haleby se.haleby.kystrix kystrix-core se.haleby.kystrix kystrix-spring Esmu izveidojis piemēru, un tas atrodas modulī . Pirmkārt, mēs aplūkojam kodu: GitHub no-paris-to-berlin-kystrix-runnable-app @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() } } Šis kods apzīmē piemēra 2. komandu. Pārbaudiet 1. komandas kodu. Šeit notiek tas, ka mēs definējam vajadzīgo komandu ar . Šeit mēs definējam metodi, kas mums jāizsauc. Programmā mēs definējam noteikumus, kas liek mainīt stāvokli uz atvērtu. Mēs nepārprotami kavējam zvanu, lai tas ilgtu precīzi 1 sekundi. monoCommand commandProperties circuit-breaker Tajā pašā laikā mēs definējam milisekundes taimautu. Tas nozīmē, ka mēs nekad nesasniegsim taimautu. Šajā piemērā mēs varam veikt zvanus ar . Tā kā šis ir tikai tests, mēs pieņemam, ka ir automašīnas, Jaguar, kam nav nepieciešams . Tas nozīmē arī to, ka mēs nekad nesaņemsim Tank1, kā noteikts atkāpšanās metodē. Ja vēl neesat pamanījis, rūpīgi apskatiet atkāpšanās metodi. Šī metode izmanto . Lai gan ir ieviests saskaņā ar dizaina modeli, nav gluži novērojams. 5000 Id Id=1 circuit-breaker Id Observable WebFlux Observable Flux Tomēr hystrix atbalsta abus. Lūdzu, palaidiet lietojumprogrammu un atveriet pārlūkprogrammu vietnē , lai to apstiprinātu. Ir svarīgi saprast, ka, ja sākat zvanīt ļoti agri, startējot Spring Boot, jūs galu galā varat saņemt Tank1 ziņojumu. Tas ir tāpēc, ka startēšanas aizkave var ļoti viegli pārsniegt 5 sekundes atkarībā no tā, kā jūs veicat šo procesu. Otrajā piemērā mēs īssavienosim savu piemēru ar tvertni 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() } } Šajā piemērā mūsu kā atbilde pāries atvērtā stāvoklī, atgriešanās tvertni 2. Tas ir tāpēc, ka mēs arī šeit radām 1 s aizkavi, taču mēs norādām, ka mūsu ķēdes pārtraukuma stāvoklis tiek aktivizēts pēc 500 ms atzīmes. Ja jūs zināt, kā darbojas, jūs atklāsit, ka nav nekas atšķirīgs, virzoties uz priekšu. Tas, ko hystrix man šajā brīdī nenodrošināja, bija nevainojams, bez piepūles veids, kā nodrošināt to, kas man bija nepieciešams spēles izveidei. Šķiet, ka strādā uz klienta pamata. Tas nozīmē, ka mums ir jādeklarē savs kods, pirms pieprasām pakalpojumus, kas ir mūsu galvenā pakalpojuma pamatā. circuit-breaker hystrix kystrix Kystrix 2.2. Izturība4J Šķiet, ka daudzi atsaucas uz ļoti pilnīgu ķēdes pārtraucēja ieviešanu. Mani pirmie izmēģinājumi bija daži svarīgi ķēdes pārtraucēju aspekti. Proti, es gribēju redzēt ķēdes pārtraucēju, kas varētu darboties, pamatojoties uz taimautu un veiksmīgu pieprasījumu biežumu. ļauj konfigurēt dažāda veida moduļus. Tie ir sadalīti dažādās kategorijās: , , , un . Tie visi ir arī dizaina modeļu nosaukumi. modulis nodrošina pilnīgu šī modeļa ieviešanu. Resilience4J Resilience4J short-circuiting 6 CircuitBreaker Bulkhead Ratelimiter Retry Timelimiter CircuitBreaker Mums ir daudz parametru, ko varam konfigurēt, taču būtībā modulis ļauj mums konfigurēt to, ko mēs atpazīstam kā kļūdu, cik pieprasījumu mēs pieļaujam pusatvērtā stāvoklī un bīdāmu logu, ko var konfigurēt pēc laika vai count, kur mēs saglabājam slēgtā stāvoklī veikto pieprasījumu skaitu. Tas ir svarīgi, lai aprēķinātu kļūdu biežumu. Būtībā mēs varētu teikt, ka šis modulis mums palīdzēs noteikt pieprasījumu ātrumu, taču tas ne vienmēr ir taisnība. CircuitBreaker CircuitBreaker Tas ir atkarīgs no tā, kā jūs to interpretējat. Šķiet, ka tas ir labāks veids, kā to uzskatīt par vienkāršu veidu, kā tikt galā ar kļūmēm. Neatkarīgi no tā, vai tie nāk no taimauta vai izņēmuma, šeit tie tiek apstrādāti un kā pieprasījumus var nemanāmi pāradresēt kaut kur citur. modulis ir paredzēts, lai apstrādātu vienlaikus pieprasījumus. Tas nav ātruma ierobežotājs. Bulkhead Tā vietā tiek ieviests dizaina modelis, kas tiek izmantots, lai novērstu pārāk daudz apstrādes vienā galapunktā. Šajā gadījumā ļauj mums apstrādāt mūsu pieprasījumus tā, lai tie tiktu sadalīti visos pieejamajos galapunktos. Nosaukums cēlies no dažādiem aizzīmogotiem nodalījumiem, kuros lielam kuģim parasti ir jāizvairās no nogrimšanas, ja notiek negadījums, un, tāpat kā kuģu gadījumā, mums ir jādefinē, cik pavedienu būs pieejams pavedienu baseinā un to nomas laiks. . Bulkhead Bulkhead Bulkhead modulis ir paredzēts, lai apstrādātu pieprasījumu ātrumu. Atšķirība starp šo un moduli ir būtiska, lai mēs vēlamies būt iecietīgi pret likmēm līdz noteiktam brīdim. Tas nozīmē, ka mums nav jāizraisa neveiksme. Mēs tikai projektā sakām, ka mēs nepieļaujam likmi, kas pārsniedz noteiktu vērtību. Turklāt mēs varam vai nu pāradresēt pieprasījumu, vai paturēt to aizturēt, līdz tiek piešķirta atļauja izpildīt pieprasījumu. Modulis , iespējams, ir visvieglāk saprotams, jo tam nav daudz kopīga ar citiem moduļiem. RateLimiter Bulkhead Retry Mēs būtībā skaidri deklarējam atkārtotu mēģinājumu skaitu līdz noteiktam beigu punktam, līdz sasniedzam mūsu noteikto slieksni. moduli var uzskatīt par moduļa vienkāršojumu, jo tiem abiem ir kopīga iespēja konfigurēt taimautus. Tomēr nav atkarīgs no citiem parametriem, piemēram, bīdāmiem logiem, un tam nav arī iebūvēta atteices sliekšņa aprēķina. Timelimiter CircuitBreaker Timelimiter Tātad, ja mūs interesē tikai noildzes apstrāde, zvanot noteiktam pakalpojumam, un mēs neņemam vērā citas iespējamās kļūdas, iespējams, mums ir labāk izmantot . Timelimiter 2.2.1. Resilience4J ar Kotlin and No Spring ietvaru (no Parīzes līdz Berlīnei-resilience4j-runnable-app) Šajā modulī esmu nolēmis izmantot tikai kotlin bibliotēku: 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 Šī ieviešana ir pieejama repo pakalpojumā GitHub. Vispirms apskatīsim modeli: 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") } Šajā gadījumā mēs izrotājam savu ar funkcionalitāti, izmantojot funkciju . Tas izraisīs taimautu, ja funkcija, kuru mēs izsaucam, aizņem pārāk ilgu laiku, mēs saņemsim Opel Corsa, nevis Lancya. Lai to izmēģinātu, mēs varam vienkārši palaist lietojumprogrammu un atvērt . function getPrivateCar TimeLimiter decorateSuspendFunction http://localhost:8080/cars/timelimiter/normal/1 Aplūkojot ieviešanu, mēs redzam, ka mēs nekad nevarēsim iegūt . Un tas ir tāpēc, ka mēs apzināti nogaidām , pirms atgriežam to atpakaļ. Mūsu ir daudz mazāks taimauts, tāpēc tas nekad nedarbosies. ir diezgan vienkārši saprotams. No otras puses, var būt atšķirīgs stāsts. Šis ir piemērs tam, kā to var izdarīt: 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") } Šajā gadījumā mēs sakām, ka mēs vēlamies, lai mūsu ķēdes pārtraucējs aizvērtu ķēdi, tiklīdz atteices līmenis ar īpašumu ir mazāks par . Lēniem zvaniem arī būs slieksnis, taču šajā gadījumā tas būs mazāks par 50%. Mēs sakām, ka lēnam zvanam ir jāilgst ilgāk par 1 s, lai tas tiktu uzskatīts par tādu. Mēs arī precizējam, ka pusatvērtā stāvokļa ilgumam jābūt 1 s. Tas praksē nozīmē, ka mums būs atvērts stāvoklis, daļēji atvērts vai slēgts stāvoklis. 20% Mēs arī sakām, ka mēs pieļaujam ne vairāk kā 500 daļēji atvērtus pieprasījumus. Lai veiktu kļūdu aprēķinus, ķēdes pārtraucējam ir jāzina, pie kuras atzīmes tas to darīs. Tas ir svarīgi, lai noteiktu, kad ķēde ir jāaizver. Mēs sakām, ka šim aprēķinam būs nepieciešami vismaz 2 pieprasījumi ar rekvizītu . Atcerieties, ka pusatvērts ir brīdis, kad mēs turpināsim mēģināt panākt, lai ķēde tiktu aizvērta, ja pieprasījumi sasniegs drošu atteices slieksni? minimumNumberOfCalls Šajā konfigurācijā tas nozīmē, ka mums ir jāveic vismaz pieprasījumi bīdāmajā logā, lai aprēķinātu kļūdu biežumu un noteiktu, vai atgriezties aizvērtā stāvoklī. Tas ir precīzs visu mūsu konfigurēto mainīgo lielumu nolasījums. Kopumā tas nozīmē, ka mūsu lietojumprogramma, iespējams, veiks vairākus zvanus uz alternatīvo dienestu, ja tāds būs, tas nepārslēgsies no atvērta uz slēgtu stāvokli, ņemot vērā, ka veiksmes rādītājam, lai to izdarītu, ir jābūt 80% pusgadā. ir jābūt atvērtiem stāvokļiem un atvērtā stāvokļa taimautai. 2 Ir daudz veidu, kā norādīt šādus taimautus. Mūsu piemērā mēs sakām, ka ir 1 s. Tas nozīmē, ka mūsu statuss būs atvērts tikai tad, ja mūsu pārbaude neatbilst slēgtā stāvokļa nosacījumam vai ja šis taimauts vēl nav iestājies. Šajā definētajai darbībai var būt grūti sekot un paredzēt tikai tāpēc, ka konkrētus dīkstāves, ātrumus un citas pieprasījumu funkcijas vienkārši nav iespējams precīzi replicēt, taču, ja šim galapunktam izpildīsim vairākus pieprasījumus, mēs redzēsim, ka iepriekš aprakstītā uzvedība atbilst mūsu pieredzei. maxDurationInHalfOpenState CircuitBreaker CircuitBreaker Tātad, mēģināsim izpildīt vairākus pieprasījumus galapunktiem: un . Beidzas ar 1 ir veiksmīgas automašīnas izguves beigu punkts, un, kas beidzas ar 2, ir galapunkts, kas beidzas, ja netiek iegūta noteikta automašīna. Aplūkojot kodu, mēs redzam, ka viss, kas nav 2, nozīmē, ka mēs saņemam kā atbildi. A nozīmē, ka mēs nekavējoties izlaižam darbības laika izņēmumu, kas nozīmē, ka mēs saņemam kā atbildi. http://localhost:8080/cars/circuit/1 http://localhost:8080/cars/circuit/2 Lancya 2 Opel Corsa Ja mēs tikai iesniegsim pieprasījumus galapunktam , mēs turpināsim redzēt kā atbildi. Ja sistēma sāk kļūdīties, tas ir, kad jūs veicat pieprasījumus 2,\; jūs redzēsiet, ka atgriešanās pie pēc kāda laika nebūs pastāvīga. informēs, ka tā ir atvērtā stāvoklī un ka vairs nav atļauti pieprasījumi. 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 Pēc veiksmīga pieprasījuma mūsu ķēdes pārtraucējs pāries pusatvērtā stāvoklī, un tas nozīmē, ka mums būs jāveic daži pieprasījumi, kas jāatgriež līdz 1, pirms tas normalizējas. Mēs pāris reizes pārslēgsimies no uz pirms atkal iegūsim . Mēs definējām šo skaitli kā 2. Tas ir kļūdu aprēķina minimums. Ja mēs izraisīsim tikai vienu kļūdu un turpinām izsaukt galapunktu, kas nav neveiksmīgs, mēs varam iegūt skaidrāku priekšstatu par notiekošo: 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 Lai gan šis atvērtā statusa ziņojums ir patiess, tas notika pēc tam, kad es veicu 2 pieprasījumus galapunktam bez kļūmes. Tāpēc valsts esot pusatvērta. 2.2.2. Resilience4J ar Spring Boot un bez AOP (no-paris-to-berlin-resilience4j-spring-app) Iepriekšējā segmentā mēs redzējām, kā to ieviest ļoti programmatiski, neizmantojot nekādu Spring tehnoloģiju. Mēs izmantojām Spring, bet tikai, lai nodrošinātu veida pakalpojumu. Turklāt mēs neko nemainījām attiecībā uz pašiem pakalpojumiem. Šajā lietojumprogrammā mēs izpētīsim šādas bibliotēkas: WebFlux MVC io.github.resilience4j resilience4j-spring-boot2 io.github.resilience4j resilience4j-all io.github.resilience4j resilience4j-reactor Aplūkojot, kā kods tiek darīts, mēs varam redzēt diezgan lielu atšķirību: @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")) } } Šajā un turpmākajā piemērā mēs galvenokārt aplūkosim noildzes īpašības. Pašas sarežģītības ir mazāk svarīgas, jo šis ir ievadraksts. Šeit ir svarīgi saprast, cik viegli mēs varam to īstenot ar nodrošinātajiem dekoratoriem. Lai gan joprojām ir , mēs varam viegli izrotāt savu sākotnējo izdevēju, kuru iegūstam no , ar vēlamajiem veidiem. CircuitBreaker Resilience4J programmatical carService.getCar() short-circuit Šajā piemērā mēs reģistrējam , un . Visbeidzot, mēs definējam atkāpšanās funkciju, kas jāaktivizē, tiklīdz ir noticis TimeoutException. Mums vēl ir jāredz, kā tas viss ir konfigurēts. Mēs konfigurējam Resilience4J pavasarī tāpat kā jebkuru citu konfigurējamu moduli. Mēs izmantojam : 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 Šis fails ir parauga fails, kas ņemts no viņu repo un attiecīgi pārveidots par manu piemēru. Kā mēs redzējām iepriekš, dažādu veidu gadījumiem ir nosaukums. Nosaukums ir ļoti svarīgs, ja jums ir daudz dažādu reģistru un dažādu ierobežotāju. Piemēram, tāpat kā iepriekš minēts, mūs interesē laika ierobežotājs. Mēs redzam, ka tas ir ierobežots līdz 2 s. Ja aplūkojam pakalpojuma ieviešanas veidu, mēs redzam, ka mēs piespiežam notikt taimautu: limiters/short-circuit @Component open class CarService { open fun getCar(): Mono { return Mono.just(Car("Fiat")).delayElement(Duration.ofSeconds(10)); } } Sāksim lietojumprogrammu un pārlūkprogrammā dodieties uz: . Tā vietā, lai iegūtu , mēs iegūsim . Šādi mēs definējām taimautu. Tādā pašā veidā mēs varam viegli izveidot . http://localhost:8080/cars/test/2 Fiat Rolls Royce CircuitBreaker 3. Lieta Līdz šim mēs esam redzējuši trīs būtiskus veidus, kā ieviest un saistītos ierobežotājus. Tālāk mēs apskatīsim manu iecienītāko ķēdes pārtraucēju ieviešanas veidu, izmantojot manis izveidoto lietojumprogrammu, kas ir ļoti vienkārša spēle, kurā mēs vienkārši noklikšķiniet uz kvadrātiem, lai nokļūtu no Parīzes uz Berlīni. Spēle ir izveidota, lai saprastu, kā to īstenot. Tajā nav daudz teikts par to, kur to īstenot. Šis ir tikai gadījums, ko esmu izstrādājis, lai dalītos ar jums zinātībā. CircuitBreakers Zināšanas par to, kad es to atstāju jums, lai izlemtu vēlāk. Būtībā mēs vēlamies izveidot vairākas automašīnas un izveidot maršrutu uz Berlīni. Dažādās šī maršruta vietās mēs nokļūsim pilsētās, kur nejauši radīsim problēmas. Mūsu izlems, cik daudz laika mums būs jāgaida, pirms varēsim doties tālāk. Pārējām automašīnām nav problēmu, un mums vienkārši jāizvēlas pareizais maršruts. circuit breakers Mums ir atļauts pārbaudīt kustības grafiku, kurā tiek reģistrēts, kad pilsētā noteiktā minūtē notiks kāda problēma. Minūtes atzīme ir derīga tās 0 indeksētās pozīcijās. Tas nozīmē, ka 2 nozīmē, ka 2, 12, 22, 32, 42, 52 minūšu atzīme pulkstenī būs derīga, lai radītu šo problēmu. Problēmas būs divu veidu: un . Kļūdas kļūme radīs 20 sekunžu aizkavi. every ERROR TIMEOUT Taimauts nodrošinās 50 sekunžu aizkavi. Katrai pilsētas maiņai ikvienam ir jāgaida 10 sekundes. Tomēr pirms gaidīšanas automašīna jau atrodas pie nākamās pilsētas iebraukšanas, kad tas tiek darīts ar rezerves metodēm. Šajā gadījumā nākamā pilsēta tiek izvēlēta nejauši. 4. Īstenošana Mēs jau iepriekš esam redzējuši, kā konfigurēt mūsu reģistru, izmantojot . Kad tas ir izdarīts, apskatīsim dažus piemērus, kā izrotāt mūsu funkcijas: 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) } Kā redzam, oriģinālie servisa izsaukumi ir tieši noformēti, izmantojot anotācijas! To var izdarīt tikai tāpēc, ka paketē ir modulis: AOP org.springframework.boot spring-boot-starter-aop jeb ir vēl viena programmēšanas paradigma, kuras pamatā ir . Tas tiek uzskatīts par papildinājumu, un tas ir tieši tas, cik daudz anotāciju darbojas. Tas ļauj aktivizēt citas funkcijas ap, pirms vai pēc sākotnējās metodes precīzos griezuma punktos. Kā redzams piemērā, mēs vai nu ģenerējam taimautus vai kļūdas. tiek ģenerēts arī atkāpšanās metodes ietvaros. Tas nerada problēmu. Izņemot atbildi. AOP Aspect Oriented Programming OOP OOP BlockageException Tomēr lietojumprogramma darbojas un tāpēc šī kļūda lietojumprogrammā nebūs redzama. Līdz šim tā bija spēle. Es to ieviesu, lai parādītu, kā anotāciju izmantošana var ievērojami atvieglot mūsu dzīvi, ieviešot elastīgu lietojumprogrammu. Mums ir ieviesti ne tikai CircuitBreakers, bet arī citas tehnoloģijas, piemēram , , , , un vairākas citas. Tas viss tika darīts, lai redzētu, kā CircuitBreakers varētu darboties lietojumprogrammā. Ja vēlaties spēlēt ar šo lietojumprogrammu, lūdzu, dodieties uz projekta sakni un palaidiet: WebSockets, WebSockets Spring WebFlux Docker NGINX typescript make docker-clean-build-start Pēc tam palaidiet šo komandu: 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":[]}' Šī pieprasījuma lietderīgā slodze tiek ģenerēta, izmantojot moduli . Ja ieskatīsieties šajā modulī, jūs redzēsit, ka to ir diezgan vienkārši saprast un ka varat izveidot savu karti spēlei! Visbeidzot, dodieties uz un jūsu lietojumprogrammai vajadzētu darboties! Tagad jums vienkārši jānoklikšķina uz pareizajiem laukumiem, lai spēlētu spēli. Vienkārši neklikšķiniet uz sarkanajiem, ja vēlaties laimēt. Ja tomēr vēlaties redzēt ķēdes pārtraucēju darbībā, lūdzu, palaidiet lietojumprogrammu žurnālus: from-paris-to-berlin-city-generator vietni http://localhost:9000, docker logs from_paris_to_berlin_web -f Un skaidri noklikšķiniet uz sarkanajiem kvadrātiem, lai izraisītu kļūmi. 5. Kā Kystrix un Resilience4J atšķiras ir ideāli piemērots gadījumos, kad jūsu lietojumprogramma ir maza, un jūs vēlaties pārliecināties, ka DSL lietojums ir patiešām zems. Šķiet, ka vienīgais trūkums ir tāds, ka tas nepiedāvā vienkāršu veidu, kā dekorēt metodes, kuras ietekmē ķēdes pārtraucējs. Šķiet, ka ir lieliska iespēja uzņēmuma darbam ar automātiskiem slēdžiem. Tas nodrošina uz anotācijām balstītu programmēšanu, izmanto visas AOP priekšrocības, un tā moduļi ir atdalīti. Savā ziņā to var stratēģiski izmantot arī lietojumprogrammas kritiskajiem punktiem. To var izmantot arī kā pilnīgu ietvaru, kas aptver daudzus lietojumprogrammas aspektus. Kystrix Resilience4J 6. Secinājums Neatkarīgi no mūsu izvēlētā zīmola mērķis vienmēr ir nodrošināt elastīgu pielietojumu. Šajā rakstā es parādīju dažus piemērus tam, kā es personīgi pieredzēju automātisko slēdžu izmeklēšanu un savus atklājumus ļoti augstā līmenī. Tas nozīmē, ka šis raksts patiešām ir rakstīts cilvēkiem, kuri vēlas uzzināt, kas ir automātiskie slēdži un ko Limiters var darīt. Atklāti sakot, iespējas ir bezgalīgas, domājot par mūsu lietojumprogrammu uzlabošanu, izmantojot elastīguma mehānismus, piemēram, . Šis modelis ļauj precizēt lietojumprogrammu, lai labāk izmantotu mūsu rīcībā esošos resursus. Pārsvarā mākonī joprojām ir ļoti svarīgi optimizēt mūsu izmaksas un to, cik daudz resursu mums faktiski ir jāpiešķir. circuit breakers konfigurēšana nav triviāls uzdevums, kā tas ir Limiters, un mums patiešām ir jāsaprot visas konfigurācijas iespējas, lai sasniegtu optimālu veiktspējas un noturības līmeni. Šī iemesla dēļ es nevēlējos iedziļināties šajā ievadrakstā par automātiskiem slēdžiem. CircuitBreakers var izmantot dažādiem lietojumu veidiem. Lielākajai daļai ziņojumapmaiņas un straumēšanas lietojumprogrammu tas būs nepieciešams. Lietojumprogrammām, kas apstrādā lielus datu apjomus, kuriem arī jābūt ļoti pieejamiem, mēs varam un mums vajadzētu ieviest kādu ķēdes pārtraucēju. Lielajiem tiešsaistes mazumtirdzniecības veikaliem katru dienu ir jāapstrādā milzīgs datu apjoms, un agrāk tika plaši izmantots. Pašlaik šķiet, ka mēs virzāmies virzienā, kas ietver daudz vairāk. Circuit-breakers Hystrix Resilience4J 6. Atsauces https://youtu.be/kR2sm1zelI4 https://youtu.be/AiP2_icXpAk Uzlabojiet savu Kotlin kodu, izmantojot Detekt Resilience 4J Spring-Boot-Demo Netflix / Hystrix Kystrix — Kotlin DSL, kas paredzēts Hystrix johanhaleby / kystrix elastīgums4j / elastīgums4j CircuitBreaker — darba sākšana ar resilience4j-circuitbreaker Paldies! Ceru, ka jums patika šis raksts tikpat ļoti kā man tā tapšana! Lūdzu, atstājiet atsauksmi, komentārus vai jebkādas atsauksmes, ko vēlaties sniegt par kādu no sociālajiem tīkliem, kas atrodas tālāk esošajās saitēs. Esmu ļoti pateicīgs, ja vēlaties man palīdzēt uzlabot šo rakstu. Esmu ievietojis visu šīs lietojumprogrammas pirmkodu vietnē Paldies, ka izlasījāt! GitHub.