【Spring Cloud】Eureka 服务治理

---

整体架构

一、服务注册 （30秒）

1、Eureka客户端在启动后，首先会创建一个心跳的定时任务，定时向服务端发送心跳信息，服务端会对客户端心跳做出响应。
2、如果响应状态码为404时，表示服务端没有该客户端的服务信息，那么客户端会通过EurekaHttpClient调用register方法向服务端发送注册请求，注册信息包括服务名、ip、端口、唯一实例ID等信息。
3、当服务端返回状态码204则代表注册成功。

二、服务续约 （30秒）

客户端启动后，就会启动一个定时任务，定时向服务端发送心跳数据，告知服务端自己还活着，默认的心跳时间间隔是30秒。

三、 服务注册表维护

服务端将客户端信息放在一个ConcurrentHashMap对象中。

四、服务列表拉取 （60秒）

• 客户端每隔 60 秒向服务端拉取一次服务列表，并缓存在本地，在使用时，会直接从本地获取。
• 获取的方式有两种，全量获取和增量获取。第一次全量获取，后续增量获取；

五、服务剔除 （90秒）

• 如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)

如果开启了自我保护机制，那么所有的服务，包括长时间没有收到心跳的服务（即已过期的服务）都不会被剔除；

• 在服务剔除时，Eureka服务端并不会直接剔除所有已过期的服务，而是通过随机数的方式进行剔除，避免自我保护开启之前将所有的服务（包括正常的服务）给剔除。

• 客户端主动通知注册中心下线

六、自我保护机制

当有85%的服务不可用时，会认为是网络异常，服务端将不再进行服务剔除，从而确保正常的服务不被误剔除。

自我保护，是eureka重AP的重要体现，其主要目标是保证高可用，短时间的服务列表不可靠（一致性），是可以接受的。

七、集群高可用

• 搭建高可用的Eureka集群，只需要在注册中心的配置文件中配置其他注册中心的地址。
• 注册中心收到注册信息后会判断时客户度发起的信息，还是其他注册中心发起的，如果是客户端注册的信息，那么他将会将该客户端信息同步到其他注册中心去；否则收到信息后不作任何操作。通过此机制避免集群中信息同步的死循环。

八、eureka 和 zookeeper 对比

1、eureka 重AP，zookeeper 重CP
2、由于上述第1点的原因，决定了本质的区别：
zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，期间是不可用的。
eureka各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。

九、几个思考问题

• 当有多个Eureka Server 时，Eureka Client是向谁注册的？
  Eureka Client在发送注册、心跳等请求时，会向Eureka Server集群节点serviceUrlList顺序逐个去尝试，当有一个成功了，就直接返回。最多重试3次。

• 当某台 Eureka Server 宕机时，服务会怎么调用？
  由于Eureka Client 端在发起调用时从本地缓存获取的，如果服务提供方的ip没有改变，Eureka Client 端在期间是能正常调用的。
  如果server_url配置了多个server，那下一次60秒，会从其他server获取服务列表。

• 当某台服务提供方宕机了，服务会怎么调用？
  Eureka Client 之间远程调用是直接调用，在开启了重试策略的情况下，客户端会依据重试策略进行同一个实例的重试，或者按照负载均衡算法重试。