服务发现组件之 — Eureka

2020-03-15 本文已影响0人 mghio

前言

现在流行的微服务体系结构正在改变我们构建应用程序的方式，从单一的单体服务转变为越来越小的可单独部署的服务（称为微服务），共同构成了我们的应用程序。当进行一个业务时不可避免就会存在多个服务之间调用，假如一个服务 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，就可以将其作为注册中心，启动服务后访问页面如下：

eureka-server-homepage.png

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

instance-registered-currently.png

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

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

服务注册（Register）

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

eureka-server-applicationresource-addinstance.png

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

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

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

eureka-server-registry-structure.png

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

eureka-server-register-sequence-chart.png

服务续约（Renew）

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

eureka-server-instanceresource-renew.png

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

eureka-server-renew-sequence-chart.png

服务下线（Cancel）

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

eureka-server-instanceresource-cancellease.png

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

eureka-server-cancellease-sequence-chart.png

服务剔除（Eviction）

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

eureka-server-evict-sequence-chart.png

服务提供者（Service Provider）

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