[apache/dubbo]dubbo.provider.delay 配置 1 秒结果 30 秒后才注册到注册中心

Environment

在 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 问题。

liuzhiguo630

由于需要对数据更新数据进行压制，防止应用级实例信息频繁更改对元数据中心、注册中心带来特别大的压力，应用级数据需要使用定期刷新的机制。这一块可以在 Dubbo QoS 加个命令执行强制刷新数据到注册中心的行为（目前未支持，可以帮忙提交下），然后部署的时候通过 post 脚本去触发。

AlbumenJ

是否可以通过定时任务来实现延迟注册？

carlos-ho

Can I have a try it? Please assigned it to me.

方案：

azhsmesos

是否可以通过定时任务来实现延迟注册？

这个issue的核心问题不是延迟注册本身导致的，是应用级服务发现的注册周期就是 30s，导致没有及时刷新到注册中心

AlbumenJ

两个方式，一个是提供 API 让用户强制刷新；一个是在 delay 结束后框架侧执行强制刷新。

AlbumenJ

再引申一些，是不是在 Dubbo 启动结束后我们不需要 30s 的 delay，或者是这个 delay 可以缩小到 1s 这种短周期。设计注册 delay 的原因是因为大批量服务发布的时候避免重复注册太多次。

AlbumenJ

使用delay的用户一般只希望控制刚启动的时候的时间，所以比较推荐delay 结束后框架侧执行强制刷新，之后的元数据则通过原有的应用级别30s周期来进行。

CrazyHZM

AlbumenJ

你好，可以assigned给我吗？想尝试解决一下～

WeiXiao-Hyy

3.2.0 中已经将检测周期缩短到 1s

AlbumenJ

回答