一、服务注册与发现：Spring Cloud 之 Eureka

痛定思痛。 2023-06-06 10:39 93阅读 0赞

## 1、是什么 ##

Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。而Spring Cloud集成了 Eureka，并提供了开箱即用的支持。Eureka采用了C/S的设计架构，它包含两个组件：Eureka Server和Eureka Client。

## 2、为什么 ##

1、Eureka可以动态加入和注销服务，不用手动去做； 2、Eureka实现子服务之间的注册与发现，不再像以前单体应用直接暴露API。

[![format_png][]][format_png 1]

Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址 提供者：启动后向Eureka注册自己信息（地址，提供什么服务） 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新 心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

## 3、基本原理 ##

[![原理图][format_png 2]][format_png 2 1]

上图是来自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秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

## 4、Eureka的自我保护机制 ##

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

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

`eureka.server.enable-self-preservation=true`

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

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

## 5、作为服务注册中心，Eureka比Zookeeper好在哪里？ ##

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

## 5.1 Zookeeper保证CP ##

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

## 5.2 Eureka保证AP ##

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

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

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

## 5.3 总结 ##

Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。

[format_png]: /images/20230601/cc23f0903eed4e2ea71c844a6d6cd621.png
[format_png 1]: http://58.62.207.50:13983/sznf/images/eureka.png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cDovLzU4LjYyLjIwNy41MDoxMzk4My9zem5mL2ltYWdlcy9ldXJla2EyLnBuZw?x-oss-process=image/format,png
[format_png 2 1]: http://58.62.207.50:13983/sznf/images/eureka2.png