在使用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个心跳的周期。