= Fehlertoleranz-Bibliothek für funktionale Programmierung :author: Robert Winkler and Bohdan Storozhuk :icons: :toc: macro :numbered: 1 ifdef::env-github[] :tip-caption: 💡 :note-caption: ℹ️ :important-caption: ❗ :caution-caption: 🔥 :warning-caption: ⚠️ endif::[]

image:https://github.com/resilience4j/resilience4j/actions/workflows/gradle-build.yml/badge.svg["Build Status"] image:https://img.shields.io/nexus/r/io.github.resilience4j/resilience4j-circuitbreaker?server=https%3A%2F%2Foss.sonatype.org["Release"] image:https://img.shields.io/nexus/s/io.github.resilience4j/resilience4j-circuitbreaker?server=https%3A%2F%2Foss.sonatype.org["Snapshot"] image:http://img.shields.io/badge/license-ASF2-blue.svg["Apache License 2", link="http://www.apache.org/licenses/LICENSE-2.0.txt"]

image:https://raw.githubusercontent.com/vshymanskyy/StandWithUkraine/main/banner2-direct.svg["SWUbanner",link="https://vshymanskyy.github.io/StandWithUkraine"]

toc::[]

== Einführung

Resilience4j ist eine leichtgewichtige Fehlertoleranz-Bibliothek, die für funktionale Programmierung entwickelt wurde. Resilience4j stellt Funktionen höherer Ordnung (Dekorateure) bereit, um jede funktionale Schnittstelle, jeden Lambda-Ausdruck oder jede Methodenreferenz mit einem Circuit Breaker, Rate Limiter, Retry oder Bulkhead zu erweitern. Sie können mehr als einen Dekorateur auf jede funktionale Schnittstelle, jeden Lambda-Ausdruck oder jede Methodenreferenz stapeln. Der Vorteil besteht darin, dass Sie die Dekorateure auswählen können, die Sie benötigen – und sonst nichts.

Resilience4j 3 erfordert Java 21.

[source,java]

// Create a CircuitBreaker with default configuration CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("backendService");

// Create a Retry with default configuration // 3 retry attempts and a fixed time interval between retries of 500ms Retry retry = Retry.ofDefaults("backendService");

// Create a Bulkhead with default configuration Bulkhead bulkhead = Bulkhead.ofDefaults("backendService");

Supplier supplier = () -> backendService .doSomething(param1, param2);

// Decorate your call to backendService.doSomething() // with a Bulkhead, CircuitBreaker and Retry // **note: you will need the resilience4j-all dependency for this Supplier decoratedSupplier = Decorators.ofSupplier(supplier) .withCircuitBreaker(circuitBreaker) .withBulkhead(bulkhead) .withRetry(retry) .decorate();

// 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);

// You can also run the supplier asynchronously in a ThreadPoolBulkhead ThreadPoolBulkhead threadPoolBulkhead = ThreadPoolBulkhead .ofDefaults("backendService");

// The Scheduler is needed to schedule a timeout on a non-blocking CompletableFuture ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(3); TimeLimiter timeLimiter = TimeLimiter.of(Duration.ofSeconds(1));

CompletableFuture future = Decorators.ofSupplier(supplier) .withThreadPoolBulkhead(threadPoolBulkhead) .withTimeLimiter(timeLimiter, scheduler) .withCircuitBreaker(circuitBreaker) .withFallback(asList(TimeoutException.class, CallNotPermittedException.class, BulkheadFullException.class), throwable -> "Hello from Recovery") .get().toCompletableFuture();

NOTE: Mit Resilience4j müssen Sie nicht alles auf einmal nutzen, Sie können https://mvnrepository.com/artifact/io.github.resilience4j[*auswählen, was Sie benötigen*].

== Dokumentation

Einrichtung und Verwendung werden in unserem https://resilience4j.readme.io/docs[Benutzerhandbuch] beschrieben.

https://github.com/resilience4j-docs-ja/resilience4j-docs-ja[有志による日本語訳(非公式) Japanische Übersetzung von Freiwilligen (inoffiziell)]
https://github.com/lmhmhl/Resilience4j-Guides-Chinese[这是Resilience4j的非官方中文文档 Chinesische Übersetzung von Freiwilligen (inoffiziell)]

== Übersicht

Resilience4j bietet mehrere Kernmodule:

resilience4j-circuitbreaker: Abschaltung fehlerhafter Aufrufe
resilience4j-ratelimiter: Ratenbegrenzung
resilience4j-bulkhead: Abschottung
resilience4j-retry: Automatische Wiederholung (synchron und asynchron)
resilience4j-timelimiter: Behandlung von Zeitüberschreitungen
resilience4j-cache: Zwischenspeicherung von Ergebnissen

Es gibt außerdem Zusatzmodule für Metriken, Feign, Kotlin, Spring, Ratpack, Vertx, RxJava2 und weitere.

NOTE: Die vollständige Liste der Module finden Sie in unserem https://resilience4j.readme.io/docs#section-modularization[Benutzerhandbuch].

TIP: Für das Paket der Kernmodule oder den +Decorators+-Builder siehe https://mvnrepository.com/artifact/io.github.resilience4j/resilience4j-all[resilience4j-all].

== Bewährte Vorgehensweisen

=== Instanzverwaltung: Wann Instanzen geteilt werden sollten und wann nicht

Eines der wichtigsten Konzepte, das Neueinsteiger verstehen müssen, ist, wann separate Instanzen erstellt und wann Instanzen über verschiedene Remote-Dienste oder Backends hinweg geteilt werden sollten.

[IMPORTANT]

Die goldene Regel: Erstellen Sie eine eindeutige Instanz (mit einer eindeutigen ID) für jeden geschützten Remote-Dienst oder jedes Backend, mit dem Sie kommunizieren.

==== Warum eindeutige Instanzen wichtig sind

Die Erstellung separater Instanzen für jeden Backend-Dienst ist entscheidend für:

Korrekte Metrik-Erfassung - Jede Instanz verfolgt ihre eigenen Metriken, sodass Sie den Zustand einzelner Dienste überwachen können
Isolation von Fehlern - Wenn Dienst A ausfällt, hat dies keine Auswirkungen auf die Resilienz-Muster, die Dienst B schützen
Unabhängige Konfiguration - Unterschiedliche Backends können unterschiedliche Circuit-Breaker-Schwellenwerte, Nebenläufigkeitsgrenzen, Ratenbegrenzungen oder Wiederholungsrichtlinien erfordern

==== Instanzbezogene vs. nicht-instanzbezogene Muster

Verschiedene Resilienz-Muster stellen unterschiedliche Anforderungen an die Trennung von Instanzen:

===== Instanzbezogene Muster (dürfen NICHT geteilt werden)

Diese Muster halten einen Zustand vor, der für einen bestimmten Dienst spezifisch ist, und MÜSSEN über separate Instanzen verfügen:

resilience4j

Beliebteste

[source,java]

[IMPORTANT]

Die goldene Regel: Erstellen Sie eine eindeutige Instanz (mit einer eindeutigen ID) für jeden geschützten Remote-Dienst oder jedes Backend, mit dem Sie kommunizieren.