标签：dubbo 服务 可用 zookeeper Nacos 机房 注册 node1
首先，那么为什么说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外的其它信息，那就更好了
ZooKeeper其实比我想象的还要更多瓶颈，最近有遇到说下
1. ZooKeeper写是不可扩展的，当注册节点一定时，写性能会是瓶颈，发布应用时出现排队现象，表现出来的现象就是，应用的启动变得十分缓慢
2. ZooKeeper不支持跨机房的路由，不像eureka，有zone的概念，优先本地路由，当本机房路由，当本机房出现问题时，可以路由到另一个机房
3. ZooKeeper当节点过多时，如果有服务节点变更，需要同时通知机器，会发生“惊群效应”， 瞬间打满网卡，且容易重复通知
hu2010shuai
发布了8 篇原创文章 · 获赞 10 · 访问量 12万+
私信
关注
标签：dubbo,服务,可用,zookeeper,Nacos,机房,注册,node1 来源： https://blog.csdn.net/hu2010shuai/article/details/104064366
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。