Spring Cloud Eureka是Spring Cloud Netlix 微服务套件中的一部分， 它基于NetfixEureka做了二次封装，主要负责完成微服务架构中的服务治理功能。Spring Cloud 通过为Eureka增加Spring Boot风格的自动化配置,我们只需通过简单引入依赖和注解配置就能让SpringBoot构建的微服务应用轻松地与Eureka服务治理体系进行整合。
这里说到服务治理，我们先来看看什么是服务治理。
服务治理
服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册与发现。为什么我们在微服务架构中那么需要服务治理模块呢?微服务系统没有它会有什么不好的地方吗?
在最初开始构建微服务系统的时候可能服务并不多，我们可以通过做一些静态配置来完成服务的调用。比如，有两个服务A和B,其中服务A需要调用服务B来完成一个业务操作时，为了实现服务B的高可用，不论采用服务端负载均衡还是客户端负载均衡，都需要手工维护服务B的具体实例清单。但是随着业务的发展，系统功能越来越复杂，相应的微服务应用也不断增加，我们的静态配置就会变得越来越难以维护。并且面对不断发展的业务，我们的集群规模、服务的位置、服务的命名等都有可能发生变化，如果还是通过手工维护的方式，那么极易发生错误或是命名冲突等问题。同时，对于这类静态内容的维护也必将消耗大量的人力。
为了解决微服务架构中的服务实例维护问题，产生了大量的服务治理框架和产品。这些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。.
- 服务注册：在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告知注册中心，注册中心按服务名分类组织服务清单。比如，我们有两个提供服务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 位置上。当这些进程均启动，并向注册中心注册自己的服务之后，注册中心就会维护类似下面的一个服务清单。另外，服务注册中心还需要以心跳的方式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，达到排除故障服务的效果。
- 服务发现: 由于在服务治理框架下运作，服务间的调用不再通过指定具体的实例地址来实现，而是通过向服务名发起请求调用实现。所以，服务调用方在调用服务提供方接口的时候，并不知道具体的服务实例位置。因此，调用方需要向服务注册中心咨询服务，并获取所有服务的实例清单，以实现对具体服务实例的访问。比如，现有服务C希望调用服务A，服务C就需要向注册中心发起咨询服务请求，服务注册中心就会将服务A的位置清单返回给服务C,如按上例服务A的情况，C便获得了服务A的两个可用位置192.168.0.100:8000和192.168.0. 101:8000.当服务C要发起调用的时候，便从该清单中以某种轮询策略取出一个位置来进行服务调用，这就是后续我们将会介绍的客户端负载均衡。这里我们只是列举了一-种简单的服务治理逻辑，以方便理解服务治理框架的基本运行思路。实际的框架为了性能等因素，不会采用每次都向服务注册中心获取服务的方式，并且不同的应用场景在缓存和服务剔除等机制.上也会有一些不同的实现策略。
Netflix Eureka
Spring Cloud Eureka,使用Netlix 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 客户端向注册中心注册自身提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务状态。
我们简单构建一些示例，学习如何使用Eureka 构建注册中心以及进行注册与发现服务。
首先创建一个基础的Spring Boot 工程，并在pom. xml中引入必要的依赖内容，代码如下:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>通过@EnableEurekaServer注解启动一个服务注册中心提供给其他应用进行对话。这一步非常简单，只需在一个普通的SpringBoot应用中添加这个注解就能开启此功能。
不过在默认情况下，该服务注册中心也会将自己作为客户端来注册它自己，所以我们需要禁用它的客户端注册行为，我们只需要在application.properties中增加对应配置就好。
eureka.instance.hostname=localhost
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.client.serviceUrl.defaultZone=http://$ {eureka.instance.hostname} :${server.port}/eureka/- eureka.client.register-with-eureka：由于应用为注册中心，所以设置为false，代表注册中心不指向自己。
- eureka.client.fetch-registry：由于注册中心的职责就是维护服务实例，他并不需要去检索服务，所以也设置为false。
完成上面的配置后，启动应用访问http://localhost:1111/我们可以看到如下图，其中Instances currently registered with Eureka是空的，说明该注册中心还没有注册任何服务。http://localhost:1111/
这里附上各功能描述图：
高可用注册中心
在微服务架构这样的分布式环境中，我们需要充分考虑发生故障的情况，所以在生产环境中必须对各个组件进行高可用部署，对于微服务如此，对于服务注册中心也一样。但是到目前为止，我们一直都在使用单节点的服务注册中心，这在生产环境中显然并不合适，我们需要构建高可用的服务注册中心以增强系统的可用性。
Eureka Server的设计一开始就考虑了高可用问题，在Eureka的服务治理设计中，所有节点即是服务提供方，也是服务消费方，服务注册中心也不例外。是否还记得在单节点的配置中，我们设置过下面这两个参数，让服务注册中心不注册自己:我们需要构建高可用的服务注册中心以增强系统的可用性。
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=falseEureka Server 的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。
服务发现与消费
通过上面的内容介绍与实践，我们已经搭建起微服务架构中的核心组件一服务注册中心(包括单节点模式和高可用模式)。同时，还对上一章中实现的Spring Boot入门程序做了改造。通过简单的配置，使该程序注册到Eureka注册中心上，成为该服务治理体系下的一个服务，命名为hello-service.现在我们已经有了服务注册中心和服务提供者，下面就来尝试构建一个服务消费者，它主要完成两个目标，发现服务以及消费服务。其中，服务发现的任务由Eureka的客户端完成，而服务消费的任务由Ribbon完成。Ribbon 是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。
例子设计如下：
部署 Eureka Server 服务端
依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
引导类：
@SpringBootApplication
@EnableEurekaServer
public class EurekaServer {
public static void main(String[] args) {
SpringApplication.run(EurekaServer.class, args);
}
}
application.yaml 配置文件
server:
port: 8761
eureka:
client:
registerWithEureka: false
fetchRegistry: false
server:
waitTimeInMsWhenSyncEmpty: 0
部署 Eureka Client 客户端：
依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
引导类：
@SpringBootApplication
@EnableDiscoveryClient
public class EurekaClientProviderServer {
public static void main(String[] args) {
new SpringApplicationBuilder(EurekaClientProviderServer.class)
.web(WebApplicationType.SERVLET)
.run(args);
}
}
application.yaml 配置文件：
server:
port: 8081
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:8761/eureka/
spring:
application:
name: eureka-client-provider
Eureka详解
在上面，我们通过一个简单的服务注册与发现示例，构建了Eureka 服务治理体系中的三个核心角色:服务注册中心、服务提供者以及服务消费者。目前，我们已经知道了如何构建服务注册中心(包括单节点和高可用部署)，也知道了如何使用Eureka 的注解和配置将Spring Boot应用纳入Eureka的服务治理体系，成为服务提供者或是服务消费者。同时，对于客户端负载均衡的服务消费也有了一些简单的接触。但是，在实践中，我们的系统结构往往都要比上述示例复杂得多，如果仅仅依靠之前构建的服务治理内容，大多数情况是无法完全直接满足业务系统需求的，我们还需要根据实际情况来做一些配置、调整和扩展。所以我们应该了解一下Eureka的基础架构、节点间的通信机制以及一些进阶的配置等。
基础架构
- 服务注册中心：Eureka提供的服务端，提供服务注册与发现的功能，也就是上面我们所说的
eureka-server
- 服务提供者：提供服务的应用，可以是SpringBoot应用，也可以是其他技术平台且遵循Eureka通信机制的应用。它将自己提供的服务注册到Eureka，以供其他应用发现，也就是上面的HELLO-SERVICE。
- 服务消费者：消费者应用从服务注册中心获取服务列表，从而使消费者可以知道去何处调用其所需要的服务，一般用Ribbon来实现服务消费，另外还有Fegin的消费方式。
其实很多时候，客户端既是服务提供者也是服务消费者。
服务治理机制：
我们进一步了解一下Eureka基础架构中各个元素的一些通信行为，以此来理解基于Eureka实现的服务治理体系是如何运作起来的。以下图为例，其中有这样几个重要元素：
- “服务注册中心-1”和“服务注册中心-2”，它们互相注册组成了高可用集群。
- “服务提供者”启动了两个实例，一个注册到“服务注册中心-1”上，另外一个注册到“服务注册中心-2”上。
- 还有两个“服务消费者”，它们也都分别只指向了一个注册中心。
根据上面的结构，可以详细了解一下，从服务注册开始到服务调用，及各个元素所涉及的一些重要通信行为。
服务提供者
服务注册
“服务提供者”在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server接收到这个REST请求之后，将元数据信息存储在一个双层结构Map中，其中第一层的key是服务名，第二层的key是具体服务的实例名。
在服务注册时，需要确认一下。eureka.client. register-with-eureka-true参数是否正确，该值默认为true。若设置为false将不会启动注册操作。
服务同步
如架构图中所示，这里的两个服务提供者分别注册到了两个不同的服务注册中心上,也就说，它们的信息分别被两个服务注册中心所维护。此时，由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心的任意一台获取到。
服务续约
在注册完服务之后，服务提供者会维护- -个心跳用来持续告诉Eureka Server:“我还活着”，以防止Eureka Server 的“剔除任务”将该服务实例从服务列表中排除出去，我们称该操作为服务续约(Renew)。
关于服务续约有两个重要属性，我们可以关注并根据需要来进行调整:
eureka. instance . lease- renewal-interval-in-seconds参数用于定义服务续约任务的调用间隔时间，默认为30秒。eureka . instance. lease-expiration-duration-in-seconds参数用于定义服务失效的时间，默认为90秒。
服务消费者
获取服务
到这里，在服务注册中心已经注册了一个服务，并且该服务有两个实例。当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server 会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。
获取服务是服务消费者的基础,所以必须确保eureka . client . fetch-registry=true参数没有被修改成false,该值默认为true。若希望修改缓存清单的更新时间，可以通过eureka .client . registry-fetch-interval-seconds=30参数进行修改，该参数默认值为30，单位为秒。
服务调用
服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例，在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
对于访问实例的选择，Eureka中有Region和Zone的概念，一个Region 中可以包含多个Zone,每个服务客户端需要被注册到-一个 Zone中，所以每个客户端对应一个 Region和一个Zone。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方，若访问不到，就访问其他Zone。
服务下线
在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间，我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中，当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心:“我要下线了”。服务端在接收到请求之后，将该服务状态置为下线(DOWN)，并把该下线事件传播出去。
服务注册中心
失效剔除
有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使得服务不能正常工作，而服务注册中心并未收到“服务下线”的请求。为了从服务列表中将这些无法提供服务的实例剔除，Eureka Server 在启动的时候会创建一个定时任务，默认每隔一段时间(默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务剔除出去。
自我保护
当我们在本地调试基于Eureka的程序时，基本上都会碰到这样-一个问题， 在服务注册
中心的信息面板中出现类似下面的红色警告信息:
实际上，该警告就是触发了Eureka Server的自我保护机制。之前我们介绍过，服务注册到Eureka Server之后,会维护一个心跳连接,告诉Eureka Server自己还活着。Eureka Server在运行期间,会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况(在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致)，EurckaServer会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。
由于本地调试很容易触发注册中心的保护机制，这会使得注册中心维护的服务实例不那么准确。所以，我们在本地进行开发的时候，可以使用eureka.server.enable-self-preservation=false参数来关闭保护机制，以确保注册中心可以将不可用的实例正确剔除。