dubbo服务预热的bug。希望dubbo官方能改掉。

[aftersss]

com.alibaba.dubbo.rpc.cluster.loadbalance.AbstractLoadBalance类中第46行的代码：
long timestamp = invoker.getUrl().getParameter(Constants.TIMESTAMP_KEY, 0L);
存在bug，这里获取的实际上是consumer端的启动时间，这样没有意义，应该获取服务端的注册时间猜对。
我们遇到了预热问题，调试代码的时候发现了这个bug，目前我们是自定义了一个LoadBalance来解决该问题，由于API没有暴露获取服务端注册时间的接口，所以只能暂时通过反射来获取。
希望官方能解决此问题。

[tinycedar]

只要把consumer端的时间删了即可。
dubbo有太多类似的低级bug， 看起来像是故意不修复的： 比如优雅关闭provider时错误获取线程池。。

[aftersss]

问题是不少，所以我们打算转到spring cloud了

[justein]

这些问题大家可以在确认bug后自行修复的啊，spring cloud就没bug？

[MingningShao]

spring-cloud活跃度比这高呢。有问题可以得到及时反馈呢。

[bigc2000]

@MingningShao
我一直在想，dubbo和spring cloud(netflix)的区别和优缺点，有人总结么？
我没有实际使用过dubbo

1. dubbo直接基于接口api控制，cloud 是服务，因此， 粒度更细，甚至可以做到只对某个接口service（服务A部署实体A1，A2，A3）独立控制，如，禁用A3上的该接口，而对其他接口不禁用。这个应该是很大优势，cloud显然无法处理这些。
   但是，我怀疑，如果基于zk，那么一个结点可能有非常多的watcher，也会有惊群效应，这个性能有没有测试过？
   2.看了dubbo 的admin，好像cloud目前还没有类似的管理模块，都是分散在各个小模块中。

[tinycedar]

@bigc2000
根据我们线上使用dubbo的经验，是会有惊群效应， 我们线上有一个很重要的provider，每次上线都会造成client短时间内多次fullGC，严重影响线上稳定性。 究其原因，还是因为dubbo保存在zk上的service数据设计得很有问题， 太多重复数据导致watcher推送给client太大的数据量。 这个问题就不好解决了，
目前只能把服务拆得更小粒度来规避这个问题。

[zhanghw89]

@tinycedar dubbo的这个provider重启造成的consumer端的服务FullGC目前我们也发现了这个问题，目前是否有解决方法

[jabnih]

这个问题，周三的时候，在QPS较高的情况下，扩容加了一台服务器，直接被压垮了，没法紧急扩容，只能等晚上再处理。这个BUG目前在公司内部分支上修改了，将获取consumer url里面的时间改为provider url里面的时间来处理。

[ralf0131]

@jabnih Could you please send a pull request?

[jabnih]

@ralf0131 fixed on master branch, may be not release. see AbstractLoadBalance use REMOTE_TIMESTAMP_KEY

[ralf0131]

Thanks for reporting, I will close this issue.