Spring Cloud Eureka 服务治理

基础架构

Eureka [juˈriːkə] 服务治理基础架构的 3 个核心要素：

• 服务注册中心：Eureka 提供的服务端，提供服务注册与服务发现的功能。
• 服务提供者：提供服务的应用，可以是 Spring Boot 应用，也可以是其他技术平台且遵循 Eureka 通信机制的应用。它将自己提供的服务注册到 Eureka 以供其他应用发现。
• 服务消费者：消费者应用从服务注册中心获取服务列表，从而使消费者知道可以从何处调用其所需要的服务。

很多时候，Eureka 的客户端既是服务提供者也是服务消费者。

服务治理机制

以下是从服务注册开始到服务调用， Eureka 基础架构中各个元素所涉及的一些重要通信行为。

服务提供者

服务注册

服务提供者在启动的时候会通过发送 REST 请求的方式将自己注册到 Eureka Server 上， 同时带上了自身服务的一些元数据信息。Eureka Server 接收到这个 REST 请求之后， 将元数据信息存储在一个双层结构Map 中， 其中第一层的 key 是服务名， 第二层的 key 是具体服务的实例名。

服务同步

服务提供者可以分别注册到多个不同的服务注册中心上，服务提供者的信息被多个服务注册中心所维护。 此时由于服务注册中心之间互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，该注册中心会将请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，服务提供者的服务信息就可以通过多个服务注册中心中的任意一台获取到。

服务续约

在注册完服务之后，服务提供者会维护一个心跳用来持续告诉 Eureka Server 自己还存活， 以防止 Eureka Server 的 “剔除任务 ” 将该服务实例从服务列表中排除出去，称该操作为服务续约(Renew)。

服务消费者

服务获取

当启动服务消费者的时候，它会发送 REST 请求到服务注册中心来获取上面注册的服务清单。为了性能考虑，Eureka Server 会维护一份只读的服务清单来返回给客户端，同时该缓存清单会定时更新，默认是每隔 30 秒更新一次。

服务调用

服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例，在 Ribbon 中默认采用轮询方式进行调用，从而实现客户端的负载均衡。

对于访问实例的选择，Eureka 中有 Region 和 Zone 的概念， 一个 Region 中可以包含多个 Zone, 每个服务客户端需要被注册到一个 Zone 中，所以每个客户端对应一个 Region 和一个 Zone。 在进行服务调用的时候，优先访问同处一个 Zone 中的服务提供方，若访问不到，则访问其他的 Zone。

服务下线（是否属于服务消费者的内容？）

在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间，自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中，当服务实例进行正常的关闭操作时， 它会触发一个服务下线的 REST 请求给 Eureka Server, 告诉服务注册中心：“我要下线了” 。服务端在接收到请求之后，将该服务状态置为下线(DOWN), 并把该下线事件传播出去。

服务注册中心

服务剔除

有些时候服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使得服务不能正常工作，而服务注册中心并未收到 “服务下线” 的请求。为了从服务列表中将这些无法提供服务的实例剔除，Eureka Server 在启动的时候会创建一个定时任务，每隔一段时间(默认为 60 秒)将当前清单中超时(默认为90秒)没有续约的服务剔除。

自我保护

服务注册到 Eureka Server 之后，会维护一个心跳连接，告诉 Eureka Server 自己还活着。Eureka Server 在运行期间，会统计心跳失败的比例在 15 分钟之内是否低于 85 %, 如果出现低于的情况（在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致），Eureka Server 会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。 但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的清况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。

为什么要有自我保护？

默认情况下，当 Eureka Server 在一定时间内没有收到实例的心跳，便会把该实例从注册表中删除(默认是90秒)，但是，如果短时间内丢失大量的实例心跳，便会触发 Eureka Server 的自我保护机制，比如在开发测试时，需要频繁地重启微服务实例，但是我们很少会把 Eureka Server一起重启(因为在开发过程中不会修改 Eureka 注册中心)。在警告中可以看到，Eureka 认为虽然收不到实例的心跳，但它认为实例还是健康的，Eureka 会保护这些实例，不会把它们从注册表中删掉。

该保护机制的目的是避免网络连接故障，在发生网络故障时，微服务和注册中心之间无法正常通信，但服务本身是健康的，不应该注销该服务，如果 Eureka 因网络故障而把微服务误删了，那即使网络恢复了，该微服务也不会重新注册到 Eureka Server，因为只有在微服务启动的时候才会发起注册请求，后面只会发送心跳和服务列表请求，这样的话，该实例虽然是运行着，但永远不会被其它服务所感知。所以 Eureka Server 在短时间内丢失过多的客户端心跳时，会进入自我保护模式，该模式下，Eureka 会保护注册表中的信息，不再注销任何微服务，当网络故障恢复后，Eureka 会自动退出保护模式。自我保护模式可以让集群更加健壮。

但是在开发测试阶段，需要频繁地重启发布，如果触发了保护机制，则旧的服务实例没有被删除，这时请求有可能跑到旧的实例中，而该实例已经关闭了，这就导致请求错误，影响开发测试。所以，在开发测试阶段，我们可以把自我保护模式关闭。

Eureka 与 Zookeeper

Spring Cloud Eureka 实现的服务治理机制强调了 CAP 原理中的 AP, 即可用性与可靠性，它与 ZooKeeper 这类强调CP(一致性、可靠性）的服务治理框架最大的区别就是：Eureka 为了实现更高的服务可用性，牺牲了一定的一致性， 在极端情况下它宁愿接受故障实例也不要丢掉“健康”实例。

例如，当服务注册中心的网络发生故障断开时，由于所有的服务实例无法维持续约心跳，在强调 AP（此处个人认为应该是 CP） 的服务治理中将会把所有服务实例都剔除掉，而 Eureka 则会因为超过 85% 的实例丢失心跳而触发保护机制，注册中心将会保留此时的所有节点，以实现服务间依然可以进行互相调用的场景，即使其中有部分故障节点，但这样做可以继续保障大多数的服务正常消费。

参考：

《Spring Cloud 微服务实战》翟永超 著