Dari Paris ke Berlin: Cara Membuat Pemutus Litar di Kotlin

1. Pengenalan digunakan pada masa kini untuk mengelakkan jumlah permintaan yang berlebihan dilakukan kepada satu atau perkhidmatan tidak responsif yang lain. Apabila, sebagai contoh, perkhidmatan dimatikan, atas apa jua sebab, pemutus litar harus, seperti yang dinyatakan dalam namanya, memutuskan litar. Dalam erti kata lain, dalam keadaan di mana 1 juta permintaan sedang dilakukan pada masa yang sama untuk mendapatkan keputusan perlumbaan kuda, kami mahu permintaan ini dialihkan ke perkhidmatan lain yang boleh menangani perkara ini. Circuit-breakers Perkhidmatan lain ini boleh menjadi replikanya, atau ia boleh digunakan semata-mata untuk melaksanakan operasi lain mengenai kegagalan perkhidmatan asal. Matlamat akhir adalah sentiasa untuk memecahkan panggilan yang tidak perlu dan menjalankan aliran di tempat lain. Pada , membawa corak reka bentuk Pemutus Litar ke hadapan dalam reka bentuk pembangunan perisian. Ini dilakukan dalam penerbitannya Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) 1st Edition. 2017 Michael Nygard Corak reka bentuk diilhamkan oleh litar elektronik dan elektrik sebenar. Walau bagaimanapun, dari segi konsep umum, idea pemutus litar sebenarnya telah dicipta pada oleh . Sama seperti pada masa itu, arus yang melimpah perlu dikendalikan. Dalam istilah yang sangat, sangat mudah, inilah yang kami gunakan untuk seni bina perisian dalam kes ini. Matlamat utama adalah untuk memastikan sistem itu cukup berdaya tahan. Sejauh mana ia mesti berdaya tahan dan betapa itu sebenarnya di mata jurutera yang bertanggungjawab untuk memudahkan pelaksanaan corak ini. Idea di sebaliknya ialah dalam keadaan tertentu kita mungkin ingin mengubah hala aliran permintaan tertentu kepada aliran lain yang lebih tersedia di belakang yang sama. circuit breaker 1879 Thomas Edison fault-tolerant endpoint Katakan kita mahu melaksanakan permintaan daripada kepada . Dari semasa ke semasa, B gagal dan sentiasa tersedia. Jika gagal secara rawak, kami ingin mencapai untuk menyediakan perkhidmatan kami sepenuhnya. Walau bagaimanapun, untuk membuat permintaan kembali kepada , kami ingin memastikan bahawa tidak gagal lagi. Kami kemudiannya boleh mengkonfigurasi sistem kami untuk membuat permintaan rawak kepada B dan hanya kembali sepenuhnya ke apabila kadar kegagalan telah menurun pada tahap tertentu. A B C B C B B B Kami mungkin ingin membuat permintaan C atas kesilapan tetapi juga pada kependaman. Jika sangat lambat, kami mungkin mahu menghantar semula semua permintaan kepada . Terdapat banyak konfigurasi lain yang mungkin, seperti cuba mencapai jika selepas beberapa percubaan tertentu, jenis permintaan, utas serentak dan banyak pilihan lain Ini juga dikenali sebagai , dan kebanyakannya adalah langkah sementara. B C C short-circuiting Untuk memahami lebih lanjut pengetahuan kita tentang apa sebenarnya pemutus litar, kita perlu memahami bahawa pemutus litar berfungsi sebagai entiti dalam aplikasi kita. Terdapat tiga status utama untuk pemutus litar. Ia boleh ditutup, terbuka atau separuh terbuka. Status ditutup bermakna aliran aplikasi kami berjalan seperti biasa. Kami boleh membuat permintaan kepada perkhidmatan A dengan selamat, dengan mengetahui bahawa semua permintaan akan pergi ke perkhidmatan B. Keadaan terbuka bermakna semua permintaan untuk perkhidmatan B akan gagal. Peraturan yang telah kami tentukan untuk mewakili kegagalan telah berlaku dan kami tidak lagi mencapai perkhidmatan B. Dalam kes ini, pengecualian sentiasa dikembalikan. Keadaan ialah apabila pemutus litar kami diarahkan untuk melakukan ujian pada perkhidmatan B untuk melihat sama ada ia beroperasi semula. half-open Setiap permintaan yang berjaya dikendalikan seperti biasa, tetapi ia akan terus membuat permintaan kepada C. Jika B berkelakuan seperti yang diharapkan mengikut peraturan pengesahan yang telah kami tetapkan, pemutus litar kami akan kembali kepada keadaan tertutup dan perkhidmatan A akan mula membuat permintaan secara eksklusif kepada perkhidmatan B. Dalam kebanyakan aplikasi, pemutus litar mengikut corak reka bentuk penghias. Walau bagaimanapun, ia boleh dilaksanakan secara manual, dan kami akan melihat tiga cara program untuk melaksanakan pemutus litar dan akhirnya menggunakan pelaksanaan berasaskan AOP. Kod ini tersedia di . GitHub 2. Pemeriksaan Kereta Dalam titik terakhir artikel ini, kita akan melihat permainan perlumbaan kereta. Walau bagaimanapun, sebelum kita sampai ke sana, saya ingin membimbing anda melalui beberapa aspek membina aplikasi yang berjalan dengan . circuit breaker 2.1. Kystrix (dari-paris-ke-berlin-kystrix-runnable-app) , sebagai kecil , adalah perpustakaan yang menakjubkan yang dicipta dan dicipta oleh . Perpustakaan menyediakan banyak kemungkinan, termasuk penyepaduan dengan Spring dan Spring WebFlux. Adalah menarik untuk melihatnya dan bermain-main sedikit: Kystrixs DSL Johan Haleby se.haleby.kystrix kystrix-core se.haleby.kystrix kystrix-spring Saya telah mencipta contoh, dan ia terletak pada modul pada . Pertama, kita lihat pada kod: 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() } } Kod ini mewakili arahan 2 contoh. Semak kod untuk arahan 1. Apa yang berlaku di sini ialah kita mentakrifkan arahan yang kita mahu dengan . Di sini, kami menentukan kaedah yang perlu kami panggil. Dalam , kami mentakrifkan peraturan yang menjadikan keadaan perubahan dibuka. Kami menangguhkan panggilan kami secara eksplisit agar panggilan itu bertahan tepat 1 saat. monoCommand commandProperties circuit-breaker Pada masa yang sama, kami menentukan tamat masa milisaat. Ini bermakna kita tidak akan mencapai tamat masa. Dalam contoh ini, kita boleh membuat panggilan dengan . Oleh kerana ini hanyalah ujian, kami menganggap , sebagai kereta, Jaguar tanpa memerlukan . Ini juga bermakna bahawa kita tidak akan mendapat Tank1 seperti yang ditakrifkan dalam kaedah sandaran. Jika anda masih belum perasan, lihat dengan teliti kaedah sandaran. Kaedah ini menggunakan . Walaupun dilaksanakan mengikut corak reka bentuk , bukanlah Observable. 5000 Id Id=1 Id circuit-breaker Observable WebFlux Observable Flux Walau bagaimanapun, hystrix menyokong kedua-duanya. Sila jalankan aplikasi dan buka penyemak imbas anda di , untuk mengesahkan ini. Adalah penting untuk memahami bahawa jika anda mula membuat panggilan sangat awal dalam permulaan Spring Boot, anda akhirnya mungkin mendapat mesej Tank1. Ini kerana kelewatan permulaan boleh melepasi 5 saat dengan sangat mudah bergantung pada cara anda menjalankan proses ini. Dalam contoh kedua, kita akan membuat litar pintas contoh kita ke Tangki 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() } } Dalam contoh ini, kami akan masuk ke Tangki pengembalian hujung keadaan terbuka 2 sebagai tindak balas. Ini kerana kami juga menyebabkan kelewatan 1s di sini, tetapi kami menyatakan bahawa keadaan pemutus litar kami tercetus selepas tanda 500ms. Jika anda tahu cara berfungsi, anda akan dapati bahawa bukanlah sesuatu yang berbeza untuk bergerak ke hadapan. Apa yang tidak disediakan oleh hystrix untuk saya pada ketika ini, ialah cara yang lancar dan mudah untuk menyediakan apa yang saya perlukan untuk membuat permainan. nampaknya berfungsi berdasarkan pelanggan. Ini bermakna kami perlu mengisytiharkan kod kami sebelum membuat permintaan kepada perkhidmatan di belakang perkhidmatan utama kami. circuit-breaker hystrix kystrix Kystrix 2.2. Ketahanan4J nampaknya dirujuk oleh ramai orang sebagai pelaksanaan pemutus litar yang sangat lengkap. Percubaan pertama saya meneroka beberapa aspek penting pemutus litar. Iaitu, saya ingin melihat pemutus litar yang boleh berfungsi berdasarkan tamat masa dan kekerapan permintaan yang berjaya. membolehkan pelbagai jenis modul dikonfigurasikan. Ini dipisahkan kepada kategori berbeza: , , , dan . Semua ini juga nama corak reka bentuk. Modul menyediakan pelaksanaan lengkap corak ini. Resilience4J Resilience4J short-circuiting 6 CircuitBreaker Bulkhead Ratelimiter Retry Timelimiter CircuitBreaker Kami mempunyai banyak parameter yang boleh kami konfigurasikan, tetapi pada asasnya, modul membolehkan kami mengkonfigurasi perkara yang kami kenali sebagai gagal, berapa banyak permintaan yang kami benarkan dalam keadaan separuh terbuka dan tetingkap gelongsor, yang boleh dikonfigurasikan mengikut masa atau count, di mana kami menyimpan kiraan permintaan yang berlaku dalam keadaan tertutup. Ini penting untuk mengira kekerapan ralat. Pada asasnya, kami boleh mengatakan bahawa modul ini akan membantu kami dengan kadar permintaan, tetapi itu tidak semestinya benar. CircuitBreaker CircuitBreaker Ia bergantung kepada cara anda mentafsirnya. Nampaknya cara yang lebih baik untuk menganggapnya sebagai cara untuk menangani kesilapan. Sama ada ia datang daripada tamat masa atau pengecualian, di sinilah ia ditangani dan cara permintaan boleh diubah hala dengan lancar ke tempat lain Modul direka bentuk untuk menangani permintaan serentak. Ia bukan penghad kadar. Bulkhead Sebaliknya, ia melaksanakan corak reka bentuk , yang digunakan untuk menghalang terlalu banyak pemprosesan daripada berlaku dalam satu titik akhir tunggal. Dalam kes ini, membenarkan kami memproses permintaan kami dengan cara ia dapat diedarkan merentas semua titik akhir yang tersedia. Nama berasal dari petak tertutup yang berbeza yang biasanya perlu dielakkan oleh kapal besar, sekiranya berlaku kemalangan, dan seperti dalam kes kapal, kita perlu menentukan bilangan benang yang akan tersedia dalam kumpulan benang dan masa pajakannya. . Bulkhead Bulkhead Bulkhead Modul direka untuk mengendalikan kadar permintaan. Perbezaan antara ini dan modul adalah penting supaya kita mahu bertolak ansur dengan kadar sehingga satu tahap tertentu. Ini bermakna kita tidak perlu menyebabkan kegagalan untuk itu. Kami hanya katakan, dalam reka bentuk bahawa kami tidak bertolak ansur dengan kadar di atas nilai tertentu. Selain itu, kami boleh sama ada mengubah hala permintaan atau menahannya sehingga kebenaran untuk melaksanakan permintaan itu diberikan. Modul mungkin adalah yang paling mudah untuk difahami kerana ia tidak mempunyai banyak persamaan dengan modul lain. RateLimiter Bulkhead Retry Kami pada asasnya mengisytiharkan secara jelas bilangan percubaan semula ke titik akhir tertentu, sehingga kami mencapai ambang yang ditetapkan kami. Modul boleh dilihat sebagai penyederhanaan modul kerana kedua-duanya berkongsi kemungkinan untuk mengkonfigurasi tamat masa. Walau bagaimanapun, tidak bergantung pada parameter lain seperti tetingkap gelongsor, dan ia juga tidak mempunyai pengiraan ambang kegagalan dalam binaan. Timelimiter CircuitBreaker Timelimiter Jadi, jika kami benar-benar berminat untuk mengendalikan tamat masa semasa memanggil perkhidmatan tertentu, dan kami tidak mengambil kira kemungkinan kerosakan lain, maka kami mungkin lebih baik menggunakan . Timelimiter 2.2.1. Resilience4J dengan rangka kerja Kotlin dan No Spring (from-paris-to-berlin-resilience4j-runnable-app) Dalam modul ini, saya telah memutuskan untuk menggunakan hanya perpustakaan 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 Pelaksanaan ini tersedia pada repo di GitHub. Mula-mula kita akan melihat corak : 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") } Dalam kes ini, kami menghiasi kami dengan fungsi menggunakan fungsi . Perkara ini akan menyebabkan tamat masa, jika fungsi yang kita panggil mengambil masa terlalu lama, kita akan mendapat Opel Corsa dan bukannya Lancya. Untuk mencuba ini, kami hanya boleh menjalankan aplikasi dan membuka . function getPrivateCar TimeLimiter decorateSuspendFunction http://localhost:8080/cars/timelimiter/normal/1 Melihat ke dalam pelaksanaan, kami melihat bahawa kami tidak boleh mendapatkan . Dan ini kerana kami sengaja menunggu sebelum kami mengembalikannya semula. kami mempunyai tamat masa yang jauh lebih rendah jadi ini tidak akan berjaya. agak mudah difahami. A , sebaliknya, boleh menjadi cerita yang berbeza. Ini adalah contoh bagaimana ia boleh dilakukan: 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") } Dalam kes ini, kami mengatakan bahawa kami mahu pemutus litar kami menutup litar apabila kadar kegagalan lebih rendah daripada dengan harta itu. Panggilan perlahan juga akan mempunyai ambang, tetapi dalam kes ini, ia akan menjadi kurang daripada 50%. Kami mengatakan bahawa panggilan perlahan mesti bertahan lebih lama daripada 1 untuk dianggap sebagai satu. Kami juga menyatakan bahawa tempoh keadaan separuh terbuka hendaklah 1s. Ini bermakna, dalam amalan, kita sama ada akan mempunyai keadaan terbuka, keadaan separuh terbuka, atau keadaan tertutup. 20% Kami juga mengatakan bahawa kami membenarkan maksimum 500 permintaan keadaan separuh terbuka. Untuk pengiraan ralat, pemutus litar perlu tahu pada tanda mana ia akan melakukannya. Ini penting untuk menentukan masa untuk menutup litar. Kami mengatakan bahawa 2 permintaan akan diperlukan untuk pengiraan ini, dengan sifat . Ingat bahawa separuh terbuka ialah apabila kita akan terus mencuba untuk menutup litar jika permintaan mencapai ambang selamat gagal? minimumNumberOfCalls Dalam konfigurasi ini, ini bermakna kita perlu membuat sekurang-kurangnya permintaan, dalam tetingkap gelongsor, untuk mengira kekerapan ralat dan menentukan sama ada untuk kembali kepada keadaan tertutup atau tidak. Ini ialah bacaan tepat bagi semua pembolehubah yang telah kami konfigurasikan. Secara umum, maksud ini ialah aplikasi kami mungkin akan membuat beberapa panggilan ke perkhidmatan alternatif, sekiranya ada, ia tidak akan bertukar dengan mudah daripada keadaan terbuka kepada tertutup memandangkan kadar kejayaan untuk melakukannya mestilah 80% dalam tempoh separuh -keadaan terbuka dan tamat masa untuk keadaan terbuka mesti telah berlaku. 2 Terdapat banyak cara untuk menentukan tamat masa sedemikian. Dalam contoh kami, kami mengatakan bahawa ialah 1s. Ini bermakna bahawa kami akan mengekalkan status terbuka, hanya jika semakan kami tidak memenuhi syarat keadaan tertutup atau jika tamat masa ini belum berlaku. Tingkah laku yang ditakrifkan dalam ini mungkin sukar untuk diikuti dan untuk diramalkan, semata-mata kerana masa henti tertentu, kadar dan ciri permintaan lain tidak mungkin untuk direplikasi dengan tepat, tetapi jika kami melakukan beberapa permintaan ke titik akhir ini, kami akan melihat bahawa tingkah laku yang diterangkan di atas sepadan dengan pengalaman kami. maxDurationInHalfOpenState CircuitBreaker CircuitBreaker Jadi, mari cuba dan lakukan beberapa permintaan ke titik akhir: dan . Berakhir dengan 1 ialah titik akhir untuk mendapatkan semula kereta yang berjaya, dan berakhir dengan 2 ialah titik akhir kegagalan mendapatkan kereta tertentu. Melihat pada kod, kita melihat bahawa apa-apa selain daripada 2 bermakna kita mendapat sebagai respons. A , bermakna kami segera membuang pengecualian masa jalan, yang bermakna kami akhirnya mendapat sebagai respons. http://localhost:8080/cars/circuit/1 http://localhost:8080/cars/circuit/2 Lancya 2 Opel Corsa Jika kami hanya membuat permintaan untuk titik akhir , kami akan terus melihat sebagai respons. Jika sistem mula gagal, iaitu apabila anda membuat permintaan untuk 2,\; anda akan melihat bahawa kembali ke tidak akan menjadi berterusan selepas beberapa ketika. akan memaklumkan bahawa ia berada dalam keadaan Terbuka dan tiada lagi permintaan dibenarkan. 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 Pemutus litar kami kemudiannya akan pergi ke keadaan separuh terbuka selepas permintaan berjaya, dan ini bermakna kami perlu melakukan beberapa permintaan kembali kepada 1 sebelum ia menjadi normal. Kami akan bertukar daripada kepada beberapa kali sebelum kami mendapatkan semula. Kami mentakrifkan nombor ini sebagai 2. Ini adalah minimum untuk pengiraan ralat. Jika kita hanya menyebabkan satu gagal dan terus memanggil titik akhir tidak gagal, kita boleh mendapatkan gambaran yang lebih jelas tentang perkara yang berlaku: 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 Mesej status terbuka ini, walaupun benar, berlaku selepas saya membuat 2 permintaan ke titik akhir tidak gagal. Inilah sebabnya negeri itu dikatakan separuh terbuka. 2.2.2. Resilience4J dengan Spring Boot dan No AOP (from-paris-to-berlin-resilience4j-spring-app) Dalam segmen sebelumnya, kami melihat cara melaksanakannya dengan cara yang sangat terprogram, tanpa menggunakan sebarang teknologi Spring. Kami memang menggunakan Spring tetapi hanya untuk menyediakan jenis perkhidmatan . Selanjutnya, kami tidak mengubah apa-apa tentang perkhidmatan itu sendiri. Dalam aplikasi berikut, kami akan meneroka perpustakaan berikut: WebFlux MVC io.github.resilience4j resilience4j-spring-boot2 io.github.resilience4j resilience4j-all io.github.resilience4j resilience4j-reactor Apabila melihat bagaimana kod itu dilakukan, kita dapat melihat perbezaan yang agak besar: @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")) } } Dalam contoh ini dan yang berikut, kita akan melihat kebanyakannya pada sifat tamat masa. Selok-belok sendiri kurang relevan kerana ini adalah artikel pengenalan. Apa yang penting untuk disedari di sini ialah betapa mudahnya kita boleh melaksanakan perkara ini dengan penghias yang disediakan untuk Spring oleh . Walaupun masih dalam fesyen , kami boleh menghiasi penerbit awal kami dengan mudah, yang kami dapat daripada , dengan jenis yang kami mahukan. CircuitBreaker Resilience4J programmatical carService.getCar() short-circuit Dalam contoh ini, kami mendaftarkan , dan . Akhir sekali, kami mentakrifkan fungsi sandaran untuk dicetuskan sebaik sahaja TimeoutException telah berlaku. Apa yang masih perlu kita lihat ialah bagaimana semua ini dikonfigurasikan. Kami mengkonfigurasi Resilience4J dalam Spring sama seperti mana-mana modul boleh dikonfigurasikan lain. Kami menggunakan : 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 Fail ini ialah fail contoh yang diambil dari repo mereka dan diubah suai kepada contoh saya dengan sewajarnya. Seperti yang telah kita lihat sebelum ini, contoh pelbagai jenis , mempunyai nama. Nama itu sangat penting jika anda mempunyai banyak pendaftaran yang berbeza dan pengehad yang berbeza. Untuk contoh kami, dan seperti yang dinyatakan sebelum ini, kami berminat dengan pembatas masa. Kita dapat lihat bahawa ia terhad kepada 2s. Jika kami melihat cara kami melaksanakan perkhidmatan, kami melihat bahawa kami memaksa tamat masa berlaku: limiters/short-circuit @Component open class CarService { open fun getCar(): Mono { return Mono.just(Car("Fiat")).delayElement(Duration.ofSeconds(10)); } } Mari mulakan aplikasi, dan dalam penyemak imbas, pergi ke: . Daripada mendapatkan , kami akan mendapat . Beginilah cara kami menentukan tamat masa. Dengan cara yang sama, kita boleh membuat dengan mudah. http://localhost:8080/cars/test/2 Fiat Rolls Royce CircuitBreaker 3. Kes Sehingga kini, kami telah melihat tiga cara penting untuk melaksanakan dan pengehad yang berkaitan. Selanjutnya, kita akan melihat cara kegemaran saya untuk melaksanakan pemutus litar dengan melalui aplikasi yang saya buat, yang merupakan permainan yang sangat mudah di mana kita hanya mengklik pada petak untuk pergi dari Paris ke Berlin. Permainan dibuat untuk memahami bagaimana untuk melaksanakan. Ia tidak mengatakan banyak tentang di mana untuk melaksanakan ini. Ia hanyalah satu kes yang saya reka bentuk untuk berkongsi dengan anda pengetahuan. CircuitBreakers Yang tahu-bila saya serahkan kepada anda untuk membuat keputusan kemudian. Pada asasnya, kami ingin mencipta beberapa kereta dan mewujudkan laluan ke Berlin. Di lokasi yang berbeza dalam laluan ini, kami akan sampai ke bandar di mana secara rawak, kami akan mencipta masalah. kami akan menentukan berapa lama kami perlu menunggu sebelum kami dibenarkan untuk meneruskan. Kereta lain tiada masalah, dan kami hanya perlu memilih laluan yang betul. circuit breakers Kami dibenarkan menyemak jadual waktu di mana ia didaftarkan apabila masalah tertentu akan berlaku di bandar pada tanda minit tertentu. Tanda minit adalah sah dalam 0 kedudukan terindeksnya. Ini bermakna 2 bermakna tanda 2, 12, 22, 32, 42, 52 minit pada jam akan sah untuk mencipta masalah ini. Masalah akan terdiri daripada 2 jenis: dan . Kegagalan ralat akan memberi anda kelewatan selama 20 saat. every ERROR TIMEOUT Tamat masa akan memberi anda kelewatan selama 50 saat. Untuk setiap perubahan bandar, semua orang perlu menunggu 10 saat. Sebelum menunggu, bagaimanapun, kereta itu sudah berada di pintu masuk bandar berikut apabila ini dilakukan dalam kaedah sandaran. Dalam kes ini, bandar seterusnya dipilih secara rawak. 4. Pelaksanaan Kami telah melihat sebelum ini, bagaimana untuk mengkonfigurasi pendaftaran kami menggunakan . Setelah melakukan ini, mari kita lihat beberapa contoh cara menghiasi fungsi kita: 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) } Seperti yang kita dapat lihat, panggilan perkhidmatan asal dihiasi terus menggunakan anotasi! Ini hanya boleh dilakukan kerana kehadiran modul dalam pakej: AOP org.springframework.boot spring-boot-starter-aop , atau ialah satu lagi paradigma pengaturcaraan berdasarkan . Ia dianggap sebagai pelengkap kepada , dan ia adalah tepat berapa banyak anotasi yang berfungsi. Ini membolehkan untuk mencetuskan fungsi lain di sekeliling, sebelum, atau selepas kaedah asal dalam titik potong yang tepat. Seperti yang anda boleh lihat daripada contoh, kami sama ada menjana tamat masa atau ralat. , dijana juga dalam kaedah sandaran. Ini tidak mewakili masalah. Kecuali respons. AOP Aspect Oriented Programming OOP OOP BlockageException Walau bagaimanapun, aplikasi berjalan pada dan oleh itu, ralat ini tidak akan dilihat dalam aplikasi. Setakat ini, ini adalah permainan. Saya melaksanakan ini dengan fokus untuk menunjukkan cara menggunakan anotasi boleh menjadikan hidup kita lebih mudah apabila melaksanakan aplikasi yang berdaya tahan. Kami bukan sahaja melaksanakan CircuitBreakers, tetapi juga teknologi lain, seperti , , , , , dan beberapa yang lain. Ini semua telah dibuat untuk melihat bagaimana CircuitBreakers akan dimainkan dalam aplikasi. Jika anda ingin bermain dengan aplikasi ini, sila pergi ke akar projek dan jalankan: WebSockets, WebSockets Spring WebFlux Docker NGINX typescript make docker-clean-build-start Kemudian jalankan arahan ini: 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":[]}' Muatan permintaan ini dijana menggunakan modul . Jika anda melihat ke dalam modul ini, anda akan melihat bahawa ia agak mudah untuk difahami dan anda boleh menjana peta anda sendiri untuk permainan! Akhir sekali, pergi ke dan aplikasi anda sepatutnya berjalan! Sekarang, anda hanya perlu klik pada petak yang betul untuk bermain permainan. Cuma jangan klik pada yang merah jika anda mahu menang. Jika anda ingin melihat pemutus litar sedang beraksi, sila jalankan log aplikasi: from-paris-to-berlin-city-generator http://localhost:9000 docker logs from_paris_to_berlin_web -f Dan secara eksplisit klik pada petak merah untuk menyebabkan kegagalan. 5. Bagaimana Kystrix dan Resilience4J Berbeza sesuai dalam kes di mana aplikasi anda kecil, dan anda ingin memastikan penggunaan DSL benar-benar rendah. Satu-satunya kelemahan nampaknya ialah ia tidak menawarkan cara mudah untuk menghiasi kaedah yang dipengaruhi oleh pemutus litar. nampaknya merupakan pilihan yang bagus untuk kerja perusahaan dengan pemutus litar. Ia menyediakan pengaturcaraan berasaskan anotasi, menggunakan semua faedah van AOP, dan modulnya diasingkan. Dari satu segi, ia juga boleh digunakan secara strategik untuk mata kritikal dalam aplikasi. Ia juga boleh digunakan sebagai rangka kerja lengkap untuk merangkumi banyak aspek aplikasi. Kystrix Resilience4J 6. Kesimpulan Tidak kira jenama yang kami pilih, matlamatnya adalah untuk sentiasa mempunyai aplikasi yang berdaya tahan. Dalam artikel ini, saya menunjukkan beberapa contoh bagaimana saya secara peribadi mengalami penyiasatan pemutus litar dan penemuan saya pada tahap yang sangat tinggi. Ini bermakna bahawa artikel ini benar-benar ditulis untuk orang yang ingin mengetahui apa itu pemutus litar dan apa yang boleh dilakukan oleh Limiters. Kemungkinannya adalah tidak berkesudahan apabila memikirkan tentang menambah baik aplikasi kami dengan mekanisme ketahanan seperti . Corak ini membenarkan penalaan halus aplikasi untuk menggunakan lebih baik sumber yang ada yang kami ada. Kebanyakannya dalam awan, masih sangat penting untuk mengoptimumkan kos kami dan berapa banyak sumber yang sebenarnya perlu kami peruntukkan. circuit breakers Mengkonfigurasi bukanlah tugas remeh kerana ia adalah untuk Limiters, dan kami benar-benar perlu memahami semua kemungkinan konfigurasi untuk mencapai tahap prestasi dan daya tahan yang optimum. Inilah sebabnya saya tidak mahu pergi secara terperinci dalam artikel pengenalan tentang pemutus litar ini. CircuitBreakers boleh digunakan pada pelbagai jenis aplikasi. Kebanyakan aplikasi pemesejan dan penstriman memerlukan ini. Untuk aplikasi yang mengendalikan volum data yang besar yang juga perlu sangat tersedia, kami boleh dan harus melaksanakan beberapa bentuk pemutus litar. Kedai runcit dalam talian yang besar perlu mengendalikan sejumlah besar data setiap hari dan pada masa lalu, digunakan secara meluas. Pada masa ini, kami nampaknya bergerak ke arah yang merangkumi lebih banyak daripada ini. Circuit-breakers Hystrix Resilience4J 6. Rujukan https://youtu.be/kR2sm1zelI4 https://youtu.be/AiP2_icXpAk Tingkatkan kod Kotlin anda dengan Detekt Ketahanan 4J Spring-Boot-Demo Netflix / Hystrix Kystrix – DSL Kotlin untuk Hystrix johanhaleby / kystrix daya tahan4j / resilience4j CircuitBreaker - Bermula dengan resilience4j-circuitbreaker Terima kasih! Saya harap anda menikmati artikel ini sama seperti saya membuatnya! Sila tinggalkan ulasan, ulasan atau sebarang maklum balas yang anda ingin berikan pada mana-mana sosial dalam pautan di bawah. Saya sangat berterima kasih jika anda ingin membantu saya membuat artikel ini lebih baik. Saya telah meletakkan semua kod sumber aplikasi ini pada Terima kasih kerana membaca! GitHub.

Dari Paris ke Berlin: Cara Membuat Pemutus Litar di Kotlin

About Author

KOMEN

GANTUNG TANDA

ARTIKEL INI DIBENTANGKAN DALAM

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps