Eureka, Client, Ribbon之间的缓存和服务实时上下线实现思路分析

在使用Eureka做注册中心时，我平时遇到的最不爽问题，就是无法做到实时上下线。比如，我服务已经正常下线了，为什么上游还能调通？我服务已经上线了，为什么还有等"很久"才能真正被其他服务所"发现"？其实这些都是从Eureka到Client再到Ribbion这条链路中的逐级缓存造成的。

Eureka为什么要使用缓存

比如，对于Eureka来说，Eureka Client获取注册更新信息时，Eureka Server返回的数据其实是从一个默认每30s才更新的缓存获取的。也就是说，如果你服务下了一个，即使client是在服务下线之后发请求查询的注册列表，那这次请求也不会包括服务下线的信息。那么Eureka为什么要搞cache而不是实时的返回注册信息呢？我个人推测了一下，应该是为了在访问注册数据结构时尽量少加锁，从而提升单次请求时的性能。如果没有这层cache, 那么对于服务注册表这个数据结构来说，就会存在并发读写的情况，那就避免不了加锁保护。如果有cache, 是可以做到完全不加锁的。想一下，对于微服务架构来说，特点就是每个服务较轻，但服务数量较多。如果每个服务都定时请求eureka更新注册信息的话，对于Eureka Server来说，确实是可能会造成严重的锁竞争的。除了这个responseCache外，Eureka对于无心跳服务的清理也是默认每60s执行一次的，也就是说对于异常下线的服务(没有主动取消注册，而是中断了心跳)，在Eureka Server端最大会有长达 60s + 30s * 3 = 150s的延迟。这里的30s * 3 是3个心跳的周期。