首页天道酬勤dubbo为什么用zk作为注册中心,dubbo现在还用吗

dubbo为什么用zk作为注册中心,dubbo现在还用吗

张世龙 05-04 00:05 112次浏览

首先,为什么zookeeper不适合服务注册中心呢?

从CAP的角度看

有一种思考。 从CAP的角度来看,服务注册中心是CP系统还是AP系统?

首先,服务注册中心是用于服务间呼叫,绝对不允许服务注册中心出现问题导致的服务间呼叫问题。

注意,假设存在节点1、节点2、节点3和集群节点。 已保存可用服务的列表ip1、ip2、ip3。 如果此时不匹配,例如,如果node1只存储ip1、ip2,而服务此时读取了node1的节点,会产生什么影响?

调用node1的服务是在node1与ip3同步返回后才匹配的,这样负载平衡时ip3不会产生通信量。 这对服务影响不大。

因此,开设服务注册中心应该是APP系统。

zookeeper是一个CP系统,具有很强的一致性。

方案1、主机挂起时,zookeeper集群需要重新选举,那时服务需要读取可用服务,无法使用。 影响了服务的可用性

当然,可以说服务本地有一个缓存可用的列表。 但是,用以下方法无法应对。

场景2,分区可用。 想想有三个机房。 其中机房3和机房1、2的网络断开后,机房3的注册中心不能注册新机器吗? 这显然是不合理的

从体检看

zookeeper通过TCP的心跳来判断服务是否可用

然而,TCP的活性并不意味着服务可用,但TCP活性是否意味着服务可用? 答案显然是否定的。 例如,连接池已满、DB挂起等

理想的注册中心是什么样的呢? 请考虑一下

1、至少服务自动注册、发现。 希望在注册新服务时可以推送到调用方

2 )可以方便地管理注册的设备,手动删除(发送信号使服务优雅脱机),恢复设备

3、服务体检能真正检测服务是否可用

4 )如果更好,可以看到其他呼叫服务是否订阅了注册的服务

5 )如果带着IP以外的信息就更好了

------------- -请参阅

2019. 1.22

过一会儿,我会补充一下想法

ZooKeeper其实比我想象的更有瓶颈,最近遇到了他,他说

1.ZooKeeper写入是不可扩展的,出现了注册节点一定时写入性能成为瓶颈,发布APP应用时会出现排队现象,导致APP应用程序启动非常慢

2.ZooKeeper不支持机房之间的路由。 与eureka不同,它有zone概念,优先考虑本地路由。 本机房路由,本机房出现问题时,可以路由到其他机房

3.ZooKeeper在节点数过多、服务节点发生变更时,需要同时通知设备,产生“惊群效应”,瞬间网卡变满,而且容易重复通知

-------------请参阅

关于Nacos

3359 yq.a liyun.com/articles/604028

请关注我的号码、JVM和微服务

dubbo底层是不是netty,dubbo k8s