자기 보호 배경
우선, 우리는 유레카 등록 센터에 대해 유레카의 모든 노드가 동일하다는 것을 이해해야하며 ZK에는 역할 개념이 없습니다. N-1 노드가 손실 되더라도 다른 노드의 정상 작동에는 영향을 미치지 않습니다.
기본적으로 Eureka Server가 특정 시간 내에 마이크로 서비스 인스턴스로부터 하트 비트를받지 못하면 (기본값 90 초) Eureka Server는 인스턴스를 제거합니다. 그러나 네트워크 파티션 실패가 발생하면 마이크로 서비스는 Eureka 서버와 정상적으로 통신 할 수 없으며 마이크로 서비스 자체가 정상적으로 실행됩니다. 이 마이크로 서비스는 현재 제거되어서는 안되므로 자체 보호 메커니즘이 도입됩니다.
자기 보호 메커니즘
자체 보호 메커니즘의 공식 정의 : https://github.com/netflix/eureka/wiki/understanding-eureka-peer-communication
자체 보호 모드는 비정상적인 네트워크 변동을위한 보안 보호 측정입니다. 자체 보호 모드를 사용하면 유레카 클러스터를보다 강력하고 안정적으로 실행할 수 있습니다.
자체 보호 메커니즘의 작동 메커니즘은 클라이언트 노드의 85% 이상이 15 분 이내에 정상적인 심장 박동을 갖지 않으면 Eureka는 클라이언트와 등록 센터에 네트워크 실패가 있다고 생각하고 Eureka Server는 자동으로 자체 보호 메커니즘을 입력한다는 것입니다. 현재 다음 상황이 발생합니다.
1. 유레카 서버는 더 이상 심장 박동을 오랫동안받지 못했기 때문에 만료되어야하는 서비스를 더 이상 제거하지 않습니다. /
2. Eureka Server는 여전히 새로운 서비스에 대한 등록 및 쿼리 요청을 수락 할 수 있지만 현재 노드를 사용할 수 있도록 다른 노드와 동기화되지는 않습니다. /
3. 네트워크가 안정되면 Eureka Server의 새 등록 정보는 다른 노드와 동기화됩니다.
따라서 Eureka Server는 네트워크 고장으로 인해 일부 노드가 손실되는 상황을 처리 할 수 있으며 절반의 절반이 ZK처럼 마비되지 않습니다.
자체 보호 스위치
Eureka 자체 보호 메커니즘, Eureka.server.enable-self-reservation을 구성하여 자체 보호 메커니즘을 비활성화하여 활성화/거짓으로 진실합니다. 기본값이 켜집니다. 프로덕션 환경 에서이 구성을 여는 것이 좋습니다.
개발 환경 구성
개발 환경에서 서비스 실패를 자동으로 제거하려면 다음 구성 만 수정하면됩니다.
1. 등록 센터는 자체 보호 메커니즘을 닫고 유효하지 않은 서비스를 확인하는 시간을 수정합니다.
Eureka : 서버 : enable-self-reservation : false epiction-interval-timer-in-ms : 3000
2. 마이크로 서비스 변형은 서비스 하트 비트의 시간을 줄입니다.
# 기본값 90 초 임대료-초반 : 10# 기본 30 초의 임대-renewal-interval-in-seconds : 3
위 구성은 프로덕션 환경에서 기본 시간 구성을 사용하는 것이 좋습니다. 모든 사람의 학습에 도움이되기를 바랍니다. 모든 사람이 wulin.com을 더 지원하기를 바랍니다.