Spring Cloud第三篇 | 搭建高可用Eureka注册中心

​

​本文是Spring Cloud专栏的第三篇文章，了解前两篇文章内容有助于更好的理解后面文章：

1. Spring Cloud第一篇 | Spring Cloud前言及其常用组件介绍概览

2. Spring Cloud第二篇 | 使用并认识Eureka注册中心

​

一、Eureka注册中心高可用集群概述

1-1、传统架构

在微服务架构的这种分布式系统中,我们要充分考虑各个微服务组件的高可用性问题,不能有单点故障,由于注册中心Eureka本身也是一个服务,如果它只有一个节点,那么它有可能发生故障,这样我们就不能注册与查询服务了,所以我们需要—个高可用的服务注册中心,这就需要通过注册中心集群来解决。Eureka服务注册中心它本身也是一个服务,它也可以看做是一个提供者,又可以看做是一个消费者,我们之前通过配置eureka.client.register-with-eureka= false让注册中心不注册自己,但是我们可以向其他注册中心注册自己。

Eureka server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己,这样就会形成一组互相注册的服务注册中心,进而实现服务清单的互相同步,往注册中心A上注册的服务,可以被复制同步到注册中心B上,所以从任何一台注册中心上都能查询到已经注册的服务,从而达到高可用的效果。

​

二、Eureka注册中心高可用集群搭建

Eureka注册中心高可用集群就是各个注册中心相互注册

1、我们复制Eureka服务端(springcloud-eureka-server)的application.yml为application-eureka8701.yml，application-eureka8702.yml,我们让8701和8702的Eureka服务相互注册。

修改application-eureka8701.yml相应的配置如下：

spring:
  application:
    name: springcloud-eureka-server
server:
  port: 8701
#设置该服务中心的hostname，指定ip,该实例名称不能重复
eureka:
  instance:
    hostname: eureka8701
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka8702:8702/eureka

    修改application-eureka8701.yml相应的配置如下

spring:
  application:
    name: springcloud-eureka-server
server:
  port: 8702
#设置该服务中心的hostname，指定ip,该实例名称不能重复
eureka:
  instance:
    hostname: eureka8702
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka8701:8701/eureka

2、复制SpringcloudEurekaServerApplication启动类命名为SpringcloudEureka8701ServerApplication，SpringcloudEureka8702ServerApplication，鼠标放在启动类上右键选择如图

​

然在启动类SpringcloudEureka8701ServerApplication添加-Dspring.profiles.active=eureka8701

​

同理8702启动类操作也是一样，此处省略。

3、为了让eureka8701和eureka8702能够被正确相互访问到，同步数据，如果不能相互访问，Eureka服务中的数据不能同步共享，我们需要在C:\Windows\System32\drivers\etc目录下的hosts文件中添加两行配置，如下:

127.0.0.1 eureka8701
127.0.0.1 eureka8702

4、启动两个SpringcloudEureka8701ServerApplication，SpringcloudEureka8702ServerApplication服务我们可以看到注册成功了。

​

Eureka8702也是如此，到此Eureka服务集群搭建完毕

三、Eureka详解

1、服务消费者模式

1-1、获取服务

消费者启动的时候，使用服务别名，会发送一个rest请求到服务注册中心获取对应的服务信息，然后会缓存到本地jvm客户端中，同时客户端每隔30秒从服务器上更新一次。

可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改，该配置默认值为30， 单位为秒。

1-2、服务下线

在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中，当服务实例正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务中心:“我要下线了”。服务端在接收到请求之后，将该服务状态置为下线(DOWN)，并将该下线事件传播出去。

2、服务注册模式

2-1、失效剔除

有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障原因使得服务不能正常工作，而服务注册中心并未收到“服务下线”的请求。为了从服务表中将这些无法提供服务的实例剔除，Eureka Server 在启动的时候会创建一个定时任务默认每隔一段时间(默认为60秒eureka.server.eviction-interval-timer-in-ms=6000L)将当前清单中超时(默认为90秒eureka.instance.lease-expiration-duration-in-seconds= 90)没有续约的服务踢除出去

2-2、Eureka服务注册中心自我保护机制

当我们在本地调试基于Eureka的程序时，基本上都会碰到这样一个问题， 在服务主中心的信息面板中出现类似下面的红色警告信息，在开发测试时，需要频繁地重启微服务实例，但是我们很少会把eureka server一起重启（因为在开发过程中不会修改eureka注册中心），当一分钟内收到的心跳数大量减少时，会触发该保护机制。可以在eureka管理界面看到Renews threshold和Renews(last min)，当后者（最后一分钟收到的心跳数）小于前者（心跳阈值）的时候，触发保护机制，会出现红色的警告：

​

实际上，该警告就是触发了Eureka Server的自我保护机制，服务注册到Eureka Server之后，会维护个心跳连接， 告诉Eureka Server自己还活着。Eureka Server在运行期间，会统计客户端节点的心跳失败的比例在15分钟之内是否低于85%如果出现低于的情况，如果低于85%，那就触发自我保护机制，单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致)，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请使用重试、断路器等机制。

在没有Eureka自我保护的情况下,如果 Eureka Server在一定时间内没有接收到某个微服务实例的心跳, Eureka Server将会注销该实例,但是当发生网络分区故障时,那么微服务与 Eureka Server之间将无法正常通信,以上行为可能变非常危险了，因为微服务本身其实是正常的,此时不应该注销这个微服务，如果没有自我保护机制，那么Eureka Server就会将此服务注销掉。

Eureka通过“自我保护模式”来解决这个问题——当 Eureka Server节点在短时间内丢失过多客户端时(可能发生了网络分区故障),那么就会把这个微服务节点进行保护。一旦进入自我保护模式, Eureka server就会保护服务注册表中的信息,不删除服务注册表中的数据(也就是不会注销任何微服务)。当网络故障恢复后,该 Eureka Server节点会再自动退出自我保护模式。所以,自我保护模式是一种应对网络异常的安全保护措施,它的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留),也不盲目注销任何健康的微服务,使用自我保护模式,可以让Eureka集群更加的健壮、稳定当然也可以使用配置项: eureka.server.enable-self-preservation=fase禁用自我保护模式。

但是Eureka Server自我保护模式也会给我们带来一些困扰,如果在保护期内某个服务提供者刚好非正常下线了,此时服务消费者就会拿到一个无效的服务实例,此时会调用失败,对于这个问题需要服务消费者端具有一些容错机制,如重试,断路器等。

Eureka的自我保护模式是有意义的,该模式被激活后,它不会从注册列表中剔除因长时间没收到心跳导致注册过期的服务,而是等待修复,直到心跳恢复正常之后,它自动退出自我保护模式。这种模式旨在避免因网络分区故障导致服务不可用的问题。

例如,两个微服务客户端实例A和B之间有调用的关系,A是消费者,B是提供者,但是由于网络故障,B未能及时向Eureka发送心跳续约,这时候 Eureka不能简单的将B从注册表中剔除,因为如果剔除了,A就无法从Eureka服务器中获取B注册的服务,但是这时候B服务是可用的;所以, Eureka的自我保护模式最好还是开启它。

2-3、关闭自我保护的相关配置如下

• 服务端配置

eureka:
  server:
    enable-self-preservation: false
    #eureka server清理无效节点的时间间隔，默认60000毫秒，即60秒
    eviction-interval-timer-in-ms: 60000 # 单位毫秒

• 客户端配置

# 心跳检测检测与续约时间，测试时将值设置设置小些，保证服务关闭后注册中心能及时踢出服务
eureka:
  instance:
    # 每间隔1s，向服务端发送一次心跳，证明自己依然“存活”
    lease-renewal-interval-in-seconds: 1
    # 告诉服务端，如果我2s之内没有给你发心跳，就代表我“死”了，请将我踢掉
    lease-expiration-duration-in-seconds: 2

• 关闭自我保护模式Eureka服务端显示如下：

​

案例源码地址：https://gitee.com/coding-farmer/spirngcloud-learn

​

​