Eureka 服务治理机制？

Eureka 服务治理机制？

• 最近读了Spring Cloud 微服务实战 翟永超的书籍对服务治理有所了解，以下是学习笔记。

Eureka服务治理的三个核心要素

1. 服务的注册中心: 提供了服务的注册和发现功能。
2. 服务提供者：提供服务的应用，供其他服务进行调用。
3. 服务消费者：从服务注册中心根据服务名获取服务列表。

下面我们对着三个元素进行细讲其原理。
如下图所示：

Eureka服务治理流程

服务的提供者

服务的提供者保护三个部分，服务的注册，服务的同步，服务的续约

服务的注册

• 首先肯定要先注册到注册中心上去，通过发送REST请求的方式将字节注册到Eureka Server上，同事带上自身服务的一些元数据。Eureka Server接收到这个Rest请求之后，将元数据存在类似一个双层Map（key,value）里面,第一层 key是服务名，第二层key是服务的实例名，为什么会有双层map，因为同一个服务可能集群注册到注册中心。所以有了第二层服务的实例名，第一层value是服务的端口号，第二层value是服务的ip地址（类似这样的）。

服务的同步

在实际的生成环境中，注册中心往往是集群部署的，这个时候就会涉及到服务的同步，同步的前提条件就是：注册中心首先要相互注册，这样当一个服务提供者发起请求到注册中心进行注册，它会将该请求转发给集群相连的其他注册中心，实现了注册中之间的服务同步。

服务的续约

完成注册之后，注册中心就通过心跳机制检查各个服务是否还存活着，如果超过了配置参数定义的是就会将服务移除注册中心。

Eureka:
  instance:
    lease-renewal-interval-in-seconds: 30 # 发ping的时间间隔
    lease-expiration-duration-in-seconds: 90 # 服务的实效时间

服务的消费者

获取服务

• 消费者服务进行消费的的时候会发起一个REST请求到注册中心获取注册到注册中心的服务列表，这个服务列表按照上面配置会30s中更新一次。

服务调用

• 消费者在获取服务清单后，通过服务名获取服务的实例名，和该实例的元数据（ip + 端口等），Eureka底层会通过Ribbon默认采用讯轮的方式进行调用从而实现了客户端的负载均衡。

服务下线

• 我们服务重启或者关闭服务的时候，要主动告诉注册中心。当服务正常关机的时候回发起一个REST请求到注册中心。注册中心收到请求之后就会把服务从注册列表中剔除。

注册中心

实效剔除

• 上面讲了服务的下线是服务正常关闭。当服务非正常关闭（内存溢出，网络故障等）服务不能正常工作，而注册中心没有收到服务下线的请求，这个时候该肿么办呢？注册中心会定时没每隔一段时间（默认是60s）将服务列表超时的服务（90s）没有续约的服务剔除出去。

自我保护

• 之前我们知道服务注册到注册中心之后会维持一个心跳机制，当然心跳也会有失败的时候，这个时候注册中心，会统计失败比例在15分钟之后低于百分之85的，会将当前服务保护起来，当这些服务不会过期。在保护的这个阶段消费者很可能调用了不存在的服务，所以消费者一般都会有容错机制，请求重试，断路器等当然这个自我保护可以通过以下配置进行自行配置。

Eureka:
  server:
    enable-self-preservation: false