[apache/dubbo]dubbo服务预热的bug。希望dubbo官方能改掉。

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

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

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

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

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

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

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

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

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