注册中心系列一：Eureka的接入与使用

一、Eureka原理介绍

从组件功能看：

• 黄色注册中心集群，分别部署在北京、天津、青岛机房；
• 红色服务提供者，分别部署北京和青岛机房；
• 淡绿色服务消费者，分别部署在北京和天津机房；

从机房分布看：

• 北京机房部署了注册中心、服务提供者和服务消费者；
• 天津机房部署了注册中心和服务消费者；
• 青岛机房部署了注册中心和服务提供者；

组件调用关系
服务提供者
启动后，向注册中心发起register请求，注册服务
在运行过程中，定时向注册中心发送renew心跳，证明“我还活着”。
停止服务提供者，向注册中心发起cancel请求，清空当前服务注册信息。

服务消费者
启动后，从注册中心拉取服务注册信息
在运行过程中，定时更新服务注册信息。

服务消费者发起远程调用：
服务消费者（北京）会从服务注册信息中选择同机房的服务提供者（北京），发起远程调用。只有同机房的服务提供者挂了才会选择其他机房的服务提供者（青岛）。
服务消费者（天津）因为同机房内没有服务提供者，则会按负载均衡算法选择北京或青岛的服务提供者，发起远程调用。

注册中心
启动后，从其他节点拉取服务注册信息。
运行过程中，定时运行evict任务，剔除没有按时renew的服务（包括非正常停止和网络故障的服务）。
运行过程中，接收到的register、renew、cancel请求，都会同步至其他注册中心节点。

二、使用

1.依赖引入

服务端

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

客户端

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2.配置文件

在 Eureka 实现服务注册与发现时一共涉及了 3 个角色：服务注册中心、服务提供者以及服务消费者，这三个角色分工明确，各司其职。但是其实在 Eureka 中，所有服务都既是服务消费者也是服务提供者，服务注册中心 Eureka Server 也不例外。

在搭建集群版的注册中心的时候，每一个注册中心的application.yml中有如下类似的配置，将自己注册到其他机器上

服务端配置

server:
  port: 7001  #端口号

eureka:
  instance:
    hostname: eureka7001.com #eureka服务端的实例名称

  client:
    register-with-eureka: false #false 表示不向注册中心注册自己。
    fetch-registry: false #false 表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url:
      #defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #单机版
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ 
      #集群版 将当前的 Eureka Server 注册到 7003 和 7003 上，形成一组互相注册的 Eureka Server 集群

客户端配置

eureka:
  client: #将客户端注册到 eureka 服务列表内
    service-url:
      #defaultZone: http://eureka7001.com:7001/eureka  
      #这个地址是 7001 注册中心在 application.yml 中暴露出来的注册地址 （单机版）
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/  
      #将服务注册到 Eureka Server 集群

三、自我保护机制

所谓 “Eureka 的自我保护机制”，其中心思想就是“好死不如赖活着”。如果 Eureka Server 在一段时间内没有接收到 Eureka Client 的心跳，那么 Eureka Server 就会开启自我保护模式，将所有的 Eureka Client 的注册信息保护起来，而不是直接从服务注册表中移除。一旦网络恢复，这些 Eureka Client 提供的服务还可以继续被服务消费者消费。

这里的一段时间指的是：Eureka Server在运行期间，会统计心跳失败的比例在15分钟内是否低于85%，如果低于85%，Eureka Server则任务是网络故障，不会删除心跳过期服务

优点：它的架构哲学是：宁可同时保留所有微服务（健康的服务和不健康的服务都会保留）也不盲目移除任何健康的服务。通过 Eureka 的自我保护机制，可以让 Eureka Server 集群更加的健壮、稳定。

弊端：如果在 Eureka 自我保护机制触发期间，服务提供者提供的服务出现问题，那么服务消费者就很容易获取到已经不存在的服务进而出现调用失败的情况

eureka:
  server:
    enable-self-preservation: false # false 关闭 Eureka 的自我保护机制，默认是开启,一般不建议大家修改

优雅停服

在Spring Cloud中，可以通过HTTP请求的方式，通知Eureka Client优雅停服，这个请求一旦发送到Eureka Client，那么Eureka Client会发送一个shutdown请求到Eureka Server，Eureka Server接收到这个shutdown请求后，会在服务列表中标记这个服务的状态为down，同时Eureka Client应用自动关闭。这个过程就是优雅停服。如果使用了优雅停服，则不需要再关闭Eureka Server的服务保护模式。

1、POM依赖：

优雅停服是通过Eureka Client发起的，所以需要在Eureka Client中增加新的依赖，这个依赖是autuator组件，添加下述依赖即可。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-actuator</artifactId>
</dependency>

2、修改全局配置文件：

Eureka Client默认不开启优雅停服功能，需要在全局配置文件中新增如下内容：

endpoints.shutdown.enabled=true  # 启用shutdown，优雅停服功能
endpoints.shutdown.sensitive=false  # 禁用密码验证

3、发起shutdown请求：

必须通过POST请求向Eureka Client发起一个shutdown请求。请求路径为：http://ip:port/shutdown。可以通过任意技术实现，如：HTTPClient、form表单，AJAX等。建议使用优雅停服方式来关闭Application Service/Application Client服务

四、多级缓存机制

Eureka Server为了避免同时读写内存数据结构造成的并发冲突问题，还采用了多级缓存机制来进一步提升服务请求的响应速度

优点：

• 1.尽可能保证了内存注册表数据不会出现频繁的读写冲突问题。

• 2.保证对Eureka Server的大量请求，都是快速从纯内存走，性能极高。