Eureka服务注册原理及高可用集群配置

基本原理

上图是来自eureka的官方架构图，这是基于集群配置的eureka；
- 处于不同节点的eureka通过Replicate进行数据同步
- Application Service为服务提供者
- Application Client为服务消费者
- Make Remote Call完成一次服务调用

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

Eureka的自我保护机制

在默认配置中，Eureka Server在默认90s没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，但是因为网络分区故障时，Eureka Server注销服务实例则会让大部分微服务不可用，这很危险，因为服务明明没有问题。

为了解决这个问题，Eureka 有自我保护机制，通过在Eureka Server配置如下参数，可启动保护机制

#默认为true ，当客户端上线率过低时，eureka发出警告，但是状态还是显示为up，有可能实际上已经下线了，所以在开发的时候设置为false
eureka.server.enable-self-preservation=true

它的原理是，当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。

自我保护模式的架构哲学是宁可放过一个，决不可错杀一千

Eureka Server高可用集群

理论上来讲，因为服务消费者本地缓存了服务提供者的地址，即使Eureka Server宕机，也不会影响服务之间的调用，但是一旦新服务上线，已经在缓存在本地的服务提供者不可用了，服务消费者也无法知道，所以保证Eureka Server的高可用还是很有必要的。

在分布式系统中，任何的地方存在单点，整个体系就不是高可用的，Eureka 也一样，在上面的架构图中Eureka Server不是以单点存在的，而是以集群的方式对外提供服务。

这节我们说说如何将Eureka Server进行集群配置（在本地搭建一个伪集群）。

配置系统的hosts（C:\Windows\System32\drivers\etc\hosts文件）

代码配置

application.properties

# 每次启动一个备用注册中心只需要修改active即可
spring.profiles.active=discovery1

# 不向注册中心注册自己
eureka.client.register-with-eureka=true
# 不检索服务，是否从eureka上获取注册信息
eureka.client.fetch-registry=true

application-discovery1.properties

spring.application.name=eureka-server
server.port=1111
eureka.instance.hostname=discovery1

eureka.client.serviceUrl.defaultZone=http://discovery2:1112/eureka/,http://discovery3:1113/eureka/

application-discovery2.properties

spring.application.name=eureka-server
server.port=1112
eureka.instance.hostname=discovery2

eureka.client.serviceUrl.defaultZone=http://discovery1:1111/eureka/,http://discovery3:1113/eureka/

application-discovery3.properties

spring.application.name=eureka-server
server.port=1113
eureka.instance.hostname=discovery3

eureka.client.serviceUrl.defaultZone=http://discovery1:1111/eureka/,http://discovery2:1112/eureka/

深入理解

虽然上面我们以双节点作为例子，但是实际上因负载等原因，我们往往可能需要在生产环境构建多于两个的Eureka Server节点。那么对于如何配置serviceUrl来让集群中的服务进行同步，需要我们更深入的理解节点间的同步机制来做出决策。

Eureka Server的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就可以进行信息传播与同步。什么意思呢？不妨我们通过下面的实验来看看会发生什么。

场景一：假设我们有3个注册中心，我们将peer1、peer2、peer3各自都将serviceUrl指向另外两个节点。换言之，peer1、peer2、peer3是两两互相注册的。启动三个服务注册中心，并将compute-service的serviceUrl指向peer1并启动，可以获得如下图所示的集群效果。

访问http://localhost:1112/，可以看到3个注册中心组成了集群，compute-service服务通过peer1同步给了与之互相注册的peer2和peer3。

通过上面的实验，我们可以得出下面的结论来指导我们搭建服务注册中心的高可用集群：

两两注册的方式可以实现集群中节点完全对等的效果，实现最高可用性集群，任何一台注册中心故障都不会影响服务的注册与发现

Client配置

eureka:
  client:
    service-url:
     defaultZone: http://discovery1:8761/eureka,http://discovery2:8762/eureka/,http://discovery3:8763/eureka
#  instance:
#    hostname: clientName  修改client端的host     localhost  ----》 clientName
spring:
  application:
    name: myClient

启动方式一，打成jar包，分别启动1个eureka - client 和 3个 eureka - server‘

java -jar eureka-server-1.0.0.jar --spring.profiles.active=discovery1
java -jar eureka-server-1.0.0.jar --spring.profiles.active=discovery2
java -jar eureka-server-1.0.0.jar --spring.profiles.active=discovery3

启动方式二，IDEA设置多实例启动

这里写图片描述

去掉Single instance only选项即可

修改spring.profiles.active=discovery1，启动系统
修改spring.profiles.active=discovery2，启动系统
修改spring.profiles.active=discovery3，启动系统

启动discovery1和discovery2的时候都会报错，不用管，启动discovery3的时候就不会报错了

这里写图片描述

验证

分别访问：
http://localhost:1111/
http://localhost:1112/
http://localhost:1113/

可以看到都含有三个节点，说明集群成功

Instances currently registered with Eureka

Application AMIs    Availability Zones  Status
EUREKA-SERVER   n/a (3) (3) UP (3) - windows10.microdone.cn:eureka-server:1113 , windows10.microdone.cn:eureka-server:1112 , windows10.microdone.cn:eureka-server:1111

只要个中，存在一个，就可以继续使用系统

此帖子参考http://blog.didispace.com/springcloud6/，http://www.leftso.com/blog/111.html

Spring-cloud 学习笔记（一） Eureka服务注册原理及高可用集群配置