杨翊 SionYang

`restart nacos server` is restart one node or restart whole cluster?

1. I think do check should be in Cleaner. 2. How to queryInstance? if use ServiceStorage, it is a cache which might update with a little delay. If query by...

> > How to queryInstance? if use ServiceStorage, it is a cache which might update with a little delay. If query by traversing, whether cause performance problem? > > I...

主要得看一下深层原因，为什么连接的会慢吧。

> 对于状态的判断应该要是一个同步操作，如果RpcClient在timeout时间都没成功建立连接才抛出异常，而不是直接判断status ！= running就抛出异常。 这个不行的， 那就变成应用强制依赖nacos稳定性和网络稳定性， 这样就完全失去了可用性和容灾能力。 实际上nacos-client在连不上服务端的时候，是可以通过snapshot返回配置的， 不会因为nacos挂了阻塞业务启动。实在不行还有failover可以不阻塞业务启动。 但是如果client连不上就抛异常，那意味着用户如果不自己捕获异常处理，然后走下去，就必然阻塞业务。

应该是可以优化的， 我记得java client就优化过， 首次连接未成功前，会阻塞一次，如果首次连接超过重试次数未成功，结束阻塞，让应用逻辑走下去。代价就是如果连接不畅的话， 可能启动会慢几秒。

应该和版本没什么关系， 感觉是应用有问题，没有进行连接。

看报错是鉴权失败，Invalid signature， 我看了下应该是默认鉴权插件校验的请求中的token中有一部分内容和server中预期的token不对应，所以报错了。

可以研究一下这部分token校验和生成是否有改动过逻辑， 鉴权插件社区中会因为优化和安全问题经常更新或添加新优化， 可能老版本没有校验token的这部分内容或者校验方式错误导致旧版本可以复用旧的错误token。 也可能是新版本改动导致了token校验错误。

是说新版本和旧版本的base64计算方式不同吗？