原文
译者： Jackson Lee

介绍

在2015-2016年，我们采用微服务的概念重新设计了一个独立应用，并选择Spring Cloud Netflix作为应用实现的基础。

Spring Cloud Netflix 通过自动配置、绑定Spring环境和其他Spring编程定式，来为Spring Boot应用程序提供Netflix OSS集成。

随着时间的迁移，我们进一步熟悉了框架，甚至提出了一些拉动进展的请求。我以为我知道得足够了。直到我开始研究Eureke的冗余和故障切换的那一刻起，我意识到一个概念上的快速印证是行不通的。随着我挖出更多的东西，我遇到了其他可怜鬼在互联网上所记录的类似信息。不幸的是，没有找到多少。据了解，Spring Cloud文档相当不错，还有一个Netflix Wiki，但没有一个涉及我所寻找的细节。这个帖子试图弥补这个空白。我假设你对Eureka和服务发现已经有一些基本的了解，所以如果你是个新手，那么请在阅读了Spring Cloud文档后再回来。

基础架构

Eureka有两类基础部件，服务和客户端。以下引自Netflix Wiki:

Eureka是一种基于REST（Representational State Transfer）的服务，主要用于AWS云，用于定位服务，以实现中间层服务器的负载平衡和故障转移。我们称这个服务，Eureka Server。Eureka还提供了一个基于Java的客户端组件Eureka Client，它使得与服务的交互变得更加容易。客户端还具有内置负载均衡器，可进行基本的轮询负载均衡。

Eureka客户端应用程序被称为实例。客户端应用程序和Eureka客户端之间存在细微差别; 前者是您的应用程序，而后者是由框架提供的组件。
Netflix设计的Eureka具有高度的动态性。有属性，有为属性定义的更新间隔，在第一次设置属性后会按照所设置间隔来查找配置的变更。这是一个常见的范例，意味着大多数这些属性可以在运行时更改，并在下一个刷新周期中被选中。例如，客户端用于向尤里卡注册的URL可以更改，并在5分钟后被配置（可配置eureka.client.eurekaServiceUrlPollIntervalSeconds）。大多数用户不需要这样的动态更新，但如果这样做，您可以找到所有配置选项，如下所示：

• 对于Eureka服务器配置：
  org.springframework.cloud.netflix.eureka.server.EurekaServerConfigBean实现com.netflix.eureka.EurekaServerConfig。所有属性均为前缀eureka.server。
• 对于Eureka客户端配置：
  org.springframework.cloud.netflix.eureka.EurekaClientConfigBean实现com.netflix.discovery.EurekaClientConfig。所有属性均为前缀eureka.client。
• 对于Eureka实例config：
  org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean实现（间接）com.netflix.appinfo.EurekaInstanceConfig。所有属性均为前缀eureka.instance。
  有关进一步的架构细节，请参阅Netflix Wiki。

Eureka实例和客户端

一个Eureka实例，通常由eureka.instance.instanceId进行区分，若不存在的情况下将使用eureka.instance.metadataMap.instanceId进行识别。实例间彼此使用eureka.instance.appName来进行查找，Spring Cloud默认使用spring.application.name,在前者参数未被定义的情况下使用UNKNOWN。需要设置spring.application.name，因为具有相同名称的应用程序将聚集在Eureka服务器中。没有必要去设置eureka.instance.instanceId，如果没有设置默认会被设置为CLIENT IP:PORT，但如果您设置它，则它必须在该范围内是唯一的appName。还有一个eureka.instance.virtualHostName，但它并没有被Spring使用，默认设置为spring.application.name或UNKNOWN如上所述。

如果registerWithEureka是true，一个实例使用给定的URL向Eureka服务器注册;然后，它每隔30s（可配置eureka.instance.leaseRenewalIntervalInSeconds）发送心跳。如果服务器没有收到心跳线，则eureka.instance.leaseExpirationDurationInSeconds在从实例注册表中删除实例之前等待90秒（可配置），并禁止该实例的流量。发送心跳是一个异步任务;如果操作失败，它将按指数次数退避2倍，直到eureka.instance.leaseRenewalIntervalInSeconds * eureka.client.heartbeatExecutorExponentialBackOffBound达到最大延迟。对Eureka注册的重试次数没有限制。

心跳与将实例信息更新到Eureka服务器不同。每个实例都由一个com.netflix.appinfo.InstanceInfo记录实例的信息。将InstanceInfo被定期发送到Eureka服务器，启动后40秒发送（通过配置eureka.client.initialInstanceInfoReplicationIntervalSeconds），然后开始每30秒发送（通过配置eureka.client.instanceInfoReplicationIntervalSeconds）。

如果eureka.client.fetchRegistry是true，客户端在启动时获取Eureka服务器注册表，并在本地缓存。从那时起，它只是获取增量（这可以通过设置来关闭eureka.client.shouldDisableDelta=false，尽管这会是浪费带宽）。注册表提取是每30秒调度一个异步任务（可配置eureka.client.registryFetchIntervalSeconds）。如果操作失败，它将按指数级数2倍，直到eureka.client.registryFetchIntervalSeconds * eureka.client.cacheRefreshExecutorExponentialBackOffBound达到最大延迟。获取注册表信息的重试次数没有限制。

客户端任务由com.netflix.discovery.DiscoveryClient调度，在Spring Cloud由org.springframework.cloud.netflix.eureka.CloudEurekaClient扩展实现。

为什么要花这么长时间注册一个与Eureka的实例？

大部分内容引自 https://github.com/spring-cloud/spring-cloud-netflix/issues/373[spring-cloud-netflix＃373]

1. 客户注册
   启动后第一次心跳发生在30s（先前已经描述），所以实例在此间隔之前不会出现在Eureka注册表中。
2. 服务器响应缓存
   服务器维护每30秒更新一次的响应缓存（可配置eureka.server.responseCacheUpdateIntervalMs）。所以即使实例刚刚被注册，它也不会出现在/eureka/apps的REST接口结果中。但是，实例可能会在注册后出现在Eureka面板上。这是因为面板绕过REST API使用的响应缓存。如果知道instanceId，仍然可以通过调用/eureka/apps//接口从Eureka获取一些细节。此端点不会使用响应缓存。
   因此，其他客户端可能需要30多秒才能发现新注册的实例。
3. 客户端缓存刷新
   Eureka客户端保留注册表信息的缓存。这个缓存每30秒刷新一次（如前所述）。因此，客户端决定刷新其本地缓存并发现其他新注册的实例可能需要30多秒。
4. LoadBalancer刷新
   Ribbon使用的负载均衡器从本地的Eureka客户端获取其信息。同时还维护一份本地缓存，以避免为每个请求调用客户端。该缓存每30秒刷新一次（可配置ribbon.ServerListRefreshInterval）。因此，可能需要30秒才能使用新注册的实例。

最后，在新注册的实例开始从其他实例开始接收流量之前可能需要2分钟。

Eureka服务器

Eureka服务器具有对等感知模式，在其中复制其他Eureka服务器上的服务注册表，以提供负载平衡和弹性。对等感知模式是默认的，所以Eureka服务器也充当Eureka客户端，并在给定的URL上注册到对等体。这是你应该在生产所采取的，但对于演示或概念验证，你可以通过设置registerWithEureka=false运行在独立模式下。

当eureka服务器启动时，它尝试从对等eureka节点获取所有注册表信息。对每个对等体（可配置eureka.server.numberRegistrySyncRetries）重试5次。如果由于某种原因导致此操作失败，服务器将不允许客户端获取注册表信息5分钟（可配置eureka.server.getWaitTimeInMsWhenSyncEmpty）。

Eureka对等体感知，通过引入所谓的“自我保护”的概念，达到了一个全新的更为复杂的水平带（可以通过设置来关闭eureka.server.enableSelfPreservation到false）。事实上，从网上的资料来看，这是我看到大多数人绊倒的地方。来自于Netflix Wiki的描述是这样的：

当Eureka服务器启动时，它尝试从相邻节点获取所有实例注册表信息。如果从节点获取信息时出现问题，服务器会在放弃之前尝试所有对等体。如果服务器能够成功获取所有实例，它将根据该信息设置应该接收的更新阈值。如果有任何时间，续订低于为该值配置的百分比，则服务器将停止到达实例以保护当前实例注册表信息。

场景是这样的：如果有两个客户注册到一个Eureka实例，每一个人每30秒发送一次心跳，实例应该在一分钟内收到4个心跳。Spring将Eureka最小值加1（可配置eureka.instance.registry.expectedNumberOfRenewsPerMin），因此实例预计每分钟会收到5个心跳。然后乘以0.85（可配置eureka.server.renewalPercentThreshold），并天花板到下一个整数，这使我们再次回到5。如果任何时候在10分钟内由Eureka收到的心跳小于5次eureka.server.renewalThresholdUpdateIntervalMs，则进入自我保存模式并停止已经注册的实例。

Eureka服务器作出了一个隐含的假设：客户端每隔30s以固定的速率发送心跳。如果注册了两个实例，则服务器(2 * 2 + 1 ) * 0.85 = 5每分钟都会收到心跳。如果更新率下降到该值以下，则自动保存模式被激活。现在，如果客户端发送的心跳速度要快得多（比如每10秒钟），服务器每分钟会收到12个心跳，即使其中一个实例出现故障，也能接收到6 / min。因此，自我保护模式即使应该被激活。这就是为什么不建议改变eureka.client.instanceInfoReplicationIntervalSeconds。如果你确实需要调整时，可以修改eureka.server.renewalPercentThreshold。

Eureka对等体并不计入预期的续订次数，但是他们的心跳在最近一次收到的续订次数中被考虑。在对等感知模式下，心跳可以去任何Eureka实例; 这一点对运行在负载平衡器或做为Kubernetes服务之后是重要的，其中心跳（通常）以轮询模式发送到每个实例。

Eureka服务器在续订上限超过门槛值时，才会退出自我保存模式。自我保护模式期间，可能会导致客户端获取不再存在的实例。请参阅 了解Eureka对等体通讯。

还有一件事：在同一个主机上运行多个Eureka服务器有一个问题。Netflix code（com.netflix.eureka.cluster.PeerEurekaNodes.isThisMyUrl）过滤出同一主机上的对等网址。（我猜）这可能是为了防止服务器注册为自己的对等体，但是由于他们不检查端口，因此除非Eureka主机名eureka.client.serviceUrl.defaultZone不同，否则对等意识不起作用。这种情况最有效的解决方法是为每一个服务定义唯一的主机名，然后将它们在/etc/hosts文件（或它的Windows等价物）映射到127.0.0.1。Spring Cloud doc介绍了这个解决方法，但没有提到为什么需要它。现在你知道了。

区域和可用区

Eureka旨在运行在AWS中，并使用了许多AWS特有的概念和术语。区域(Regions)和可用区(Zone)是两个这样的情况。来自AWS文档：

Amazon EC2托管在全球多个地点。这些位置由区域和可用区组成。每个区域都是一个独立的地理区域。每个区域都有多个隔离位置，称为可用区…每个区域都是完全独立的。每个区域是d地理分布上是相互隔离的，但区域中的可用区是通过低延迟链接连接的。

Eureka仪表板显示环境和数据中心。值被org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap，借助使用com.netflix.config.ConfigurationManager，设置为test与default分别。有各种查找和回退，所以如果由于某些原因需要更改它们，请参考上述类的源代码。

Eureka客户端默认偏好相同的可用区（可配置eureka.client.preferSameZone）。来自com.netflix.discovery.endpoint.EndpointUtils.getServiceUrlsFromDNSJavadoc：

eureka客户端从DNS获取所有eureka服务URL的列表，用于eureka客户端交互。客户端从其可用区中取出服务网址，遇到故障后随机地切换到其他可用区。如果同一可用区中有多个服务，则客户端将选择一个服务器进行尝试。在这种故障出现的情况下，请求流量将被分流。

spring-cloud-netflix＃203的这篇文章是开放的，有几个人谈论到了区域和可用区。我做任何的验证，所以我不能评论区域和可用区是如何与Eureka一起协同工作的。

High Availability (HA)

大部分复制自 spring-cloud-netflix＃203。

• HA策略似乎是server1做主Eureka服务，server2做从Eureka服务。
• 客户端通过配置（或DNS或/etc/hosts）提供Eureka服务器列表
• 客户端尝试连接server1; 此时，server2处于空闲状态。
• 如果server1不可用，客户端将从列表中尝试下一个。
• 当server1回到网路时，客户端回到使用server1的状态。

当然，server1、server2可以在对等感知模式下运行，并且它们的注册表被复制。但这与客户端注册是互不依赖的。