首先，那么为什么说zookeeper不适合做服务注册中心呢？
从CAP角度来看
有个思考，从CAP角度考虑，服务注册中心是CP系统还是AP系统呢？
首先，服务注册中心是为了服务间调用服务的，那么绝对不允许因为服务注册中心出现了问题而导致服务间的调用出问题。
再者， 假如有node1,node2,node3,集群节点。 保存着可用服务列表ip1，ip2，ip3，试想如果此时不一致，比如node1只保存了ip1,ip2，此时服务读取node1的节点，那么会造成什么影响？
调用node1的服务，顶多就是负载均衡时不会有流量打到ip3， 然后等 node1同步回ip3后，又一致了，这对服务其实没什么太大影响。
所以，推出服务注册中心应该是个AP系统。
zookeeper是个CP系统，强一致性。
场景1， 当master挂了，此时，zookeeper集群需要重新选举，而此时服务需要来读取可用服务，是不可用的。 影响到了服务的可用性
当然你可以说服务本地有缓存可用列表。然而下面这种方式就更无法处理了。
场景2， 分区可用。试想，有3个机房，如果其中机房3和机房1，2网络断了， 那么机房3的注册中心就不能注册新的机器了么，这显然也不合理
从健康检查来看
zookeeper是通过TCP的心跳判断服务是否可用
但TCP的活性并不代表服务是可用的，但TCP活性就说明服务是可用的么，答案显然是否定的，如： 连接池已经满了，DB挂了等
那么理想的注册中心是什么样的呢，思考下
1， 起码服务的自动注册，发现。 最好有新的服务注册上去时还能推送到调用端
2， 能对注册上来的机器方便的进行管理，能手工剔除（发送信号让服务优雅下线）、恢复机器
3，服务的健康检查，能真正的检测到服务是否可用
4， 如果再好点，可以看到是否有其他调用服务正在订阅注册上来的服务
5，如果能够带上些除了IP外的其它信息，那就更好了
--------------------------------------------------------------
2019. 1.22
一段时间后，补充点想法
ZooKeeper其实比我想象的还要更多瓶颈，最近有遇到说下
1. ZooKeeper写是不可扩展的，当注册节点一定时，写性能会是瓶颈，发布应用时出现排队现象，表现出来的现象就是，应用的启动变得十分缓慢
2. ZooKeeper不支持跨机房的路由，不像eureka，有zone的概念，优先本地路由，当本机房路由，当本机房出现问题时，可以路由到另一个机房
3. ZooKeeper当节点过多时，如果有服务节点变更，需要同时通知机器，会发生“惊群效应”， 瞬间打满网卡，且容易重复通知
----------------------------
关于 Nacos
https://yq.aliyun.com/articles/604028
本文转载自: https://my.oschina.net/u/867417/blog/1865971
原文地址：https://www.cnblogs.com/youyouxiaosheng-lh/p/11209421.html