springcloud (4): 퓨즈 Hystrix

퓨즈
눈사태 효과
마이크로 서비스 구조 에서 보통 여러 개의 서비스 층 이 호출 되 고 기초 서비스의 고장 은 직렬 고장 을 초래 하여 전체 시스템 이 사용 할 수 없 는 상황 을 초래 할 수 있다. 이런 현상 은 서비스 눈사태 효과 라 고 불 린 다.서비스 눈사태 효 과 는 '서비스 제공 자' 의 사용 불 능 으로 인해 '서비스 소비자' 가 사용 할 수 없고 점차적으로 확대 할 수 없 는 과정 이다.
다음 그림 에서 보 듯 이 A 는 서비스 제공 자로 서 B 는 A 의 서비스 소비자 이 고 C 와 D 는 B 의 서비스 소비자 이다.A 는 사용 할 수 없어 B 의 사용 할 수 없 음 을 일 으 키 고 사용 할 수 없 음 을 눈 덩이 처럼 C 와 D 로 확대 할 때 눈사태 효과 가 형성 된다.
퓨즈 (회로 차단기)
퓨즈 의 원 리 는 전력 과부하 보호 기와 같이 간단 하 다.이 는 빠 른 실 패 를 실현 할 수 있 습 니 다. 만약 에 한 동안 비슷 한 오 류 를 많이 감지 하면 앞으로 여러 호출 이 빠 른 실 패 를 강요 하고 원 격 서버 에 접근 하지 않 으 며 프로그램 이 실패 할 수 있 는 동작 을 계속 시도 하 는 것 을 방지 합 니 다. 이 를 통 해 프로그램 이 오 류 를 수정 하 기 를 기다 리 지 않 고 계속 실 행 될 수 있 습 니 다.CPU 시간 을 낭비 하거나 시간 초과 가 발생 할 때 까지 기다 리 세 요.퓨즈 도 프로그램 으로 하여 금 오류 가 수정 되 었 는 지 진단 할 수 있 게 할 수 있 으 며, 수정 되 었 다 면 프로그램 은 다시 호출 작업 을 시도 할 것 입 니 다.
퓨즈 모드 는 오 류 를 일 으 키 기 쉬 운 에이전트 와 같다.이 에이 전 트 는 최근 호출 에 오류 가 발생 한 횟수 를 기록 한 다음 에 허용 동작 을 계속 하거나 즉시 오 류 를 되 돌려 주기 로 결정 할 수 있 습 니 다.퓨즈 스위치 가 서로 전환 하 는 논 리 는 다음 과 같다.
퓨즈 는 서비스 가 사용 가능 한 마지막 방어선 을 보호 하 는 것 이다.
Hystrix 특성
1. 차단기 메커니즘
차단기 가 이해 하기 쉽 습 니 다. Hystrix Command 가 백 엔 드 서 비 스 를 요청 하 는 데 실패 한 수량 이 일정 비율 (기본 50%) 을 초과 하면 차단기 가 열 린 상태 (Open) 로 전 환 됩 니 다. 이 때 모든 요청 이 백 엔 드 서비스 로 전송 되 지 않 고 실패 합 니 다. 차단기 가 열 린 상태 에서 일정 시간 (기본 5 초) 동안 유지 되면 자동 으로 반 열 린 상태 (HALF - OPEN) 로 전 환 됩 니 다.. 이 때 다음 요청 의 반환 상황 을 판단 합 니 다. 요청 이 성공 하면 차단기 가 폐쇄 상태 (CLOSED) 로 전환 되 지 않 으 면 다시 개방 상태 (OPEN) 로 전환 합 니 다. Hystrix 의 차단 기 는 우리 가정 회로 의 퓨즈 와 같 습 니 다. 백 엔 드 서비스 가 사용 되 지 않 으 면 차단기 가 요청 체인 을 직접 차단 하여 대량의 무효 요청 을 보 내 시스템 스루풋 에 영향 을 주지 않도록 합 니 다.또한 차단 기 는 자체 검 측 및 회복 능력 이 있 습 니 다.
2.Fallback
Fallback 은 강등 작업 에 해당 합 니 다. 조회 작업 에 대해 서 는 fallback 방법 을 실현 할 수 있 습 니 다. 백 엔 드 서비스 에 이상 이 있 을 때 fallback 방법 으로 돌아 갈 수 있 는 값 입 니 다. fallback 방법의 반환 값 은 일반적으로 설 정 된 기본 값 이나 캐 시 에서 나 옵 니 다.
3. 자원 격 리
Hystrix 에 서 는 주로 스 레 드 탱크 를 통 해 자원 격 리 를 실현 합 니 다. 보통 사용 할 때 저 희 는 호출 된 원 격 서비스 에 따라 여러 개의 스 레 드 탱크 를 구분 합 니 다. 예 를 들 어 제품 서 비 스 를 호출 하 는 Command 를 A 스 레 드 탱크 에 넣 습 니 다.계 정 서 비 스 를 호출 하 는 Command 를 B 스 레 드 탱크 에 넣 습 니 다. 이렇게 하 는 주요 장점 은 운영 환경 이 분리 되 었 다 는 것 입 니 다. 이렇게 하면 서 비 스 를 호출 하 는 코드 에 bug 가 존재 하거나 다른 이유 로 자신의 온라인 스 레 드 탱크 가 소 진 되 었 을 때,시스템 의 다른 서비스 에 영향 을 주지 않 습 니 다. 그러나 가 져 온 대 가 는 여러 스 레 드 탱크 를 유지 하 는 것 이 시스템 에 추가 적 인 성능 비용 을 가 져 올 수 있 습 니 다. 성능 에 대해 엄격 한 요구 가 있 고 자신 이 서 비 스 를 호출 하 는 클 라 이언 트 코드 에 문제 가 없 을 것 이 라 고 확신 하 는 경우 Hystrix 신호 모드 (Semaphores) 를 사용 하여 자원 을 격 리 할 수 있 습 니 다.
Feign Hystrix
녹 는 것 은 서비스 호출 에 만 작용 하기 때문에 이전 예제 코드 에 따라 spring - cloud - consumer 프로젝트 관련 코드 만 바 꾸 면 됩 니 다.Feign 에 서 는 이미 Hystrix 에 의존 하고 있 기 때문에 Maven 설정 에 서 는 변경 할 필요 가 없습니다.
1. 프로필
application. properties 에 이 항목 을 추가 합 니 다:

feign.hystrix.enabled=true

2. 리 셋 클래스 만 들 기
Hello Remote Hystrix 클래스 계승 과 Hello Remote 를 만 드 는 방법

@Component
public class HelloRemoteHystrix implements HelloRemote{

    @Override
    public String hello(@RequestParam(value = "name") String name) {
        return "hello" +name+", this messge send failed ";
    }
}

3 、 fallback 속성 추가HelloRemote 클래스 에 지정 한 fallback 클래스 를 추가 하고 서비스 가 녹 을 때 fallback 클래스 의 내용 을 되 돌려 줍 니 다.

@FeignClient(name= "spring-cloud-producer",fallback = HelloRemoteHystrix.class)
public interface HelloRemote {

    @RequestMapping(value = "/hello")
    public String hello(@RequestParam(value = "name") String name);

}

움직임 을 바 꾸 는 것 은 이 정도 입 니 다. 간단 하 죠?
4. 테스트
그럼 우리 한번 테스트 해 보 자.
spring - cloud - eureka, spring - cloud - producer, spring - cloud - consumer 세 항목 을 순서대로 시작 합 니 다.
브 라 우 저 에 입력: http://localhost:9001/hello/neo복귀: hello neo，this is first messge관련 정 보 를 녹 인 후 정상 적 인 방문 에 영향 을 주지 않 는 다 는 뜻 이다.다음은 spring - cloud - producer 프로젝트 의 재 테스트 를 수 동 으로 중단 합 니 다.
브 라 우 저 에 입력: http://localhost:9001/hello/neo복귀: hello neo, this messge send failed반환 결과 에 따 르 면 녹 아내 리 는 데 성공 했다.
예제 코드
참고:
Spring Cloud 와 Docker 실전 마이크로 서 비 스 를 사용 합 니 다.
마이크로 서비스 프레임 워 크 Spring Cloud 소개 Part 5: 마이크로 서비스 시스템 에서 Hystrix, Hystrix Dashboard 와 Turbine 을 사용 합 니 다.
저자: 순결 한 미소 출처:http://www.ityouknow.com/ 판권 은 작자 소유 이 니, 전재 할 때 출처 를 밝 혀 주 십시오