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

首先，为什么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和微服务