在分析Eureka的原理之前，先来了解一下Region和Availability Zone，如图4-2所示。

Region和Availability Zone均是AWS的概念。其中，Region表示AWS中的地理位置，每个Region都有多个Availability Zone，各个Region之间完全隔离。AWS通过这种方式实现了最大的容错和稳定性。

SpringCloud默认使用的Region是us-east-1，在非AWS环境下，可以将Availability Zone理解成机房，将Region理解为跨机房的Eureka集群。

对Region和Availability Zone感兴趣的读者可前往 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html 进行扩展阅读。

理解Region和Availability Zone后，来分析一下Eureka的原理，Eureka架构如图4-3所示。

图4-3来自Eureka官方的架构图，该图比较详细地描述了Eureka集群的工作原理。图中的组件非常多，概念也比较抽象，笔者先来用通俗易懂的文字翻译一下：

●Application Service相当于本书中的服务提供者。

●Application Client相当于本书中的服务消费者。

●MakeRemoteCall可以理解成调用RESTfulAPI的行为。

●us-east-1c、us-east-1d等都是zone，它们都属于us-east-1这个region。

由图4-3可知，Eureka包含两个组件：Eureka Server和EurekaClient，它们的作用如下：

●Eureka Server提供服务发现的能力，各个微服务启动时，会向Eureka Server注册自己的信息（例如IP、端口、微服务名称等），Eureka Server会存储这些信息。

●EurekaClient是一个Java客户端，用于简化与Eureka Server的交互。

●微服务启动后，会周期性（默认30s）地向Eureka Server发送心跳以续约自己的“租期”。

●如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将注销该实例（默认90s）。

●默认情况下，Eureka Server同时也是EurekaClient。多个Eureka Server实例互相之间通过复制的方式来实现服务注册表中数据的同步。

●EurekaClient会缓存服务注册表中的信息。这种方式有一定的优势——首先，微服务无须每次请求都查询Eureka Server，从而降低了Eureka Server的压力；其次，即使Eureka Server所有节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者并完成调用。

综上，Eureka通过心跳检查、客户端缓存等机制，提高了系统的灵活性、可伸缩性和可用性。 DijLcVfCSlIkAkWeoagdpswhf6rWTuXAeu5uJyRhLlb0ZnbLslxhFvA929foXZ2Q