Eureka源码分析
注册中心
1、Register：服务注册
当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等
1.1、服务端注册
会拉取配置的注册中心地址，向附近注册服务注册
1.2、客户端注册
- 客户端第一次续约会失败，因为服务端没有注册，失败后会调register()注册
- Lock read = readWriteLock.readLock(),使用读写ReentrantReadWriteLock
- 服务端注册表：ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
- 注册后会invalidateCache()，使readWriteCacheMap失效
- 注册完之后，会把注册信息同步到其它节点replicateToPeers()
- readWriteCacheMap有自己的过期时间，过期后自动从loader加载新数据
2、Renew：服务续约
Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔
注意：客户端第一次续约会失败，因为服务端没有注册，失败后会调register()注册
3、Cancel：服务下线
Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。
4、Fetch Registries：获取注册列表信息
Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。
4.1、客户端获取注册列表
客户端启动服务会启动一个定时任务CacheRefreshThread()，30秒执行一次CacheRefreshThread.refreshRegistry()，jersey通讯，拉取server端的注册表信息保存到本地注册表中，服务之间的调用依靠本地的注册表，这是设计高可用重要之一，拉取分为首次全量更新、部分更新；
4.2、服务端返回注册列表
1、只读缓存：ConcurrentMap<Key, Value> readOnlyCacheMap，优先从只读缓存拿
2、读写缓存：LoadingCache<Key, Value> readWriteCacheMap，定时180秒会清除，
注册表发生变更的时候：
- 会在内存中更新变更的注册表数据，同时过期掉ReadWriteCacheMap。
- 此过程不会影响ReadOnlyCacheMap提供人家查询注册表。
- 默认每30秒Eureka Server会将ReadWriteCacheMap更新到ReadOnlyCacheMap里
- 默认每180秒Eureka Server会将ReadWriteCacheMap里是数据失效
- 下次有服务拉取注册表，又会从内存中获取最新的数据了，同时填充各级缓存。
多级缓存机制的优点：
- 尽可能保证了内存注册表数据不会出现频繁的读写冲突问题。
- 并且进一步保证对Eureka Server的大量请求，都是快速从纯内存走，性能极高（可以稍微估计下对于一线互联网公司，内部上千个eureka client实例，每分钟对eureka上千次的访问，一天就是上千万次的访问）
5、Eviction 服务剔除
在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除
- 优点：
Eureka保证AP Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，简单方便使用。
- 缺点：
不能保证一致性，eureka consumer本身有缓存，服务状态更新滞后，最常见的状况就是，服务下线了但是服务消费者还未及时感知，此时调用到已下线服务会导致请求失败，只能依靠consumer端的容错机制来保证。
