מפריז לברלין: כיצד ליצור שוברי חשמל בקוטלין

1. הקדמה משמשים בימינו כדי למנוע כמות מוגזמת של בקשות לשירות כזה או אחר שאינו מגיב. כאשר, למשל, שירות נכבה, מכל סיבה שהיא, מפסק צריך, כפי ששמו מציין, לשבור את המעגל. במילים אחרות, במצב בו נעשות מיליון בקשות בו-זמנית כדי לקבל תוצאות של מרוץ סוסים, אנו רוצים שהבקשות הללו יופנו לשירות אחר שיכול להתמודד עם זה. Circuit-breakers שירות אחר זה יכול להיות העתק שלו, או שהוא יכול לשמש אך ורק לביצוע פעולות אחרות לגבי כשל השירות המקורי. המטרה הסופית היא תמיד לשבור שיחות מיותרות ולהוביל את הזרימה למקום אחר. בשנת , הביא את דפוס העיצוב Circuit Breaker לחזית עיצוב פיתוח התוכנה. זה נעשה בפרסום שלו Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) Edition 1st Edition. 2017 Michael Nygard דפוס העיצוב הוא בהשראת מעגלים אלקטרוניים וחשמליים בפועל. עם זאת, במונחים של מושג כללי, רעיון מפסק החשמל הומצא למעשה בשנת על ידי . בדיוק כמו בתקופה ההיא, צריך לטפל בזרם שעולה על גדותיו. במונחים מאוד מאוד פשוטים, זה מה שאנחנו מיישמים על ארכיטקטורת תוכנה במקרה זה. המטרה העיקרית היא לוודא שהמערכת עמידה מספיק. עד כמה היא חייבת להיות עמידה ועד כמה היא חייבת להיות היא באמת בעיני המהנדסים האחראים להקל על יישום הדפוס הזה. הרעיון מאחורי זה הוא שבתנאים מסוימים אולי נרצה לנתב בצורה חלקה את הזרימה של בקשה מסוימת לזרימה אחרת זמינה יותר מאחורי אותה . circuit breaker 1879 Thomas Edison fault-tolerant endpoint נניח שאנו רוצים לבצע בקשה מ- עד מעת לעת, B נכשל ו- תמיד זמין. אם נכשל באופן אקראי, אנו רוצים להגיע ל- כדי להפוך את השירות שלנו לזמין במלואו. עם זאת, כדי להחזיר בקשות ל- , אנו רוצים לוודא ש- לא ייכשל שוב כל כך. לאחר מכן נוכל להגדיר את המערכת שלנו לבצע בקשות אקראיות ל-B ולחזור במלואו ל- רק לאחר ששיעור הכשל ירד לרמה מסוימת. A B C B C B B B אולי נרצה להגיש בקשה C על שגיאה אבל גם על חביון. אם איטי מאוד, ייתכן שנרצה לשלוח מחדש את כל הבקשות ל- . ישנן תצורות אפשריות רבות אחרות, כמו ניסיון להגיע ל- אם לאחר מספר מוגדר של ניסיונות, סוגי בקשות, שרשורים בו-זמניים ואפשרויות רבות אחרות. זה ידוע גם , וזה בעיקר מהלך זמני. B C C short-circuiting על מנת להבין יותר את הידע שלנו על מה זה בעצם מפסק, עלינו להבין שהפסק פועל כישות באפליקציה שלנו. ישנם שלושה סטטוסים עיקריים למפסק. זה יכול להיות סגור, פתוח או חצי פתוח. מצב סגור פירושו שזרימות האפליקציה שלנו פועלות כרגיל. אנו יכולים להגיש בבטחה בקשות לשירות א', בידיעה שכל הבקשות יעברו לשירות ב'. מצב פתוח פירושו שכל הבקשות לשירות ב' ייכשלו. הכללים שהגדרנו לייצג כשל התרחשו וכבר איננו מגיעים לשירות B. במקרה זה, תמיד מוחזר חריג. מצב הוא כאשר המפסק שלנו מקבל הוראה לבצע בדיקות בשירות B כדי לראות אם הוא פעיל שוב. half-open כל בקשה מוצלחת מטופלת כרגיל, אך היא תמשיך להגיש בקשות ל-C. אם B יתנהג כמצופה על פי כללי האימות שקבענו, המפסק שלנו יחזור למצב סגור, ושירות A יתחיל לבצע מבקש בלעדי לשירות B. ברוב היישומים, מפסק עוקב אחר דפוס העיצוב של הדקורטור. עם זאת, ניתן ליישם אותו באופן ידני, ונבחן שלוש דרכים פרוגרמטיות להטמעת מפסקים ולבסוף שימוש ביישום מבוסס AOP. הקוד זמין ב- . GitHub 2. בדיקות רכב בנקודה האחרונה של מאמר זה, נסתכל על משחק מירוץ מכוניות. עם זאת, לפני שנגיע לשם, ברצוני להדריך אותך בכמה מההיבטים של בניית אפליקציה הפועלת עם . circuit breaker 2.1. Kystrix (מ-פריז-לברלין-kystrix-runnable-app) , בתור קטן, היא ספרייה מדהימה שהומצאה ויצרה על ידי . הספרייה מספקת אפשרויות רבות, כולל אינטגרציה עם Spring ו-Spring WebFlux. מעניין להסתכל על זה ולשחק קצת: Kystrixs DSL Johan Haleby se.haleby.kystrix kystrix-core se.haleby.kystrix kystrix-spring יצרתי דוגמה, והיא ממוקמת במודול ב- . ראשית, נסתכל על הקוד: מ-פריז-לברלין-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() } } קוד זה מייצג פקודה 2 של הדוגמה. בדוק את הקוד של פקודה 1. מה שקורה כאן הוא שאנחנו מגדירים את הפקודה שאנחנו רוצים עם . כאן, אנו מגדירים את השיטה שאנו צריכים לקרוא. ב- , אנו מגדירים את הכללים שגורמים לשנות מצב להיפתח. אנו מעכבים במפורש את השיחה שלנו כדי שהיא תימשך שנייה אחת בדיוק. monoCommand commandProperties circuit-breaker במקביל, אנו מגדירים פסק זמן של אלפיות השנייה. זה אומר שלעולם לא נגיע לפסק זמן. בדוגמה זו, אנו יכולים לבצע שיחות עם . מכיוון שזהו רק מבחן, אנו מניחים הוא של מכונית, יגואר ללא צורך . זה גם אומר שלעולם לא נקבל את Tank1 כפי שמוגדר בשיטת ה-fallback. אם עדיין לא שמת לב, תסתכל מקרוב על שיטת ה-fallback. שיטה זו משתמשת ב- . למרות ש- מיושם על פי דפוס העיצוב , הוא לא בדיוק Observable. 5000 Id Id=1 Id circuit-breaker Observable WebFlux Observable Flux עם זאת, Hystrix תומך בשניהם. אנא הפעל את היישום ופתח את הדפדפן שלך בכתובת , כדי לאשר זאת. חשוב להבין שאם תתחיל לבצע שיחות מוקדם מאוד בהפעלה של Spring Boot, ייתכן שבסופו של דבר תקבל הודעת Tank1. הסיבה לכך היא שעיכוב האתחול יכול לעלות על 5 שניות בקלות רבה, תלוי איך אתה מפעיל את התהליך הזה. בדוגמה השנייה, אנחנו הולכים לקצר את הדוגמה שלנו לטנק 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() } } בדוגמה זו, שלנו יכנס למצב פתוח קצה החזר טנק 2 כתגובה. הסיבה לכך היא שאנו גורמים כאן גם לעיכוב של 1 שניות, אך אנו מציינים שמצב הפסקת החשמל שלנו מופעל לאחר סימון ה-500ms. אם אתה יודע איך עובדת, תגלה לא שונה מהתקדם. מה שהיסטריקס לא סיפקה לי בשלב זה, הייתה דרך חלקה וחסרת מאמץ לספק את מה שאני צריך כדי להפוך את המשחק. נראה כי עובדת על בסיס לקוח. משמעות הדבר היא שעלינו להצהיר על הקוד שלנו לפני ביצוע בקשות לשירותים מאחורי השירות הראשי שלנו. circuit-breaker hystrix kystrix Kystrix 2.2. חוסן 4J נראה שרבים מתייחסים כיישום שלם מאוד של מפסק זרם. הניסויים הראשונים שלי נסעו על חקר כמה היבטים חשובים של מפסקים. כלומר, רציתי לראות מפסק שיוכל לעבוד על בסיס פסקי זמן ותדירות של בקשות מוצלחות. מאפשר להגדיר סוגים שונים של . אלה מופרדים ל קטגוריות שונות: , , , ומגביל . כל אלה הם גם שמות של דפוסי עיצוב. מודול מספק יישום מלא של דפוס זה. Resilience4J Resilience4J short-circuiting 6 CircuitBreaker Bulkhead Ratelimiter Retry Timelimiter CircuitBreaker יש לנו הרבה פרמטרים שאנחנו יכולים להגדיר, אבל בעצם, מודול מאפשר לנו להגדיר מה אנחנו מזהים ככשל, כמה בקשות אנחנו מאפשרים במצב חצי פתוח וחלון הזזה, שניתן להגדיר לפי זמן או count, שבו אנו שומרים את ספירת הבקשות המתרחשות במצב סגור. זה חשוב כדי לחשב את תדירות השגיאה. בעיקרו של דבר, אנחנו יכולים לומר שמודול זה יעזור לנו עם קצב הבקשות, אבל זה לא בהכרח נכון. CircuitBreaker CircuitBreaker זה תלוי איך אתה מפרש את זה. נראה שזו דרך טובה יותר לחשוב על זה כעל דרך להתמודדות עם תקלות. בין אם הם מגיעים מפסק זמן או חריג, זה המקום שבו הם מטופלים וכיצד ניתן להפנות את הבקשות בצורה חלקה למקום אחר. מודול נועד להתמודד עם בקשות במקביל. זה לא מגביל שיעור. Bulkhead במקום זאת, הוא מיישם את דפוס העיצוב של , המשמש למניעת התרחשות של עיבוד רב מדי בנקודת קצה אחת. במקרה זה, מאפשרת לנו לעבד את הבקשות שלנו באופן שהן מופצות בכל נקודות הקצה הזמינות. השם מגיע מהתאים האטומים השונים שספינה גדולה צריכה בדרך כלל להימנע מהטבעה, במקרה של תאונה, וכמו במקרה של ספינות, עלינו להגדיר כמה חוטים יהיו זמינים במאגר החוטים ואת זמן החכירה שלהם . Bulkhead Bulkhead Bulkhead מודול נועד לטפל בקצב הבקשות. ההבדל בין זה לבין מודול הוא חיוני כדי שנרצה להיות סובלניים לתעריפים עד לנקודה מסוימת. זה אומר שאנחנו לא צריכים לגרום לכישלון בשביל זה. אנחנו רק אומרים, בעיצוב שאנחנו לא סובלים שיעור מעל ערך מסוים. בנוסף, אנו יכולים להפנות בקשה או להשאיר אותה בהמתנה עד למתן רשות לבצע את הבקשה. המודול הוא כנראה הקל ביותר להבנה מכיוון שאין לו הרבה במשותף עם המודולים האחרים. RateLimiter Bulkhead Retry למעשה, אנו מצהירים במפורש על מספר הניסיונות החוזרים לנקודת קצה מסוימת, עד שנגיע לסף המוגדר שלנו. ניתן לראות את מודול כפישוט של מודול בכך ששניהם חולקים את האפשרות להגדיר פסקי זמן. עם זאת, אינו תלוי בפרמטרים אחרים כמו חלונות הזזה, ואין לו גם חישוב סף כשל מובנה. Timelimiter CircuitBreaker Timelimiter לכן, אם אנו מעוניינים אך ורק בטיפול בתקופות זמן קצובות בעת קריאה לשירות מסוים, ואיננו מביאים בחשבון תקלות אפשריות אחרות, אז כנראה שעדיף לנו עם . Timelimiter 2.2.1. Resilience4J עם Kotlin ו-No Spring Framework (מ-פריז-to-berlin-resilience4j-runnable-app) במודול זה, החלטתי להשתמש רק בספריית 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 יישום זה זמין ב-repo ב- GitHub. ראשית נסתכל על דפוס : 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") } במקרה זה, אנו מקשטים את שלנו בפונקציונליות באמצעות הפונקציה . מה שזה יגרום לפסק זמן, אם הפונקציה שאנו קוראים לה לוקח יותר מדי זמן נקבל אופל קורסה במקום לאנסיה. כדי לנסות זאת, נוכל פשוט להפעיל את האפליקציה ולפתוח . function getPrivateCar TimeLimiter decorateSuspendFunction את http://localhost:8080/cars/timelimiter/normal/1 כשבוחנים את היישום, אנו רואים שלעולם לא נוכל להשיג . וזה בגלל שאנחנו בכוונה מחכים לפני שנחזיר אותו בחזרה. שלנו יש פסק זמן נמוך בהרבה כך שזה לעולם לא יעבוד. הוא די פשוט להבנה. , לעומת זאת, יכול להיות סיפור אחר. זו דוגמה כיצד ניתן לעשות זאת: 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") } במקרה זה, אנו אומרים שאנו רוצים שהמפסק שלנו יסגור את המעגל ברגע ששיעור הכשלים נמוך מ בנכס. גם לשיחות איטיות יהיה סף, אך במקרה זה, הוא יהיה פחות מ-50%. אנו אומרים ששיחה איטית חייבת להימשך יותר מ-1 שניות כדי להיחשב כזו. אנו גם מציינים שמשך מצב חצי פתוח צריך להיות 1 שניות. זה אומר, בפועל, שיהיה לנו מצב פתוח, מצב פתוח למחצה או מצב סגור. 20% אנחנו גם אומרים שאנחנו מאפשרים לכל היותר 500 בקשות מדינה פתוחות למחצה. עבור חישובי שגיאה, המפסק צריך לדעת באיזה סימן הוא יעשה זאת. זה חשוב כדי לקבוע מתי לסגור את המעגל. אנו אומרים ש-2 בקשות יהיו המינימליות הכרחיות לחישוב זה, עם המאפיין . זוכרים שחצי פתוח זה הזמן שבו נמשיך לנסות לגרום למעגל להיסגר אם הבקשות יגיעו לסף כשל בטוח? minimumNumberOfCalls בתצורה זו, זה אומר שעלינו לבצע לפחות בקשות, בתוך חלון ההזזה, כדי לחשב את תדירות השגיאה ולקבוע אם לחזור למצב סגור או לא. זוהי הקריאה המדויקת של כל המשתנים שקבענו. באופן כללי, המשמעות היא שהאפליקציה שלנו כנראה תבצע מספר שיחות לשירות האלטרנטיבי, אם תהיה כזו, היא לא תעבור בקלות רבה ממצב פתוח לסגור בהתחשב בכך ששיעור ההצלחה לעשות זאת חייב להיות 80% במהלך חצי -מצבים פתוחים וזמן הקצוב עבור המצב הפתוח חייבים להתרחש. 2 ישנן דרכים רבות לציין פסקי זמן כאלה. בדוגמה שלנו, אנו אומרים שה- הוא 1s. המשמעות היא שה- שלנו ישמור על סטטוס פתוח, רק אם הבדיקה שלנו אינה עומדת בתנאי המצב הסגור או אם פסק הזמן הזה עדיין לא התרחש. ההתנהגות המוגדרת ב- זה עשויה להיות קשה לעקוב ולחזות, אך ורק בגלל שזמני השבתה, תעריפים ותכונות אחרות של בקשות פשוט לא ניתן לשכפל בדיוק, אבל אם נבצע מספר בקשות לנקודת קצה זו, נראה כי ההתנהגות המתוארת לעיל תואמת את הניסיון שלנו. maxDurationInHalfOpenState CircuitBreaker CircuitBreaker אז בואו ננסה לבצע מספר בקשות לנקודות קצה: ו- . הסיום ב-1 הוא נקודת הסיום של שליפת מכונית מוצלחת, והסיום ב-2 הוא נקודת הסיום של כשל בהשגת מכונית מוגדרת. בהסתכלות על הקוד, אנו רואים שכל דבר מלבד 2 אומר שאנו מקבלים כתגובה. A , אומר שאנחנו מיד זורקים חריג זמן ריצה, מה שאומר שבסופו של דבר אנחנו מקבלים כתגובה. http://localhost:8080/cars/circuit/1 http://localhost:8080/cars/circuit/2 Lancya 2 Opel Corsa אם רק נגיש בקשות לנקודת קצה , נמשיך לראות כתגובה. אם המערכת מתחילה להיכשל, זה כאשר אתה מגיש בקשות ל-2,\; אתה תראה שהחזרה לא תהיה קבועה לאחר זמן מה. תודיע שהיא במצב פתוח ושלא מותרות בקשות נוספות. 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 המפסק שלנו יעבור למצב חצי פתוח לאחר בקשה מוצלחת, וזה אומר שנצטרך לבצע כמה בקשות חזרה ל-1 לפני שהוא יתנרמל. נעבור כמה פעמים לפני שנקבל שוב . הגדרנו את המספר הזה כ-2. זהו המינימום לחישוב שגיאה. אם נגרום רק לכשל אחד ונמשיך להתקשר לנקודת הקצה הלא נכשלת, נוכל לקבל תמונה ברורה יותר של מה שקורה: 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 הודעת הסטטוס הפתוח הזו, למרות שהיא אמיתית, קרתה לאחר ששלחתי 2 בקשות לנקודת הקצה שאינה נכשלת. זו הסיבה שאומרים שהמדינה חצי פתוחה. 2.2.2. Resilience4J עם Spring Boot וללא AOP (מ-פריז-to-berlin-resilience4j-spring-app) בקטע הקודם ראינו איך מיישמים את זה בצורה מאוד פרוגרמטית, ללא שימוש בשום טכנולוגיית Spring. השתמשנו ב-Spring אבל רק כדי לספק שירות מסוג . יתר על כן, לא שינינו דבר לגבי השירותים עצמם. ביישום הבא, נסקור את הספריות הבאות: WebFlux MVC io.github.resilience4j resilience4j-spring-boot2 io.github.resilience4j resilience4j-all io.github.resilience4j resilience4j-reactor כאשר בוחנים כיצד מתבצע הקוד, אנו יכולים לראות הבדל גדול למדי: @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")) } } בדוגמה זו ובדוגמה הבאה, אנו הולכים להסתכל בעיקר על מאפייני הזמן הקצוב. המורכבויות של עצמם פחות רלוונטיות כי זהו מאמר מבוא. מה שחשוב כאן להבין הוא באיזו קלות נוכל ליישם זאת עם המעצבים שסופקו עבור Spring על ידי . למרות שעדיין בצורה , אנו יכולים בקלות לקשט את המפרסם הראשוני שלנו, זה שאנו מקבלים מ- , עם סוגי שאנו רוצים. CircuitBreaker Resilience4J programmatical carService.getCar() short-circuit בדוגמה זו, אנו רושמים , ו- . לבסוף, אנו מגדירים את פונקציית ה-fallback שתופעל ברגע שהתרחשה חריגה של Timeout. מה שאנחנו עדיין צריכים לראות זה איך כל זה מוגדר. אנו מגדירים את Resilience4J באביב בדיוק כמו כל מודול אחר שניתן להגדרה. אנו משתמשים : 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 הקובץ הזה הוא קובץ לדוגמה שנלקח מהריפו שלהם ושונה לדוגמא שלי בהתאם. כפי שראינו בעבר, למקרים של הסוגים השונים של יש שם. השם חשוב מאוד אם יש לך רישום רבים ומגבילים שונים. לדוגמא שלנו, ובדיוק כמו שהוזכר קודם, אנו מעוניינים במגביל הזמן. אנחנו יכולים לראות שזה מוגבל ל-2 שניות. אם אנחנו מסתכלים על הדרך שבה אנחנו מיישמים את השירות, אנחנו רואים שאנחנו מאלצים להתרחש פסק זמן: limiters/short-circuit @Component open class CarService { open fun getCar(): Mono { return Mono.just(Car("Fiat")).delayElement(Duration.ofSeconds(10)); } } בואו נתחיל את האפליקציה, ובדפדפן, עבור אל: . במקום לקבל נקבל . כך הגדרנו את פסק הזמן. באותו אופן, נוכל ליצור בקלות . http://localhost:8080/cars/test/2 Fiat Rolls Royce CircuitBreaker 3. מקרה עד עכשיו ראינו שלוש דרכים חיוניות ליישם ומגבילים קשורים. בהמשך, נסתכל על הדרך האהובה עלי ליישם מפסקים על ידי מעבר על אפליקציה שהכנתי, שהיא משחק פשוט מאוד שבו אנחנו פשוט לוחצים על ריבועים כדי להגיע מפריז לברלין. המשחק נוצר כדי להבין איך ליישם. זה לא אומר הרבה על היכן ליישם את זה. זה רק מקרה שתכננתי כדי לחלוק איתך את הידע. CircuitBreakers לדעת מתי אני משאיר לך להחליט מאוחר יותר. בעיקרו של דבר, אנחנו רוצים ליצור מספר מכוניות ולהקים נתיב לברלין. במקומות שונים במסלול זה, נגיע לערים שבהן ניצור בעיות באופן אקראי. שלנו יחליטו כמה זמן נצטרך לחכות לפני שנאפשר לנו להמשיך הלאה. למכוניות האחרות אין בעיה, ואנחנו רק צריכים לבחור את המסלול הנכון. circuit breakers מותר לנו לבדוק לוח זמנים שבו נרשם מתי תתרחש בעיה מסוימת בעיר בסימון דקה מסוים. סימן הדקה תקף ב-0 מיקומי האינדקס שלו. זה אומר ש-2 אומר סימן של 2, 12, 22, 32, 42, 52 דקות בשעון יהיה תקף ליצירת בעיה זו. הבעיות יהיו משני סוגים: ו- . כשל בשגיאה ייתן לך עיכוב של 20 שניות. every ERROR TIMEOUT פסק זמן ייתן לך עיכוב של 50 שניות. על כל שינוי עיר, כולם צריכים לחכות 10 שניות. אולם לפני ההמתנה, המכונית כבר נמצאת בכניסה לעיר הבאה כאשר הדבר נעשה בשיטות החלפה. במקרה זה, העיר הבאה נבחרת באופן אקראי. 4. יישום ראינו בעבר כיצד להגדיר את הרישום שלנו באמצעות . לאחר שעשינו זאת, בואו נסתכל על כמה דוגמאות כיצד לקשט את הפונקציות שלנו: 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) } כפי שאנו יכולים לראות, קריאות השירות המקוריות מעוטרות ישירות באמצעות הערות! זה יכול להיעשות רק בגלל נוכחות של מודול בחבילה: AOP org.springframework.boot spring-boot-starter-aop , או היא פרדיגמת תכנות נוספת המבוססת על . זה נחשב כהשלמה ל- , וזה בדיוק כמה הערות עובדות. זה מאפשר להפעיל פונקציות אחרות סביב, לפני או אחרי השיטה המקורית בנקודות חיתוך מדויקות. כפי שניתן לראות מהדוגמה, אנו מייצרים פסקי זמן או שגיאות. ה- , נוצר גם בשיטת ה-fallback. זה לא מייצג בעיה. חוץ מהתגובה. AOP Aspect Oriented Programming OOP OOP BlockageException עם זאת, האפליקציה פועלת על ולכן שגיאה זו לא תופיע באפליקציה. עד כה, זה היה המשחק. יישמתי את זה מתוך דגש להראות כיצד שימוש בהערות יכול להפוך את חיינו לקלים הרבה יותר בעת יישום יישום גמיש. לא רק שהטמינו את CircuitBreakers, אלא גם טכנולוגיות אחרות, כמו , , , , ועוד כמה. כל זה נעשה כדי לראות איך CircuitBreakers יפעלו באפליקציה. אם ברצונך לשחק עם היישום הזה, אנא עבור לשורש הפרויקט והפעל: WebSockets, WebSockets Spring WebFlux Docker NGINX typescript make docker-clean-build-start לאחר מכן הפעל את הפקודה הזו: 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":[]}' המטען של בקשה זו נוצר באמצעות המודול . אם תסתכל על המודול הזה, תראה שהוא די פשוט להבנה ושאתה יכול ליצור מפה משלך עבור המשחק! לבסוף, עבור אל והאפליקציה שלך אמורה לפעול! כעת, עליך פשוט ללחוץ על הריבועים הנכונים כדי לשחק את המשחק. רק אל תלחץ על האדומים אם אתה רוצה לזכות. אם אתה רוצה לראות את מפסק החשמל בפעולה, אנא הפעל את יומני היישום: from-paris-to-berlin-city-generator http://localhost:9000 docker logs from_paris_to_berlin_web -f ולחצו במפורש על הריבועים האדומים על מנת לגרום לכשל. 5. איך Kystrix ו-Resience4J נבדלים אידיאלית במקרים שבהם האפליקציה שלך קטנה, ואתה רוצה לוודא שהשימוש ב-DSL נמוך באמת. החיסרון היחיד שנראה הוא שהוא לא מציע דרך קלה לקשט שיטות שיושפעו ממפסק. נראה כי היא אופציה מצוינת לעבודה ארגונית עם מפסקים. הוא אכן מספק תכנות מבוסס הערות, משתמש בכל היתרונות של AOP, והמודולים שלו מופרדים. במובן מסוים, זה יכול לשמש גם אסטרטגית עבור נקודות קריטיות באפליקציה. זה יכול לשמש גם כמסגרת שלמה לכיסוי היבטים רבים של יישום. Kystrix Resilience4J 6. מסקנה ללא קשר למותג שאנו בוחרים, המטרה היא תמיד לקבל יישום גמיש. במאמר זה, הראיתי כמה דוגמאות כיצד חוויתי באופן אישי את חקירת מפסקי החשמל ואת הממצאים שלי ברמה גבוהה מאוד. זה אומר שהמאמר הזה באמת נכתב עבור אנשים שרוצים לדעת מה הם מפסקי זרם ומהם Limiters יכולים לעשות. האפשרויות הן למען האמת אינסופיות כשחושבים על שיפור היישומים שלנו עם מנגנוני גמישות כמו . דפוס זה אכן מאפשר כוונון עדין של אפליקציה על מנת לנצל טוב יותר את המשאבים הזמינים שיש לנו. בעיקר בענן, עדיין חשוב מאוד לייעל את העלויות שלנו וכמה משאבים אנחנו באמת צריכים להקצות. circuit breakers הגדרת היא לא משימה טריוויאלית כפי שהיא עבור ה-Limiters, ואנו באמת צריכים להבין את כל אפשרויות התצורה כדי להגיע לרמות אופטימליות של ביצועים וחוסן. זו הסיבה שלא רציתי להיכנס לפרטים במאמר המבוא הזה על מפסקי זרם. CircuitBreakers ניתן ליישם בהרבה סוגים שונים של יישומים. רוב סוגי יישומי העברת ההודעות והסטרימינג יזדקקו לכך. עבור יישומים שמטפלים בכמויות גדולות של נתונים שצריכים להיות גם זמינים מאוד, אנחנו יכולים וצריכים ליישם צורה כלשהי של מפסק החשמל. חנויות קמעונאיות מקוונות גדולות צריכות להתמודד עם כמויות אדירות של נתונים על בסיס יומי, ובעבר נעשה שימוש נרחב . נכון לעכשיו, נראה שאנחנו מתקדמים לכיוון של שמקיף הרבה יותר מזה. Circuit-breakers Hystrix Resilience4J 6. הפניות https://youtu.be/kR2sm1zelI4 https://youtu.be/AiP2_icXpAk שפר את קוד Kotlin שלך עם Detekt Resilience 4J Spring-Boot-Demo נטפליקס / היסטריקס Kystrix - Kotlin DSL עבור Hystrix johanhaleby / kystrix resilience4j / resilience4j CircuitBreaker - תחילת העבודה עם resilience4j-circuitbreaker תודה לך! אני מקווה שנהניתם מהמאמר הזה כמו שאני עשיתי אותו! אנא השאירו ביקורת, הערות או כל משוב שתרצו לתת על כל אחד מהחברתיים בקישורים למטה. אני מאוד אסיר תודה אם אתה רוצה לעזור לי לשפר את המאמר הזה. שמתי את כל קוד המקור של האפליקציה הזו ב- תודה שקראת! GitHub.