Eureka 目前 1.x 版本还在更新，但是应该不会更新新的功能了，只是对现有功能进行维护，升级并兼容所需的依赖。 Eureka 2.x 已经胎死腹中了。但是，这也不代表 Eureka 就是不能用了。如果你需要一个简便易于部署的注册中心，Eureka 还是一个很好的选择。云服务环境中，基本上所有实例地址和微服务名称都在不断变化，也并不太需要 Eureka 所缺少的持久化特性。当你的集群属于中小规模的时候（节点小于 1000 个）， Eureka 依然是一个不错的选择。当你的集群很大的时候，Eureka 的同步机制可能就限制了他的表现。
Eureka 的设计比较小巧，没有复杂的同步机制(例如 Nacos 基于 Raft，Zookeeper 基于 Zab)，也没有复杂的持久化机制，集群关系只是简单的将收到的客户端请求转发到集群内的其他 Eureka 实例。Eureka 本身也只有注册中心的功能，不像其他种类的注册中心那样，将注册中心和配置中心合在一起，例如 Consul 和 nacos。
这里我们忽略所有的 AWS 相关的术语以及配置还有相关逻辑处理。
Eureka 中的术语：
- Eureka 实例：每个注册到 Eureka 上面的实例就是 Eureka 实例。
- Eureka 实例状态：包括 UP（可以处理请求），DOWN（健康检查失败，不能正常处理请求），STARTING（启动中，不能处理请求），OUT_OF_SERVICE（人为下线，暂时不处理请求），UNKNOWN（未知状态）。
- Eureka 服务器：作为注册中心运行，主要提供实例管理功能（处理实例注册（register）请求、处理实例注销（cancel）请求、处理实例心跳（renew）请求、内部处理实例过期（evict））、实例查询功能（各种查询实例信息的接口，例如通过 AppName 获取实例列表，通过实例 id 获取实例信息等等）
- Eureka 服务器集群：Eureka 服务器的集群，每个 Eureka 服务器都配置了区域以及可用区，Eureka 服务器收到的客户端请求会转发到同一区域内的其他 Eureka 服务器，可以配置优先发到同一可用区的 Eureka 服务器。非同一区域内 Eureka 服务器，通过定时拉取的方式进行同步。
- Eureka 客户端：请求 Eureka 服务器的客户端。封装发送实例注册（register）请求、实例注销（cancel）请求和实例心跳（renew）请求。
- VIP（或者是 Virtual Hostname）: Eureka 中可以通过两种方式获取实例，一个是通过服务名称，另一种是通过 VIP。每个实例都有服务名称，以及 VIP。Eureka 服务器中的索引方式是以服务名称为 key 的索引，我们也可以通过遍历所有实例信息的方式通过 VIP 字符串匹配获取相关的实例。在 Spring Cloud 体系中，一个实例的 VIP、SVIP（其实就是 Secure VIP，即 https 的地址）以及服务名称都是
spring.application.name指定的服务名称。
首先，Service A 通过 Eureka Client 发送注册请求（Register）到同一可用区的 Eureka Server 1。之后通过发送心跳请求（Renew）到这个 Eureka Server 1. Eureka Server 1 收到这些请求的时候，会处理这些请求并将这些请求转发到其他的集群内的 Eureka Server 2 和 Eureka Server 3. Eureka Server 2 和 Eureka Server 3 不会再转发收到的 Eureka Server 1 转发过来的请求。然后，Service B 还有 Service C 通过 Eureka 获取到了 Service A 的位置，最后调用了 Service A。
对于本地没有查询到的微服务，Eureka Server 还会从远程 Region 的 Eureka Server 去获取，例如这里对于 Service D，本地没有查到，Eureka Server 会返回远程 Region 的 Service D 的实例。由于本地有 Service A，所以肯定不会返回远程 Region 的 Service A 的实例。并且，本地是定时拉取的远程 Region 的 Service 列表，并不是每次查询的时候现查询的。
一般的，微服务之间的互相调用，并不经过 Eureka，也不会涉及到 Eureka 客户端了，而是通过负载均衡器调用，这个我们后面就会提到。
我们这一节详细分析了 Eureka 的架构，以及其中的核心概念。下一节，我们将开始介绍我们微服务的注册中心 Eureka 的实例配置。
