1. Eureka是什么

Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于Rest的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对微服务架构来说非常重要，有了服务发现与注册，只需使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。类似于Dubbo的注册中心zookeeper

2. 原理

Eureka采用了C-S的设计架构，有两个组件：Eureka Server 和 Eureka Client
Eureka Server:提供服务注册服务，即作为服务注册功能的服务器，是服务注册中心，而系统中其他微服务，使用Eureka的客户端 Eureka Client连接到Eureka Server并维持心跳连接，这样系统的维护人员就可通过Eureka Server来监控系统中各个微服务是否正常运行。Spring Cloud的其它模块（如ZUUL）就可通过Eureka Server来发现系统中的其它服务，并进行相关的逻辑
Eureka Client:是一个java客户端，用于简化Eureka server的交互，相当于我们在的本地提供服务的程序，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器，在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒），如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）

3.自我保护机制

默认情况下，如果EurekaServer在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险，因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题：当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式，一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（即不再注销任何微服务）。当网络故障恢复后（即受到的心跳数重新恢复到阈值以上），该EurekaServer节点会自动退出自我保护模式。它的设计哲学为：宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。好死不如赖活着。

4. 项目实战

4.1 Eureka server

添加Eureka依赖

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

主启动类上面，添加Eureka有关注解

@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/  // 集群

到此eureka server就搭建成功了，其它服务就可以注册了（是不是很简单）

4.2 Eureka Client

添加依赖

  <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就注册到Eureka上了

@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地址

到此此服务就暴露出来注册到Eureka上了

5. Eureka 与 zookeeper 的区别

将区别前先将两个概念：

传统的ACID分别是：

A （Atomicity）原子性
C （Consistency）一致性
I （Isolation）独立性
D （Durability）持久性

CAP指：

C （Consistency）强一致性
A （Availability）可用性
P （Partition tolerance）分区容错性
CAP只能保证两点，无法同时满足

5.1 Zookeeper保证的是CP

当向注册中心查询服务列表时，可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。即服务注册功能对可用性的要求要高于一致性，但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，但是leader选举时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，在云部署的环境下，因网络问题导致zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是选举时间导致的注册长期不可用是不能容忍的

5.2 Eureka 保证的是AP

优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以可以提供注册和查询服务。而Eureka客户端在向Eureka注册是发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查询到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册列表中移除因长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）
当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此，Eureka可以很好的应对网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

【SpringCloud】Eureka服务注册与发现

文章目录