无法加入nacos服务列表_Nacos注册中心落地实践

前言

公司在19年开始推进同城双活架构,未来规划是在南汇机房出现故障时能把所有读流量切到宝山机房,这样至少保证读请求是没问题的;我们的微服务使用的zookeeper来做服务发现, zk由于它的强一致性模型不适合多机房部署, 由于zk的服务发现模型是基于会话机制创建的临时节点, 就算两个机房各部署一套zk, 再部署一个sync服务两边同步,也会因为跨机房网络不稳定导致连接断开, zk会因此一开始就没有考虑继续用zk作为下一代服务发现的注册中心.

zk基于ZAB协议实现了强一致性,在出现网络分区时有可能因集群无法选出Leader导致服务不可用, 这时候不可以新部署，重新启动，扩容或者缩容,这对于服务发现场景来讲是不能接受的, 在实践中，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性, 数据的短期不一致对客户端来说就是多一个或者少一个节点,对于业务层面完全是可以接受的, 因此注册中心在设计时应偏向AP架构.

背景故事

我刚入职的时候便接手了一个任务:把zk注册中心替换成consul,因为网上的介绍都说consul是AP架构, 而且consul在生产环境已经完全落地, 运维已经用了consul来做物理机的发现和监控, 因此当时的做法就是研究consul的接入文档和API, 完成了基于consul的开发和验证,上线了一个注册中心同步的服务,用于把zk注册中心和consul双向同步, 上线后很多服务开始报no active server的错误,最后排查下来发现我们线上的consul版本并不支持tag过滤的功能, 导致consul返回了在测试环境不会返回的服务实例信息, 最后导致反复触发服务上线下线事件, 进而引起了故障,最后把sync服务强制下线才解决; 这次事故还发现个问题是线上的prometheus会给所有thrift端口发送/metric http请求, 导致m2服务解析时直接内存溢出了, 需要重启服务才能解决.

这次事故我们吸取了深刻的教训, 由于没有深入了解Consul的原理, 导致解决问题花了较长时间,后面我们便把进度放慢, 先去熟悉Consul的技术架构, 深入Consul的源码才发现,Consul并不是AP架构, Consul的服务注册模型和KV模型都是基于Raft实现的强一致性,因此对于服务发现它是一个CP的架构, 而Consul内部Agent的发现和事件机制是基于Gossip流言协议实现的, 这个协议是最终一致性的,所以网上很多文章把Consul归类为AP架构, 这个是有问题的.

还有一个暴露出来的问题是运维用Consul来管理物理机,他们对可用性,一致性,性能这些指标并没有太多的要求, 因此业务和运维共用一套服务发现系统是有很大的风险的, 运维测试环境和生产环境安装的consul版本不一致就是如此, 因此基于一致性模型和数据共享的风险我们最终弃用了Consul.

注册