AsperforMias commented on issue #3615: URL: https://github.com/apache/dubbo-go/issues/3615#issuecomment-5226221692
我下面会给一套复现步骤，实际上这个bug非常的古老（）它的达成时间条件也比较苛刻。首先的话，我们知道在dubbogo里，「Provider 每重启一次，哪怕接口一行没改，revision 也必变。这意味着重启后 Consumer 手里的旧缓存必然失效，必须重新向 Provider 拉一次元数据」这个"必须拉一次"的时刻，就是问题所在。 因为在很早的设计之初，consumer并没有一个说 它去有定时任务触发/指数退避的形式，去轮询nacos注册中心，而是只有等到provider组成的实例列表变化/provider上下线，以此导致revision变化，这时候 nacos这边才会回调consumer的listener，然后去从 metadata service里拿新的rpc list并存入缓存 但实际上，我觉得这是一种有些风险的设计（ 可能需要 @Alanxtl 老师思考下这个问题 比如现在有个场景， 拉metadata失败了，此时listener跳过这个实例（我假设这个微服务同时3个实例，比如xxx.1 ,xxx.2, xxx.3），由于实际prod里，我们往往一个微服务基本不可能只部署一个服务实例/pod上，我们可能要做水平拓展来面对负载均衡和做故障转移，这时候比如说我 xxx.1 这个服务实例/pod由于网络的抖动 它超时丢包了，那就会被跳过。但由于在 xxx2和xxx3上拉metadata还是正常的，因此在xxx2中，revision存入缓存后，后续的xxx3发现有了，revision hash没问题，那就直接复用这个revision拉下来的rpc清单，不用新拉。因此，这个服务的任意一个服务实例正常，那整体就正常 那现在问题来了，如果我很懒，我既用了微服务，但又不想一个服务部署多实例呢，我只起了一个。 那当这个服务实例首次拉metadata失败，我假设它丢包超时了，那此时它被跳过，然后得到「本次provider暴露的url list是空的」，覆盖进入provider directory。这里没有因为是单实例而特别关照，没有抛err，没有重试，没有定时队列。然后现在这时候因为是空的，nacos sdk发现实例列表永远不变，那就不会触发listener重拉。 至此，左脚踩右脚，闭环（（ 一旦发生，prod上就要重启这个consumer，或者重启provider让revision变化触发新推送，nacos console，只要能让nacos实例变化就能解决，但由于这个A比较懒，他不想provider重启也不重启consumer也不想上新实例刷新下，那就完蛋了（） 因此，这是个很苛刻的条件。一般不会发生。话说真的有用户会用了微服务但是一个consumer服务只起一个实例，然后provider一直不动吗（） -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
