Eureka服务注册与发现 介绍及使用

五：Eureka服务注册与发现

1. 是什么

Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务注册和发现(请对比Zookeeper)。

Eureka 采用了 C-S 的设计架构。Eureka Server 作为服务注册功能的服务器，它是服务注册中心。

而系统中的其他微服务，使用 Eureka 的客户端连接到 Eureka Server并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块（比如Zuul）就可以通过 Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。

2. 原理讲解

三大角色：
Eureka Server 提供服务注册和发现
Service Provider 服务提供方将自身服务注册到Eureka，从而使服务消费方能够找到
Service Consumer 服务消费方从Eureka获取注册服务列表，从而能够消费服务

Eureka：

Dubbo：

Eureka包含两个组件：Eureka Server和Eureka Client。

Eureka Server 提供服务注册。各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

EurekaClient 是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）。

3. 构建步骤

1. Eureka服务注册中心Module

1.新建microservicecloud-eureka-7001
2.POM
3.YML
4.EurekaServer7001_App主启动类
5.测试 http://localhost:7001/
​ 结果页面：No application available 没有服务被发现
​ 因为没有注册服务进来当然不可能有服务被发现

1.2 POM

<!--eureka-server服务端 -->
<dependency>
	<groupId>org.springframework.cloud</groupId>
  	<artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>
<!-- 修改后立即生效，热部署 -->
<dependency>
	<groupId>org.springframework</groupId>
  	<artifactId>springloaded</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.boot</groupId>
  	<artifactId>spring-boot-devtools</artifactId>
</dependency>

1.3 YML

server:
	port: 7001
eureka:
	instance:
		hostname: localhost  #eureka服务端的实例名称
	client:
		register-with-eureka: false  #false表示不向注册中心注册自己
		fetch-registry: false  #false表示自己端就是注册中心
		service-url:  #单机  #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址
			defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

1.4 EurekaServer7001_App主启动类

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

2. 将已有的部门微服务注册进eureka服务中心

修改microservicecloud-provider-dept-8001：

2.1 修改POM：

<!-- 将微服务provider者注册进eureka -->
<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>

2.2 修改YML：

eureka:
	client:  #客户端注册进eureka服务列表内
		service-url: 
			defaultZone: http://localhost:7001/eureka/

2.3 DeptProvider8001_App主启动类：

@EnableEurekaClient  //本服务启动后会自动注册进eureka服务中

2.4 测试：

先要启动EurekaServer
http://localhost:7001/
微服务注册名配置说明：spring.application.name = microservicecloud-dept

3. actuator与注册微服务信息完善

修改microservicecloud-provider-dept-8001：

3.1 主机名称：服务名称修改：

eureka:
	instance:
		instance-id: microservicecloud-dept8001  #自定义服务名称信息

3.2 访问信息有IP信息展示：

eureka:
	instance:
		prefer-ip-address: true  #访问路径可以显示IP地址

3.3 微服务info内容详细信息：

3.3.1 修改microservicecloud-provider-dept-8001(POM)：

<!-- actuator监控信息完善 -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

3.3.2 总的父工程microservicecloud修改pom.xml添加构建build信息(POM)：

<build>
  <finalName>microservicecloud</finalName>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-resources-plugin</artifactId>
      <configuration>
        <delimiters>
          <!-- 使用maven-resources-plugin插件读取src/mai/resources文件下的application.yml -->
          <!-- 读取application.yml文件里的以$开头，以$结尾之间的信息 -->
          <delimit>$</delimit>
        </delimiters>
      </configuration>
    </plugin>
  </plugins>
</build>

3.3.3 修改microservicecloud-provider-dept-8001(YML)：

info: 
  app.name: atguigu-microservicecloud
  company.name: www.atguigu.com
  build.artifactId: $project.artifactId$	#由maven-resources-plugin插件来进行读取
  build.version: $project.version$

4. eureka自我保护

什么是自我保护模式？

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

在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着

综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。

在Spring Cloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式。

导致原因：一句话：某时刻某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存

5. 服务发现Discovery

对于注册进eureka里面的微服务，可以通过服务发现来获得该服务的信息。

5.1 修改microservicecloud-privider-dept-8001工程的DeptController

@Autowired
private DiscoveryClient client;

@RequestMapping(value = "/dept/discovery", method = RequestMethod.GET)
public Object discovery()
{
  	List<String> list = client.getServices();
  	System.out.println("**********" + list);

  	List<ServiceInstance> srvList = client.getInstances("MICROSERVICECLOUD-DEPT");
  	for (ServiceInstance element : srvList) {
   	 System.out.println(element.getServiceId() + "\t" + element.getHost() + "\t" + element.getPort() + "\t" + element.getUri());
  	}
  	return this.client;
}

5.2 DeptProvider8001_App主启动类

@EnableDiscoveryClient //服务发现

5.3 自测

先要启动EurekaServer
再启动DeptProvider8001_App主启动类，需要稍等一会
http://localhost:8001/dept/discovery

5.4 修改microservicecloud-consumer-dept-80工程的DeptController_Consumer

// 测试@EnableDiscoveryClient,消费端可以调用服务发现
@RequestMapping(value = "/consumer/dept/discovery")
public Object discovery()
{
  return restTemplate.getForObject(REST_URL_PREFIX + "/dept/discovery", Object.class);
}

//DeptConsumer80_App主启动类上添加@EnableEurekaClient注解标签
@EnableEurekaClient

4. 集群配置

1. 原理说明

2. 新建microservicecloud-eureka-7002/microservicecloud-eureka-7003

3. 按照7001为模板粘贴POM

4. 修改7002和7003的主启动类

5. 修改映射配置

在C:\Windows\System32\drivers\etc路径下的hosts文件中添加：

127.0.0.1  eureka7001.com
127.0.0.1  eureka7002.com
127.0.0.1  eureka7003.com

6. 在3台eureka服务器的yml配置

# 7001配置
server:
	port: 7001
eureka:
	instance:
		hostname: eureka7001.com	#eureka服务端的实例名称
	client:
		service-url: 	# 服务注册与发现的交互地址
			defaultZone: 	http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
# 7002配置
server:
	port: 7002
eureka:
	instance:
		hostname: eureka7002.com	#eureka服务端的实例名称
	client:
		service-url: 	# 服务注册与发现的交互地址
			defaultZone: 	http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
# 7003配置
server:
	port: 7003
eureka:
	instance:
		hostname: eureka7003.com	#eureka服务端的实例名称
	client:
		service-url: 	# 服务注册与发现的交互地址
			defaultZone: 	http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/

7.微服务8001注册到上面3台eureka集群配置中

eureka:
  client: #客户端注册进eureka服务列表内
    service-url: 
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

5. 作为服务注册中心，Eureka比Zookeeper好在哪里

1. 传统的ACID分别是什么？关系型数据库遵循ACID规则

事务在英文中是transaction,和现实世界中的交易很类似,它有如下四个特性:
1,1 A (Atomicity)原子性

原子性很容易理解,也就是说事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败整个事务就失败,需要回滚。比如银行转账,从A账户转100元至B账户,分为两个步骤: 1)从A账户取100元; 2)存入100元至B账户。这 1两步要么一起完成,要么一起不完成,如果只完成第一步,第二步失败,钱会莫名其妙少了100元。

1.2c (Consistency)一致性

1. 一致性也比较容易理解,也就是说数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。

1.3I (Isolation)独立性

所谓的独立性是指并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户,在这个交易还未完成的情况下,如果此时B查询自己的账户,是看不到新增加的100元的

1.4D（Durability）持久性

持久性是指一旦事务提交后，他所做的修改将永久的保存在数据库上，即使出现宕机也不会丢失。

2.经典CAP图

最多只能同时较好的满足两个。

CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,因此,根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类:

CA-单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
CP-满足一致性,分区容忍必的系统,通常性能不是特别高。
AP-满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。

3.CAP的3进2

CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。

C:强一致性A:高可用性P:分布式容忍性
CA 传统Oracle数据库
AP 大多数网站架构的选择
CP Redis, Mongodb
注意:分布式架构的时候必须做出取舍。

4.Eureka比Zookeeper好在哪里

著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。
因此 Zookeeper保证的是CP，Eureka则是AP。

4.1 Zookeeper保证CP

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

4.2 Eureka保证AP

Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作 ,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外, Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1.Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2.Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
3.当网络稳定时,当前实例新的注册信息会被同步到其它节点中

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