SpringCloud03—服务治理：SpringCloud Eureka
上一篇：《SpringCloud02—微服务构建：SpringBoot》
3.服务治理:SpringCloud Eureka
Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分，它基于NetflixEureka做了二次封装，主要负责完成微服务架构中的服务治理功能。Spring Cloud通过为Eureka增加了Spring Boot风格的自动化配置，我们只需通过简单引入依赖和注解配置就能让 Spring Boot构建的微服务应用轻松地与Eureka服务治理体系进行整合。
3.1 服务治理
服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册与发现。
3.1.1 为什么我们在微服务架构中那么需要服务治理模块呢?微服务系统没有它会有什么不好的地方吗?
在最初开始构建微服务系统的时候可能服务并不多，我们可以通过做一些静态配置来完成服务的调用。
比如，有两个服务A和B，其中服务A需要调用服务B来完成一个业务操作时，为了实现服务B的高可用，不论采用服务端负载均衡还是客户端负载均衡，都需要手工维护服务B的具体实例清单。但是随着业务的发展，系统功能越来越复杂，相应的微服务应用也不断增加，我们的静态配置就会变得越来越难以维护。
并且面对不断发展的业务，我们的集群规模、服务的位置、服务的命名等都有可能发生变化，如果还是通过手工维护的方式，那么极易发生错误或是命名冲突等问题。同时，对于这类静态内容的维护也必将消耗大量的人力。
为了解决微服务架构中的服务实例维护问题，产生了大量的服务治理框架和产品。这些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。
-
1.服务注册
服务注册:在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告知注册中心，注册中心按服务名分类组织服务清单。
比如，我们有两个提供服务A的进程分别运行于192.168.0.100:8000和192.168.0.101:8000位置上
另外还有三个提供服务B的进程分别运行于192.168.0.100 : 9000 、192.168.0.101 :9000、192.168.0.102:9000位置上。
当这些进程均启动，并向注册中心注册自己的服务之后，注册中心就会维护类似下面的一个服务清单。
另外，服务注册中心还需要以心跳的方式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，达到排除故障服务的效果。服务名 位置 服务A 192.168.0.100:8000、192.168.0.101:8000 服务B 192.168.0.100 : 9000 、192.168.0.101 :9000、192.168.0.102:9000 -
2.服务发现
服务发现:由于在服务治理框架下运作，服务间的调用不再通过指定具体的实例地址来实现，而是通过向服务名发起请求调用实现， 所以，服务调用方在调用服务提供方接口的时候，并不知道具体的服务实例位置。因此，调用方需要向服务注册中心咨询服务，并获取所有服务的实例清单，以实现对具体服务实例的访问。比如，现有服务C希望调用服务A，服务C就需要向注册中心发起咨询服务请求，服务注册中心就会将服务A的位置清单返回给服务C，如按上例服务A的情况，C便获得了服务A的两个可用位置192.168.0.100:8000和 192.168.0.101:8000。当服务C要发起调用的时候，便从该清单中以某种轮询策略取出一个位置来进行服务调用，这就是后续我们将会介绍的客户端负载均衡。
这里我们只是列举了一种简单的服务治理逻辑，以方便理解服务治理框架的基本运行思路。实际的框架为了性能等因素，不会采用每次都向服务注册中心获取服务的方式，并且不同的应用场景在缓存和服务剔除等机制上也会有一些不同的实现策略。
3.2 Netflix Eureka
Spring Cloud Eureka，使用Netflix Eureka来实现服务注册与发现，它既包含了服务端组件，也包含了客户端组件，并且服务端与客户端均采用Java编写，所以Eureka主要适用于通过Java实现的分布式系统，或是与JVM兼容语言构建的系统。
但是，由于Eureka服务端的服务治理机制提供了完备的RESTful API，所以它也支持将非Java语言构建的微服务应用纳入Eureka的服务治理体系中来。只是在使用其他语言平台的时候，需要自己来实现 Eureka的客户端程序。不过庆幸的是，在目前几个较为流行的开发平台上，都已经有了一些针对 Eureka 注册中心的客户端实现框架，比如.NET平台的Steeltoe、Node.js 的eureka-js-client等。
Eureka服务端，我们也称为服务注册中心。它同其他服务注册中心一样，支持高可用配置。它依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。
如果 Eureka 以集群模式部署，当集群中有分片出现故障时，那么 Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中的其他分片会把它们的状态再次同步回来。
以在 AWS上的实践为例，Netflix 推荐每个可用的区域运行一个Eureka服务端，通过它来形成集群。不同可用区域的服务注册中心通过异步模式互相复制各自的状态，这意味着在任意给定的时间点每个实例关于所有服务的状态是有细微差别的。
Eureka客户端，主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中，在应用程序运行时Eureka 客户端向注册中心注册自身提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务状态。
3.3 搭建服务中心
首先，创建一个基础的Spring Boot-web工程，命名为eureka，并在pom.xml中引入必要的依赖内容，代码如下：
<parent>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-parentartifactId>
<version>2.5.0version>
<relativePath/>
parent>
<dependencies>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-eureka-serverartifactId>
<version>1.4.6.RELEASEversion>
dependency>
dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-dependenciesartifactId>
<version>2020.0.2version>
<type>pomtype>
<scope>importscope>
dependency>
dependencies>
dependencyManagement>
通过@EnableEurekaServer 注解启动一个服务注册中心提供给其他应用进行对话。
@EnableEurekaServer
@SpringBootApplication
public class EurekaApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class, args);
}
}
在默认设置下，该服务注册中心也会将自己作为客户端来尝试注册它自己，所以我们需要禁用它的客户端注册行为，只需在application.properties中增加如下配置:
server.port=1111
#ureka服务端实例名称
eureka.instance.hostname=eureka-center
# 是否向注册中心注册自己
eureka.client.register-with-eureka=false
# 是否从Eureka上获取服务的注册信息,自己就是注册中心，本身职责就是维护服务实例，并不需要去检索服务
eureka.client.fetch-registry=false
# 设置与Eureka Server交互的地址(查询服务、注册服务等)
eureka.client.service-url.defaultZone=http://localhost:${server.port}/eureka/
完成以上操作之后我们重启服务，访问http://localhost:1111/，可以看到以下页面
3.4 注册服务提供者
在完成了服务注册中心的搭建之后，接下来我们尝试将一个既有的Spring Boot应用加入 Eureka的服务治理体系中去。
在创建一个springBoot-web项目，将其作为一个微服务应用向服务注册中心发布自己。首先，修改pom. xml，增加Spring Cloud Eureka模块的依赖，具体代码如下所示:
<parent>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-parentartifactId>
<version>2.5.1version>
<relativePath/>
parent>
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-eurekaartifactId>
<version>1.4.7.RELEASEversion>
dependency>
dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-dependenciesartifactId>
<version>2020.0.2version>
<type>pomtype>
<scope>importscope>
dependency>
dependencies>
dependencyManagement>
接着创建一个接口HelloController
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class HelloController {
private static final Logger logger = LoggerFactory.getLogger(HelloController.class);
@RequestMapping(value = "/hello", method = RequestMethod.GET)
public String index() {
return "Hello SpringCloud";
}
}
然后，在主类中通过加上@EnableDiscoveryClient 注解，激活 Eureka中的DiscoveryClient实现（自动化配置，创建DiscoveryClient接口针对Eureka客户端的EurekaDiscoveryClient实例)，才能实现上述Controller中对服务信息的输出。
@EnableDiscoveryClient
@SpringBootApplication
public class HelloServiceApplication {
public static void main(String[] args) {
SpringApplication.run(HelloServiceApplication.class, args);
}
}
最后，我们需要在 application.properties 配置文件中，通过spring.application.name属性来为服务命名，比如命名为hello-service。
再通过eureka.client.serviceUrl.defaultzone属性来指定服务注册中心的地址，这里我们指定为之前构建的服务注册中心地址，完整配置如下所示:
spring.application.name=hello-service
# 注册服务的时候使用服务的ip地址
eureka.instance.prefer-ip-address=true
eureka.client.service-url.defaultZone=http://localhost:1111/eureka/
通过访问Eureka的信息面板，在Instances currently registered with Eureka一栏中看到服务的注册信息。
3.5 高可用注册中心
在微服务架构这样的分布式环境中，我们需要充分考虑发生故障的情况，所以在生产环境中必须对各个组件进行高可用部署，对于微服务如此，对于服务注册中心也一样。但是到本节为止，我们一直都在使用单节点的服务注册中心，这在生产环境中显然并不合适，我们需要构建高可用的服务注册中心以增强系统的可用性。
Eureka Server的设计一开始就考虑了高可用问题，在 Eureka的服务治理设计中，所有节点即是服务提供方，也是服务消费方，服务注册中心也不例外。在单节点的配置中，我们设置过下面这两个参数，让服务注册中心不注册自己:
# 是否向注册中心注册自己
eureka.client.register-with-eureka=false
# 是否从Eureka上获取服务的注册信息,自己就是注册中心，
# 本身职责就是维护服务实例，并不需要去检索服务
eureka.client.fetch-registry=false
Eureka Server 的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。下面我们就来尝试搭建高可用服务注册中心的集群。可以在本章第3.3节中实现的服务注册中心的基础之上进行扩展，构建一个双节点的服务注册中心集群。
- 1.创建application-peer1.properties，作为peer1服务中心的配置，并将serviceUrl 指向peer2:
server.port=1111 spring.application.name=eureka-server #ureka服务端实例名称 eureka.instance.hostname=peer1 # 设置与Eureka Server交互的地址(查询服务、注册服务等) eureka.client.service-url.defaultZone=http://peer2:1112/eureka/ - 2.创建application-peer2.properties作为peer2服务中心的配置，并将serviceUrl 指向peer1:
server.port=1112 spring.application.name=eureka-server #ureka服务端实例名称 eureka.instance.hostname=peer2 # 设置与Eureka Server交互的地址(查询服务、注册服务等) eureka.client.service-url.defaultZone=http://peer1:1111/eureka/
- 在/etc/hosts 文件中添加对peer1和 peer2的转换,让上面配置的host形式的serviceUrl 能在本地正确访问到;Windows系统路径为C:\Windows\System32\drivers\etc\hosts。
cmd 127.0.0.1 peer1 127.0.0.1 peer2
-
4.分别激活peer1、peer2，打包之后通过指令java -jar 包名 来运行
浏览器访问地址http://localhost:1111、http://localhost:1112 可以看到
-
5.在设置了多节点的服务注册中心之后，服务提供方还需要做一些简单的配置才能将服务注册到 Eureka Server集群中。我们以 hello-service为例，修改application.properties配置文件，如下所示:
spring.application.name=hello-service eureka.client.service-url.defaultZone=http://peer1:1111/eureka/,http://peer2:1112/eureka/上面的配置主要对eureka.client.serviceUrl.defaultzone 属性做了改动，将注册中心指向了之前我们搭建的peer1 与peer2.
下面，我们启动该服务，通过访问http://localhost:1111/和http://localhost:1112/，可以观察到hello-service服务同时被注册到了peerl和peer2上。
若此时断开peerl，由于compute-service同时也向peer2注册，因此在peer2上的其他服务依然能访问到hello-service，从而实现了服务注册中心的高可用。
如我们不想使用主机名来定义注册中心的地址，也可以使用IP地址的形式，但是需要在配置文件中增加配置参数eureka.instance.prefer-ip-address=true，该值默认为false。
3.6 服务发现与服务消费
通过上面的内容介绍与实践，我们已经搭建起微服务架构中的核心组件——服务注册中心(包括单节点模式和高可用模式)。同时，还对上一章中实现的Spring Boot 入门程序做了改造。
通过简单的配置，使该程序注册到Eureka注册中心上，成为该服务治理体系下的一个服务，命名为 hello-service。
现在我们已经有了服务注册中心和服务提供者，下面就来尝试构建一个服务消费者，它主要完成两个目标:
- 发现服务 由Eureka的客户端完成
- 消费服务 由Ribbon完成
Ribbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。当Ribbon与 Eureka 联合使用时，Ribbon的服务实例清单RibbonServerList会被DiscoveryEnabledNIwSServerList 重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。
在本章中，我们对Ribbon不做详细的介绍，我们只需要理解它在 Eureka服务发现的基础上，实现了一套对服务实例的选择策略,从而实现对服务的消费。下一章我们会对Ribbon做详细的介绍和分析。
下面我们通过构建一个简单的示例，看看在 Eureka的服务治理体系下如何实现服务的发现与消费。
首先，我们做一些准备工作。启动之前实现的服务注册中心eureka-server 以及hello-service服务，为了实验Ribbon
的客户端负载均衡功能，我们分别打包两个端口号为8080，8081的项目，然后通过java -jar来进行运行:
在成功启动两个hello-service服务之后，如下图所示，从eureka信息面板中可以看到名为hello-service的服务中出现了两个实例单元，分别是通过命令行启动的8080端口和8081端口的服务
创建一个Spring Boot的基础web工程来实现服务消费者，取名为ribbon-consumer,并在 pom.xml 中引入如下的依赖内容。较之前的 hello-service，我们新增了Ribbon模块的依赖spring-cloud-starter-ribbon。
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0modelVersion>
<parent>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-parentartifactId>
<version>2.5.1version>
<relativePath/>
parent>
<groupId>com.cloudgroupId>
<artifactId>ribbon-consumerartifactId>
<version>0.0.1-SNAPSHOTversion>
<name>ribbon-consumername>
<description>Demo project for Spring Bootdescription>
<properties>
<java.version>11java.version>
properties>
<dependencies>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-eurekaartifactId>
<version>1.4.7.RELEASEversion>
dependency>
<dependency>
<groupId>com.netflix.ribbongroupId>
<artifactId>ribbon-loadbalancerartifactId>
<version>2.3.0version>
dependency>
<dependency>
<groupId>com.netflix.ribbongroupId>
<artifactId>ribbon-coreartifactId>
<version>2.3.0version>
dependency>
<dependency>
<groupId>com.netflix.ribbongroupId>
<artifactId>ribbon-httpclientartifactId>
<version>2.3.0version>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-netflix-ribbonartifactId>
<version>2.2.6.RELEASEversion>
dependency>
dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-dependenciesartifactId>
<version>2020.0.2version>
<type>pomtype>
<scope>importscope>
dependency>
dependencies>
dependencyManagement>
<build>
<plugins>
<plugin>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-maven-pluginartifactId>
plugin>
plugins>
build>
project>
创建应用主类ConsumerApplication，通过@EnableDiscoveryClient注解让该应用注册为Eureka客户端应用，以获得服务发现的能力。同时，在该主类中创建RestTemplate的Spring Bean实例，并通过@LoadBalanced注解开启客户端负载均衡。
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;
@EnableDiscoveryClient
@SpringBootApplication
public class RibbonConsumerApplication {
@Bean
@LoadBalanced
RestTemplate restTemplate() {
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(RibbonConsumerApplication.class, args);
}
}
在application.properties中配置Eureka服务注册中心的位置，需要与之前的HELLO-SERVICE一样，不然是发现不了该服务的,同时设置该消费者的端口为9000，不能与之前启动的应用端口冲突。
server.port=9000
spring.application.name=ribbon-consumer
# 注册服务的时候使用服务的ip地址
eureka.instance.prefer-ip-address=false
eureka.client.service-url.defaultZone=http://peer1:1111/eureka/,http://peer2:1112/eureka/
启动ribbon-consumer应用后，我们可以在 Eureka
信息面板中看到，当前除了
HELLO-SERVICE之外，还多了我们实现的RIBBON-CONSUMER服务。
接下来编写consumerController
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;
@RestController
public class ConsumerController {
@Autowired
RestTemplate restTemplate;
@RequestMapping(value = "ribbon-consumer", method = RequestMethod.GET)
public String helloConsumer() {
return restTemplate.getForEntity("http://hello-service/hello", String.class).getBody();
}
}
注意：hello-service对应的是hello-service服务中application.properties文件中spring.application.name
通过向http://localhost:9000/ribbon-consumer发起请求，成功返回数据
此时我们关闭一个hello-service服务，再次访问http://localhost:9000/ribbon-consumer，可以发现仍然也可以获取到数据,不过由于默认的是轮询算法，所以会间断一次才能获取到数据
3.7 Eureka详解
在上面几个小节中，我们通过一个简单的服务注册与发现实例，构建了Eureka服务治理体系中的三个核心角色:
- 服务注册中心
- 服务提供者
- 服务消费者
通过上述示例，对于Eureka 的服务治理机制已经有了一些初步的认识。至此，我们已经学会了如何构建服务注册中心（包括单节点和高可用部署)，也知道了如何使用 Eureka的注解和配置将Spring Boot应用纳入Eureka的服务治理体系，成为服务提供者或是服务消费者。同时，对于客户端负载均衡的服务消费也有了一些简单的接触。
但是，在实践中，我们的系统结构往往都要比上述示例复杂得多，如果仅仅依靠之前构建的服务治理内容，大多数情况是无法完全直接满足业务系统需求的，我们还需要根据实际情况来做一些配置、调整和扩展。所以，在本节中，我们将详细介绍 Eureka的基础架构、节点间的通信机制以及一些进阶的配置等。
3.7.1 基础架构
整个Eureka服务治理基础架构的三个核心要素:
- 服务注册中心:Eureka提供的服务端，提供服务注册与发现的功能，也就是在上一节中我们实现的eureka-server。
- 服务注册中心：eureka提供的服务端，提供服务注册与发现的功能，也就是在上一节中我们实现的eureka-server。
- 服务提供者:提供服务的应用，可以是Spring Boot应用，也可以是其他技术平台且遵循Eureka通信机制的应用。它将自己提供的服务注册到Eureka，以供其他应用发现，也就是在上一节中我们实现的HELLO-SERVICE应用。
- 服务消费者:消费者应用从服务注册中心获取服务列表，从而使消费者可以知道去何处调用其所需要的服务，在上一节中使用了Ribbon来实现服务消费，另外后续还会介绍使用Feign的消费方式。
很多时候，客户端既是服务提供者也是服务消费者。
3.7.2 服务治理机制
在体验了Spring Cloud Eureka通过简单的注解配置就能实现强大的服务治理功能之后，我们来进一步了解一下 Eureka基础架构中各个元素的一些通信行为，以此来理解基于Eureka实现的服务治理体系是如何运作起来的。以下图为例，其中有这样几个重要元素:
- “服务注册中心-1”和“服务注册中心-2”，它们互相注册组成了高可用集群。
- “服务提供者”启动了两个实例，一个注册到“服务注册中心-1”上，另外一个注册到“服务注册中心-2”上。
- 还有两个“服务消费者”，它们也都分别只指向了一个注册中心。
根据上面的结构，下面我们来详细了解一下，从服务注册开始到服务调用，及各个元素所涉及的一些重要通信行为。
3.7.2.1 服务提供者
- 服务注册
“服务提供者”在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server接收到这个REST请求之后，将元数据信息存储在一个双层结构Map中，其中第一层的key 是服务名，第二层的key 是具体服务的实例名。(我们可以回想一下之前在实现Ribbon负载均衡的例子中，Eureka信息面板中一个服务有多个实例的情况，这些内容就是以这样的双层 Map形式存储的。)
在服务注册时，需要确认一下eureka.client.register-with-eureka=true参数是否正确，该值默认为true。若设置为false将不会启动注册操作。 - 服务同步
如架构图中所示，这里的两个服务提供者分别注册到了两个不同的服务注册中心上，也就是说，它们的信息分别被两个服务注册中心所维护。
此时，由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心中的任意一台获取到。 - 服务续约
在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server:“我还活着”，以防止 Eureka Server“剔除任务”将该服务实例从服务列表中排除出去，我们称该操作为服务续约(Renew)。
关于服务续约有两个重要属性，我们可以关注并根据需要来进行调整:# 定义服务续约任务的调用间隔时间，默认是30秒 eureka.instance.lease-renewal-interval-in-seconds=30 # 定义服务失效的时间，默认是90秒 eureka.instance.lease-expiration-duration-in-seconds=90
3.7.2.2 服务消费者
- 1.获取服务
到这里，在服务注册中心已经注册了一个服务，并且该服务有两个实例。
当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。获取服务是服务消费者的基础,所以必须确保eureka.client.fetch-registry=true参数没有被修改成false，该值默认为true。若希望修改缓存清单的更新时间，可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改，该参数默认值为30，单位为秒。 - 2.服务调用
服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例，在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
对于访问实例的选择，Eureka 中有Region和 Zone 的概念，一个Region中可以包含多个Zone，每个服务客户端需要被注册到一个Zone中,所以每个客户端对应一个Region和一个Zone。
在进行服务调用的时候，优先访问同处一个Zone中的服务提供方，若访问不到，就访问其他的Zone，更多关于Region和Zone的知识我们会在后续的源码解读中介绍。 - 3.服务下线
在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间，我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中，当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心:“我要下线了”。服务端在接收到请求之后，将该服务状态置为下线(DOWN)，并把该下线事件传播出去。
3.7.2.3 服务注册中心
-
1.失效剔除
有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使得服务不能正常工作，而服务注册中心并未收到“服务下线”的请求。为了从服务列表中将这些无法提供服务的实例剔除，Eureka Server在启动的时候会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。 -
2.自我保护
当我们在本地调试基于Eureka的程序时，基本上都会碰到这样一个问题，在服务注册中心的信息面板中出现类似下面的红色警告信息:
实际上，该警告就是触发了Eureka Server的自我保护机制。
之前我们介绍过，服务注册到Eureka Server之后,会维护一个心跳连接,告诉Eureka Server自己还活着。
Eureka Server在运行期间,会统计心跳失败的比例在15分钟之内是否低于85%,如果出现低于的情况(在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致)，EurekaServer会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。
但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。
由于本地调试很容易触发注册中心的保护机制，这会使得注册中心维护的服务实例不那么准确。所以，我们在本地进行开发的时候，可以使用eureka.server.enable-self-preservation=false参数来关闭保护机制，以确保注册中心可以将不可用的实例正确剔除。
下一篇：《SpringCloud04—客户端负载均衡 SpringCLoud Ribbon》