服务发现组件之 — Eureka

前言

现在流行的微服务体系结构正在改变我们构建应用程序的方式，从单一的单体服务转变为越来越小的可单独部署的服务（称为微服务），共同构成了我们的应用程序。当进行一个业务时不可避免就会存在多个服务之间调用，假如一个服务 A 要访问在另一台服务器部署的服务 B，那么前提是服务 A 要知道服务 B 所在机器的 IP 地址和服务对应的端口，最简单的方式就是让服务 A 自己去维护一份服务 B 的配置（包含 IP 地址和端口等信息），但是这种方式有几个明显的缺点：随着我们调用服务数量的增加，配置文件该如何维护；缺乏灵活性，如果服务 B 改变 IP 地址或者端口，服务 A 也要修改相应的文件配置；还有一个就是进行服务的动态扩容或缩小不方便。
一个比较好的解决方案就是 服务发现（Service Discovery）。它抽象出来了一个注册中心，当一个新的服务上线时，它会将自己的 IP 和端口注册到注册中心去，会对注册的服务进行定期的心跳检测，当发现服务状态异常时将其从注册中心剔除下线。服务 A 只要从注册中心中获取服务 B 的信息即可，即使当服务 B 的 IP 或者端口变更了，服务 A 也无需修改，从一定程度上解耦了服务。服务发现目前业界有很多开源的实现，比如 apache 的 zookeeper、 Netflix 的 eureka、hashicorp 的 consul、 CoreOS 的 etcd。

Eureka 是什么

Eureka 在 github 上对其的定义为

Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.
At Netflix, Eureka is used for the following purposes apart from playing a critical part in mid-tier load balancing.

Eureka 是由 Netflix 公司开源，采用的是 Client / Server 模式进行设计，基于 http 协议和使用 Restful Api 开发的服务注册与发现组件，提供了完整的服务注册和服务发现，可以和 Spring Cloud 无缝集成。其中 Server 端扮演着服务注册中心的角色，主要是为 Client 端提供服务注册和发现等功能，维护着 Client 端的服务注册信息，同时定期心跳检测已注册的服务当不可用时将服务剔除下线，Client 端可以通过 Server 端获取自身所依赖服务的注册信息，从而完成服务间的调用。遗憾的是从其官方的 github wiki 可以发现，2.0 版本已经不再开源。但是不影响我们对其进行深入了解，毕竟服务注册、服务发现相对来说还是比较基础和通用的，其它开源实现框架的思想也是想通的。

服务注册中心（Eureka Server）

我们在项目中引入 Eureka Server 的相关依赖，然后在启动类加上注解 @EnableEurekaServer，就可以将其作为注册中心，启动服务后访问页面如下：

我们继续添加两个模块 service-provider，service-consumer，然后在启动类加上注解 @EnableEurekaClient 并指定注册中心地址为我们刚刚启动的 Eureka Server，再次访问可以看到两个服务都已经注册进来了。

Demo 仓库地址：https://github.com/mghio/depth-in-springcloud

可以看到 Eureka 的使用非常简单，只需要添加几个注解和配置就实现了服务注册和服务发现，接下来我们看看它是如何实现这些功能的。

服务注册（Register）

注册中心提供了服务注册接口，用于当有新的服务启动后进行调用来实现服务注册，或者心跳检测到服务状态异常时，变更对应服务的状态。服务注册就是发送一个 POST 请求带上当前实例信息到类 ApplicationResource 的 addInstance 方法进行服务注册。

可以看到方法调用了类 PeerAwareInstanceRegistryImpl 的 register 方法，该方法主要分为两步：

调用父类 AbstractInstanceRegistry 的 register 方法把当前服务注册到注册中心
调用 replicateToPeers 方法使用异步的方式向其它的 Eureka Server 节点同步服务注册信息

服务注册信息保存在一个嵌套的 map 中，它的结构如下：

第一层 map 的 key 是应用名称（对应 Demo 里的 SERVICE-PROVIDER），第二层 map 的 key 是应用对应的实例名称（对应 Demo 里的 mghio-mbp:service-provider:9999），一个应用可以有多个实例，主要调用流程如下图所示：

服务续约（Renew）

服务续约会由服务提供者（比如 Demo 中的 service-provider）定期调用，类似于心跳，用来告知注册中心 Eureka Server 自己的状态，避免被 Eureka Server 认为服务时效将其剔除下线。服务续约就是发送一个 PUT 请求带上当前实例信息到类 InstanceResource 的 renewLease 方法进行服务续约操作。

进入到 PeerAwareInstanceRegistryImpl 的 renew 方法可以看到，服务续约步骤大体上和服务注册一致，先更新当前 Eureka Server 节点的状态，服务续约成功后再用异步的方式同步状态到其它 Eureka Server 节上，主要调用流程如下图所示：

服务下线（Cancel）

当服务提供者（比如 Demo 中的 service-provider）停止服务时，会发送请求告知注册中心 Eureka Server 进行服务剔除下线操作，防止服务消费者从注册中心调用到不存在的服务。服务下线就是发送一个 DELETE 请求带上当前实例信息到类 InstanceResource 的 cancelLease 方法进行服务剔除下线操作。

进入到 PeerAwareInstanceRegistryImpl 的 cancel 方法可以看到，服务续约步骤大体上和服务注册一致，先在当前 Eureka Server 节点剔除下线该服务，服务下线成功后再用异步的方式同步状态到其它 Eureka Server 节上，主要调用流程如下图所示：

服务剔除（Eviction）

服务剔除是注册中心 Eureka Server 在启动时就启动一个守护线程 evictionTimer 来定期（默认为 60 秒）执行检测服务的，判断标准就是超过一定时间没有进行 Renew 的服务，默认的失效时间是 90 秒，也就是说当一个已注册的服务在 90 秒内没有向注册中心 Eureka Server 进行服务续约（Renew），就会被从注册中心剔除下线。失效时间可以通过配置 eureka.instance.leaseExpirationDurationInSeconds 进行修改，定期执行检测服务可以通过配置 eureka.server.evictionIntervalTimerInMs 进行修改，主要调用流程如下图所示：

服务提供者（Service Provider）

对于服务提供方（比如 Demo 中的 service-provider 服务）来说，主要有三大类操作，分别为 服务注册（Register）、服务续约（Renew）、服务下线（Cancel），接下来看看这三个操作是如何实现的。