apache
dubbo.provider.delay 配置 1 秒结果 30 秒后才注册到注册中心
- [x] I have searched the issues of this repository and believe that this is not a duplicate.
Environment
- Dubbo version: 3.1.0
- Java version: 1.8.0
Steps to reproduce this issue
- 在 Dubbo Provider 端配置
dubbo.provider.delay = 1000并启动服务 - 启动过程中会发现日志
[DUBBO] No valid instance found, stop registering instance address to registry. - 启动后马上到 zookeeper 中查看 /services/xxxService/ 下，会发现并没有刚启动的这台实例的 IP
- 30s 后 zookeeper 上会出现实例 IP
问题原因
AbstractServiceDiscovery#register() 在注册到注册中心时，会发现找不到元数据信息，从而报出 No valid instance 警告:
而 30s 后则由 Dubbo 定时线程同步 Metadata 时发现并上报到注册中心的。
怀疑是应用级注册功能，并没有实现 dubbo.provider.delay 延迟暴露功能，反而会有冲突，导致实际上 30s 后才暴露。在线上这会。导致旧 Pod 已经下线，新 Pod 还没有注册上去，出现数秒到十数秒 No Provider 问题。
由于需要对数据更新数据进行压制，防止应用级实例信息频繁更改对元数据中心、注册中心带来特别大的压力，应用级数据需要使用定期刷新的机制。 这一块可以在 Dubbo QoS 加个命令执行强制刷新数据到注册中心的行为（目前未支持，可以帮忙提交下），然后部署的时候通过 post 脚本去触发。
Can I have a try it? Please assigned it to me.
方案：
- 是否可以直接通过在第一次启动服务时，直接强制刷新到注册中心？
是否可以通过定时任务来实现延迟注册？
这个issue的核心问题不是延迟注册本身导致的，是应用级服务发现的注册周期就是 30s，导致没有及时刷新到注册中心
- 是否可以直接通过在第一次启动服务时，直接强制刷新到注册中心？
两个方式，一个是提供 API 让用户强制刷新；一个是在 delay 结束后框架侧执行强制刷新。
再引申一些，是不是在 Dubbo 启动结束后我们不需要 30s 的 delay，或者是这个 delay 可以缩小到 1s 这种短周期。设计注册 delay 的原因是因为大批量服务发布的时候避免重复注册太多次。
- 是否可以直接通过在第一次启动服务时，直接强制刷新到注册中心？
两个方式，一个是提供 API 让用户强制刷新；一个是在 delay 结束后框架侧执行强制刷新。
使用delay的用户一般只希望控制刚启动的时候的时间，所以比较推荐delay 结束后框架侧执行强制刷新，之后的元数据则通过原有的应用级别30s周期来进行。
