实战：Eureka的概念作用以及用法详解

概叙

什么是Eureka？

Netflix Eureka 是一款由 Netflix 开源的基于 REST 服务的注册中心，用于提供服务发现功能。Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件的一部分，基于 Netflix Eureka 进行了二次封装，主要负责完成微服务架构中的服务治理功能。

Spring Cloud Eureka 是一个基于 REST 的服务，并提供了基于 Java 的客户端组件，能够非常方便的将服务注册到 Spring Cloud Eureka 中进行统一管理。

Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件的一部分，基于 Netflix Eureka 做了二次封装，主要负责实现微服务架构中的服务治理功能。

服务治理是微服务架构中必不可少的一部分，阿里开源的 Dubbo 框架就是针对服务治理的。服务治理必须要有一个注册中心，除了用 Eureka 作为注册中心外，我们还可以使用 Consul、Etcd、Zookeeper 等来作为服务的注册中心。

Eureka 由两部分组成：服务端和客户端，服务端就是注册中心，用来接收其它的服务注册，客户端是一个java客户端，用来注册，并可以实现负载均衡等功能。

为什么 Eureka 比 Zookeeper 更适合作为注册中心呢？

主要是因为 Eureka 是基于 AP 原则构建的，而 ZooKeeper 是基于 CP 原则构建的。在分布式系统领域有个著名的 CAP 定理，即 C 为数据一致性；A 为服务可用性；P 为服务对网络分区故障的容错性。这三个特性在任何分布式系统中都不能同时满足，最多同时满足两个。Zookeeper 有一个 Leader，而且在这个 Leader 无法使用的时候通过 Paxos（ZAB）算法选举出一个新的 Leader。这个 Leader 的任务就是保证写数据的时候只向这个 Leader 写入，Leader 会同步信息到其他节点。通过这个操作就可以保证数据的一致性。

想要保证 AP 就要用 Eureka，想要保证 CP 就要用 Zookeeper。

Eureka体系结构

服务注册

注册中心

拆开来看注册和中心。注册比如用户注册，就是将自己的信息注册在某个平台上。中心可以理解成一个统一管理信息的平台。所以注册中心顾名思义是统一管理所有注册信息的平台。

服务注册

指的是服务在启动时将自身的信息注册到注册中心中，方便信息进行统一管理。服务注册是客户端向注册中心提交信息的动作。

想要参与服务注册发现的实例首先需要向Eureka服务器注册信息注册在第一次心跳发生时提交

Renew:续租，心跳。Eureka客户需要每30秒发送一次心跳来续租
Fetch Registry：Eureka客户端拉取注册表信息，并缓存在本地。可以30秒更新一次。
Cancel：Eureka客户端在关闭时向Eureka服务器发送取消请求。这将从服务器的实例注册表中删除实例，从而有效地将实例从通信量中取出。

服务注册--客户端配置选项

#续约发送间隔默认30秒，心跳间隔

eureka.instance.lease-renewal-interval-in-seconds=5

#表示eureka client间隔多久去拉取服务注册信息，默认为30秒，对于api-gateway，如果要迅速获取服务注册状态，可以缩小该值，比如5秒

eureka.client.registry-fetch-interval-seconds=5

# 续约到期时间（默认90秒）

eureka.instance.lease-expiration-duration-in-seconds=60

服务注册--服务器端配置选项

#关闭自我保护模式

eureka.server.enable-self-preservation=false

#失效服务间隔

eureka.server.eviction-interval-timer-in-ms=3000

服务发现

服务发现

指的是从注册中心获取对应服务的信息,是客户端向注册中心拉取pull信息的动作。

Eureka原理

概念：实现服务治理，即管理所有的服务信息和状态。 eureka分为两部分，Server端和Client端 Client端向Server端定时发送心跳包。 Server端根据Clinet端的心跳包，来维护一个服务列表（判断服务是否在线）。

client功能
1. 注册：每个微服务启动时，将自己的网络地址等信息注册到注册中心，注册中心会存储（内存中）这些信息。
2. 获取服务注册表：服务消费者从注册中心，查询服务提供者的网络地址，并使用该地址调用服务提供者，为了避免每次都查注册表信息，所以client会定时去server拉取注册表信息到缓存到client本地。
3. 心跳：各个微服务与注册中心通过某种机制（心跳）通信，若注册中心长时间和服务间没有通信，就会注销该实例。
4. 调用：实际的服务调用，通过注册表，解析服务名和具体地址的对应关系，找到具体服务的地址，进行实际调用。
server注册中心功能
1. 服务注册表：记录各个微服务信息，例如服务名称，ip，端口等。注册表提供查询API（查询可用的微服务实例）和管理API（用于服务的注册和注销）。
2. 服务注册与发现：注册：将微服务信息注册到注册中心。发现：查询可用微服务列表及其网络地址。
3. 服务检查：定时检测已注册的服务，如发现某实例长时间无法访问，就从注册表中移除。

自我保护机制

默认情况下，Eureka Server在一定时间内（90s），没有接收到某个微服务心跳，就会将该服务注销。但是当网络出现问题、故障，微服务之间无法通信，就不应该直接注销了。所以Eureka Server的自我保护机制，是在短时间内出现大量客户端丢失，就不会从注册表中注销。
思想：宁可保留健康的和不健康的，也不盲目注销任何健康的服务。
关闭自我保护

eureka:

server:

enable-self-preservation: false

Eureka 健康检查

server和client通过心跳保持服务列表，而只有状态为UP的服务才能被访问。看eureka界面中的status。比如心跳一直正常，服务一直UP，但是此服务DB连不上了，无法正常提供服务(有的时候业务出现问题catch住异常，也可以手动传输DOWN让服务下线)。此时，我们需要将微服务的健康状态也同步到server。只需要启动eureka的健康检查就行。这样微服务就会将自己的健康状态同步到eureka。配置如下即可。 开启手动控制 在client端配置：将自己真正的健康状态传播到server。

eureka:

client:

healthcheck:

enabled: true

Client端配置Actuator

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

改变健康状态的Service

@Service

public class HealthStatusService implements HealthIndicator{

private Boolean status = true;

public void setStatus(Boolean status) {

this.status = status;

}

@Override

public Health health() {

// TODO Auto-generated method stub

if(status)

return new Health.Builder().up().build();

return new Health.Builder().down().build();

}

public String getStatus() {

// TODO Auto-generated method stub

return this.status.toString();

}

Eureka监听事件

EurekaInstanceCanceledEvent 服务下线事件
EurekaInstanceRegisteredEvent 服务注册事件
EurekaInstanceRenewedEvent 服务续约事件
EurekaRegistryAvailableEvent 注册中心可用事件
EurekaServerStartedEvent 注册中心启动

import org.springframework.cloud.netflix.eureka.server.event.EurekaInstanceCanceledEvent;

import org.springframework.context.event.EventListener;

import org.springframework.stereotype.Component;

@Component

public class CustomEvent {

@EventListener

public void listen(EurekaInstanceCanceledEvent e) {

System.out.println(e.getServerId()+"下线事件");

}

将Eureka Client停止后打印：

api-listen-order:30.136.133.9:port下线事件

Eureka缺陷

集群之间的同步复制是通过HTTP的方式进行，基于网络的不可靠性，集群中的Eureka Server间的注册表信息难免存在不同步的时间节点，不满足CAP中的C(数据一致性)。

Eureka核心概念服务注册和服务发现

Eureka有三个角色：

Eureka Server：注册中心
Eureka Provider：服务提供者
Eureka Consumer：服务消费者

2.1 Eureka Server

Eureka Server主要对外提供了三个功能：

服务注册，所有的服务都注册到Eureka Server上面来
提供注册表，注册表就是所有注册上来服务的一个列表，Eureka Client在调用服务时，需要获取这个注册表，一般来说，这个注册表会缓存下来，如果缓存失效，则直接获取最新的注册表
同步状态，Eureka Client 通过注册、心跳等机制，和Eureka Server同步当前客户端的状态

2.2 Eureka Client

Eureka Client 主要是来简化每一个服务和Eureka Server 之间的交互。Eureka Client 会自动拉取、更新以及缓存Eureka Server 中的信息，这样，即便Eureka Server 所有节点都宕机，Eureka Client 依然能够获取到想要调服务的地址（但是地址可能不准确）。

2.2.1 服务注册

服务提供者将自己注册到服务注册中心(Eureka Server)，需要注意，所渭的服务提供者，只是一个业务上的划分，本质上他就是一个 Eureka Client 。当 Eureka Client 向 Eureka Server 注册时，他需要提供自身的一些元数据信息，例如IP地址、端囗、名称、运行状态等等。

2.2.2 服务续约

Eureka Client 注册到 Eureka Server 上之后，事情还没有结束，刚刚开始而已。注册成功后，默认情况下，Eureka Client 每隔30秒就要向 Eureka Server 发送一条心跳消息，来告诉Eureka Server 我还在运行。如果 Eureka Server 连续90秒有沿有收到Eureka Client 的续约消息（连续三次没发送），它会认为Eureka Client已经线了，会将掉线的Eureka Client从当前的服务注册列表中剔除。

服务续约，有两个相关的属性（一般不建议修改）：

# 表示服务的续约时间，默认是30秒

eureka.instance.lease-renewal-intetval-in-seconds=30

# 服务失效时间，默认是90秒

eureka.instance.lease-expiration-duration-in-seconds=90

2.2.3 服务下线

当 Eureka Client 下线时，它会主动发送一条消息，告诉Eureka Server，我下线了。

2.2.4 获取注册表信息

Eureka Client 从Eureka Server 上获取服务的注册信息，将其缓存在本地。本地客户端在需要调用远程服务时，会从该信息中查找远程服务所对应的IP地址、端囗等信息。Eureka Client 上缓存的服务注册信息会定期更新（30秒)，如果 Eureka Server 返回的注册表信息与本地缓存的注册表信息不同的话，Eureka Client 会自动处理。

这里，也涉及至两个属性，一个是是否允许获取注册表信息：

1	`eureka.client.fetch-registry=true`

Eureka Client 上缓存的服务注册信息，定期更新的时间间隔，默认30秒：

1	`eureka.client.registry-fetch-interval-seconds=30`

Eureka实战

Eureka 的架构主要分为 Eureka Server 和 Eureka Client 两部分，Eureka Client 又分为 Applicaton Service 和 Application Client，Applicaton Service 就是服务提供者，Application Client 就是服务消费者。
Eureka Client 会向 Eureka Server 发送请求，进行注册，并将自己的一些信息发送给 Eureka Server。
注册成功后，每隔一定的时间，Eureka Client 会向 Eureka Server 发送心跳来续约服务，也就是汇报健康状态。如果客户端长时间没有续约，那么 Eureka Server 将在 90 秒（默认）内从服务器注册表中删除客户端的信息。
Eureka Client 还会定期从 Eureka Server 拉取注册表信息，然后通过Ribbon 组件根据负载均衡算法得到一个目标，并发起远程调用。
应用正常停止时也会通知 Eureka Server 移除相关信息，信息成功移除后，其他客户端会更新服务的信息，这样就不会调用已经下线的服务了，当然这个会有延迟，有可能会调用到已经失效的服务，所以在客户端会开启失败重试功能来避免这个问题。
Eureka Server 会有多个节点组成一个集群，保证高可用。Eureka Server 没有集成其他第三方存储，而是存储在内存中，内部维护一个注册表的概念。
所以 Eureka Server 之间会将注册信息复制到集群中的 Eureka Server 的所有节点。这样数据才是共享状态，任何的 Eureka Client 都可以在任何一个 Eureka Server 节点查找注册表信息。

Eureka服务端单节点构建

打开start.spring.io/ 或者阿里云的快速start start.aliyun.com/bootstrap.h… ，开始构建对应的服务端项目。推荐使用阿里云的快速start，因为访问速度更快些。

自动生成完成后，在resource目录下，新建application.yml文件替换原来的application.properties。内容如下：

#应用名称

spring:

application:

name: eureka-server

server:

port: 8001

eureka:

client:

# 是否将自己实例注册到Eureka Server中

register-with-eureka: false

# 是否应从Eureka Server获取Eureka注册表信息

fetch-registry: false

在SpringBoot的启动类上添加@EnableEurekaServer 注解，表示是Eureka 服务端。

项目创建成功后，在项目启动类上添加注解，标记该项目是一个Eureka Server：

@SpringBootApplication

@EnableEurekaServer //开启Eureka

public class EurekaApplication {

public static void main(String[] args) {

SpringApplication.run(EurekaApplication.class, args);

}

然后启动项目，项目启动成功后在浏览器访问：http://localhost:8001 就可以看到Eureka的管理页面了。

目前还没有任何一个服务注册到 Eureka 中，不过从上图中，我们还是可以看到关于 Eureka 服务器内存、CPU 、IP等的相关信息。

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE。

图中红色警告翻译为：紧急!Eureka已经不能确认这些已经启动的实例是否可用，由于最近的续订次数小于续订阈值（续订期望值），为了安全起见（实例可用），当前这些实例不会删除。这是因为Eureka进入自我保护模式（SELF PRESERVATION MODE）。

Eureka服务端集群构建

高可用：可以通过运行多个Eureka server实例并相互注册的方式实现。Server节点之间会彼此增量地同步信息，从而确保节点中数据一致。

写一个地址也行（但是server得互相注册），EurekaServer会自动同步，但为了避免极端情况，还是写多个。集群中各个server会从其他server同步注册表信息。

#client配置

eureka:

client:

#设置服务注册中心的URL

service-url:

defaultZone: http://root:root@eureka-7801:7801/eureka/,http://root:root@eureka-7802:7802/eureka/

单个 Eureka 服务可能存在的单点失效问题，我们通常都需要构建一个 Eureka 服务器集群来确保注册中心本身的可用性。与传统的集群构建方式不同，如果我们把 Eureka 也视为一个服务，也就是说 Eureka服务自身也能注册到其他 Eureka 服务上，从而实现相互注册，并构成一个集群。同样可以通过单节点构建步骤构建两个Eureka Server服务A和B。对应的yml配置如下：

server:

port: 8761

eureka:

instance:

hostname: eurekaA

client:

serviceUrl:

defaultZone: http:// eurekaB:8762/eureka/

server:

port: 8762

eureka:

instance:

hostname: eurekaB

client:

serviceUrl:

defaultZone: http://eurekaA:8761/eureka/

**eureka.instance.hostname **是Eureka 实例管理类配置项，用于指定当前 Eureka 服务的主机名称。需要在本机的hosts文件中添加以下信息：

127.0.0.1 eurekaA
127.0.0.1 eurekaB

我们可以看到服务端A和B只调整了端口和地址的引用。构建 Eureka 集群模式的关键点在于使用客户端配置项 eureka.client.serviceUrl.defaultZone 用于指向集群中的其他 Eureka 服务器。
所以 Eureka 集群的构建方式实际上就是将自己作为服务并向其他注册中心注册自己，这样就形成了一组互相注册的服务注册中心以实现服务列表的同步。
这个场景下 register-with-eureka（是否将自己实例注册到Eureka Server中）和 fetch-registry（是否应从Eureka Server获取Eureka注册表信息）配置项应该都使用其默认的 true 值，我们不需要对其进行显式的设置。
如果你尝试使用本机搭建集群环境，显然 eureka.instance.hostname 配置项中的 eureka1 和 eureka2 是无法访问的，所以需要在本机hosts 文件中添加以下信息。
现在启动这两个 Eureka 服务，然后分别打开 http://127.0.0.1:8761/ 和 http://127.0.0.1:8762/ 端点可以看到各自的服务注册效果。

Eureka客户端构建

客户端引入的pom坐标有差异，需要引入客户端坐标：

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>

</dependency>

在启动类上需要加@EnableDiscoveryClient注解表示是Eureka客户端。

@EnableDiscoveryClient

@SpringBootApplication

public class EurekaClientProviderApplication {

public static void main(String[] args) {

SpringApplication.run(EurekaClientProviderApplication.class, args);

}

yml配置如下：

spring:

application:

name: eureka-client

server:

port: 8081

eureka:

client:

serviceUrl:

#指定eureka服务端地址，如果是集群则通过逗号分隔

defaultZone: http://localhost:8761/eureka/

配置完成后可以在eureka控制台查看到相关注册信息。

启动命令

java -jar eureka-0.0.1-SNAPSHOT.jar --spring.profiles.active=a
java -jar eureka-0.0.1-SNAPSHOT.jar --spring.profiles.active=b

注意：启动第一个a之后你会发现控制台报错，是因为它一直发送心跳，而同时b还没有上线，等b也启动后错误即可消失。如果还报错，那就是代码的问题了。

启动成功后，就可以看到两个服务之间互相注册，共同组成一个集群。

Eureka分区策略

第一步：背景和概念介绍

背景：用户量比较大或者用户地理位置分布范围很广的项目，一般都会有多个机房。这个时候如果上线springCloud服务的话，我们希望一个机房内的服务优先调用同一个机房内的服务，当同一个机房的服务不可用的时候，再去调用其它机房的服务，以达到减少延时的作用。

概念：region：能够简单理解为地理上的分区。好比亚洲地区，或者华北地区，再或者北京地区等等，没有具体大小的限制，根据项目具体的状况，能够自行划分region。 zone：能够简单理解为 region 内的具体机房，好比说 region 划分为华北地区，而后华北地区有两个机房，就能够在此 region 之下划分出 zone1、zone2 两个 zone eureka 也借用了 region 和 zone 的概念架构

如图所示，有一个 region:华北地区，下面有两个机房，机房A 和机房Burl

每一个机房内有一个 Eureka Server 集群和两个服务提供者 ServiceA 和 ServerB
如今假设 serverA 须要调用 ServerB 服务，按照就近原则，serverA 会优先调用同一个 zone 内的 ServiceB，当 ServiceB 不可用时，才会去调用另外一个 zone 内的 ServiceBcode

第二步：相关参数介绍

服务注册相关:

eureka: client: # 尽可能向同一区域的 eureka 注册,默认为true prefer-same-zone-eureka: true #地区 region: huabei availability-zones: huabei: zone-1,zone-2 service-url: zone-1: http://Eureka的Ip地址:8761/eureka/ zone-2: http://Eureka的Ip地址:8761/eureka/

当存在多个注册中心时，选择逻辑为cdn

若是 prefer-same-zone-eureka 为 false，按照 service-url 下的 list 取第一个注册中心来注册，并和其维持心跳检测，再也不向list内的其它的注册中心注册和维持心跳。server只有在第一个注册失败的状况下，才会依次向其它的注册中心注册，总共重试3次，若是3个service-url都没有注册成功，则注册失败。blog

注册失败后每隔一个心跳时间，会再次尝试。it

若是 prefer-same-zone-eureka 为true，先经过 region 取 availability-zones 内的第一个zone，而后经过这个zone取 service-url 下的list，并向list内的第一个注册中心进行注册和维持心跳，再也不向list内的其它的注册中心注册和维持心跳。只有在第一个注册失败的状况下，才会依次向其它的注册中心注册，总共重试3次，若是3个service-url都没有注册成功，则注册失败。注册失败后每隔一个心跳时间，会再次尝试。

为了保证服务注册到同一个 zone 的注册中心，必定要注意 availability-zones 的顺序，必须把同一 zone 写在最前面

eureka: instance: # 服务和注册中心的心跳间隔时间，默认为30s lease-renewal-interval-in-seconds: 30 # 服务和注册中心的心跳超时时间，默认为90s lease-expiration-duration-in-seconds: 90 metadata-map: # 当前服务所属的 zone zone: zone1

服务消费者和服务提供者分别属于哪一个zone，均是经过 eureka.instance.metadata-map.zone 来断定的。
服务消费者会先经过 ribbon 去注册中心拉取一份服务提供者的列表，而后经过 eureka.instance.metadata-map.zone 指定的 zone 进行过滤，过滤以后若是同一个 zone 内的服务提供者有多个实例，则会轮流调用。
只有在同一个 zone 内的全部服务提供者都不可用时，才会调用其它zone内的服务提供者。