eureka 问题记录

Eureka 注册服务慢的问题如何解决？

eureka.instance.leaseRenewalIntervalInSeconds
参考文档：
http://cloud.spring.io/spring-cloud-static/Camden.SR1/#_why_is_it_so_slow_to_register_a_service
原文：

Why is it so Slow to Register a Service?
Being an instance also involves a periodic heartbeat to the registry (via the client’s serviceUrl) with default duration 30 seconds. A service is not available for discovery by clients until the instance, the server and the client all have the same metadata in their local cache (so it could take 3 heartbeats). You can change the period using eureka.instance.leaseRenewalIntervalInSeconds and this will speed up the process of getting clients connected to other services. In production it’s probably better to stick with the default because there are some computations internally in the server that make assumptions about the lease renewal period.

翻译：

作为实例还涉及到与注册中心的周期性心跳，默认持续时间为 30 秒（通过 serviceUrl）。在实例、服务器、客户端都在本地缓存中具有相同的元数据之前，服务不可用于客户端发现（所以可能需要 3 次心跳）。你可以使用 eureka.instance.leaseRenewalIntervalInSeconds 配置，这将加快客户端连接到其他服务的过程。在生产中，最好坚持使用默认值，因为在服务器内部有一些计算，他们对续约做出假设。

如何解决 Eureka Server 不踢出已关停的节点的问题？

server 端:

eureka.server.enable-self-preservation （设为 false，关闭自我保护主要）
eureka.server.eviction-interval-timer-in-ms 清理间隔（单位毫秒，默认是 60*1000）

client 端：

eureka.client.healthcheck.enabled = true 开启健康检查（需要 spring-boot-starter-actuator 依赖）
eureka.instance.lease-renewal-interval-in-seconds =10 租期更新时间间隔（默认 30 秒）
eureka.instance.lease-expiration-duration-in-seconds =30 租期到期时间（默认 90 秒）

示例：
服务器端配置：

eureka:
server:
enableSelfPreservation: false
evictionIntervalTimerInMs: 4000

客户端配置：

eureka:
instance:
leaseRenewalIntervalInSeconds: 10
leaseExpirationDurationInSeconds: 30

注意：
更改 Eureka 更新频率将打破服务器的自我保护功能
Issue #373 · spring-cloud/spring-cloud-netflix

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

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

4.1 Zookeeper 保证 CP

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

4.2 Eureka 保证 AP

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

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