SpringCloud（三）之Eureka（搭建高可用的服务集群）

转载请注明出处：https://blog.csdn.net/weixin_41133233/article/details/85070323
本文出自程熙cjp 的博客

继上一篇搭建简单的单个eureka服务之后，本篇小熙将详细讲解eureka和如何搭建高可用的集群

一. 添加Dashboard模板

添加Dashboard运行模板是为了以后更好的搭建集群。（如果打开项目时右下角有提示：show Dashboard。点击即可，如果没有则按照如下配置）

1. 第一种查找Dashboard模板方法

 view > Tool Windows > Run Dashboard

2. 第二种查找Dashboard模板方法

（1）. 首先找到.idea，在项目名称的下面首先找到.idea，在项目名称的下面

idea

（2）. 在workspace.xml配置如下

dashboard

复制代码：

<component name="RunDashboard">
    <option name="configurationTypes">
      <set>
        <option value="SpringBootApplicationConfigurationType" />
      </set>
    </option>
    <option name="ruleStates">
      <list>
        <RuleState>
          <option name="name" value="ConfigurationTypeDashboardGroupingRule" />
        </RuleState>
        <RuleState>
          <option name="name" value="StatusDashboardGroupingRule" />
        </RuleState>
      </list>
    </option>
  </component>

Dashboard模板如图所示：

二. 修改yml文件，配置集群

1. 修改yml文件

我习惯的是写多个，用到哪一个打开哪一个，其他的注释。
这里推荐其他人的yml配置，个人习惯不同，因人而异吧。

我的yml文件是：

扫描二维码关注公众号，回复： 4667784 查看本文章

server:
#  注意这里的eureka注册是个模板，在搭建集群的时候会被多次复制，其中Eureka01的端口号是：8091，Eureka02的端口号是8092。注意修改
  port: 8090
#  port: 8091
#  port: 8092
spring:
  application:
#   应用名称，会在Eureka中显示
    name: eureka-server
eureka:
  client:
#  是否注册自己的信息到EurekaServer，默认是true。搭建集群的时候需要互相注册，提高项目的高可用性。在用Dashboard模板时，重新修改配置文件部署在Tomcat相当于把原来的复制了一份
    register-with-eureka: true
#  是否拉取其它服务的信息，默认是true，同上
    fetch-registry: true
#  EurekaServer的地址，现在是自己的地址，如果是集群，需要加上其它Server的地址。
    service-url:
#    注意搭建eureka集群的时候，要相互注册，需要修改此处配置
      defaultZone: http://127.0.0.1:8091/eureka,http://127.0.0.1:8092/eureka
#      defaultZone: http://127.0.0.1:8090/eureka,http://127.0.0.1:8092/eureka
#      defaultZone: http://127.0.0.1:8090/eureka,http://127.0.0.1:8091/eureka
#      defaultZone: http://127.0.0.1:${server.port}/eureka

2. 配置集群

由yml配置文件可知，我们是要配置三个euraka集群节点的。所以要创建三个springboot启动索引，如上图按步骤配置

配置结果如图：
eureka集群配置

运行结果如图
eureka集群结果

三. 详解Eureka

1. Eureka比Zookeeper好在哪里

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

2. Zookeeper保证CP

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

3. Eureka保证AP

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

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

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

注意Eureka的心跳机制是每30秒，其他服务向注册中心发送一次心跳，如果90秒内没有发送则被保护起来（保护机制），如果15分钟内还没有续约发送心跳则保护机制失效，然后等待每60秒一次的清除机制，清除这个服务的注册。