Eureka的初理解【服务注册与发现、高可用集群、自我保护机制、与Zookeeper的比较】

Eureka的初理解

什么是Eureka？

Eureka【读音要知道怎么读】

Netflix 在设计 Eureka 时，遵循的就是AP原则（CAP文章下面有介绍）。

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

Eureka的原理介绍

Eureka的基本架构

• SpringCloud封装了 NetFlix 公司开发的 Eureka 模块来实现服务注册和发现(对比Zookeeper)。
• Eureka采用了 C-S 的架构设计，EurekaServer 作为服务注册功能的服务器，他是服务注册中心。
• 而系统中的其他微服务。使用Eureka的客户端连接到 EurekaServer 并维持心跳连接。这样系统的维护人员就可以通过 EurekaServer 来监控系统中各个微服务是否正常运行，SpringCloud的一些其他模块（比如 Zuul )就可以通过 EurekaServer 来发现系统中的其他微服务，并执行相关的逻辑；
• 和Dubbo架构对比：
  Dubbo结构图：
  
  Eureka架构图：
  
  Eureka包含两个组件: Eureka Server和Eureka Client。
  Eureka Server提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表将会注册所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

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

Eureka的服务注册与发现

概括

在前后端分离的架构中，由于服务层被拆分成了多个微服务，而微服务的信息需要被管理起来，SpringCloud就提供了服务注册中心去管理这些信息。

那么问题就来了，为什么微服务需要注册中心呢？

• 由于微服务的数量众多，要进行远程调用就必须要知道服务端的IP地址和端口号，而使用注册中心就可以帮我们管理这些服务端的端口和IP。
• 微服务需要实时的上报自己的状态，这些状态由注册中心统一进行管理，并且将存在问题的服务踢出服务列表，让客户端获取到可用的服务进行调用。

Eureka Server的搭建

1、创建一个Maven项目springcloud-eureka-7001

包结构为：com.olodou.springcloud
这是Eureka的服务端Server

2、添加Pom依赖

			<!--SpringCloud的依赖-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Hoxton.SR8</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
		    <!--eureka服务依赖-->
		    <dependency>
		        <groupId>org.springframework.cloud</groupId>
		        <artifactId>spring-cloud-starter-eureka-server</artifactId>
		        <version>1.4.6.RELEASE</version>
		    </dependency>

yml配置文件中的配置

server:
  port: 7001 # 服务端口

#Eureka的配置
eureka:
  instance:
    hostname: localhost   #Eureka服务端的实例名称
  client:
    register-with-eureka: false   #表示是否向Eureka注册中心注册自己
    fetch-registry: false   # fetch-registry如果为false,则表示自己为注册中心
    server-url:  # 监控页面
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

• register-with-eureka：表示被其它服务调用时需向Eureka注册
• fetch-registry：需要从Eureka中查找要调用的目标服务时需要设置为true
• server-url.defaultZone：配置上报Eureka服务地址高可用状态配置对方的地址，单机状态配置自己。

启动类

//启动之后访问: http://localhost:7001/
@SpringBootApplication
@EnableEurekaServer //EnableEurekaServer服务端的启动类,可以接受别人的注册类
public class EurekaServer_7001 {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServer_7001.class,args);
    }
}

@EnableEurekaServer需要在启动类上用@EnableEurekaServer标识此服务为Eureka服务。

启动EurekaServer访问：http://localhost:7001/

一段时间过后就会该页面就会出现以下信息：

这是Eureka的自我保护机制，下面介绍一下这个机制。

Eureka的自我保护机制

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

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

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

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

• 在SpringCloud中，可以使用eureka.server.enable-self-preservation = false禁用自我保护模式【不推荐关闭自我保护机制】

自我保护机制的输出信息：

Eureka的服务注册

第一步：我们需要在服务提供者provider的pom文件中加入以下Eureka的依赖和监控依赖：

<!--引入eureka的依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <version>1.4.6.RELEASE</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

第二步：同时配置服务提供者provider的yml配置文件

# Eureka的配置  配置服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
  instance:
    instance-id: springcloud-provider-dept-8001   # 修改eureka上的默认描述信息

• service-url.defaultZone：表示注册中心的地址
• instance.instance-id：访问的Eureka页面上的Status名，如下所示：

第三步：在服务提供者的启动类上添加开启Eureka的注解

@SpringBootApplication
@EnableEurekaClient  //在服务启动后自动注册到Eureka中。
public class DeptProvider_8001 {
    public static void main(String[] args) {
        SpringApplication.run(DeptProvider_8001.class,args);
    }
}

@EnableEurekaClient ：在服务启动后自动注册到Eureka中。

第四步：测试，先启动Eureka7001，然后再去启动服务提供者，这个时候就可以看见Eureka的页面有注册的信息：

Eureka的服务的发现

我们可以看见Eureka的页面中的Status，也就是以上图片中有一个超链接，但是点过去啥都没有，因此我们要在服务提供者配置以下：
第一步：导包，导入监控信息的包

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

第二步：在yml配置文件中添加info配置

# Eureka的配置  配置服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka/
  instance:
    instance-id: springcloud-provider-dept-8001   # 修改eureka上的默认描述信息

#info配置
info:
  app.name: Oldou's SpringCloud
  company.name: https://mp.csdn.net/console/home

• app.name：自己设置的项目名
• company.name：公司名

第三步：在Controller中添加输出信息方法

//提供Restful服务
@RestController
public class DeptController {

    //获取一些配置的信息,得到具体的微服务
    @Autowired
    private DiscoveryClient client;
		.....中间其他方法我省略了....
    //注册进来的微服务~ 获取一些消息
    @GetMapping("/dept/discovery")
    public Object discovery(){
        //获取微服务列表的清单
        List<String> services = client.getServices();
        System.out.println("discovery----->service:-->"+services);

        //得到一个具体的微服务信息，通过具体的微服务id，applicationName
        List<ServiceInstance> instances = client.getInstances("SPRINGCLOUD-PROVIDER-DEPT");
        for (ServiceInstance instance : instances) {
            System.out.println(
            		//获取主机名
                    instance.getHost()+"\t"+
                    //获取端口
                    instance.getPort()+"\t"+
                    //获取完整的IP
                    instance.getUri()+"\t"+
                    //获取服务名
                    instance.getServiceId()
            );
        }
        return this.client;
    }
}

第四步：接着启动类上需要添加@EnableDiscpveryClient注解，这样才能开启服务发现，接着启动项目，服务注册之后，访问http://localhost:8001/dept/discovery可以拿到注册的微服务信息，点击Eureka的页面中的Status下的那个链接就会输出配置文件中配置的信息。

同时控制台输出以下信息：

以上为从哪个地方注册过来的IP地址 ，端口号，完整的URI地址，需要注册服务的名字。

高可用环境搭建

Eureka Server 高可用环境需要部署两个Eureka server，它们互相向对方注册。如果在本机启动三个Eureka需要注意三个Eureka Server的端口要设置不一样，这里我们使用端口7001-7003，按照下图搭建一个集群模型

新建springcloud-eureka-7002、springcloud-eureka-7003，同时将Maven依赖拷贝一份。
然后将application.yml文件分别拷贝一份，修改一下server端口
同时还需要将主启动类再拷贝一份修改名字，接着我们为了更容易显得这是一个集群，去本机电脑中修改一下域名映射（C:\Windows\System32\drivers\etc\hosts），注意，这个文件不要轻易删改东西，因为这个文件特别重要。这里我添加了三个域名映射，其实都是localhost

接着我们去每个Eureka Server 中修改配置文件：
例如：7001的服务中的service-url.defaultZone需要注册7002和7003的服务

server:
  port: 7001

#Eureka的配置
eureka:
  instance:
    hostname: eureka7001.com #Eureka服务端的实例名称
  client:
    register-with-eureka: false  #表示是否向Eureka注册中心注册自己
    fetch-registry: false  # fetch-registry如果为false,则表示自己为注册中心
    service-url: # 监控页面 http://${eureka.instance.hostname}:${server.port}/eureka/
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
      #单机配置：http://${eureka.instance.hostname}:${server.port}/eureka/
      #集群配置：需要将另外两个注册中心的地址也关联进来，如上所示

7002的服务中的service-url.defaultZone需要注册7001和7003的服务
7003的服务中的service-url.defaultZone需要注册7001和7002的服务

配置完成之后就一个个都要启动。先启动注册中心，再启动提供者。
![在这里插入图片描述](https://img-blog.csdnimg.cn/20200929000301516.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzI0NjIxNQ==,size_16,color_FFFFFF,t_70#pic_center
总结
1、在实际使用时Eureka Server至少部署两台服务器（这里我弄了三台），实现高可用。
2、两台Eureka Server互相注册（也就是在service-url.defaultZone中添加其他两个注册服务的地址）。
3、微服务需要连接两台Eureka Server注册，当其中一台Eureka死掉也不会影响服务的注册与发现。
4、微服务会定时向Eureka server发送心跳（5秒发送一次），报告自己的状态。
5、微服务从注册中心获取服务地址以RESTful方式发起远程调用

Eureka的集群的优点，下面介绍。

Eureka的CAP原则以及与Zookeeper的对比

CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

• 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
• 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
• 分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

RDBMS（Mysql、Oracle、sqlServer）关系型数据库-------->ACID

NoSQL（Redis、Mongodb）非关系型数据库---------->CAP

ACID

• A（Atomicity）：原子性、
• C（Consistency）：一致性
• I（Isolation）：隔离性
• D（Durability）：持久性

作为注册中心，Eureka比Zookeeper好在哪里？

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

• Zookeeper保证的是CP；
• Eureka保证的是AP。

Zookeeper保证的是CP

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

Eureka保证的是AP

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

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

Zookeeper与Eureka区别总结【重点】：

• zookeeper保证cp（一致性）；
• eureka保证ap（可用性）；
• zookeeper在选举Leader的期间注册服务瘫痪，期间不可用；
• eureka的各个节点平等关系，只要有一台就可保证服务可用，而查询到的数据可能不是最新的，可以很好应对网络故障导致部分节点失联情况；
• zookeeper有leader、follower、observer三种角色，而eureka各个节点平等；
• zookeeper采用半数存活原则（避免脑裂），eureka采用自我保护机制来解决分区问题；
• eureka本质是个工程，zookeeper只是一个进程 ZooKeeper基于CP，不保证高可用，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。Eureka基于AP，能保证高可用，即使所有机器都挂了，也能拿到本地缓存的数据。作为注册中心，其实配置是不经常变动的，只有发版（发布新的版本）和机器出故障时会变。对于不经常变动的配置来说，CP是不合适的，而AP在遇到问题时可以用牺牲一致性来保证可用性，既返回旧数据，缓存数据。所以理论上Eureka是更适合做注册中心。而现实环境中大部分项目可能会使用ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。

这是我初学Eureka的时候所记笔记以及整理梳理所得的知识，如果对你有所帮助，请记得点赞支持一下哈，如果文中有不恰当需要纠正的地方，还请各位同行大佬指正，在此感激不尽！

参考文章：https://www.jianshu.com/p/e2e3ded1f54a

本文地址：https://blog.csdn.net/weixin_43246215/article/details/108859072