eureka原理

1、eureka架构图

服务提供者向注册中心注册服务实例信息（服务名称、ip、端口号等），服务消费者拉取服务提供者列表，服务消费者根据服务提供者列表通过负载均衡算法选取服务并发起远程调用（jersey框架封装的http）。

2、eureka原理

• 服务注册
  eureka client 启动过程中会向eureka server 发送服务注册的http请求，server 端会通过本地注册表registry存储注册实例信息。
• 服务续约
  eureka client 每隔30s发送心跳检查的http请求到eureka server
• 服务剔除（服务驱逐）
  server端每隔60s检测注册表中注册实例是否续约正常，如果续约心跳时间超过90s则将服务状态更新为DOWN。
• 服务更新
  eureka client 每隔30s检测实例信息是否变更（实例状态、ip地址），如果变更则会发送注册请求到eureka server。
• 服务下线
  eureka client 进程正常关闭则会发送服务下线请求到eureka server ，server 端则会删除服务注册列表。
• 本地缓存更新
  eureka client 启动过程中全量拉取注册表至本地缓存，每隔30s 增量拉取注册信息及注册表hash值，然后合并到本地注册表信息并计算本地hash值，如果本地hash值和服务端注册表hash值不一致，则会全量拉取注册表。
• 自我保护机制
  eureka server 默认开启自我保护机制。eureka server 统计15分钟内心跳正常的比例是是否低于85%，如果低于85%则不会剔除心跳超时的服务。
  目的：在微服务系统出现网络分区故障时，微服务实例本身是正常运行的。自我保护机制为了防止微服务实例心跳续约超时剔除微服务，防止误杀服务 （宁可放过一个不可错杀一千）。
• eureka server三级缓存
  1、一级缓存：ConcurrentHashMap<String, Map<String, Lease>> registry
  实时更新，又名注册表，UI界面从这里获取服务注册信息。
  第一层key是AppName(应用名称)，value是应用对应的实例map。
  第二层key是实例id,value是实例信息。
  2、二级缓存：LoadingCache<Key, Value> readWriteCacheMap
  3、三级缓存：ConcurrentMap<Key, Value> readOnlyCacheMap
  Eureka Client默认从这里获取服务注册信息，可配为直接从readWriteCacheMap获取。
  多级缓存目的：为了防止写操作不阻塞读操作以及提高读写性能；mysql 读写分离是为了分担主库的读压力。
  在写的时候，线程会持有ConcurrentHashmap相应Hash桶节点对象的锁，阻塞同一个Hash桶的其他读线程。
  这样可以有效的降低读写并发，避免读写争抢资源所带来的压力。
  4、缓存更新：一级缓存readOnlyCacheMap每隔30s从二级缓存readWriteCacheMap拉取数据更新到自己的缓存，只更新三级缓存已存在key对应的value；服务注册、服务续约、服务下线、服务剔除都会更新到一级缓存registry并清空二级缓存。
• 服务发现
  Eureka Client客户端获取注册列表：
  1、如果使用只读缓存（三级缓存）<默认使用>，则先从只读缓存中获取；如果获取不到，则从读写缓存（二级缓存）中获取，并将数据缓存到只读缓存；
  2、不使用只读缓存，则直接从读写缓存中获取；
  如果读写缓存获取不到则触发读写缓存中guava的回调函数从注册表registry中同步数据（即从一级缓存 – 注册表registry中取）
• eureka server集群原理
  eureka client 注册、续约、状态变更、下线发送请求到eureka server,eureka server 更新本地注册表信息后同步复制信息到集群临节点流程，集群临节点收到复制信息后更新本地注册表不会再次同步复制信息到其临节点。
  eureka server 通过将实例复制信息交给任务分发器TaskDispatchers异步处理,任务分发器具有任务执行失败后重新投递任务到队列中的功能。
  eureka server 只有在接收集群批量复制请求时isReplication=true（不执行集群复制逻辑）,其他场景（eureka client 注册、续约、状态变更等）isReplication=false才执行集群复制到临节点的逻辑。
  场景: clientA、serverA、serverB、serverC。clientA注册到serverA，serverA临节点是serverB，serverB临节点是serverC。
  此场景serverA、serverB有clientA注册信息，serverC没有clientA注册信息。
  eureka server 集群配置需要配置集群非自己节点的所有节点地址信息，这样可以保证任一节点的注册信息变更都可以通过集群复制功能同步到集群所有节点。
  eureka server 和zookeeper区别
  eureka server 满足CAP中的PA。eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，Eureka的客户端在向某个Eureka服务端注册时如果发现链接失败，则自动切换到其他节点，只要有一台Eureka活着，就能保证服务可用，只不过查询到的信息可能不是最新的（不保证一致性）
  zk满足CAP中的PC。当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，问题在于，选择leader的时间太长，30-120s,且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用。