服务发现是微服务架构中的一个重要概念。试想当系统服务之间的依赖越来越多，A服务可能需要调用B、C、D等服务，同时被调用方也就是服务提供方可能为了保证自身高可用，还需要同时以集群的模式部署B1、B2、C1、C2等，想象一下A的配置文件该有多复杂。将服务提供方的地址写死在配置文件中，那么服务提供方如果横向扩展增加实例，是不是还需要修改作为服务调用方的A的配置文件？这时我们就迫切需要一种服务发现的机制。所有的服务提供方启动时向注册中心报告自身的信息，包括自己的地址、端口，以及提供哪些服务等相关信息。当服务调用方需要调用服务时，只需要问注册中心是谁提供了相关的服务，注册中心返回哪些提供方提供了这些服务，调用方就可以自己根据注册中心返回的信息去请求了。Eureka就提供了这样一种能力，同时自身作为注册中心的同时也提供了高可用的支持，支持集群部署时各个节点之间的注册数据同步复制。

Eureka是Netflix开源的一款提供服务注册和发现的产品，提供了完整的服务注册和服务发现实现，也是Spring Cloud体系中最重要、最核心的组件之一。

通俗讲，Eureka就是一个服务中心，将所有可以提供的服务都注册到它这里来管理，其他各调用者需要的时候去注册中心获取，然后服务调用方再向服务提供方发起调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。

所以，服务中心这么重要的组件一旦宕机将会影响全部服务，因此需要搭建Eureka集群来保持高可用性，建议生产中最少配备两台。随着系统流量的不断增加，需要根据情况来扩展某个服务，Eureka内部提供均衡负载的功能，只需要增加相应的服务端实例即可。那么在系统的运行期间某个实例宕机怎么办？Eureka提供心跳检测机制，如果某个实例在规定的时间内没有进行通信则会被自动剔除掉，避免了某个实例挂掉而影响服务。

因此，使用Eureka就自动具有了注册中心、负载均衡、故障转移的功能。

它主要包括两个组件。

· Eureka Client ：一个Java客户端，用于简化与Eureka Server的交互（通常就是微服务中的客户端和服务端）。

· Eureka Server ：提供服务注册和发现的能力（通常就是微服务中的注册中心）。

各个微服务启动时，会通过Eureka Client向Eureka Server注册自己，Eureka Server会存储该服务的信息，如图2-1所示。

也就是说，每个微服务的客户端和服务端都会注册到Eureka Server，这就衍生出了微服务相互识别的话题。

· 同步 ：每个Eureka Server同时是Eureka Client（逻辑上的），多个Eureka Server之间通过复制的方式完成服务注册表的同步，从而实现Eureka的高可用。

· 识别 ：Eureka Client会在本地缓存Eureka Server中的信息。

即使所有Eureka Server节点都宕掉，服务消费方仍可使用本地缓存中的信息找到服务提供方。

· 续约 ：微服务会周期性（默认30s）地向Eureka Server发送心跳以续约（Renew）自己的信息（类似于heartbeat机制）。

· 续期 ：Eureka Server会定期（默认60s）执行一次失效服务检测功能，它会检查超过一定时间（默认90s）没有续约的微服务，发现则会注销该微服务节点。

当一个注册器客户端通过Eureka进行注册时，它会带上一些描述自己情况的元数据，如地址、端口、健康指示器地址、主页等。Eureka会接收每一个服务实例发送的心跳包。如果心跳包超过配置的间隔时间，则这个服务实例就会被移除。 tR3PsiWwYa11m1E4/C7EJ+0AIPhq6RxTzhndE1CQ37H+/riSyHAYff315Q098rZX