ZooKeeper 并不适合做注册中心
zookeeper 的 CP 模型不适合注册中心 zookeeper 是一个非常优秀的项目，非常成熟，被大量的团队使用，但对于服务发现来讲，zookeeper 真的是一个错误的方案。 在 CAP 模型中，zookeeper 是 CP，意味着面对网络分区时，为了保持一致性，他是不可用的。 因为 zookeeper 是一个分布式协调系统，如果使用最终一致性（AP）的话，将是一个糟糕的设计，他的核心算法是 Zab，所有设计都是为了一致性。 对于协调系统，这是非常正确的，但是对于服务发现，可用性是第一位的，例如发生了短暂的网络分区时，即使拿到的信息是有瑕疵的、旧的，也好过完全不可用。 zookeeper 为协调服务所做的一致性保障，用在服务发现场景是错误的。 注册中心本质上的功能就是一个查询函数： ServiceList = F(service-name) 以 service-name 为查询参数，得到对应的可用的服务端点列表 endpoints(ip:port) 。 我们假设不同的客户端得到的服务列表数据是 不一致的 ，看看有什么后果。 一个 serviceB 部署了 10 个实例，都注册到了注册中心。 现在有 2 个服务调用者 service1 和 service2，从注册中心获取 serviceB 的服务列表，但取得的数据不一致。 s1 = { ip1,ip2 ... ip9 }