SpringCloud解析之Eureka

本文基于Spring Cloud Edgware.SR6版本，从功能和架构上解析Eureka，让你们对Eureka有一个较为清晰的认识（本文默认你们对分布式微服务有一个初步的概念和理解，本文不涉及或少许涉及源码）。

官方概念这里就不贴了，我的理解，Eureka是Spring Cloud分布式微服务架构的服务治理方案之一，提供服务注册，服务发现，服务维护和治理，注册中心集群等功能。

Eureka中维护一份服务列表，当客户端（服务提供者或服务消费者）注册服务实例到Eureka，Eureka会将其实例信息维护到列表中，这叫建立租约；租约的有效时间默认是30秒，客户端须要每隔一段时间发送一次心跳告知Eureka本身的服务正常有效，这叫续约。

Eureka是服务注册中心，但当注册中心集群时，Eureka也作为客户端，向其它注册中心注册本身，同时获取其它注册中心的维护的服务列表，当有新的客户端注册进来时，Eureka会通知其它的注册中心，异步更新服务列表，达到高可用的目的。Eureka默认会开启以下配置，若是做为单个注册中心或本地测试，能够关闭。

eureka:
  client:
#   不向Eureka注册本身
    registerWithEureka: false
#     不获取服务列表
    fetchRegistry: false

客户端正常下线时，会通知Eureka，Eureka就从服务列表中将其剔除。若是客户端非正常下线（好比宕机，系统崩溃）没法通知到Eureka，Eureka会定时检查本身的服务列表，发现有服务的租约超过有效时间，也会认为服务失效而剔除。

Eureka默认配置会开启一个保护机制，当一段时间内有超过15%的服务失效时，Eureka不会剔除这些服务，而是继续维护在服务列表，直到客户端从新发送心跳。Eureka有一个心跳次数阀值系数=0.85（能够经过配置修改），客户端默认心跳间隔=30秒，1分钟内总心跳数=客户端实例数*2，1分钟心里跳阀值=1分钟内总心跳数*0.85，当1分钟内有效客户端实例的心跳总数<心跳阀值，Eureka就会由于保护机制而继续维护在服务列表，所以客户端须要有重试和熔断机制。

Eureka和ZooKeeper

Eureka和ZooKeeper，虽然都是服务集群治理的实现方案，可是区别也是比较明显的。CAP理论中，C(consistency)数据一致性，A(availability)可用性，P(partition-tolerance)分区容错性，Eureka强调AP，经过缓存和异步同步达到最终一致性，ZooKeeper更兼顾CP，当节点失效就会剔除。

我的更倾向Eureka，无论是服务注册和发现，仍是注册中心集群，只须要引入依赖包，添加配置和注解，就能够达到效果，同时不得不佩服Spring Boot和Spring Cloud的强大。可是，若是是ZooKeeper转使用Eureka，可能会由于其内部的缓存和保护机制感到别扭，此处贴上本人的配置，能够减小缓存时效，提升缓存刷新频率，强制关闭客户端的话，大概30秒Eureka就会剔除服务（Eureka默认状况下大概要4分钟才会剔除服务），供你们参考

Eureka注册中心配置（YML）

eureka:
  server:
#     检查失效服务剔除时间间隔
    evictionIntervalTimerInMs: 2000
#   关闭保护机制
    enableSelfPreservation: false

Eureka客户端（properties）

#服务实例租约有效时间
eureka.instance.lease-expiration-duration-in-seconds=15
#服务实例续约间隔时间（心跳间隔）
eureka.instance.lease-renewal-interval-in-seconds=5
#客户端更新服务列表间隔时间
eureka.client.registryFetchIntervalSeconds=5