1)SldingWindowType
서킷브레이커의 동작을 결정할 때 바라볼 대상(요청)을 일부로 한정 시키는 개념 -->최근 데이터를 대상으로
기본값 Count_base -->요청 개수를 기준으로
Time_based -->시간을 기준으로 결정
2)SldingWindowSize(기본값 100)
100으로하면 100개의 요청을 기준으로 설정하게 됨
3)failureRateThreshold:70-->몇 퍼센트를 실패해야 서킷브레이커를 OPEN으로 열지
4)minimumNumberOfCalls : 100
슬라이딩 윈도우가 다 채워지지 않았을 때 이 숫자(5라고 하면 5개)에서 실패율을 환산해서 서킷변경
5)waitDuratinInOpenState : 오픈에서 얼마큼 머물러있게 할 것인지
6)permittedNumberOfCallsinHalfOpenState : 횟수만큼 시도후 임계치만큼 높으면 closed //아니면 open
@Bean
public RegistryEventConsumer<CircuitBreaker> myRegistryEventConsumer() {
return new RegistryEventConsumer<CircuitBreaker>() {
@Override
public void onEntryAddedEvent(EntryAddedEvent<CircuitBreaker> entryAddedEvent) {
log.info("RegistryEventConsumer.onEntryAddedEvent");
entryAddedEvent.getAddedEntry().getEventPublisher()
.onEvent(event -> log.info(event.toString()));
entryAddedEvent.getAddedEntry()
.getEventPublisher()
.onFailureRateExceeded(event -> log.info("FailureRateExceeded: {}", event.getEventType()));
}
@Override
public void onEntryRemovedEvent(EntryRemovedEvent<CircuitBreaker> entryRemoveEvent) {
log.info("RegistryEventConsumer.onEntryRemovedEvent");
}
@Override
public void onEntryReplacedEvent(EntryReplacedEvent<CircuitBreaker> entryReplacedEvent) {
log.info("RegistryEventConsumer.onEntryReplacedEvent");
}
};
}
이벤트 핸들러를 어떻게 활용할것인가?
->서비스 모니터링용 로그를 활용할 수 있다.
이 오픈 상태를 주변에 전파해줄 필요가 있다.
다른 서버들도 open 상태로 전파
트래픽을 차단할 필요가 있는 경우
부하가 높을 때 발생할 수 있는 예외들을 찾아봐야 함
-->부하테스트를 해보고, 어떤 예외가 발생하는지 확인해야함
유효성 검사나 NullpointerException처럼 서킷이 열리는 것과 무관한 예뇌는 등록하면 안된다.
Exception이나 RuntimeException처럼 너무 높은 수준의 예외도 등록 x
해당 서버에 문제가 있어서 502 응답이 오는데 이건 예외x
-->이걸 예외로 직접 던져주고 recordException으로 등록
fallback 메서드가 실행되는 경우
1.Record Exception이 발생했을 때
2.Ignore Exception이 발생했을 때
3.서킷이 Open 돼 요청이 실행되지 않을 때
폴백으로 할 수 있는 것?
1)param을 통해서 원래 메서드가 뭘 하려고 했는지 알 수 있다.
2)로그를 찍거나, 실패했던 요청을 모아뒀다가 나중에 재시도할 수도 있다.
(DB에 저장)
3)리뷰저장소의 요청 값을 빈 값으로 주거나, 캐시값을 주는 식으로
구동장치 : 시스템을 움직이거나 제어할 때 쓰는 기계 장치
->모니터링 정보, api 설정변경