1. 유레카 무엇입니까

유레카 넷플릭스의 서브 모듈 코어 모듈이다. 유레카 REST 기반 위치 서비스를위한 서비스 클라우드 서비스 검색 및 복구를 달성하기 위해서, 중간 층이다. 서비스 등록 및 검색이 마이크로 서비스 아키텍처에 매우 중요하다, 서비스 발견 및 등록되어있는, 단지 서비스의 식별자를 사용, 당신은 서비스에 액세스 할 수있는 서비스 요청의 구성 파일을 수정 할 필요없이. 레지스트리 사육사 두보와 유사

2. 원리

유레카 서버 및 클라이언트 유레카 다음 CS 디자인 아키텍처를 사용하여 유레카는 두 가지 구성 요소가
유레카 서버 : 서비스 레지스트리 서비스를 제공을 즉 유레카의 서비스 기능 등록 서버, 서비스 레지스트리 및 기타 마이크로 시스템, 고객 서비스, 사용과 같은 유레카 서버에 연결하고 하트 비트 연결을 유지하기 위해 유레카 클라이언트를 종료, 유지 보수 인력은 이러한 시스템은 각 마이크로 시스템 서비스는 유레카 서버가 제대로 작동하고 모니터링 할 수 있습니다. 유레카 서버 시스템의 다른 서비스에 의해 발견 및 관련 로직을 할 수있다 (Zuul는, 예를 들어) 봄 클라우드 다른 모듈
유레카 클라이언트 : 자바 클라이언트, 단순화 된 유레카 서버 상호 작용의 로컬 상응하는 우리의 프로그램 서비스는 클라이언트는 경우가 내장로드 폴링 알고리즘 부하 분산 응용 프로그램을 시작한 후, (기본 시간은 30 초입니다) 유레카 서버에 하트 비트를 보낼 것 가지고 유레카 서버의 복수 하트 비트 노드를 이길 기간 내에 수신되지, 유레카 서버는 서비스 레지스트리에서이 서비스 노드 (기본 90 초)을 제거합니다

3. 자기 보호 메커니즘

특정 시간 (기본 30 초) 조건 내에서 EurekaServer 하트 비트에게 위젯 서비스 인스턴스를 수신하지 않은 경우 기본적으로, 취소는 인스턴스를 EurekaServer 것입니다. 마이크로 및 EurekaServer 서비스 사이의 네트워크 파티션 장애, 의사 소통을 할 수없는 경우 서비스 자체가 다음이이 마이크로 서비스를 쓸 수 없습니다해야, 실제로 마이크로 건강 때문에 그러나, 위의 행동은 매우 위험 할 수 있습니다. "림프 홈 모드"이 문제가 해결 유레카 : EurekaServer 노드가 클라이언트 (네트워크 파티션 오류가 발생했을 수 있습니다) 짧은 시간에 너무 많은 손실을 때, 노드는이 모드, EurekaServer에 한 번, 자기 보호 모드로 전환 레지스트리의 정보를 보호하는 서비스가 더 이상 레지스트리에서 서비스 데이터를 삭제 (즉, 어떤 마이크로 서비스를 작성하지). 네트워크 장애 복구 (즉, 심장 박동이 임계 값 이상으로 복원) 할 때, 노드는 자동으로 EurekaServer 자기 보호 모드를 종료합니다. 그것의 디자인 철학은 다음과 같습니다 서비스 등록 정보가 아니라 예약 오류가 맹목적으로 가능한 의료 서비스 인스턴스를 작성하지 않습니다. 라이브 살아보다 낫다.

4. 프로젝트 전투

4.1 유레카 서버

유레카 의존 추가

 <dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-eureka-server</artifactId>
 </dependency>

마스터 부트 클래스는 위의 유레카에 대한 메모를 추가

@SpringBootApplication
@EnableEurekaServer // EurekaServer服务器端启动类,接受其它微服务注册进来
public class EurekaServer7001_App
{
	public static void main(String[] args)
	{
		SpringApplication.run(EurekaServer7001_App.class, args);
	}
}

프로필

server: 
  port: 7001  // eureka server 端口号
 
eureka: 
  instance:
    hostname: eureka7001.com  #eureka服务端的实例名称
  client: 
    register-with-eureka: false     #false表示不向注册中心注册自己。
    fetch-registry: false     #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url: 
      #单机 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/       #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/  // 集群

성공적인 다른 서비스를 구축하기 위해이 유레카 서버입니다 (그렇게 간단하지 않음)을 등록 할 수 있습니다

4.2 유레카 클라이언트

따라 추가

  <dependency>
	  <groupId>org.springframework.cloud</groupId>
	   <artifactId>spring-cloud-starter-eureka</artifactId>
  </dependency>
  <dependency>
	   	<groupId>org.springframework.cloud</groupId>
	   	<artifactId>spring-cloud-starter-config</artifactId>
   </dependency>

시작 항목 구성, 유레카에 시작하는 주요 레지스터에 @EnableEurekaClient를 추가

@SpringBootApplication
@EnableEurekaClient //本服务启动后会自动注册进eureka服务中
@EnableDiscoveryClient //服务发现
public class DeptProvider8001_App
{
	public static void main(String[] args)
	{
		SpringApplication.run(DeptProvider8001_App.class, args);
	}
}

프로필

eureka:
  client: #客户端注册进eureka服务列表内
    service-url: 
      #defaultZone: http://localhost:7001/eureka
       defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/      
  instance:
    instance-id: microservicecloud-dept8001
    prefer-ip-address: true     #访问路径可以显示IP地址

이 유레카에서 등록이 서비스를 노출합니다

5. 유레카 차분 사육사

전 처음 두 개념의 차이 :

전통적인 ACID는 다음과 같습니다

A (자성) 자성
C (일관성) 일관성
I (절연) 독립
D (내구성) 지속성

CAP는 의미 :

C (일관성) 강한 일관성
A (가용성) 지원
P (파티션 허용) 파티션 결함 허용
CAP는 동시에 충족시킬 수 없다, 두 점을 보장 할 수

5.1 사육사가 CP를 확인

레지스트리에 쿼리 서비스 목록, 레지스트리 등록 정보 전에 몇 분을 반환 견딜 수 있지만, 직접 아래로 서비스를받을 수없는 경우 밖에 사용할 수 없습니다. 즉, 서비스 등록은 일관성보다 가용성에 대한 요구 사항 ,하지만 다른 노드와 마스터 노드는 네트워크가 접촉 불량을 잃었 때문에 때, 나머지 노드가 리더 선거 다시되며, 상황이 될 ZK,하지만 리더 선거 시간이 너무 깁니다 30 ~ 120S, 전체 클러스터 ZK 마스터 ZK 클러스터 노드의 손실을 주도 네트워크 문제로 인해, 클라우드 배포 환경에서, 선거 등록 서비스 기간 동안 마비되었다 선거 동안 사용할 수없는 더 큰 확률이 일어날 것입니다 일, 선거의 타이밍이 장기 사용의 등록에지도 서비스가 결국 회복하지만지라도 용납되지 않는다

5.2 유레카 그 AP를 보장

가용성을 보장하는 우선 순위. 유레카 각 노드는 동일한 정상 노드에 영향을 미치지 않습니다 몇 노드를 중지 나머지 노드는 여전히 등록 및 조회 서비스를 제공 할 수 있습니다. 연결 실패에 등록 유레카 유레카 클라이언트는 여전히 유레카이있는 한 자동 우리는 등록 서비스를 사용할 수 보장 할 수, 한, 다른 노드로 전환됩니다, 발견 (가용성을 보장하기 위해) 하지만, 정보가 현재하지 않을 수 쿼리 ( 그것은 강력한 보증하지 않습니다 ) 일관성을 . 또한, 15 개 노드의 85 % 이상이없는 정상 심장 박동 경우 유레카는, 다음 클라이언트는 유레카 및 네트워크 장애의 등록 센터, 다음 나타납니다 간주됩니다 자체 보호 메커니즘이 상황 :

유레카는 더 이상 오랜 시간 동안 제거 할 수 및 목록에서 하트 비트 만료 등록 서비스를받을 수 없습니다해야
유레카는 여전히 새로운 서비스에 대한 등록 및 쿼리 요청을 받아 들일 수 있지만 다른 노드 (현재 노드가 계속 사용할 수 있도록, 즉)에 동기화되지 않습니다
네트워크가 안정되면, 새로운 등록 정보의 현재 인스턴스는 다른 노드에 동기화됩니다

따라서, 유레카는 연결이 끊어 일부 노드로 이어질 수 있지만 사육사와 같은 전체 등록 서비스의 마비로 네트워크 장애를 처리하는 것은 매우 좋은 수 있습니다

[유레카] SpringCloud 서비스의 등록 및 검색

기사 디렉토리