資訊專欄INFORMATION COLUMN
摘要：以下是它的示例現(xiàn)在，如果需要的話，所有對已修飾的服務塊的調用都要符合速率限制器配置。
案例概述
在本文中，我們討論一下Resilience4j庫。
該庫通過管理遠程通信的容錯性來幫助實現(xiàn)彈性系統(tǒng)。
這個庫受到Hystrix的啟發(fā)，但提供了更方便的API和許多其他特性，如速率限制器(阻塞太頻繁的請求)、Bulkhead(避免太多并發(fā)請求)等。
Maven設置
首先，我們需要將目標模塊添加到我們的pom.xml中（例如，我們添加了Circuit Breaker）：
???? io.github.resilience4j ????resilience4j-circuitbreaker ????0.12.1
在這里，我們使用的是斷路器模塊。所有模塊及其最新版本均可在Maven Central上找到。
在接下來的部分中，我們將介紹庫中最常用的模塊。
斷路器
請注意，對于此模塊，我們需要上面顯示的設置resilience4j-circuitbreaker依賴項。
斷路器模式可以幫助我們在遠程服務中斷時防止一連串的故障。
在多次失敗的嘗試之后，我們可以認為服務不可用/重載，并急切地拒絕所有后續(xù)的請求。通過這種方式，我們可以為可能失敗的調用節(jié)省系統(tǒng)資源。
讓我們看看我們如何通過Resilience4j實現(xiàn)這一目標。
首先，我們需要定義要使用的設置。最簡單的方法是使用默認設置：
CircuitBreakerRegistry circuitBreakerRegistry ??= CircuitBreakerRegistry.ofDefaults();
也可以使用自定義參數(shù)：
CircuitBreakerConfig config = CircuitBreakerConfig.custom() ??.failureRateThreshold(20) ??.ringBufferSizeInClosedState(5) ??.build();
在這里，我們將速率閾值設置為20％，并將嘗試呼叫設置為最少5次。
然后，我們創(chuàng)建一個CircuitBreaker對象并通過它調用遠程服務：
interface RemoteService {
????int process(int i);
}
?
CircuitBreakerRegistry registry = CircuitBreakerRegistry.of(config);
CircuitBreaker circuitBreaker = registry.circuitBreaker("my");
Function decorated = CircuitBreaker
??.decorateFunction(circuitBreaker, service::process);
最后，讓我們通過JUnit測試看看它是如何工作的。
我們將嘗試調用服務10次。我們應該能夠驗證該呼叫至少嘗試了5次，然后在20%的呼叫失敗后停止:
when(service.process(any(Integer.class))).thenThrow(new RuntimeException());
?
for (int i = 0; i < 10; i++) {
????try {
????????decorated.apply(i);
????} catch (Exception ignore) {}
}
?
verify(service, times(5)).process(any(Integer.class));
斷路器的狀態(tài)和設置
斷路器可以處于以下三種狀態(tài)之一:
CLOSED - 一切正常，不涉及短路
OPEN - 遠程服務器已關閉，所有請求都被短路
HALF_OPEN - 從進入開放狀態(tài)到現(xiàn)在已經(jīng)經(jīng)過了一段時間，斷路器允許請求檢查遠程服務是否重新上線
我們可以配置以下設置:
斷路器打開并開始短路呼叫的故障率閾值
等待時間，它定義了斷路器在切換到半開狀態(tài)之前應該保持打開狀態(tài)的時間
斷路器半開或半閉時環(huán)形緩沖器的尺寸
處理斷路器事件的定制電路斷路器事件監(jiān)聽器
一個自定義謂詞，用于評估異常是否應算作故障，從而提高故障率
速率限制器
與上一節(jié)類似，此功能需要resilience4j-ratelimiter依賴項。
顧名思義，此功能允許限制對某些服務的訪問。它的API與CircuitBreaker非常相似- 有Registry，Config和Limiter類。
以下是它的示例：
RateLimiterConfig config = RateLimiterConfig.custom().limitForPeriod(2).build();
RateLimiterRegistry registry = RateLimiterRegistry.of(config);
RateLimiter rateLimiter = registry.rateLimiter("my");
Function decorated
??= RateLimiter.decorateFunction(rateLimiter, service::process);
現(xiàn)在，如果需要的話，所有對已修飾的服務塊的調用都要符合速率限制器配置。
我們可以配置如下參數(shù)：
限制刷新的時間段
刷新周期的權限限制
默認等待權限持續(xù)時間
Bulkhead
在這里，我們首先需要relasticience4j-bulkhead依賴項。
可以限制對特定服務的并發(fā)調用數(shù)。
讓我們看一個使用Bulkhead API配置最多一個并發(fā)調用的示例：
BulkheadConfig config = BulkheadConfig.custom().maxConcurrentCalls(1).build();
BulkheadRegistry registry = BulkheadRegistry.of(config);
Bulkhead bulkhead = registry.bulkhead("my");
Function decorated
??= Bulkhead.decorateFunction(bulkhead, service::process);
要測試此配置，我們將調用模擬服務的方法。
然后，我們確保Bulkhead不允許任何其他調用：
CountDownLatch latch = new CountDownLatch(1);
when(service.process(anyInt())).thenAnswer(invocation -> {
????latch.countDown();
????Thread.currentThread().join();
????return null;
});
?
ForkJoinTask task = ForkJoinPool.commonPool().submit(() -> {
????try {
????????decorated.apply(1);
????} finally {
????????bulkhead.onComplete();
????}
});
latch.await();
assertThat(bulkhead.isCallPermitted()).isFalse();
我們可以配置以下設置：
Bulkhead允許的最大并行執(zhí)行量
嘗試進入飽和艙壁時線程等待的最長時間
重試
對于此功能，我們需要將resilience4j-retry庫添加到項目中。
我們可以使用Retry API 自動重試失敗的呼叫：
RetryConfig config = RetryConfig.custom().maxAttempts(2).build();
RetryRegistry registry = RetryRegistry.of(config);
Retry retry = registry.retry("my");
Function decorated
??= Retry.decorateFunction(retry, (Integer s) -> {
????????service.process(s);
????????return null;
????});
現(xiàn)在讓我們模擬在遠程服務調用期間拋出異常的情況，并確保庫自動重試失敗的調用：
when(service.process(anyInt())).thenThrow(new RuntimeException());
try {
????decorated.apply(1);
????fail("Expected an exception to be thrown if all retries failed");
} catch (Exception e) {
????verify(service, times(2)).process(any(Integer.class));
}
我們還可以配置以下內容：
最大嘗試次數(shù)
重試前的等待時間
自定義函數(shù)，用于修改失敗后的等待間隔
自定義謂詞，用于評估異常是否應導致重試調用
緩存
Cache模塊需要resilience4j-cache依賴項。
初始化看起來與其他模塊略有不同：
