// Payment Service protection
private final CircuitBreaker paymentCB = CircuitBreaker.ofDefaults("paymentService");
private final Retry paymentRetry = Retry.ofDefaults("paymentService");
private final Bulkhead paymentBulkhead = Bulkhead.ofDefaults("paymentService");

// Inventory Service protection
private final CircuitBreaker inventoryCB = CircuitBreaker.ofDefaults("inventoryService");
private final Retry inventoryRetry = Retry.ofDefaults("inventoryService");
private final Bulkhead inventoryBulkhead = Bulkhead.ofDefaults("inventoryService");

// Notification Service protection
private final CircuitBreaker notificationCB = CircuitBreaker.ofDefaults("notificationService");
private final Retry notificationRetry = Retry.ofDefaults("notificationService");

public Order processOrder(OrderRequest request) {
    // Each service call is protected by its own set of resilience instances

    // Call payment service
    Supplier<PaymentResult> paymentCall = () -> paymentService.charge(request);
    PaymentResult payment = Decorators.ofSupplier(paymentCall)
        .withCircuitBreaker(paymentCB)
        .withRetry(paymentRetry)
        .withBulkhead(paymentBulkhead)
        .decorate()
        .get();

    // Call inventory service
    Supplier<InventoryResult> inventoryCall = () -> inventoryService.reserve(request);
    InventoryResult inventory = Decorators.ofSupplier(inventoryCall)
        .withCircuitBreaker(inventoryCB)
        .withRetry(inventoryRetry)
        .withBulkhead(inventoryBulkhead)
        .decorate()
        .get();

    // Call notification service (demonstrates circuit isolation: the notification circuit breaker remains independent of the payment circuit breaker, even if payment opens its circuit in other calls)
    Runnable notificationCall = () -> notificationService.send(request);
    Decorators.ofRunnable(notificationCall)
        .withCircuitBreaker(notificationCB)
        .withRetry(notificationRetry)
        .decorate()
        .run();

    return new Order(payment, inventory);
}

속성(또는 시스템 속성)을 생략하면 라이브러리는 일반 *플랫폼* 스레드로 폴백(fallback)됩니다.

== 사용 예제

[[circuitbreaker-retry-fallback]]
=== CircuitBreaker, Retry 및 Fallback

다음 예제는 CircuitBreaker로 람다 표현식(Supplier)을 데코레이션하고, 예외가 발생했을 때 호출을 최대 3번 재시도하는 방법을 보여줍니다. 재시도 사이의 대기 간격을 구성할 수 있으며, 사용자 정의 백오프 알고리즘도 구성할 수 있습니다.

이 예제는 Vavr의 Try 모나드를 사용하여 예외를 복구하고, 모든 재시도가 실패한 경우 폴백으로 다른 람다 표현식을 호출합니다.

[source,java]
----
// Simulates a Backend Service
public interface BackendService {
    String doSomething();
}

// Create a CircuitBreaker (use default configuration)
CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("backendName");
// Create a Retry with at most 3 retries and a fixed time interval between retries of 500ms
Retry retry = Retry.ofDefaults("backendName");

// Decorate your call to BackendService.doSomething() with a CircuitBreaker
Supplier<String> decoratedSupplier = CircuitBreaker
    .decorateSupplier(circuitBreaker, backendService::doSomething);

// Decorate your call with automatic retry
decoratedSupplier = Retry
    .decorateSupplier(retry, decoratedSupplier);

// Use of Vavr's Try to
// execute the decorated supplier and recover from any exception
String result = Try.ofSupplier(decoratedSupplier)
    .recover(throwable -> "Hello from Recovery").get();

// When you don't want to decorate your lambda expression,
// but just execute it and protect the call by a CircuitBreaker.
String result = circuitBreaker.executeSupplier(backendService::doSomething);
----

==== CircuitBreaker 및 RxJava2

다음 예제는 사용자 정의 RxJava 연산자를 사용하여 Observable을 데코레이션하는 방법을 보여줍니다.

[source,java]
----
CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("testName");
Observable.fromCallable(backendService::doSomething)
    .compose(CircuitBreakerOperator.of(circuitBreaker))
----

NOTE: Resilience4j는 `+RateLimiter+`, `+Bulkhead+`, `+TimeLimiter+` 및 `+Retry+`를 위한 RxJava 연산자도 제공합니다. 자세한 내용은 *https://resilience4j.readme.io/docs/getting-started-2[사용자 가이드]*를 참조하세요.

==== CircuitBreaker 및 Spring Reactor

다음 예제는 사용자 정의 Reactor 연산자를 사용하여 Mono를 데코레이션하는 방법을 보여줍니다.

[source,java]
----
CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("testName");
Mono.fromCallable(backendService::doSomething)
    .transformDeferred(CircuitBreakerOperator.of(circuitBreaker))
----

NOTE: Resilience4j는 `+RateLimiter+`, `+Bulkhead+`, `+TimeLimiter+` 및 `+Retry+`를 위한 Reactor 연산자도 제공합니다. 자세한 내용은 *https://resilience4j.readme.io/docs/getting-started-1[사용자 가이드]*를 참조하세요.

[[ratelimiter]]
=== RateLimiter

다음 예제는 특정 메서드의 호출 속도를 초당 1회를 넘지 않도록 제한하는 방법을 보여줍니다.

[source,java]
----
// Create a custom RateLimiter configuration
RateLimiterConfig config = RateLimiterConfig.custom()
    .timeoutDuration(Duration.ofMillis(100))
    .limitRefreshPeriod(Duration.ofSeconds(1))
    .limitForPeriod(1)
    .build();
// Create a RateLimiter
RateLimiter rateLimiter = RateLimiter.of("backendName", config);

// Decorate your call to BackendService.doSomething()
Supplier<String> restrictedSupplier = RateLimiter
    .decorateSupplier(rateLimiter, backendService::doSomething);

// First call is successful
Try<String> firstTry = Try.ofSupplier(restrictedSupplier);
assertThat(firstTry.isSuccess()).isTrue();

// Second call fails, because the call was not permitted
Try<String> secondTry = Try.of(restrictedSupplier);
assertThat(secondTry.isFailure()).isTrue();
assertThat(secondTry.getCause()).isInstanceOf(RequestNotPermitted.class);
----

[[bulkhead]]
=== Bulkhead
두 가지 격리 전략 및 Bulkhead 구현이 있습니다.

==== SemaphoreBulkhead
다음 예제는 Bulkhead로 람다 표현식을 데코레이션하는 방법을 보여줍니다. Bulkhead는 병렬 실행 수를 제한하는 데 사용할 수 있습니다. 이 벌크헤드 추상화는 다양한 스레딩 및 I/O 모델에서 잘 작동해야 합니다. 세마포어 기반이며, Hystrix와 달리 "shadow" 스레드 풀 옵션을 제공하지 않습니다.

[source,java]
----
// Create a custom Bulkhead configuration
BulkheadConfig config = BulkheadConfig.custom()
    .maxConcurrentCalls(150)
    .maxWaitDuration(100)
    .build();

Bulkhead bulkhead = Bulkhead.of("backendName", config);

Supplier<String> supplier = Bulkhead
    .decorateSupplier(bulkhead, backendService::doSomething);
----

[[threadpoolbulkhead]]
==== ThreadPoolBulkhead
다음 예제는 제한된 큐와 고정 스레드 풀을 사용하는 ThreadPoolBulkhead로 람다 표현식을 사용하는 방법을 보여줍니다.

[source,java]
----
// Create a custom ThreadPoolBulkhead configuration
ThreadPoolBulkheadConfig config = ThreadPoolBulkheadConfig.custom()
    .maxThreadPoolSize(10)
    .coreThreadPoolSize(2)
    .queueCapacity(20)
    .build();

ThreadPoolBulkhead bulkhead = ThreadPoolBulkhead.of("backendName", config);

// Decorate or execute immediately a lambda expression with a ThreadPoolBulkhead.
Supplier<CompletionStage<String>> supplier = ThreadPoolBulkhead
    .decorateSupplier(bulkhead, backendService::doSomething);

CompletionStage<String> execution = bulkhead
    .executeSupplier(backendService::doSomething);
----

[[events]]
== 발생된 이벤트 소비

`+CircuitBreaker+`, `+RateLimiter+`, `+Cache+`, `+Bulkhead+`, `+TimeLimiter+` 및 `+Retry+` 구성 요소는 이벤트 스트림을 발생시킵니다. 이는 로깅, 검증 및 기타 목적으로 소비할 수 있습니다.

=== 예제

`+CircuitBreakerEvent+`는 상태 전환, 서킷 브레이커 리셋, 성공적인 호출, 기록된 오류 또는 무시된 오류일 수 있습니다. 모든 이벤트에는 이벤트 생성 시간 및 호출 처리 시간과 같은 추가 정보가 포함됩니다. 이벤트를 소비하려면 이벤트 소비자를 등록해야 합니다.

[source,java]
----
circuitBreaker.getEventPublisher()
    .onSuccess(event -> logger.info(...))
    .onError(event -> logger.info(...))
    .onIgnoredError(event -> logger.info(...))
    .onReset(event -> logger.info(...))
    .onStateTransition(event -> logger.info(...));
// Or if you want to register a consumer listening to all events, you can do:
circuitBreaker.getEventPublisher()
    .onEvent(event -> logger.info(...));
----

RxJava 또는 Spring Reactor 어댑터를 사용하여 `+EventPublisher+`를 리액티브 스트림으로 변환할 수 있습니다. 리액티브 스트림의 장점은 RxJava의 `+observeOn+` 연산자를 사용하여 CircuitBreaker가 옵저버/소비자에게 알림을 보낼 때 사용할 다른 Scheduler를 지정할 수 있다는 점입니다.

[source,java]
----
RxJava2Adapter.toFlowable(circuitBreaker.getEventPublisher())
    .filter(event -> event.getEventType() == Type.ERROR)
    .cast(CircuitBreakerOnErrorEvent.class)
    .subscribe(event -> logger.info(...))
----

NOTE: 다른 구성 요소의 이벤트도 소비할 수 있습니다. 자세한 내용은 *https://resilience4j.readme.io/[사용자 가이드]*를 참조하세요.

== 발표

[cols="4*"]
|===

|0:34
|https://www.youtube.com/watch?v=kR2sm1zelI4[서킷 브레이커의 대결: Resilience4J vs Istio]
|Nicolas Frankel
|GOTO Berlin

|0:33
|https://www.youtube.com/watch?v=AwcjOhD91Q0[서킷 브레이커의 대결: Istio vs. Hystrix/Resilience4J]
|Nicolas Frankel
|JFuture

|0:42
|https://www.youtube.com/watch?v=KosSsZEqS-k&t=157[Hystrix 이후 세상의 복원 패턴]
|Tomasz Skowroński
|Cloud Native Warsaw

|0:52
|https://www.youtube.com/watch?v=NHVxrLb3jFI[Spring Boot 및 Resilience4j를 사용하여 견고하고 복원력 있는 앱 구축]
|David Caron
|SpringOne

|0:22
|https://www.youtube.com/watch?v=gvDvOWtPLVY&t=140[Hystrix는 죽었습니다. 이제 무엇을?]
|Tomasz Skowroński
|DevoxxPL

|===

== Resilience4j를 사용하는 기업

* *Deutsche Telekom* (하루 4억 건 이상의 요청을 처리하는 애플리케이션)
* *AOL* (낮은 지연 시간 요구 사항이 있는 애플리케이션)
* *Netpulse* (40개 이상의 통합을 가진 시스템)
* *wescale.de* (B2B 통합 플랫폼)
* *Topia* (마이크로서비스 아키텍처로 구축된 HR 애플리케이션)
* *Auto Trader Group plc* (영국 최대 디지털 자동차 마켓플레이스)
* *PlayStation Network* (플랫폼 백엔드)
* *TUI InfoTec GmbH* (숙박 예약 워크플로 스트림 내의 백엔드 애플리케이션)

== 라이선스

Copyright 2020 Robert Winkler, Bohdan Storozhuk, Mahmoud Romeh, Dan Maas 및 기타

Apache License, Version 2.0 (이하 "라이선스")에 따라 사용이 허가됩니다.
이 라이선스를 준수하지 않는 한 이 파일을 사용할 수 없습니다.
라이선스 사본은 다음에서 얻을 수 있습니다.

    http://www.apache.org/licenses/LICENSE-2.0

해당 법률에서 요구하거나 서면으로 합의하지 않는 한, 이 라이선스에 따라 배포되는 소프트웨어는 "있는 그대로" 기준(AS IS BASIS)으로 배포되며,
명시적이든 묵시적이든 어떠한 종류의 보증이나 조건 없이 제공됩니다.
라이선스에 따른 특정 권한과 제한 사항을 확인하려면 라이선스 전문을 참조하십시오.