These are chat archives for alibaba/dubbo

19th
Oct 2017
FX.li
@shanyepifu
Oct 19 2017 02:41
有没有考虑过把文档拿出来, 不要放到gitbook上,毕竟国内用户比较多。
等gitbook 可以访问了一定要, 拷贝一份离线文档
maroon
@DocEcho
Oct 19 2017 04:01
请教个问题,
当 服务提供者 下线了,正常情况下,消费者端 会收到 来自 zookeeper 的服务通知,
但是 如果 zookeeper 没有通知到 消费者,那岂不是 就出 生产事故了吗?
大家 有遇到这种情况的吗?
Zhaohui Yu
@yuyijq
Oct 19 2017 05:10
不会因为这个就会出现生产事故的
maroon
@DocEcho
Oct 19 2017 05:11
@yuyijq 提供者下线了,消费者去调已经死了的服务,不就报错了么?
Zhaohui Yu
@yuyijq
Oct 19 2017 05:12
首先提供者下线了,dubbo的连接断开,consumer也是能收到通知的
会标记这个连接不可用,负载均衡也不会调用到这个provider上
Xin Wang
@lovepoem
Oct 19 2017 05:12
dubbo用zk做的服务发现,就会把这个服务去掉。如果没有去掉,就是dubbo和zk的问题了
Zhaohui Yu
@yuyijq
Oct 19 2017 05:13
他说的这种情况是存在的
zk的watcher没有高可靠保证的
maroon
@DocEcho
Oct 19 2017 05:13
你是说 消费者端 和 提供者端 有心跳机制?
消费者端 自发现 提供者端 不可用之后,就不会去调了?
Zhaohui Yu
@yuyijq
Oct 19 2017 05:14
watcher是可能会丢失的,比如provider下线,临时节点删除,然后zk通知consumer,这个时候zk与consumer之间的网络发生瞬断,这个时候watcher是可能会丢的
另外,一个健壮的服务体系,不会因为几次调用失败就会出生产事故
这个也是要业务从架构上来考量的
比如我可以重试
maroon
@DocEcho
Oct 19 2017 05:15
不是 幂等的接口,重试风险更大吧?
Xin Wang
@lovepoem
Oct 19 2017 05:15
嗯 多次调用同一个服务超时,应该有告警的。
Zhaohui Yu
@yuyijq
Oct 19 2017 05:15
我们一般要求所有服务都必须是幂等的
幂等是一个很重要的原则
maroon
@DocEcho
Oct 19 2017 05:18

@yuyijq @yuyijq
首先提供者下线了,dubbo的连接断开,consumer也是能收到通知的
会标记这个连接不可用,负载均衡也不会调用到这个provider上

这块,有空能帮忙看看 是哪个 类实现的吗?

Zhaohui Yu
@yuyijq
Oct 19 2017 05:21
Invoker上有个isAvailable方法,这个就是判断这个是不是可用的
很多地方都对这个进行了判断
maroon
@DocEcho
Oct 19 2017 05:25
@yuyijq 感谢
Zhaohui Yu
@yuyijq
Oct 19 2017 05:51
@chickenlj alibaba/dubbo#595 这个pull request你关闭了,我后来回复了,是有问题的,麻烦再review一下
ken.lj
@chickenlj
Oct 19 2017 08:01
@yuyijq 单纯改这个方法也是有问题的,WebServiceProtocol中的地址是不包含group
version的。我觉得可以再加一个包含group version的方法
mwy001
@mwy001
Oct 19 2017 10:19
请问, 在docker中运行dubbo / providers,zookeeper作为注册中心,如何让zookeeper中保存的providers ip地址为docker host的地址?有没有可用的方案?
peng.lu
@lpe234
Oct 19 2017 16:59
哈哈 这么晚了还有人吗 😀