Spring Cloud 之 Eureka 笔记

Eureka包含两个组件：

Eureka服务端：我们也称为服务注册中心。它同其他服务注册中心一样，支持高可用配置。它依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。如果Eureka以集群模式部署，当集群中有分片出现故障时，那么Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中的其他分片会把它们的状态再次同步回来
Eureka客户端：主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中，在应用程序运行时，Eureka客户端向注册中心注册自身提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务状态。

Eureka服务的基础架构与治理机制：

（1）服务注册中心： Eureka 提供的服务端，提供服务注册与发现的功能

失效剔除：有些时候，我们的服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使得服务不能正常工作，而服务注册中心并未收到“服务下线” 的请求。为了从服务列表中将这些无法提供服务的实例剔除， Eureka Server在启动的时候会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
自我保护：服务注册到Eureka Server之后，会维护一个心跳连接，告诉EurekaServer自己还活着。Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%, 如果出现低于的情况（在单机调试的时候很容易满足，实际在生产环境上通常是由于网络不稳定导致）， Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例，会出现调用失败的清况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。

（2）服务提供者：提供服务的应用，可以是Spring Boot 应用，也可以是其他技术平台且遵循Eureka 通信机制的应用。它将自己提供的服务注册到Eureka, 以供其他应用发现

服务注册：“服务提供者” 在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。Eureka Server接收到这个REST请求之后，将元数据信息存储在一个双层结构Map中，其中第一层的ke是服务名，第二层的key是具体服务的实例名。（在服务注册时，需要确认一下eureka.client.register-with-eureka=true参数是否正确，该值默认为true。若设置为false将不会启动注册操作）
服务同步：由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。通过服务同步，服务提供者的服务信息就可以通过这服务注册中心中的任意一台获取到。
服务续约：在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着”，以防止Eureka Server 的“ 剔除任务” 将该服务实例从服务列表中排除出去，我们称该操作为服务续约(Renew)。

（3）服务消费者：消费者应用从服务注册中心获取服务列表，从而使消费者可以知道去何处调用其所需要的服务

获取服务：当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取已注册的服务清单。为了性能考虑， Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。获取服务是服务消费者的基础，所以必须确保eureka.client.fetch-registry=true参数没有被修改成false, 该值默认为true。若希望修改缓存清单的更新时间，可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改，该参数默认值为30, 单位为秒。
服务调用：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例。对于访问实例的选择，Eureka中有Region和Zone的概念，一个Region中可以包含多个Zone, 每个服务客户端需要被注册到一个Zone中，所以每个客户端对应一个Region和一个Zone。在进行服务调用的时候，优先访问同处一个Zone 中的服务提供方，若访问不到，就访问其他的Zone
服务下线：所以在客户端程序中，当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了”。服务端在接收到请求之后，将该服务状态置为下线(DOWN), 并把该下线事件传播出去。

编写Server:

（1）pom引入依赖

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-eureka-server</artifactId>
    </dependency>
	<!-- 指定内置tomcat版本 -->	
    <dependency>
        <groupId>org.apache.tomcat</groupId>
        <artifactId>tomcat-juli</artifactId>
        <version>7.0.27</version>
    </dependency>
 </dependencies>

（2）启动类上加入@EnableEurekaServer注解启动一个服务注册中心提供给其他应用进行对话。

@SpringBootApplication
@EnableEurekaServer
@PropertySource(value = "file:${user.dir}/Config/application.properties")
public class EurekaServerApplication {
	public static void main(String[] args) {
		SpringApplication.run(EurekaServerApplication.class, args);
	}
}

例子中通过添加@PropertySource来加载配置文件（如果没有指定，默认在resources下）。很多人推荐使用YAML文件来配置。但是，YAML 目前还有—些不足，它无法通过@PropertySource 注解来加载配置。但是， YAML 将属性加载到内存中保存的时候是有序的，所以当配置文件中的信息需要具备顺序含义时， YAML 的配置方式比起properties 配置文件更有优势。

（3）编写applicationo.properties

spring.application.name=eureka-server
server.port=8761
eureka.client.registerWithEureka=false
eureka.client.fetchRegistry=false
eureka.client.serviceUrl.defaultZone=http://localhost:8762/eureka

eueka.client.registerWithEureka：表示是否将自己注册到Eureka Server。由于自己就是Eureka Server，所以这里填写false。默认为true

eueka.client.fetchRegistry：表示是否从Eureka Server获取注册信息。

在微服务架构这样的分布式环境中，我们需要充分考虑发生故障的情况，所以在生产环境中必须对各个组件进行高可用部署，对于微服务如此，对于服务注册中心也一样。

Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。

eureka.client.serviceUrl.defaultZone：自己作为服务向其他服务注册中心注册自己（可配置多个，逗号分隔）

Spring Cloud 之 Eureka 笔记

猜你喜欢