SpringCloud从零开始（五）之Eureka-server集群

前言

我们在上篇讲到，使用Ribbon负载均衡客户端，实现对Provider集群的访问。微服务注册在Eureka中，访问服务通过，微服务在Eureka中的ID。先在有一个问题，如果我们这个Eureka服务挂掉了，那么整个微服务是不是都会瘫痪呢。那么我们必须保证Eureka服务系统的高可用,为了达到这一目的，我们可以通过搭建Eureka集群来实现。

什么是集群：不同的服务器上运行一个相同的服务，而这些服务器群体，对外作一个超大运算的整体。
作用：高可用，其中一台机器宕机，还是集群的其他机器还能提供相同的服务。

一、Eureka-server集群搭建

工程搭建：
microservice_eureka_7002
microservice_eureka_7003

搭建过程过程同microservice_eureka_7001模块。模块创建完成之后，在本机hosts配置地址映射

//之前eureka7001也配置了
127.0.0.1 eureka7002
127.0.0.1 eureka7003

在这里插入图片描述
创建好了三个eureka-server之后。我们要考虑的问题是，如何让他们3个之间捆绑在一起，形成一个整体。我们可以想象A B C ,三个人，手牵手围成一个圈。

A 牵着 B和C
B牵着 A和B
C牵着 A和B

那么这样，他们三个是不是就捆绑在一起了呢。Eureka，也可以效仿这种模式。在每一个Eureka-server中都注册指向两个Eureka-server.
配置如下：

`microservice_eureka_7001`的配置

server:
  port: 7001 #服务端口名称

eureka:
  instance:
    hostname: eureka7001
  client:
    fetch-registry: false # 不用检索服务 自己是注册中心
    register-with-eureka: false #不向注册中心注册自己
    service-url:
      defaultZone:  http://eureka7002:7002/eureka,http://eureka7003:7003/eureka

`microservice_eureka_7002`的配置

server:
  port: 7002 #服务端口名称

eureka:
  instance:
    hostname: eureka7002
  client:
    fetch-registry: false # 不用检索服务 自己是注册中心
    register-with-eureka: false #不向注册中心注册自己
    service-url:
      #集群版本 配置7001 7003eureka服务的地址信息
      defaultZone:  http://eureka7001:7001/eureka,http://eureka7003:7003/eureka

`microservice_eureka_7003`的配置

server:
  port: 7003 #服务端口名称

eureka:
  instance:
    hostname: eureka7003
  client:
    fetch-registry: false # 不用检索服务 自己是注册中心
    register-with-eureka: false #不向注册中心注册自己
    service-url:
      defaultZone:  http://eureka7001:7001/eureka,http://eureka7002:7002/eureka

二、测试

启动我们配置好集群关系的3个Eureka服务，启动过程过程可能会有点慢，等待启动成功之后，随便访问其中一个eureka服务
http://eureka7001:7001/
在这里插入图片描述
到此处，这三个Eureka-server，注册中心也就关联起来了。

三、修改服务的注册地址

因为我的Eureka地址已经由原来的一个，变成三个，所以，我们注册的服务的时候，应该向Eureka集群服务注册。将三个服务的提供者provider的配置文件里的defaultZone修改如下：

eureka:  #设置eureka注册服务的地址
  client:
    service-url:
        defaultZone:  http://eureka7001:7001/eureka,http://eureka7003:7003/eureka,http://eureka7002:7002/eureka

四、修改服务的发现地址

同样需要修改microservice_product_consumer80发现服务的Eureka地址，也就是加上另外两个注册中心的地址，

eureka:
  client:
    service-url:
#eureka发现服务的列表
       defaultZone:  http://eureka7001:7001/eureka,http://eureka7003:7003/eureka,http://eureka7002:7002/eureka

五、测试

这样三个Eureka注册中心，就可以达到高可用状态，其中某个Eureka因为延迟，或者网络故障，并不会使得整个微服务瘫痪，一个不行了，还有两个帮忙。
启动三个服务的提供者8001 8002 8003 和服务的消费者microservice_product_consumer80。进入Eureka后台。
在这里插入图片描述
服务已经正常注册了，当我们访问http://localhost/consumer/product/list时。也能得到我们的数据，我们开始尝试关掉某一个Eureka注册中心，看看请求是不是还能正常发送。再次发送请求http://localhost/consumer/product/list，也是能够正常访问的，也就说明，整个微服务还是能够正常运转的，Eureka高可用，就的目的也就达到啦。

六、Eureka相对于Zookeeper的优势

Zookeeper遵守CP（一致性，分区容错性），但是不能保证高可用，因为当zookeeper集群某一台机器不可用之后，剩余节点会重新选举leader,但是leader选举的时候过长，会导致在选举这段时候30-120s期间，zookeeper集群是瘫痪的状态。

Eureka遵守AP（高可用，分区容错性），Eureka各个节点都是平等的，几个节点挂点，不会影响的剩余的节点提供服务。只要有Eureak服务还在工作，当Eureka-client向某个eureka节点注册或查询服务时如果发现连接失败，就会自动连接到其他eureka服务器，只不过查询到是数据可能不是最新的（因为eureka无法保证数据的一致性）

在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。
如果在15分钟内，超过85%节点没哟正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障
自我保护机制：
1、Eureka不会从注册列表中移除长时间没有心跳的服务（好死不如赖活着）。
2、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他的节点当中。
3、当网络稳定时候，当前新实例的注册信息会被同步到其他节点当中。
我们经常看到的下面这个警告，其实就是自我保护机制的提示
在这里插入图片描述
所以：Eureka能很好的应对因为网络故障和部分节点失去联系的状况，不会像zookeeper一样，需要重新选举leader，然后导致在选举期间，整个注册中心系统都会瘫痪