Eureka原理

Eureka高级架构

每一个地区对应一个region，zone 相当于机房

Eureka的服务治理流程

1、客户端启动时会向Eureka server发送注册请求；
2、当注册成功后客户端会每30秒定时通过提供的http api请求一次Eureka server端获取服务列表，第一次是全量，后面都是增量，然后缓存到本地；
3、若Eureka server端超过90秒没有收到服务客户端的请求，那么就会从服务列表中将这个服务给剔除；

Eureka 重要概念

• 服务注册（Register）
  服务启动时向Eureka server注册自己的服务信息，比如ip、port等；
  注意：服务的注册和剔除并不会通知客户端，只能等客户端自己定时去同步（30s请求同步一次）
• 服务续约（Renew，或许说是心跳检测）
  服务注册之后会周期性的向Eureka server发送心跳，表明服务是活跃的；
• 服务发现（Fetch Registers）
  服务消费者通过Eureka client向Eureka server查询可用服务，并获得服务的信息；
• 服务剔除（Eviction）
  如果客户端一定时间内没有发送心跳给Eureka server端，那么Eureka server端就会从服务列表剔除；
• 服务下线（Cancel）

Eureka 高可用架构（ap架构）

服务启动后向Eureka注册并立即响应，后续Eureka Server异步将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

正是因为本地缓存的设计才保证了eureka的高可用；

集群节点之间的数据同步通过广播的方式达到数据的最终一致性，有点像gossip算法；

Eureka server端的缓存架构

为了解决服务列表的读写冲突，Eureka采用多次缓存架构：
服务注册时，Eureka server端会将服务实例更新到注册列表缓存（registry）和读写缓存（readWriteCacheMap）中，然后每隔30秒将数据更新到只读缓存（readOnlyCacheMap）中；
客户端从Eureka server 端获取服务列表时，直接从读缓存（readOnlyCacheMap）中获取；

• registry缓存
  实时更新，ui界面直接读取这个缓存，并且服务的注册和下线都是操作这个缓存；
• readWriteCacheMap
  读写缓存，每次新的服务注册上来之后会清空这个缓存，客户端从readOnlyCacheMap中获取不到数据之后会从这里获取，如果这里也获取不到会从registry中加载进readWriteCacheMap并返回给客户端；

registry缓存的每次更新（新服务的注册，旧服务的剔除下线）都会清空readWriteCacheMap缓存，从而实现数据的一致性；
该缓存有过期时间180s

• readOnlyCacheMap
  客户端端从这里获取数据，每隔30s会从readWriteCacheMap缓存中同步数据；

Eureka的自我保护机制

当因为网络原因导致大部分服务被剔出时，如果剔除的服务达到了Eureka的阈值，那么就会触发Eureka的自我保护机制，从而不会再剔除任何服务；