SpringCloud03-Eureka 集群搭建

Eureka 集群搭建

我们都知道，一个注册中心来接收服务，如果这个注册中心崩了，放在这个注册中心里边的所有服务都会有故障；所以我们可以搭建集群的方式来避免这个问题，如下图，有三个注册中心，他们分别关联。接下来分别来搭建一下

​ 1）分别建立7001,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: #监控页面
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

server:
  port: 7002

#Eureka配置
eureka:
  instance:
    hostname: eureka7002.com  #Eureka服务端的实例名称
  client:
    register-with-eureka: false #表示是否向Eureka注册中心注册自己
    fetch-registry: false  #fetch-registry如果为false，则表示自己为注册中心
    service-url: #监控页面
      #单机  defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
      #集群 （关联）
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/

server:
  port: 7003

#Eureka配置
eureka:
  instance:
    hostname: eureka7003.com    #Eureka服务端的实例名称
  client:
    register-with-eureka: false #表示是否向Eureka注册中心注册自己
    fetch-registry: false  #fetch-registry如果为false，则表示自己为注册中心
    service-url: #监控页面
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7001.com:7001/eureka/

主启动类都是一样的

package com.mjh.springcloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication
@EnableEurekaServer   //@EnableEurekaServer  服务端启动类，可以接受别人注册进来（即注册中心）
public class EurekaServer_7003 {
    /**
     * 启动之后，访问http://localhost:7001/
     */
    public static void main(String[] args) {
        SpringApplication.run(EurekaServer_7003.class,args);
    }
}

之后打开任意一个端口，我们都能发现其中两个端口都挂载进来了

最后我们打开服务提供者，让其把信息注册进来，当然我们服务提供者也要关联他们三个端口

#Eureka配置，服务注册到哪里
eureka:
  client:
    service-url:
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/
  instance:
    instance-id: springcloud-privider-dept8001  #修改Eureka的状态描述

由此可见，Eureka搭建集群的好处就是如果其中一个注册中心崩了，我们的服务还是会正常运行，只要有一个Eureka还在，就能保住注册服务的可用性，因为一边没有了服务，还有另一边；也不排除三个注册中心都同时崩（这是少见）。

CPA原则与zookeeper对比

ACID是什么

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

CAP是什么

• C（consistency）一致性
• A(Availability) 可用性
• P（Partition tolerance）分区容错性

CAP理论的核心

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个要求
• 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和AP原则三大类
• CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
• CP：满足一致性，分区容错性的系统，通常性能不是特别高
• AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

作为服务注册中心，Eureka和Zookeeper好在哪里

著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）A（可用性）P（分区容错性）

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

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

Zookeeper保证的是CP

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

Eureka保证的是AP

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

1.Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务

2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依旧可用）

3.当网络稳定时，当前实例行的注册信息会被同步到其他节点中

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