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

Eureka Client的缓存

Eureka Client默认会对注册信息做30s缓存 ，这个很好理解 ，因为我们当然不希望每次RPC都要重新查一次注册表，这是很浪费的。 这是常规操作，无可厚非。

Ribbon的缓存

这就有点诡异了。Ribbon向上对接Eureka Client, 向下对接实现发起HTTP请求的客户端。ribbon自身也是有30s缓存的，即ribbon会每30s向Eureka Client那里索要注册信息，注意是Eureka Client而不是Eureka Server，这样就更加剧了整个系统对服务上下线感知的延迟。我认为Ribbon这样设计，原因是考虑到了其上游不仅仅是Eureka Client, 还可能是配置文件，或者以编程的方式输入的注册列表，而这些查询是有可能比较耗时的。Ribbon为了兼容这些情况，不得不添加了缓存。

实时上下线思路

只能用消息中间件了。新做一个上下线管理服务，提供HTTP接口来上下线指定服务，当指定要下线A服务时，先向Eureka发请求，将此服务下所有的实例都删掉，然后再向kafka类似这样的消息系统中发一条消息，所有的微服务都要监听此消息队列。
服务收到下线消息时，将指定服务从本地Ribbon服务列表中删除。这里Ribbon的 Loadbalancer提供了markServerDown()方法可以使用，还是容易实现的。
服务收到上线消息时，需要将服务信息添加到Ribbon中，Ribbon虽然也提供了对应的方法，但是参数较为复杂，还需要研究一下。
这些功能可以直接打包成starter, 写好以后各服务直接引用即可。

其实我更希望Eureka官方能出一套解决实时性的方案，然并卵，Eureka已经不维护了